From mmc at googlers.com Mon Dec 5 19:58:38 2011 From: mmc at googlers.com (Monica Chew) Date: Mon, 5 Dec 2011 10:58:38 -0800 Subject: [Mailman-Developers] feature request: one-click setting to preserve DKIM Message-ID: Hi, folks! I guess this is as good a time as any to introduce myself, since both Murray's MLM+DKIM RFC and the formation of a new web-ui group are relevant. For context, I work at Google on Gmail spam, and one of the things we've been doing as an anti-phishing measure is enforcing that mail from certain highly-phished domains must be signed with the DKIM key of the purported sender. We started this several years ago for just ebay and paypal ( http://gmailblog.blogspot.com/2008/07/fighting-phishing-with-ebay-and-paypal.html) and for the last couple of years have been trying to do it for google.comand a handful of other domains as well. A side effect of this has been that mailing-list mailing has been particularly difficult to classify. We've mostly solved the problem for groups that we host, but external mailing lists have been a continual challenge. As a result, many Google employees who want to participate in standards and open source communities have been unable to (see for example http://lists.openid.net/pipermail/openid-general/2009-June/018364.html, where both mail from Google and Facebook employees were not delivered to openid gmail members) with their standard mailing address. There are many ways to solve this problem, and I've been tackling two of them: groups that we host, and migrating corporate mail to use a different domain than service mail. However, it would be wonderful for MLMs to support list admins who care about this by having a one-click option to turn off the settings that break incoming DKIM signatures, namely subject tagging and unsubscribe footers. Terri and Florian, is this something that the webui group would be interested in working on? Thanks, Monica From terri at zone12.com Tue Dec 6 00:12:11 2011 From: terri at zone12.com (Terri Oda) Date: Mon, 05 Dec 2011 16:12:11 -0700 Subject: [Mailman-Developers] feature request: one-click setting to preserve DKIM In-Reply-To: References: Message-ID: <4EDD4FCB.8040906@zone12.com> On 11-12-05 11:58 AM, Monica Chew wrote: > Terri and Florian, is this something that the webui group would be > interested in working on? We have a significant complexity problem already in the admin interface. If this is really just a matter of two settings (subject tagging and unsubscribe footers) it would probably make more sense to add an appropriate FAQ entry / documentation rather than adding Yet Another Setting, especially since we'd have to deal smoothly with indicating the over-rides and I suspect there's a bonus possibility for confusion as a result. I'm not entirely convinced that this is a good way to solve the dkim problem for Mailman in the long-term, since I'm pretty sure a lot of users will balk at having the subject line tags removed, and many list owners will balk at having unsubscribe footers removed, so maybe it's best to look into the more complex re-signing solutions and not spend time encoding (and translating, and user-testing) a stop-gap measure into the interface. That said, we've talked a lot about having simplified interfaces for quick list administration and interfaces designed for specific purpose lists. It seems like this might fit in nicely with some of those ideas, so I'm definitely not adverse to keeping it in mind as an interface option if there's evidence that this would be useful to enough list owners. Terri From mmc at googlers.com Tue Dec 6 00:50:26 2011 From: mmc at googlers.com (Monica Chew) Date: Mon, 5 Dec 2011 15:50:26 -0800 Subject: [Mailman-Developers] feature request: one-click setting to preserve DKIM In-Reply-To: <4EDD4FCB.8040906@zone12.com> References: <4EDD4FCB.8040906@zone12.com> Message-ID: Hi Terri, Thanks for the response. We have a significant complexity problem already in the admin interface. > If this is really just a matter of two settings (subject tagging and > unsubscribe footers) it would probably make more sense to add an > appropriate FAQ entry / documentation rather than adding Yet Another > Setting, especially since we'd have to deal smoothly with indicating the > over-rides and I suspect there's a bonus possibility for confusion as a > result. > I am completely sympathetic to the too-many-settings problem. > I'm not entirely convinced that this is a good way to solve the dkim > problem for Mailman in the long-term, since I'm pretty sure a lot of users > will balk at having the subject line tags removed, and many list owners > will balk at having unsubscribe footers removed, so maybe it's best to look > into the more complex re-signing solutions and not spend time encoding (and > translating, and user-testing) a stop-gap measure into the interface. > Having worked in the DKIM-for-anti-phishing space for a couple of years, there is no good way to solve the DKIM problem in Mailman. As you point out, people are quite passionate about mailing list behavior. However, here's why re-signing is not ideal for anti-phishing purposes: anyone can generate a DKIM key and sign a any message using that key. Using DKIM for anti-phishing purposes requires that the signing domain be the same as the purported sender, otherwise, it's useless. Everything might as well be signed by evil.com :) It is much better if signatures don't break. The only things I can currently recommend to affected users are to switch domains (hence my goofy googlers.com alias), but not surprisingly many people are passionate about changing their email address, maybe even more passionate than about mailing list behavior. Another, hacky option that preserves list behavior for some members would be to ship a list of domains that have this strict DKIM policies, and then use this list to suppress DKIM breakages for members hosted at these domains. So, if someone wrote to a mailman list that included members at these domains, DKIM would not break for these members only. That would include gmail and Yahoo users, too ( http://ycorpblog.com/2007/10/04/say-goodbye-to-ebay-and-paypal-fraudsters/). Is this more palatable than adding a one-click setting? > That said, we've talked a lot about having simplified interfaces for quick > list administration and interfaces designed for specific purpose lists. It > seems like this might fit in nicely with some of those ideas, so I'm > definitely not adverse to keeping it in mind as an interface option if > there's evidence that this would be useful to enough list owners. What kind of data would be helpful here? Besides the problem of senders from highly-phished domains having trouble communicating to external lists, Gmail has also been ramping up the amount of UI warnings when the authenticated domain (either DKIM or SPF) does not match the payload From header for all messages: https://mail.google.com/support/bin/answer.py?answer=185812. These warnings basically appear for all mailman users who are also Gmail users. Thanks, Monica Terri > From barry at list.org Tue Dec 6 01:53:56 2011 From: barry at list.org (Barry Warsaw) Date: Mon, 5 Dec 2011 19:53:56 -0500 Subject: [Mailman-Developers] feature request: one-click setting to preserve DKIM In-Reply-To: References: <4EDD4FCB.8040906@zone12.com> Message-ID: <20111205195356.31cdd2f5@resist.wooz.org> On Dec 05, 2011, at 03:50 PM, Monica Chew wrote: >Having worked in the DKIM-for-anti-phishing space for a couple of years, >there is no good way to solve the DKIM problem in Mailman. I think this is the one big lesson from these discussions: DKIM is mostly incompatible with mailing lists. Where the two must be integrated, some usability will likely be compromised. >As you point out, people are quite passionate about mailing list >behavior. However, here's why re-signing is not ideal for anti-phishing >purposes: anyone can generate a DKIM key and sign a any message using that >key. Using DKIM for anti-phishing purposes requires that the signing domain >be the same as the purported sender, otherwise, it's useless. Everything >might as well be signed by evil.com :) It is much better if signatures don't >break. I'm no DKIM expert by far, but it seems to me that a mailing list message has enough clues that a DKIM verifier could do a better job at helping recipients make good choices. For example, all Mailman messages have a List-Id header that contains the domain name hosting the list server. With re-signing, why couldn't you verify the signature against the List-ID host instead of the original sender? >Another, hacky option that preserves list behavior for some members would >be to ship a list of domains that have this strict DKIM policies, and then >use this list to suppress DKIM breakages for members hosted at these >domains. So, if someone wrote to a mailman list that included members at >these domains, DKIM would not break for these members only. That would >include gmail and Yahoo users, too ( >http://ycorpblog.com/2007/10/04/say-goodbye-to-ebay-and-paypal-fraudsters/). >Is this more palatable than adding a one-click setting? For several reasons I don't think so. Keeping that list of sites updated will be a maintenance nightmare, and give the number of Mailman sites out there that are still running several years old versions, I think any approach depending on timely updates by site administrators will basically fail. It's also a bit scary to me from a performance standpoint to be loading up more personalized message processing at the sending-out-to-upstream-MTA phase. >> That said, we've talked a lot about having simplified interfaces for quick >> list administration and interfaces designed for specific purpose lists. It >> seems like this might fit in nicely with some of those ideas, so I'm >> definitely not adverse to keeping it in mind as an interface option if >> there's evidence that this would be useful to enough list owners. > >What kind of data would be helpful here? Besides the problem of senders >from highly-phished domains having trouble communicating to external lists, >Gmail has also been ramping up the amount of UI warnings when the >authenticated domain (either DKIM or SPF) does not match the payload From >header for all messages: >https://mail.google.com/support/bin/answer.py?answer=185812. These warnings >basically appear for all mailman users who are also Gmail users. Mailman 3 supports list-styles, which in theory are composable. Coming up with a good ui for that is a whole 'nuther issue, but the core could support something like this fairly easily. It still feels to me like a good solution to DKIM+mailing lists just hasn't been discovered yet. -Barry From mmc at googlers.com Tue Dec 6 02:12:24 2011 From: mmc at googlers.com (Monica Chew) Date: Mon, 5 Dec 2011 17:12:24 -0800 Subject: [Mailman-Developers] feature request: one-click setting to preserve DKIM In-Reply-To: <20111205195356.31cdd2f5@resist.wooz.org> References: <4EDD4FCB.8040906@zone12.com> <20111205195356.31cdd2f5@resist.wooz.org> Message-ID: > I'm no DKIM expert by far, but it seems to me that a mailing list message has > enough clues that a DKIM verifier could do a better job at helping recipients > make good choices. ?For example, all Mailman messages have a List-Id header > that contains the domain name hosting the list server. ?With re-signing, why > couldn't you verify the signature against the List-ID host instead of the > original sender? Sorry, I'm not being precise. DKIM is mostly agnostic about what is signed. The only header field it requires being signed is the From header. What Gmail is doing is requiring not only that DKIM verifies, but that the domain used for signing (d= in the DKIM header) matches the payload From. If we exempted signed mailing list mail from these anti-phishing checks, then the following attack is possible. DKIM-Signature: d=evil.com;h=list-id:date:from;b=.... From: noreply at paypal.com List-Id:?"A totally legitimate mailing list" For obvious reasons, this is not a loophole that we want. At the same time, we don't want senders from highly-phished domains not to be able to communicate with Gmail users through mailman. > >Another, hacky option that preserves list behavior for some members would > >be to ship a list of domains that have this strict DKIM policies, and then > >use this list to suppress DKIM breakages for members hosted at these > >domains. So, if someone wrote to a mailman list that included members at > >these domains, DKIM would not break for these members only. That would > >include gmail and Yahoo users, too ( > >http://ycorpblog.com/2007/10/04/say-goodbye-to-ebay-and-paypal-fraudsters/). > >Is this more palatable than adding a one-click setting? > > For several reasons I don't think so. ?Keeping that list of sites updated will > be a maintenance nightmare, and give the number of Mailman sites out there > that are still running several years old versions, I think any approach > depending on timely updates by site administrators will basically fail. ?It's > also a bit scary to me from a performance standpoint to be loading up more > personalized message processing at the sending-out-to-upstream-MTA phase. I understand your point about updates. I don't like this approach myself, but thought it might be more plausible than adding yet another setting that's exposed in the UI. > >> That said, we've talked a lot about having simplified interfaces for quick > >> list administration and interfaces designed for specific purpose lists. It > >> seems like this might fit in nicely with some of those ideas, so I'm > >> definitely not adverse to keeping it in mind as an interface option if > >> there's evidence that this would be useful to enough list owners. > > > >What kind of data would be helpful here? Besides the problem of senders > >from highly-phished domains having trouble communicating to external lists, > >Gmail has also been ramping up the amount of UI warnings when the > >authenticated domain (either DKIM or SPF) does not match the payload From > >header for all messages: > >https://mail.google.com/support/bin/answer.py?answer=185812. These warnings > >basically appear for all mailman users who are also Gmail users. > > Mailman 3 supports list-styles, which in theory are composable. ?Coming up > with a good ui for that is a whole 'nuther issue, but the core could support > something like this fairly easily. Could you elaborate more? I couldn't turn up documentation on this. If you mean sufficient hints in the headers to the MUA render subject tagging and unsubscribe footers unnecessary, then I agree. Thanks, Monica From msk at cloudmark.com Tue Dec 6 19:17:54 2011 From: msk at cloudmark.com (Murray S. Kucherawy) Date: Tue, 6 Dec 2011 10:17:54 -0800 Subject: [Mailman-Developers] feature request: one-click setting to preserve DKIM In-Reply-To: <20111205195356.31cdd2f5@resist.wooz.org> References: <4EDD4FCB.8040906@zone12.com> <20111205195356.31cdd2f5@resist.wooz.org> Message-ID: > -----Original Message----- > From: mailman-developers-bounces+msk=cloudmark.com at python.org [mailto:mailman-developers-bounces+msk=cloudmark.com at python.org] On Behalf Of Barry Warsaw > Sent: Monday, December 05, 2011 4:54 PM > To: Monica Chew > Cc: Terri Oda; mailman-developers at python.org > Subject: Re: [Mailman-Developers] feature request: one-click setting to preserve DKIM > > On Dec 05, 2011, at 03:50 PM, Monica Chew wrote: > >Having worked in the DKIM-for-anti-phishing space for a couple of > >years, there is no good way to solve the DKIM problem in Mailman. > > I think this is the one big lesson from these discussions: DKIM is > mostly incompatible with mailing lists. Where the two must be > integrated, some usability will likely be compromised. It depends on your expectations. If there's an expectation that the author's signature will/should/must persist through a mailing list, then I agree that they're largely incompatible. If on the other hand you intend for lists to re-sign mail and for receivers to evaluate the message based on the list signature rather than the author signature, then it's entirely workable. Of course, sometimes the author signature will indeed survive, and then you have two domains to evaluate instead of one. Bonus! As Monica points out, DKIM itself is oblivious to the context in which it's being used. > I'm no DKIM expert by far, but it seems to me that a mailing list > message has enough clues that a DKIM verifier could do a better job at > helping recipients make good choices. For example, all Mailman > messages have a List-Id header that contains the domain name hosting > the list server. With re-signing, why couldn't you verify the > signature against the List-ID host instead of the original sender? You could. The issue isn't that doing so is wrong or impossible. It's simply that those semantics aren't built into DKIM, largely because we have no evidence that that's a useful test. The ESP community has argued that third-party signatures (those different than the one in the From: field) shouldn't be valued any less than one that does match, for various reasons. That argument was apparently persuasive. ADSP, and a draft I'm advancing called ATPS, extend DKIM's semantics to do more than just say "domain X handled this message" (which is really all a valid DKIM signature tells you). They both attempt to say things based on whether the domain delivered as part of a valid DKIM signature matches some identifier in the message, like the domain in the From: or in the List-ID field. If Mailman (or an MUA, or a filter, or something) implements such checks and finds that it's operationally beneficial to end users do so, then it could publish that mechanism in an RFC or elsewhere, and people could start to use it. The resistance isn't that this is a bad idea, but just that there's no evidence to back it up that would justify its standardization. The trick, of course, is not just to do something like this, but to get MUA buy-in. That is, when a signature validates and it presents a domain name that matches some identifier, change the presentation of the message to show this in some meaningful way. And then make sure in doing so that you don't inadvertently discredit legitimate messages for which that's not true. -MSK From terri at zone12.com Tue Dec 6 20:36:27 2011 From: terri at zone12.com (Terri Oda) Date: Tue, 06 Dec 2011 12:36:27 -0700 Subject: [Mailman-Developers] feature request: one-click setting to preserve DKIM In-Reply-To: References: <4EDD4FCB.8040906@zone12.com> <20111205195356.31cdd2f5@resist.wooz.org> Message-ID: <4EDE6EBB.1000504@zone12.com> On 12/06/11 11:17, Murray S. Kucherawy wrote: > It depends on your expectations. If there's an expectation that the author's signature will/should/must persist through a mailing list, then I agree that they're largely incompatible. If on the other hand you intend for lists to re-sign mail and for receivers to evaluate the message based on the list signature rather than the author signature, then it's entirely workable. Of course, sometimes the author signature will indeed survive, and then you have two domains to evaluate instead of one. Bonus! There were a lot of "it depends" in your email, so maybe I've mis-read, but it sounds to me like the long-term path of least user/list admin hassle for Mailman probably is to just re-sign the messages. Except that there's no standard for third parties doing re-signing, and no one's sure how to interpret it if we do? As a developer, this sounds the makings of one of those life-sucking projects you shouldn't touch with a 10-foot pole unless you're getting paid to define and defend a standard. There's no guarantee that anything we choose to do will ever be considered correct, and it could wind up being a lot of arguing and wasted effort at a time when I think we're better off just getting mailman 3 out the door. Which is a pity, because this seems like a great opportunity for us to trailblaze and help correct a mistaken assumption in DKIM. Maybe the other developers are a lot more excited about that than I am and willing to take the risk of implementation, but maybe we should just keep an eye on the expansion of DKIM and revisit this issue after Mailman 3 is released? It sounds like our best option for the near future is to write up a nice little document describing the issue, Monica's fix for lists where DKIM is essential, and leave it at that as far as code goes until things move a bit closer to consensus on how DKIM should handle mailing lists long-term. As a bonus, a nice little document could also be usable with 2.1! If anyone needs wiki author permissions to do this, let me know. Terri From msk at cloudmark.com Tue Dec 6 20:54:01 2011 From: msk at cloudmark.com (Murray S. Kucherawy) Date: Tue, 6 Dec 2011 11:54:01 -0800 Subject: [Mailman-Developers] feature request: one-click setting to preserve DKIM In-Reply-To: <4EDE6EBB.1000504@zone12.com> References: <4EDD4FCB.8040906@zone12.com> <20111205195356.31cdd2f5@resist.wooz.org> <4EDE6EBB.1000504@zone12.com> Message-ID: > -----Original Message----- > From: mailman-developers-bounces+msk=cloudmark.com at python.org [mailto:mailman-developers-bounces+msk=cloudmark.com at python.org] On Behalf Of Terri Oda > Sent: Tuesday, December 06, 2011 11:36 AM > To: mailman-developers at python.org > Subject: Re: [Mailman-Developers] feature request: one-click setting to > preserve DKIM > > There were a lot of "it depends" in your email, so maybe I've mis-read, > but it sounds to me like the long-term path of least user/list admin > hassle for Mailman probably is to just re-sign the messages. Except > that there's no standard for third parties doing re-signing, and no > one's sure how to interpret it if we do? Right, except for the last bit. The common practice at the moment is to evaluate (the reputation of) any DKIM domain whose signatures survive transit. They are the only bits of the message guaranteed to be "true" in some way (except maybe the details of the last Received: field, because it's yours). In the case of author-signed mail transiting a list that re-signs, it's most likely I'll get the latter, but I might also get the former. This is basically what RFC6377 says. There is some automatic, intuitive desire to evaluate the message's author domain rather than the message's re-signer domain(s). That's why there's all this pressure to tweak MLMs and other components of the infrastructure to permit author domain signatures to survive to the ultimate recipient. DKIM doesn't require this, but intuition would really like it to be so. It's not really true that "it depends" permeates DKIM's definition. It's pretty clear what DKIM does and doesn't do. But there's a lot of need for stuff just outside the edges of what DKIM does. That's what's creating all this activity around MLMs, reputation, and other adjacent topics. > Which is a pity, because this seems like a great opportunity for us to > trailblaze and help correct a mistaken assumption in DKIM. Which assumption is that? -MSK From mark at msapiro.net Tue Dec 6 22:30:59 2011 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 06 Dec 2011 13:30:59 -0800 Subject: [Mailman-Developers] feature request: one-click setting to preserve DKIM In-Reply-To: References: Message-ID: <4EDE8993.2040709@msapiro.net> On 12/5/2011 10:58 AM, Monica Chew wrote: > For context, I work at Google on Gmail spam, and one of the things we've > been doing as an anti-phishing measure is enforcing that mail from certain > highly-phished domains must be signed with the DKIM key of the purported > sender. We started this several years ago for just ebay and paypal ( > http://gmailblog.blogspot.com/2008/07/fighting-phishing-with-ebay-and-paypal.html) > and for the last couple of years have been trying to do it for > google.comand a handful of other domains as well. > > A side effect of this has been that mailing-list mailing has been > particularly difficult to classify. We've mostly solved the problem for > groups that we host, but external mailing lists have been a continual > challenge. As a result, many Google employees who want to participate in > standards and open source communities have been unable to (see for example > http://lists.openid.net/pipermail/openid-general/2009-June/018364.html, > where both mail from Google and Facebook employees were not delivered to > openid gmail members) with their standard mailing address. It seems you could solve this particular problem by allowing gmail users an option (non-default) to receive such mail with a "phish" warning rather than not receiving it at all. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at list.org Tue Dec 6 23:15:05 2011 From: barry at list.org (Barry Warsaw) Date: Tue, 6 Dec 2011 17:15:05 -0500 Subject: [Mailman-Developers] feature request: one-click setting to preserve DKIM In-Reply-To: References: <4EDD4FCB.8040906@zone12.com> <20111205195356.31cdd2f5@resist.wooz.org> Message-ID: <20111206171505.0540ecd9@resist.wooz.org> On Dec 05, 2011, at 05:12 PM, Monica Chew wrote: >> Mailman 3 supports list-styles, which in theory are composable. ?Coming up >> with a good ui for that is a whole 'nuther issue, but the core could support >> something like this fairly easily. > >Could you elaborate more? I couldn't turn up documentation on this. If >you mean sufficient hints in the headers to the MUA render subject >tagging and unsubscribe footers unnecessary, then I agree. Hi Monica. I was really just talking about a way to make the setting of list configuration variables more user friendly. A "list style" is just a collection of settings that is applied to the list when it's created. A style could also in theory be applied to a list after it exists. Styles have names, so you could make one available to list owners called "make-dkim-not-break" or some such :). This is the current documentation on that feature: http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/view/head:/src/mailman/app/docs/styles.rst Cheers, -Barry From barry at list.org Tue Dec 6 23:27:08 2011 From: barry at list.org (Barry Warsaw) Date: Tue, 6 Dec 2011 17:27:08 -0500 Subject: [Mailman-Developers] feature request: one-click setting to preserve DKIM In-Reply-To: References: <4EDD4FCB.8040906@zone12.com> <20111205195356.31cdd2f5@resist.wooz.org> Message-ID: <20111206172708.57b3cadc@resist.wooz.org> On Dec 06, 2011, at 10:17 AM, Murray S. Kucherawy wrote: >> I think this is the one big lesson from these discussions: DKIM is >> mostly incompatible with mailing lists. Where the two must be >> integrated, some usability will likely be compromised. > >It depends on your expectations. If there's an expectation that the author's >signature will/should/must persist through a mailing list, then I agree that >they're largely incompatible. If on the other hand you intend for lists to >re-sign mail and for receivers to evaluate the message based on the list >signature rather than the author signature, then it's entirely workable. Of >course, sometimes the author signature will indeed survive, and then you have >two domains to evaluate instead of one. Bonus! My own personal feeling is that having lists re-sign messages is the best expectation to put forward. You're subscribed to a mailing list, so you trust that list much more than you trust the senders on that list. So having the mailing list site re-sign the outgoing messages seems to me to be best practice. My inclination is that removing the original author's signature first is not entirely inappropriate. Note too that Mailman supports anonymizing list traffic to the extent that it would wipe out the original From header. Some lists turn this on for a higher degree of privacy than you see on most open discussion lists. In that case, the From header would look like it's coming from the mailing list, and then it would make the most sense to remove any original signature and leave only the list's signature. It seems to me that relying on From header signing of mailing list messages just isn't that useful. >As Monica points out, DKIM itself is oblivious to the context in which it's >being used. > >> I'm no DKIM expert by far, but it seems to me that a mailing list >> message has enough clues that a DKIM verifier could do a better job at >> helping recipients make good choices. For example, all Mailman >> messages have a List-Id header that contains the domain name hosting >> the list server. With re-signing, why couldn't you verify the >> signature against the List-ID host instead of the original sender? > >You could. The issue isn't that doing so is wrong or impossible. It's >simply that those semantics aren't built into DKIM, largely because we have >no evidence that that's a useful test. > >The ESP community has argued that third-party signatures (those different >than the one in the From: field) shouldn't be valued any less than one that >does match, for various reasons. That argument was apparently persuasive. > >ADSP, and a draft I'm advancing called ATPS, extend DKIM's semantics to do >more than just say "domain X handled this message" (which is really all a >valid DKIM signature tells you). They both attempt to say things based on >whether the domain delivered as part of a valid DKIM signature matches some >identifier in the message, like the domain in the From: or in the List-ID >field. If Mailman (or an MUA, or a filter, or something) implements such >checks and finds that it's operationally beneficial to end users do so, then >it could publish that mechanism in an RFC or elsewhere, and people could >start to use it. The resistance isn't that this is a bad idea, but just that >there's no evidence to back it up that would justify its standardization. In that case, it would be interesting and feasible for you to perhaps line up some mailing list sites to enable this and gather some statistics. It would be pretty easy to do (I think) in Mailman 3 (though that's unreleased) and probably not hard to do in Mailman 2. >The trick, of course, is not just to do something like this, but to get MUA >buy-in. That is, when a signature validates and it presents a domain name >that matches some identifier, change the presentation of the message to show >this in some meaningful way. And then make sure in doing so that you don't >inadvertently discredit legitimate messages for which that's not true. Right. So, Gmail is probably the 800lb MUA gorilla here. Monica, do you have any thoughts on how you could run such an experiment and find out what is most useful to your users? Cheers, -Barry From barry at list.org Tue Dec 6 23:32:56 2011 From: barry at list.org (Barry Warsaw) Date: Tue, 6 Dec 2011 17:32:56 -0500 Subject: [Mailman-Developers] feature request: one-click setting to preserve DKIM In-Reply-To: <4EDE6EBB.1000504@zone12.com> References: <4EDD4FCB.8040906@zone12.com> <20111205195356.31cdd2f5@resist.wooz.org> <4EDE6EBB.1000504@zone12.com> Message-ID: <20111206173256.687b98b3@resist.wooz.org> On Dec 06, 2011, at 12:36 PM, Terri Oda wrote: >As a developer, this sounds the makings of one of those life-sucking projects >you shouldn't touch with a 10-foot pole unless you're getting paid to define >and defend a standard. There's no guarantee that anything we choose to do >will ever be considered correct, and it could wind up being a lot of arguing >and wasted effort at a time when I think we're better off just getting >mailman 3 out the door. I agree completely. (he says, still struggling with REST authentication/authorization :). >Which is a pity, because this seems like a great opportunity for us to >trailblaze and help correct a mistaken assumption in DKIM. Maybe the other >developers are a lot more excited about that than I am and willing to take >the risk of implementation, but maybe we should just keep an eye on the >expansion of DKIM and revisit this issue after Mailman 3 is released? What Mailman 3, and to some lesser extent MM2 can do today, is to provide a framework for experimentation, for those folks who are motivated to improve the current situation. Fortunately, I think MM3 has everything you'd need to do that. A team working on improving things should be able to distribute a plug-in that implemented their experiment for sites that wanted to participate. -Barry From f at state-of-mind.de Tue Dec 6 23:38:58 2011 From: f at state-of-mind.de (Florian Fuchs) Date: Tue, 06 Dec 2011 23:38:58 +0100 Subject: [Mailman-Developers] feature request: one-click setting to preserve DKIM In-Reply-To: <4EDD4FCB.8040906@zone12.com> Message-ID: <2c0d-4ede9980-b-7853eb80@240525030> Hi, > users will balk at having the subject line tags removed, and many list > owners will balk at having unsubscribe footers removed, Agreed. OTOH, if this were yet another setting, it would be the list owner's decision to use it or not. > That said, we've talked a lot about having simplified interfaces for > quick list administration and interfaces designed for specific purpose > lists. It seems like this might fit in nicely with some of those ideas, > so I'm definitely not adverse to keeping it in mind as an interface > option if there's evidence that this would be useful to enough list owners. I also think it's worth considering. For instance, those settings could be part of one or more "DKIM compatible" list templates. But even if we "bundle" this inside a template it will probably still cause a bit of confusion (how many people will know what the label 'DKIM compatible' means?). Another idea: We could still let the person installing the web-ui decide if they want to make those options available. Maybe by means of an additional django app that adds this functionality to the settings. Florian From mmc at googlers.com Wed Dec 7 00:39:52 2011 From: mmc at googlers.com (Monica Chew) Date: Tue, 6 Dec 2011 15:39:52 -0800 Subject: [Mailman-Developers] feature request: one-click setting to preserve DKIM In-Reply-To: <4EDE6EBB.1000504@zone12.com> References: <4EDD4FCB.8040906@zone12.com> <20111205195356.31cdd2f5@resist.wooz.org> <4EDE6EBB.1000504@zone12.com> Message-ID: Hi Terri, On Tue, Dec 6, 2011 at 11:36 AM, Terri Oda wrote: > There were a lot of "it depends" in your email, so maybe I've mis-read, but > it sounds to me like the long-term path of least user/list admin hassle for > Mailman probably is to just re-sign the messages. ?Except that there's no > standard for third parties doing re-signing, and no one's sure how to > interpret it if we do? I came up with something for groups that we host and would love to see another MLM implement it. It is a header that stores a copy the original authentication results as received by the MLM (or any forwarder, really) before destroying the signature. Respecting this header requires the expanded message to be re-signed by a trusted forwarder (easy in my case, since googlegroups.com uses its own DKIM key) -- so long as this header exists and is signed by a trusted forwarder, then on inbound we trust the original authentication results and don't care if the message is signed with a DKIM key that doesn't match the From. Maintaining the list of trusted forwarders then becomes a problem for receivers, but it's one that's a lot more manageable than today's situation because as Murray points out, many reputation systems have already been developed around DKIM. > As a developer, this sounds the makings of one of those life-sucking > projects you shouldn't touch with a 10-foot pole unless you're getting paid > to define and defend a standard. That is not out of the question. > It sounds like our best option for the near future is to write up a nice > little document describing the issue, Monica's fix for lists where DKIM is > essential, and leave it at that as far as code goes until things move a bit > closer to consensus on how DKIM should handle mailing lists long-term. ?As a > bonus, a nice little document could also be usable with 2.1! If anyone needs > wiki author permissions to do this, let me know. Would that go here? http://wiki.list.org/display/DOC/3+List+administrator+tasks I'm highly motivated to help :) Thanks, Monica From mmc at googlers.com Wed Dec 7 00:48:24 2011 From: mmc at googlers.com (Monica Chew) Date: Tue, 6 Dec 2011 15:48:24 -0800 Subject: [Mailman-Developers] feature request: one-click setting to preserve DKIM In-Reply-To: <4EDE8993.2040709@msapiro.net> References: <4EDE8993.2040709@msapiro.net> Message-ID: On Tue, Dec 6, 2011 at 1:30 PM, Mark Sapiro wrote: > On 12/5/2011 10:58 AM, Monica Chew wrote: > >> For context, I work at Google on Gmail spam, and one of the things we've >> been doing as an anti-phishing measure is enforcing that mail from certain >> highly-phished domains must be signed with the DKIM key of the purported >> sender. We started this several years ago for just ebay and paypal ( >> http://gmailblog.blogspot.com/2008/07/fighting-phishing-with-ebay-and-paypal.html) >> and for the last couple of years have been trying to do it for >> google.comand a handful of other domains as well. >> >> A side effect of this has been that mailing-list mailing has been >> particularly difficult to classify. We've mostly solved the problem for >> groups that we host, but external mailing lists have been a continual >> challenge. As a result, many Google employees who want to participate in >> standards and open source communities have been unable to (see for example >> http://lists.openid.net/pipermail/openid-general/2009-June/018364.html, >> where both mail from Google and Facebook employees were not delivered to >> openid gmail members) with their standard mailing address. > > > It seems you could solve this particular problem by allowing gmail users > an option (non-default) to receive such mail with a "phish" warning > rather than not receiving it at all. Ah, yes, the old trick of relying on users to correctly identify phish :) Unfortunately this rarely works well in practice. If the email looks good (e.g., the spammer just copies a legitimate message and replaces the login link with a phishing site) then most people typically don't notice that the URL is a phishing site. Some users even dig these out of their spam folder, even though the message has a big red banner at the top. In any case, a non-default setting is not going to solve the problem of senders from highly-phished domains to communicate with gmail and yahoo users through mailman. How would the list members even know to change this setting? Thanks, Monica From mmc at googlers.com Wed Dec 7 00:58:00 2011 From: mmc at googlers.com (Monica Chew) Date: Tue, 6 Dec 2011 15:58:00 -0800 Subject: [Mailman-Developers] feature request: one-click setting to preserve DKIM In-Reply-To: <20111206172708.57b3cadc@resist.wooz.org> References: <4EDD4FCB.8040906@zone12.com> <20111205195356.31cdd2f5@resist.wooz.org> <20111206172708.57b3cadc@resist.wooz.org> Message-ID: > My own personal feeling is that having lists re-sign messages is the best > expectation to put forward. ?You're subscribed to a mailing list, so you trust > that list much more than you trust the senders on that list. ?So having the > mailing list site re-sign the outgoing messages seems to me to be best > practice. ?My inclination is that removing the original author's signature > first is not entirely inappropriate. This is why Google Groups removes incoming DKIM signatures and re-signs, because chances that the original signature survives are vanishingly small given most people's list settings. > Note too that Mailman supports anonymizing list traffic to the extent that it > would wipe out the original From header. ?Some lists turn this on for a higher > degree of privacy than you see on most open discussion lists. ?In that case, > the From header would look like it's coming from the mailing list, and then it > would make the most sense to remove any original signature and leave only the > list's signature. If From is wiped out, great! Problem solved, at least for me. >>The trick, of course, is not just to do something like this, but to get MUA >>buy-in. ?That is, when a signature validates and it presents a domain name >>that matches some identifier, change the presentation of the message to show >>this in some meaningful way. ?And then make sure in doing so that you don't >>inadvertently discredit legitimate messages for which that's not true. > > Right. ?So, Gmail is probably the 800lb MUA gorilla here. ?Monica, do you have > any thoughts on how you could run such an experiment and find out what is most > useful to your users? In a sense we are already experimenting here. For example, this year there are new UI warnings when the payload From says gmail, but the message is not signed by Gmail (https://mail.google.com/support/bin/answer.py?answer=185812).[1] This either appears as a "this message was sent via " informational bar or more serious warning, "this message may not have been sent by foo at gmail.com", if the message doesn't authenticate at all. Needless to say this is affecting lots of list traffic, and many people don't like it: http://snowulf.com/2011/06/29/gmail-thinks-this-message-may-not-have-been-sent-by-you/ http://www.yellowjug.com/how-to/gmail-phishing-alert-mailman-mailing-lists-spf-record/ http://www.drake.org.uk/2011/06/googles-new-gmail-phishing-detection-system-hates-mailman/ The pipe-dream fix for this, at least as far as mailing lists go, is to do better mailing list detection on the recipient side and maintain a list of lists that the user belongs to for suppressing warnings. We can't just ignore all mail that has a List-Id, though, because that's much too easy to forge. Thanks, Monica [1] Why are we doing this? Well, it turns out that account hijacking has been a huge problem in the last couple of years, and along with theft of contact information phishing scams have gotten more sophisticated, appearing to come from people that you know. Since Gmail signs all outbound mail adding warnings was one easy way to warn users when they get mail from someone pretending to be their contact but not actually coming from Gmail. From mark at msapiro.net Wed Dec 7 01:18:17 2011 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 6 Dec 2011 16:18:17 -0800 Subject: [Mailman-Developers] feature request: one-click setting topreserve DKIM In-Reply-To: Message-ID: Monica Chew wrote: > >In any case, a non-default setting is not going to solve the problem >of senders from highly-phished domains to communicate with gmail and >yahoo users through mailman. How would the list members even know to >change this setting? The same way they now know that they aren't seeing this mail. The same way they ultimatly figure out that they never receive copies of their own posts to the list. BTW, you may be interested in the 3rd paragraph of the answer at . -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From mark at msapiro.net Wed Dec 7 01:23:33 2011 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 6 Dec 2011 16:23:33 -0800 Subject: [Mailman-Developers] feature request: one-click setting topreserve DKIM In-Reply-To: Message-ID: Monica Chew wrote: > >This is why Google Groups removes incoming DKIM signatures and >re-signs, because chances that the original signature survives are >vanishingly small given most people's list settings. And it is fairly simple to configure a Mailman installation to do the same, but this won't satisfy you unless the list is also anonymous. What do you say to some other service that applies the same policies as Gmail when they complain their users don't receive Google Groups mail from some senders? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From mmc at googlers.com Wed Dec 7 01:29:35 2011 From: mmc at googlers.com (Monica Chew) Date: Tue, 6 Dec 2011 16:29:35 -0800 Subject: [Mailman-Developers] feature request: one-click setting topreserve DKIM In-Reply-To: References: Message-ID: On Tue, Dec 6, 2011 at 4:23 PM, Mark Sapiro wrote: > Monica Chew wrote: >> >>This is why Google Groups removes incoming DKIM signatures and >>re-signs, because chances that the original signature survives are >>vanishingly small given most people's list settings. > > > And it is fairly simple to configure a Mailman installation to do the > same, but this won't satisfy you unless the list is also anonymous. > > What do you say to some other service that applies the same policies as > Gmail when they complain their users don't receive Google Groups mail > from some senders? I would say the same thing (switch domains), although I do not get complaints from Yahoo users that their openid messages are not appearing from Paypal senders, since I don't work for Yahoo. Yahoo is applying the same DKIM policies as Gmail for Paypal, so I assume it is also a problem for them. Thanks, Monica > -- > Mark Sapiro ? ? ? ?The highway is for gamblers, > San Francisco Bay Area, California ? ?better use your sense - B. Dylan > From stephen at xemacs.org Wed Dec 7 05:45:23 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 07 Dec 2011 13:45:23 +0900 Subject: [Mailman-Developers] feature request: one-click setting to preserve DKIM In-Reply-To: <20111206172708.57b3cadc@resist.wooz.org> References: <4EDD4FCB.8040906@zone12.com> <20111205195356.31cdd2f5@resist.wooz.org> <20111206172708.57b3cadc@resist.wooz.org> Message-ID: <87obvl0z30.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > My own personal feeling is that having lists re-sign messages is the best > expectation to put forward. You're subscribed to a mailing list, so you trust > that list much more than you trust the senders on that list. But as Monica points out, sometimes you need to evaluate whether you trust the sender, because otherwise you need to trust *all* of the list's competence to evaluate senders, congruence of the list's trust policy with your own, *and* the honesty of the list's host adminstrators. > So having the mailing list site re-sign the outgoing messages seems > to me to be best practice. My inclination is that removing the > original author's signature first is not entirely inappropriate. But that doesn't work in the case in point, unless you also change the from field to reflect the list's domain. What do these DKIM-strict domains do with digests? Do they actually check the content (ie, individual messages) for source domain and verify their DKIM signatures? If not, just have those people who aren't getting messages turn on digest mode with maximum frequency. :-) Of course, all the phishers out there are reading this message, and will shortly be using this technique to phish gmail users, so you'll have to extend DKIM checks to the content of digests and forwards.... What really ought to be done is to format secured messages as multipart, and sign the overall header "From" and individual parts (perhaps identified by some kind of content ID). Then have the *MUA* (not the MTA!) check for alleged sender, and for highly-phishable alleged senders display *only* authenticated portions (plus maybe buttons to see unauthenticated content at user option). Dream on, Steve ... From mmc at googlers.com Thu Dec 8 23:42:21 2011 From: mmc at googlers.com (Monica Chew) Date: Thu, 8 Dec 2011 14:42:21 -0800 Subject: [Mailman-Developers] feature request: one-click setting to preserve DKIM In-Reply-To: <87obvl0z30.fsf@uwakimon.sk.tsukuba.ac.jp> References: <4EDD4FCB.8040906@zone12.com> <20111205195356.31cdd2f5@resist.wooz.org> <20111206172708.57b3cadc@resist.wooz.org> <87obvl0z30.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: On Tue, Dec 6, 2011 at 8:45 PM, Stephen J. Turnbull wrote: > What do these DKIM-strict domains do with digests? ?Do they actually > check the content (ie, individual messages) for source domain and > verify their DKIM signatures? Typically the digest appears to come from the list, so that's ok. There's no way to verify the contents with DKIM anyway at that point, anyway. > If not, just have those people who aren't getting messages turn on > digest mode with maximum frequency. :-) :) I'm not too worried about digests. They tend to look pretty different from the average phish, even when they only contain one message. > Of course, all the phishers out there are reading this message, and > will shortly be using this technique to phish gmail users, so you'll > have to extend DKIM checks to the content of digests and forwards.... > > What really ought to be done is to format secured messages as > multipart, and sign the overall header "From" and individual parts > (perhaps identified by some kind of content ID). ?Then have the *MUA* > (not the MTA!) check for alleged sender, and for highly-phishable > alleged senders display *only* authenticated portions (plus maybe > buttons to see unauthenticated content at user option). Yeah, unfortunately pushing this problem to the MUA introduces nearly as many problems as it solves. At the MTA we can't really know what the MUA is going to display (even in Gmail's case, because some people fetch their mail and view with another client) so the only safe thing to do is to make sure that all of it verifies. Thanks, Monica From p at state-of-mind.de Fri Dec 16 06:20:02 2011 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Fri, 16 Dec 2011 06:20:02 +0100 Subject: [Mailman-Developers] [internet-drafts@ietf.org: [EAI] I-D Action: draft-ietf-eai-mailinglistbis-01.txt] Message-ID: <20111216052002.GA3835@state-of-mind.de> FYI ----- Forwarded message from internet-drafts at ietf.org ----- Date: Thu, 15 Dec 2011 15:33:54 -0800 From: internet-drafts at ietf.org To: i-d-announce at ietf.org Cc: ima at ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-mailinglistbis-01.txt Authentication-Results: mail.state-of-mind.de (amavisd-new); dkim=pass header.i=@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Mailing Lists and UTF-8 Addresses Author(s) : John Levine Randall Gellens Filename : draft-ietf-eai-mailinglistbis-01.txt Pages : 8 Date : 2011-12-15 This document describes considerations for mailing lists with the introduction of internationalized email addresses. It outlines some possible scenarios for handling lists with mixtures of internationalized and traditional addresses, but does not offer implementation or deployment advice. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-mailinglistbis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-eai-mailinglistbis-01.txt _______________________________________________ IMA mailing list IMA at ietf.org https://www.ietf.org/mailman/listinfo/ima ----- End forwarded message ----- -- state of mind () http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 3090 4664 81669 M?nchen Telefax +49 89 3090 4666 Amtsgericht M?nchen Partnerschaftsregister PR 563 From pankajxdx at gmail.com Sun Dec 18 19:01:27 2011 From: pankajxdx at gmail.com (Panks) Date: Sun, 18 Dec 2011 23:31:27 +0530 Subject: [Mailman-Developers] MM 3.0 build error Message-ID: Hello everyone, This is Pankaj, I have decent knowledge of C++ and a little bit of practice in python (I did some projects in python), I am new to Mailman and I am interested in contributing to it. Today I downloaded the source of MM 3.0 from launchpad and saw few bugs, I installed apache and got it running and installed Exim too, but while running _bootstrap.py_ from MM source directory, I'm getting this output in terminal: Traceback (most recent call last): File "bootstrap.py", line 163, in options.setup_source).read().replace('\r\n', '\n') File "/usr/lib/python2.7/urllib2.py", line 126, in urlopen return _opener.open(url, data, timeout) File "/usr/lib/python2.7/urllib2.py", line 394, in open response = self._open(req, data) File "/usr/lib/python2.7/urllib2.py", line 412, in _open '_open', req) File "/usr/lib/python2.7/urllib2.py", line 372, in _call_chain result = func(*args) File "/usr/lib/python2.7/urllib2.py", line 1201, in http_open return self.do_open(httplib.HTTPConnection, req) File "/usr/lib/python2.7/urllib2.py", line 1140, in do_open h = http_class(host, timeout=req.timeout) # will parse host:port File "/usr/lib/python2.7/httplib.py", line 693, in __init__ self._set_hostport(host, port) File "/usr/lib/python2.7/httplib.py", line 718, in _set_hostport raise InvalidURL("nonnumeric port: '%s'" % host[i+1:]) httplib.InvalidURL: nonnumeric port: '' Can someone please help me with this. *-- Panks* From barry at list.org Mon Dec 19 17:30:09 2011 From: barry at list.org (Barry Warsaw) Date: Mon, 19 Dec 2011 11:30:09 -0500 Subject: [Mailman-Developers] MM 3.0 build error In-Reply-To: References: Message-ID: <20111219113009.27f5f22d@resist.wooz.org> Hi Pankaj, Thanks for downloading MM3 and giving it a try. Please note that the bzr branch is a little more up-to-date, and I'll be working over the xmas break to integrate authentication into the REST API. Once that's done, look for the first beta early in 2012. On Dec 18, 2011, at 11:31 PM, Panks wrote: >Hello everyone, >This is Pankaj, I have decent knowledge of C++ and a little bit >of practice in python (I did some projects in python), I am new to Mailman >and I am interested in contributing to it. Today I downloaded the source of >MM 3.0 from launchpad and saw few bugs, I installed apache and got it >running and installed Exim too, but while running _bootstrap.py_ from MM >source directory, I'm getting this output in terminal: We don't have official Exim integration yet. We really need an Exim expert to help us with the integration point, although given that (I believe) Exim supports LMTP, it might be pretty easy. We use LMTP to inject messages into MM3 from Postfix, and of course SMTP to inject messages into the MTA from MM3. >Traceback (most recent call last): > File "bootstrap.py", line 163, in > options.setup_source).read().replace('\r\n', '\n') > File "/usr/lib/python2.7/urllib2.py", line 126, in urlopen > return _opener.open(url, data, timeout) > File "/usr/lib/python2.7/urllib2.py", line 394, in open > response = self._open(req, data) > File "/usr/lib/python2.7/urllib2.py", line 412, in _open > '_open', req) > File "/usr/lib/python2.7/urllib2.py", line 372, in _call_chain > result = func(*args) > File "/usr/lib/python2.7/urllib2.py", line 1201, in http_open > return self.do_open(httplib.HTTPConnection, req) > File "/usr/lib/python2.7/urllib2.py", line 1140, in do_open > h = http_class(host, timeout=req.timeout) # will parse host:port > File "/usr/lib/python2.7/httplib.py", line 693, in __init__ > self._set_hostport(host, port) > File "/usr/lib/python2.7/httplib.py", line 718, in _set_hostport > raise InvalidURL("nonnumeric port: '%s'" % host[i+1:]) >httplib.InvalidURL: nonnumeric port: '' Can you describe the exact steps you took to do the build? What OS are you using? It looks like you're using Python 2.7, which should be fine, but is that your distro's version of Python or a from-source build? Have you set up a mailman.cfg configuration file, and if so, please include its contents. Cheers, -Barry From pankajxdx at gmail.com Mon Dec 19 23:15:17 2011 From: pankajxdx at gmail.com (Panks) Date: Tue, 20 Dec 2011 03:45:17 +0530 Subject: [Mailman-Developers] MM 3.0 build error In-Reply-To: <20111219113009.27f5f22d@resist.wooz.org> References: <20111219113009.27f5f22d@resist.wooz.org> Message-ID: On Mon, Dec 19, 2011 at 10:00 PM, Barry Warsaw wrote: > Hi Pankaj, > > Thanks for downloading MM3 and giving it a try. Please note that the bzr > branch is a little more up-to-date, and I'll be working over the xmas > break to > integrate authentication into the REST API. Once that's done, look for the > first beta early in 2012. > > On Dec 18, 2011, at 11:31 PM, Panks wrote: > > >Hello everyone, > >This is Pankaj, I have decent knowledge of C++ and a little bit > >of practice in python (I did some projects in python), I am new to Mailman > >and I am interested in contributing to it. Today I downloaded the source > of > >MM 3.0 from launchpad and saw few bugs, I installed apache and got it > >running and installed Exim too, but while running _bootstrap.py_ from MM > >source directory, I'm getting this output in terminal: > > We don't have official Exim integration yet. We really need an Exim > expert to > help us with the integration point, although given that (I believe) Exim > supports LMTP, it might be pretty easy. We use LMTP to inject messages > into > MM3 from Postfix, and of course SMTP to inject messages into the MTA from > MM3. > > >Traceback (most recent call last): > > File "bootstrap.py", line 163, in > > options.setup_source).read().replace('\r\n', '\n') > > File "/usr/lib/python2.7/urllib2.py", line 126, in urlopen > > return _opener.open(url, data, timeout) > > File "/usr/lib/python2.7/urllib2.py", line 394, in open > > response = self._open(req, data) > > File "/usr/lib/python2.7/urllib2.py", line 412, in _open > > '_open', req) > > File "/usr/lib/python2.7/urllib2.py", line 372, in _call_chain > > result = func(*args) > > File "/usr/lib/python2.7/urllib2.py", line 1201, in http_open > > return self.do_open(httplib.HTTPConnection, req) > > File "/usr/lib/python2.7/urllib2.py", line 1140, in do_open > > h = http_class(host, timeout=req.timeout) # will parse host:port > > File "/usr/lib/python2.7/httplib.py", line 693, in __init__ > > self._set_hostport(host, port) > > File "/usr/lib/python2.7/httplib.py", line 718, in _set_hostport > > raise InvalidURL("nonnumeric port: '%s'" % host[i+1:]) > >httplib.InvalidURL: nonnumeric port: '' > > Can you describe the exact steps you took to do the build? What OS are you > using? It looks like you're using Python 2.7, which should be fine, but is > that your distro's version of Python or a from-source build? Have you set > up > a mailman.cfg configuration file, and if so, please include its contents. > > Cheers, > -Barry > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://wiki.list.org/x/AgA3 > Searchable Archives: > http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: > http://mail.python.org/mailman/options/mailman-developers/pankajxdx%40gmail.com > > Security Policy: http://wiki.list.org/x/QIA9 > That was a just small silly mistake from my side. Anyway, thank you. So, I was able to build and install MM 3.0 successfully. But I want to know how should I go forward with making changes in code. I mean, do it need to re-install it from source to check the results, every time i make some changes in the code or is there any other way out. * * *Pankaj* *UG Student | **Dept. of Computer Science and Engineering* *IIT Madras, Chennai, India* * * From pankajxdx at gmail.com Tue Dec 20 00:12:13 2011 From: pankajxdx at gmail.com (Panks) Date: Tue, 20 Dec 2011 04:42:13 +0530 Subject: [Mailman-Developers] MM 3.0 build error In-Reply-To: References: <20111219113009.27f5f22d@resist.wooz.org> Message-ID: * * On Tue, Dec 20, 2011 at 3:45 AM, Panks wrote: > > > That was a just small silly mistake from my side. > Anyway, thank you. > So, I was able to build and install MM 3.0 successfully. > But I want to know how should I go forward with making changes in code. I > mean, do it need to re-install it from source to check the results, every > time i make some changes in the code or is there any other way out. > * > > * > *Pankaj* > *UG Student | **Dept. of Computer Science and Engineering* > *IIT Madras, Chennai, India* > * > * > Basically I wanted to ask if I can use any IDE for for debugging, which can make it easier to debug and test changes. * Pankaj* *UG Student | **Dept. of Computer Science and Engineering* *IIT Madras, Chennai, India* From mark at msapiro.net Tue Dec 20 01:26:13 2011 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 19 Dec 2011 16:26:13 -0800 Subject: [Mailman-Developers] MM 3.0 build error In-Reply-To: Message-ID: Panks wrote: >* >On Tue, Dec 20, 2011 at 3:45 AM, Panks wrote: >> >> But I want to know how should I go forward with making changes in code. I >> mean, do it need to re-install it from source to check the results, every >> time i make some changes in the code or is there any other way out. > >Basically I wanted to ask if I can use any IDE for for debugging, which can >make it easier to debug and test changes. You should be able to use any tools at your disposal to modify the installed Mailman, but ultimately, any changes you make should be applicable to the distributed source. One way of working would be to develop and test your changes against your installed Mailman, but ultimately make them against your copy of the bzr branch. Then, if you want your changes to make their way back to the trunk, you can propose a merge of your branch. Even if the changes are only for your own use, you can update your branch by merging updates from the trunk and then rebuild your installation. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From p at state-of-mind.de Sat Dec 24 07:54:17 2011 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Sat, 24 Dec 2011 07:54:17 +0100 Subject: [Mailman-Developers] Header cleanup/unnoticed header Message-ID: <20111224065417.GA10435@state-of-mind.de> Given our recent discussions on header cleanup for MM3 I noted another x-header that went unnoticed: x-mas: Sat, 24 Dec 2011 07:43:57 +0100 Should we standardize that too? ;) p at rick -- state of mind () http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 3090 4664 81669 M?nchen Telefax +49 89 3090 4666 Amtsgericht M?nchen Partnerschaftsregister PR 563