On Saturday, May 31, 2014 1:44 AM [GMT+1=CET], Hector Santos wrote: > On 5/30/2014 5:49 PM, J. Gomez wrote: > > > > Ah, but "just like" is a complete misstatement of the situation. > > > There's a big difference. Users on a mailing list think of the > > > poster, not the mailing list, as responsible for the content. So > > > according to RFC 5322, the poster's mailbox belongs in From:. > > > Remailed or not, the author belongs there. > > > > That is debatable. As long as the mailing list program tampers with > > the message's content, rendering its DKIM signature invalid, it can > > be argued that the mailing list program is rewriting the message's > > content, and therefore that the mailing list program now becomes > > "the system responsible for the writing of the message" (as per RFC > > 5322 parlance, section 3.6.2), and thus the mailing list address > > would earn its legitimate place in the Header-From field, making > > interoperability with rogue DMARC Senders a solved problem. > > In my book, this is mail tampering. It will be hard to justify adding > support for this radical behavior in our mail list server product > which puts customers at risk. You are putting yourself at product > liability risk but intentionally defying a security protocol against > the wishes of the publishing restrictive domain.
I am not sure I am following you here. When I say that mailing list programs should take ownership of the Header-From if they tamper with the original message content rendering its DKIM signature invalid, and that this behavior should happen irrespective of the original Sender's published DMARC policy, I am not saying that mailing list programs should relay to its subscribers fake or phishing email from unverified sources. It would go something like this: 1.Sender -> 2.MTA at mailing list host -> 3.ML processes message -> 4.ML program relays message. DMARC/DKIM/SPF checking should happen at stage 2, not at stage 3. Fake/phishing email should be detected and rejected at stage 2, and only clean legitimate email should arrive at stage 3, and at that point the mailing list program would "do its work" adding subject tags, body footers, AND taking ownership of the Header-From (hopefully indicating the original Sender in the description inside the Header-From), and then go to step 4 and relay to the list members that message. And "that message" would be a clean, wanted, legitimate email which ALSO would solve the DMARC issues with mailing lists. The only check the mailing list program should do (step 3) is to ascertain whether the original Sender is or is not a subscribed address. Checking the validity/authentication of that address belongs to step 2 and to the MTA just before the mailing list program sees the message. So I think that your worries of "putting customers at risk" are not warranted, unless I do not understand what you are saying. > It is this sort of mentality that completely makes this old game no > more fun to work with. Seriously. Please, do not get frustrated. It is not helpful to the conversation. Regards, J.Gomez _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
