Dear Hector, See comments inline: On May 30, 2014, at 4:44 PM, Hector Santos <[email protected]> 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. Of course, its only becomes a problem when > its used as a loophole to further spread harmful mail and someone actually > gets harmed. Thats all you have to prove in a courtroom. If you had all > the tools before you to tell you definitively, "This is unauthorized mail" > and you intentionally, deliberately and neglectfully ignore it, do nothing > about it but further distribute to end points, well, who knows what a young > punk, tech savvy, high tech, new age lawyer will think about suing you. If > you got deep pockets, well, don't think it can't happen. > > It is this sort of mentality that completely makes this old game no more fun > to work with. Seriously. > > We can do it right. All we have to do is LOOKUP the policy and follow it. > Give the YAHOOs the tools to authorize the resigners and you and I won't have > these new ethical problems to content with. It seems wrong to describe a mailing-list adding Subject Tags, List Footers, while retaining the From header field so people have an easer task of knowing who is talking and at reviewing past conversations as putting recipients in grave risk. Causing a massive number of people to find different email providers so they can retain their effectiveness at using a mailing list is far more likely to create risk simply due to the resulting confusion. There is also the case of Intuit sending "From" invoices on behalf of various individuals and using their customer's email address given to them by their Internet provider, only to find someone now thinks DKIM can't possibly be considered valid when signing the Sender header field. That is exactly the intended purpose for this field. This is essentially the same issue with mailing-lists. In both cases, there is a valid reason for the From header field to contain that of their client or the speaker, because that is what the recipient is able to recognize. There are also MUAs that will create a synthetic From <sender> on behalf of <from>. Most MUAs can also optionally display both headers. The real effort involved in the sequence of these messages is establishing trust anchors. While there is going to be a massive number of individuals involved, there are several orders of magnitude fewer trust anchors. For any domain wanting to assert strict alignment for their messages, it is only fair for them to work out relationships between their users messages and the non-aligned third-party services (trusted domain --> worthy third-party service). Their out-bound logs and DMARC/User feedback should arrive at a reasonable estimate about which domains are being trusted. Rogue services will be excluded and any mistakes can be quickly corrected. Rather than describing this as a permission to sign, think of this as a type of server federation aimed at protecting the federated identity much like single-user-sign-on. In this case, it would be which of these services are normally used and maintain practices that protect the federated identifiers. The TPA-Label scheme allows this type of federation to be centralized or handled separately by each trusted domain (senders) as described in http://tools.ietf.org/html/draft-otis-tpa-label. Regards, Douglas Otis
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
