Yes, these are options and they should be off. It is important when you introduce options, you do not change past behavior automatically.
1) may not be necessary, if mailman recognizes the bounce message as in section http://tools.ietf.org/html/draft-kucherawy-dmarc-base-00#section-15.8 eg "550 5.7.1 Email rejected per DMARC policy for example.com" and does not increase the unsubscribe/bounce counter for the receiving email address. I suppose MM3 bounce processing is better than with MM2, so this may be already addressed. Some people have requested this feature, so it is fair to include it, rather than them having to tweak the associated MTA (which some do not have control). 2) mailman has one option: reply to poster or reply to list. I think the first one is default, but as mentioned, many list admins, enable reply to list. I won't enter in the details, but my experience is that reply to list increases participation with less technically savvy people and I read why people should not do that (but they do)... Anyhow, the option is there, so I prefer not to choose on the behalf of the List Admin, and it is best to not change this setting when the list Admins enables 2) If the From: contains the posting email of the mailing list, one would think that the default becomes reply to the list, but this is where Reply-To: can be used. If the list is set to reply to poster, the email address of the poster is added to the reply-to header If the list is set to reply to the list, then the email address of the list plus the email address of the poster is added to the reply-to header. The RFC allows as many email addresses there as needed. So if no reply-to header is present, otherwise the correct email addresses are added to the list. When you click the reply button in your MUA, you achieve same results when option 2) is on or off. Reply to all button, behaves the same in all cases. So no munging is done, unless the List is already set for munging and the reply to will contain the original author of the email retransmitted by MM3. 3) This draft has been on the table for a while, as Murray points, one large mailbox provider uses it in a proprietary way, but similar to what is in Murray's draft. So there is experience, and as far as I know they still do not think it is a bad idea. Nevertheless, I think mailman should not do the email authentication part, but be able to recognize "true" authentication-result headers coming from the MTA mailman uses and be able to rewrite them as an OAR. This keep the logic simple, and should be enabled if the MTA can control Authentication-Results headers and remove spoofed ones. Personally I think 3) is more complicated than 2) to put in place correctly as it requires tight configuration between MM3 and the MTA. I hope this helps alleviate concerns. PS: Stephen, Murray does not work for Google, and therefore cannot change the way gmail works. What you describe is a gmail "feature". ----- Original Message ----- From: "Stephen J. Turnbull" <[email protected]> To: "Murray S. Kucherawy" <[email protected]> Cc: "Mailman Developers" <[email protected]> Sent: Sunday, July 7, 2013 7:56:15 AM Subject: Re: [Mailman-Developers] Adding DMARC support for Mailman 3 Murray S. Kucherawy <[email protected]> writes: Hey, I've been trying to find the superuser at Gmail, and it turns out I've known him all along! Would you please fix the breakage where copies of one's posts aren't delivered to yourself, which is a real PITA when trying to diagnose Gmail problems?<wink/> (BTW, did you try to sign up as root? or Administrator? ;-) > I'm all for experimentation and being adaptive as new things come along, > and I'm obviously supportive of the DMARC effort. That said, I hope that > these are going to be configurable options, defaulted "off" for backward > compatibility. I second your concerns in principle, but I don't think you need to worry about these features being anything but optional. I suspect that a majority of our user don't actually have the fine control over their DNS needed to implement DMARC. > (a) the second bullet above is a significant departure from current > use Violating the RFC by munging From (for heaven's sake! have we learned nothing from the sad history of Reply-To munging?) is simply not acceptable for most purposes, although perfectly acceptable for advertising. ;-) _______________________________________________ Mailman-Developers mailing list [email protected] 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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
