On Sun, 2014-05-25 at 11:24 +0200, Alessandro Vesely wrote: > On Sun 25/May/2014 02:55:45 +0200 Sam Varshavchik wrote: > > Lindsay Haisley writes: > >> On Sat, 2014-05-24 at 09:00 -0400, Sam Varshavchik wrote: > >>> [email protected] writes: > >>> > >>>> With the recent DMARC implementation from AOL and Yahoo I > >>>> have a very broken mailing list. Is there any way using MLM > >>>> to rewrite the From: line to the list address and the > >>>> Reply-To: line to the actual sender? > >>> > >>> Reply-Tos should go back to the mailing list, not the sender. > >> > >> This isn't an appropriate choice for most lists, which are > >> configured for reply-to-sender. Munging the Reply-To header for > >> this purpose is a broken way of dealing with the problem. > > > > I hear that often; but it does not add up for me. The whole purpose > > of a discussion-oriented mailing list is to hold public discussions > > on various topics; and I'd expect the replies to go back to the > > list too. > > Nowadays most client have a distinguished reply-to-list button. > Reply-To could be left to authors for messages that are slightly > off-topic, or cross-posted, so as to direct replies appropriately.
If a post's author publishes a Reply-To address on a list post then IMHO it's the responsibility of the list to promulgate this address. Munging the Reply-To address to change it to the list's address destroys this information which may, or may not be important. And yes, most MUAs these days can detect a list posting and offer the user appropriate choices. If Reply-To gets munged, then this choice is gone. > >>> In the .courier-list file you could put something that adds or > >>> replaces the Reply-To: header. Then, use the headerdel and > >>> headeradd configuration settings, as documented in the > >>> couriermlm man page, to remove the existing From: header, and > >>> replace it with a new one. > >>> > >>> But, after doing that, you'll probably discover that it doesn't > >>> work, for some reason, or something else is broken. > >> > >> Sam, would you please disambiguate this. What else would break? > >> Why would it not work. > > > > Anyone's guess. SPF and Dmarc are hacks. And I say that even though > > I use SPF. I wouldn't be surprised to hear that someone's also > > checking the Reply-To addresses, so those will bounce too. > > That would be a really freaky behavior, inconsistent with both DMARC > and SMTP. And probably a violation of RFC 2822 and others as well. > An alternative solution is to replace: > > From: John Doe <[email protected]> > > with: > > From: List <[email protected]>, John Doe <[email protected]> The Mailman list server has the capability of replacing the From header address with an address of the form "Username -- via Listname <[email protected]>" and doing this _only_ for From addresses which publish DMARC p=reject. Putting a full email address in the address comment can be problematic. > I didn't try it myself, as I currently run no list. That was > suggested by John Levine on the IETF discussion list. The added List > address is needed for those few DMARC implementations that discard > invalid domains; reply-to-author needs manual adjustment anyway. > > >>> The correct fix is to tell your Yahoo and AOL subscribers to > >>> switch providers. > >> > >> Telling Yahoo and AOL subscribers to change ESPs is NOT a > >> solution, nor is it an option for many working mailing lists. > >> Actually getting Yahoo and AOL, and other ESPs which honor it, to > >> fix their broken DMARC p=reject implementation _would_ be a > >> solution. > > DMARC says a receiver should whitelist forwarders an mailing lists, > but fails to suggest a practical method for doing so. Given the nature of SMTP design, this isn't possible since the recipients of an email must be accepted or rejected _before_ the body content, containing the From header, is received. If a message has multiple recipients on a server then it's impossible for a mail server to bounce a post without first accepting it. Courier has the same issue with content filters, which is the reason for the "you are whitelisted by this recipient" (or similar) message one gets sometimes when an email has multiple recipients on the same server running the Courier MTA. The server can't logically deal with the situation other than by rejecting the entire email based on the fact that some recipients may have content filtering in place and some don't. Yes, a server could accept a post and then issue selective DSNs based on individual recipients, but this involves a whole other level of complexity and overhead and is probably impractical. > >> The DMARC problem implies information loss, contrary to the > >> spirit and in some cases the letter of applicable mail RFCs. > >> When and how this information loss occurs is up to ML software > >> designers and list administrators. > > No, DMARC policy provides for "reject" or "quarantine". Perhaps > you're confusing with ADSP, which provided for "all" and > "discardable"? Let me recall ADSP was demoted to historical. If an ESP honors a DMARC p=reject policy then an email which fails DMARC alignment is bounced as if the recipient address is invalid. This is based on the published _author_ of the email (not the _sender_!). Any workaround for this other than MIME encapsulation involves munging header information, hence information loss. > > I haven't looked much at Dmarc, but I'd expect that a reasonable > > implementation of Dmarc should take an analogous approach, to > > accomodate mailing list traffic. The onus on supporting Dmarc > > should fall on the end-recipient, not a mailing list intermediary. > > If someone's usage of Dmarc gets them bounced off a mailing list, > > it's their problem, not the mailing list's. In an ideal world, this is would be true. In practical terms, it's problematic and impractical. This is, IMHO, just another manifestation of the ability and the willingness of the Big Guys to run roughshod over network neutrality. -- Lindsay Haisley | "Never expect the people who caused a problem FMP Computer Services | to solve it." - Albert Einstein 512-259-1190 | http://www.fmp.com | ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
