Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
In article you write: >Folks, > >I was quite surprised -- at the level of astonished -- to see the >pushback on the Author header-field proposal, since it is such a simple >and straightforward mechanism. The different bits in the message are simple enough. The problem is that it might as well be called Really-From, and then when enough systems do mutant DMARC to cause the same problems with Really-From that we have with From, the step after that is Really-Really-From, so on ad nauseam. While that happens (or maybe doesn't) we have no idea whether MUAs will display it or let you enter it or automatically make it the same as From or maybe something else, likely making it a disaster for interoperability. I think the DMARC sender draft is a lot more promising. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] draft-crocker-dmarc-author-00 ?
Folks, I was quite surprised -- at the level of astonished -- to see the pushback on the Author header-field proposal, since it is such a simple and straightforward mechanism. I'd like to ask for clarity from the group on both concerns about it and desires for it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
On Mon, Aug 10, 2020 at 12:05 PM Tim Wicinski wrote: > > During IETF 108, the chairs realized that there was interest in Dave's > RFC5322.Sender draft. > > This starts a Call for Adoption for draft-crocker-dmarc-sender > +1 for adopting the document into the WG for continued discussion. --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] The DMARC WG has placed draft-crocker-dmarc-sender in state "Call For Adoption By WG Issued"
The DMARC WG has placed draft-crocker-dmarc-sender in state Call For Adoption By WG Issued (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/ ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
During IETF 108, the chairs realized that there was interest in Dave's RFC5322.Sender draft. This starts a Call for Adoption for draft-crocker-dmarc-sender The draft is available here: https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/ Currently, the draft is marked as "Standards Track". The chairs feel if the working group does adopt this, it should begin as "Experimental". If we start to see adoption of this work, this can be changed back to "Standards Track" before Working Group Last Call. Of course, we welcome input from the working group on this. Please review this draft to see if you think it is suitable for adoption, and send any comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends: 24 August 2020 Thanks, tim wicinski ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] third party authorization, not, was non-mailing list
On Mon, Aug 10, 2020 at 1:24 PM John Levine wrote: > In article <2ef8e773e7bf467481a05ab3fc4d9...@bayviewphysicians.com> you > write: > >>Even an external reputation system requires recipient participation. > That is why I suggested both a send3="parameters" clause to > >indicate sender support for third-party authorization and a > verify3="parameters" clause to indicate recipient support for third-party > >authentication.When both are visible to the non-domain message > source, that source can have confidence that the message will be > >handled as authorized. > > We have had a lot of attempts at third-party authorization schemes > going back at least to vouch-by-reference in 2009 and ATPS in 2012, > and the Spamhaus Whitelist in 2010. Every single one of them failed, > not due to technical problems, but because nobody was interested. > > The only third party reputation systems that anyone uses are DNSBLs > like Spamhaus that publish negative reputations, and even there you > can count the ones with non-trivial use on the fingers of one hand. > > With this in mind, I cannot see any point in designing yet another > vouching or authorization scheme unless we have evidence that an > interesting fraction of the world's mail systems want to use it. I > don't see that, and honestly see no chance that we ever will. > > R's, > John > > +1 Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] third party authorization, not, was non-mailing list
We have had a lot of attempts at third-party authorization schemes With this in mind, I cannot see any point in designing yet another vouching or authorization scheme unless we have evidence that an interesting fraction of the world's mail systems want to use it. I don't see that, and honestly see no chance that we ever will. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] third party authorization, not, was non-mailing list
In article <2ef8e773e7bf467481a05ab3fc4d9...@bayviewphysicians.com> you write: >>Even an external reputation system requires recipient participation. That >>is why I suggested both a send3="parameters" clause to >indicate sender support for third-party authorization and a >verify3="parameters" clause to indicate recipient support for third-party >authentication.When both are visible to the non-domain message source, >that source can have confidence that the message will be >handled as authorized. We have had a lot of attempts at third-party authorization schemes going back at least to vouch-by-reference in 2009 and ATPS in 2012, and the Spamhaus Whitelist in 2010. Every single one of them failed, not due to technical problems, but because nobody was interested. The only third party reputation systems that anyone uses are DNSBLs like Spamhaus that publish negative reputations, and even there you can count the ones with non-trivial use on the fingers of one hand. With this in mind, I cannot see any point in designing yet another vouching or authorization scheme unless we have evidence that an interesting fraction of the world's mail systems want to use it. I don't see that, and honestly see no chance that we ever will. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] non-mailing list use case for differing header domains
Alessandro observed: >> However, that kind of hush hush is not deterministic, since the >> protocol does not define the "external information". Providing for a >> URL pointing to such external source might help. Even an external reputation system requires recipient participation. That is why I suggested both a send3="parameters" clause to indicate sender support for third-party authorization and a verify3="parameters" clause to indicate recipient support for third-party authentication.When both are visible to the non-domain message source, that source can have confidence that the message will be handled as authorized. We have a very complete specification for ATSP signature delegation. Do we have a similar document for your RHSWL approach? Do we have a similar document for lookup into a trusted-forwarders list, assuming a service like that can be revived? If ATSP and RHSWL solve essentially the same problem, we need to do an analysis of which is more likely to succeed, and proceed with that winner. Third-party lookup is a very different approach than ATSP, so they can supplement each other. DF ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] non-mailing list use case for differing header domains
On 2020-08-09 6:54 p.m., Tõnu Tammer wrote: DMARC relies on SPF and DKIM. The latter is particularly important for the mailing lists to ensure that DMARC works. And when I read the cases it is clear that the issue is not of DMARC but of DKIM. Indeed, one of the proposed workarounds, Recognized Transformations of Messages, addresses DKIM verification algorithm. Yet, it is being discussed on this list rather than ietf-dkim. I hope it becomes a WG draft soon. RFC for DKIM says very clearly in the introductory part that and I quote "Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature." If this is not the case, the relay is actually violating DKIM standard. As Dave said, MLMs may need to carry out some transformations while usual relays don't —except those which add **SPAM** subject tags or antivirus footers. The l= tag is one of the early envisaged provisions to address footer additions. It was deprecated because of the possibility to add malicious footers. Of course, adding a footer /is/ a substantive change. However tight we define recognized transformations, they have to allow the addition of a few lines and a URL. Hence, they can be malicious. Therefore, we need to differentiate two classes of domain owners, those who can afford such risk and those who want top strictness. The lists we manage, we have made sure they follow the RFC and there is no issue of DKIM preservation. https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail#Turn_off_all_message_modifications Some lists, however, have taken a different approach and to make sure we have delivery there also, we've looked at the elements which are used for DKIM calculation. We realise that not including the content into hash calculation can have a drawback but given that non-DKIM compliant lists do with content what they wish anyway, it's not much of a drawback. At the same time, prevention against spoofing and misuse is retained, which is the key for DMARC. That only works if you trust the MLM. We cannot rely on trust, because there is no widespread common reputation system. DMARC does provide for "trusted_forwarder" and "mailing_list" policy override types: However, before this action is taken, the Mail Receiver can consult external information to override the Domain Owner's policy. For example, if the Mail Receiver knows that this particular email came from a known and trusted forwarder (that happens to break both SPF and DKIM), then the Mail Receiver may choose to ignore the Domain Owner's policy. However, that kind of hush hush is not deterministic, since the protocol does not define the "external information". Providing for a URL pointing to such external source might help. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
