Re: [dmarc-ietf] Time to work on failure reporting
On Thu 11/Aug/2022 21:06:31 +0200 John R Levine wrote: On Thu, 11 Aug 2022, Alessandro Vesely wrote: I added an example, see https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting/blob/main/draft-ietf-dmarc-failure-reporting-04.txt#L528 I just picked a report I received and anonymized it. How is it? The Source-Port field is non-standard so I'd take it out. Defined by RFC 6692. I'd also remove at least the ARC and References headers from the message inside example since they make it a lot longer and don't help explain the format. Done. I'd change text/rfc822-headers to message/rfc822 and add ther a message body or something like [ Message body was here ] Why? I chose a body-less example as it looks more privacy-friendly. Perhaps I could change Auth-Failure: to bodyhash and add a DKIM-Canonicalized-Body. That would prove one can provide that data using while still sending only rfc822-headers. BTW: The strings that Auth-Failure: can take seem to still be the ones defined by RFC 6591. The file I started from had "dmarc". There is no IANA registry. Should we define one? The goal here is to make it clear that this has to be multipart/report and what goes into the message/feedback-report. I hope anyone reading this already knows what a 5322 message looks like and how to leave out the body. I need to figure out whether the example is XML or but we can worry about that later. I thought it is the source of the email message. Its artistic content lacks somewhat... :-) For another point, should I redact the addresses? How? Possibilities: * Only s/// * Replace all what looks like a local-part with something like rZ8cqXWGiKHzhz1MsFRGTysHia4=, according to RFC 6590, including Received:'s for clauses and Message-Id. This has to be noted in the text. * Other? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Girl Scout troops vs MLM problems (#70)
On Fri 12/Aug/2022 08:46:45 +0200 Murray S. Kucherawy wrote: On Thu, Aug 11, 2022 at 3:16 AM Alessandro Vesely wrote: That's the /complicated/ de-munging strategy. The much simpler approach I described upthread would work 100% of cases for lists that add the Author: field. It is a little less secure, as you need to trust the mailing list signature. If you trust the mailing list signature, doesn't that also mean you trust the list to behave "well"? If that's true, then why do you need Author? I trust the list to not allow attacks featuring spoofed Author:. (Spoofed From: are possible but infrequent.) It is safer if Author: is set by the author's MSA. I need Author: to replace munged From:. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Girl Scout troops vs MLM problems (#70)
On Thu 11/Aug/2022 19:47:17 +0200 John R Levine wrote: On Thu, 11 Aug 2022, Murray S. Kucherawy wrote: It only works if all or most lists add Author (none do today, and it would take a long time to get this rolled out if they started), and no other software co-opts and mutates it for whatever reason. Those are big enough conditions that I'm a bit worried about writing a standards-track document that depends on it. When Dave proposed the Author header, part of the idea was that DMARC could use it rather than From. IIRC that was the Sender: field. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Girl Scout troops vs MLM problems (#70)
On Thu 11/Aug/2022 18:26:38 +0200 Murray S. Kucherawy wrote: A domain owner can know, for instance, that it only sends transactional messages that have no purpose to ever go to a mailing list. Such an operator can safely set "p=reject" because the risk of the collateral damage about which we're concerned here is close to zero. That is equivalent to the domain owner knowing not only that there's dual authentication, but also that authentication is highly likely to survive to delivery. When users are introduced into such a system, that logic goes out the window. DMARC is arguably not appropriate for those use cases, and Barry is urging that we say so. To have to use different domains for transactional messages vs. personal usage which might include mailing lists is an artifact of authentication as well. Recall, for example, Brett McDowell, who participated in the ietf-dkim list sporting an address with a domain part of paypal.com. In 2010 his company created the domain paypal-inc.com in order to separate mail flows. Creating look-alike domains is not the most natural thing to do, and has the potential to confuse recipients, as spammers quickly learned. OTOH, stopping at p=none is not much effective. It can be interesting only for email geeks. Saying that DMARC is for highly abused domains only, albeit near to the original aim, sounds like saying, after the invention of locks, that you can keep your home door unlocked because you're not a bank. Since locks exist, I want to lock my door too. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Time to work on failure reporting
The Source-Port field is non-standard so I'd take it out. Defined by RFC 6692. So it is. ARF is such a mess. I'd change text/rfc822-headers to message/rfc822 and add ther a message body or something like [ Message body was here ] Why? I chose a body-less example as it looks more privacy-friendly. I'd rather it be more general, to show where all of the plausible parts go. I need to figure out whether the example is XML or but we can worry about that later. I thought it is the source of the email message. Its artistic content lacks somewhat... :-) For another point, should I redact the addresses? How? Possibilities: Just change them to something like x...@yyy.zzz. It's an example. They don't matter. By the way, it looks like you edited this into the XML rather than the markdown source. It would be nice to have the markdown available for future edits. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Girl Scout troops vs MLM problems (#70)
On Fri, 12 Aug 2022, Alessandro Vesely wrote: When Dave proposed the Author header, part of the idea was that DMARC could use it rather than From. IIRC that was the Sender: field. No, DMARC decided not to use Sender back when DMARC was new. Dave suggested using Author to work around the From hacking. I still think this is completely out of scope and not worth any more argument. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Girl Scout troops vs MLM problems (#70)
On Fri, Aug 12, 2022 at 12:28 PM John R Levine wrote: > On Fri, 12 Aug 2022, Alessandro Vesely wrote: > >> When Dave proposed the Author header, part of the idea was that DMARC > could > >> use it rather than From. > > > > IIRC that was the Sender: field. > > No, DMARC decided not to use Sender back when DMARC was new. Dave > suggested using Author to work around the From hacking. I still think > this is completely out of scope and not worth any more argument. > > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > +1 Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Girl Scout troops vs MLM problems (#70)
It appears that Alessandro Vesely said: >> If you trust the mailing list signature, doesn't that also mean you trust >> the list to behave "well"? If that's true, then why do you need Author? > >I trust the list to not allow attacks featuring spoofed Author:. (Spoofed >From: are possible but infrequent.) It is safer if Author: is set by the >author's MSA. Hi, bot spammer here. My MSA is really good at putting other people's addresses anywhere I tell it to. You want a fake From and fake Author? No problem. To reiterate a point I think I've made three times now, the reason we have ARC rather than something simpler is exactly because spoofed mail leaks through lists and causes filtering problems. Since Author would be a copy of some version of From, it's hard to imagine how spoofed Author would be less of an issue. Perhaps since we have seen no support at all for this Author hack or other >From demunging, we could stop now and work on DMARC. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Can we put the psd tag in the IANA registry now?
Since we seem close to agreement on the tree walk text, and and it uses the psd tag, can we ask IANA to add psd=u/n/y to the registry, please? R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
