On Saturday, May 31, 2014 2:18 PM [GMT+1=CET], Stephen J. Turnbull wrote: > J. Gomez writes: > > > Furthermore, what is more important - to deserve or not to deserve > > the prize of being sanctioned as kosher, or keeping a world-wide > > system interoperable? > > In the face of bullying by large operators counting on the fact that > ostracizing them would seriously annoy millions of *our* users and > customers, I think calling it "bullying" is one of the more important > steps we can take to keep that system interoperable.
I don't mind calling it bullying, but I would not focus on that, but on the interoperability side of the issue. Users won't care about the politics of the email system, but about relevant and wanted email landing on their inbox -- hopefully in an easily readable manner. > > Yes, that is true. But a default out-of-the-box always has to > > exist, and in my opinion that default should be the most > > interoperable which is possible --interoperable with the real > > world, not with how we would like the world to be--, while keeping > > as much valuable features as possible, and while keeping operator's > > duties as straight forward and simple as possible. > > There's interoperability and there's interoperability. GNU Mailman > has a feature such that (1) a DNS query checks for "p=reject" and (2) > if found, the message is wrapped as a message/rfc822 part in a message > from the mailing list and containing the header (if any) and footer > (if any) as separate MIME parts. This is fully RFC conformant (it's > basically a one-message digest) and almost all MUAs should be able to > handle it. It is what I propose as default for Mailman. > > Do you see any defects in that proposal? That proposal is fine from a technical point of view - it solves the problem and is interoperable. However, that proposal is not perfect from a usability point of view - how well will an attached message/rf822 part be legible when the final recipient is using webmail, or a mobile device with a simple MUA? - how much a non-technical user will freak out when he gets such a message from a mailing list? - will he call the help desk about it, incurring support costs and being a burden for that help desk? - will that proposal unnecessarily consume time in the Recipient side of the communication, basically off-loading into the final innocent Recipient the cost of solving "the DMARC issue"? - is that proposal convoluted for the final Recipient's comfort? I guess that once the interoperability issue is agreed to be important, now the ergonomics of the proposed solution should get the focus. And that proposal is not very ergonomical, in my humble opinion. > > > 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, > > It can be and is argued, but the argument is clearly incorrect. The > most recent RFCs state quite clearly that "same message" is in the eye > of the users, and I cannot imagine that addition of a "[list]" tag to > Subject or an unsubscribe footer to the message body would be > interpreted by anyone involved in the list as making the list the > author. If DKIM signatures were not involved, you would be right. Now that DKIM signatures are indeed involved, and considered useful in the email ecosystem, any tampering with a message's content means taking responsibility of the result of such tampering, therefore taking ownership of the Header-From. Regards, J.Gomez _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
