Re: [dmarc-ietf] draft-crocker-dmarc-author-00
On 7/13/2020 12:08 PM, Joseph Brennan wrote: We already have a field for author, called From. Why add another one? 1. Note that the From: field typically serves two different semantic roles, author and 'handling agent' (ie, Sender:) 2. Pars 3 &6 of the Introduction lay the foundation for needing a new and separate header field. Simple summary: These days, the original From: field is tending to get corrupted and we need some place to put author information that won't be. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-crocker-dmarc-author-00
We already have a field for author, called From. Why add another one? "The only required header fields are the origination date field and the originator address field(s)." By this, RFC 5322 refers to the From field. I think client software developers would be inclined to ignore creating the Author field, or else to create it and populate it with the same value as the From field. Mailing list software might want to create Author and copy the value of From into it, and then insert the list address into the From, but then, they run into "In all cases, the "From:" field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message." No better than where we are now, is it? -- Joseph Brennan Lead, Email and Systems Applications ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-crocker-dmarc-author-00
On 7/13/2020 11:29 AM, Alessandro Vesely wrote: IMHO, it could be standard track and modify RFC 5322 if accepted. The mail header is extensible. Addition of header fields does not require modifying the base specification. Restricting From: to be single-address, or at least having all domain parts aligned to one another does require an updates= tag. ahh. hadn't seen that was your point. well, whenever there is an effort to do substantial revisions to mail format, this might be worth considering. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-crocker-dmarc-author-00
On 13/07/2020 19:27, Dave Crocker wrote: On 7/13/2020 9:29 AM, Alessandro Vesely wrote: On 13/07/2020 05:10, Dave Crocker wrote: I've just submitted an initial draft to define an RFC5322.Author field: https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/ Dave, since you also posted a second draft, I'd strike considerations about the Sender: from this one. In particular, the 4th paragraph of the Introduction, "Because the current [...]", is distracting and unhelpful. Unfortunately, misunderstanding of the relevant human factors is often introduced in discussions in this realm. People are remarkably resistant to the behavioral facts on his, so, unfortunately, it needs repeating. It'd be enough to say Sender: is syntactically and semantically different. Another use case of Author: is to indicate multiple authors. That's supported by the draft spec, since it copied From: syntax. I'd support making that a WG I-D. Thanks. Thank you. IMHO, it could be standard track and modify RFC 5322 if accepted. The mail header is extensible. Addition of header fields does not require modifying the base specification. Restricting From: to be single-address, or at least having all domain parts aligned to one another does require an updates= tag. Of course, ticket 74 has to be addressed in dmarc-bis too, or one of its parts, since Alexey said we are likely to split up the current document into multiple drafts. If the Author: I-D is going to be one of those parts, it's be convenient to recap usage of Originator Fields in the DMARC era in a single, short document. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field
> > > > 2) draft-crocker-dmarc-sender > This is an elegant solution. It puts the burden of change-- creating a Sender field in all cases, and a variant DMARC record-- on the domain owner who wants to send mail and use DMARC rules. The use of Sender complies with RFC 5322, since it is optional whether to create Sender when it is the same address as From. With this implemented, developers of mailing list software can stop figuring out which way to violate RFC 5322 in order to make mail deliverable, and developers of clients do not have to create and display a new Author field. Big win, for widespread acceptance, I would say. -- Joseph Brennan Lead, Email and Systems Applications ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-crocker-dmarc-author-00
On 7/13/2020 9:29 AM, Alessandro Vesely wrote: On 13/07/2020 05:10, Dave Crocker wrote: I've just submitted an initial draft to define an RFC5322.Author field: https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/ Dave, since you also posted a second draft, I'd strike considerations about the Sender: from this one. In particular, the 4th paragraph of the Introduction, "Because the current [...]", is distracting and unhelpful. Unfortunately, misunderstanding of the relevant human factors is often introduced in discussions in this realm. People are remarkably resistant to the behavioral facts on his, so, unfortunately, it needs repeating. I'd explicitly mention DMARC, rather than use circumlocutions mentioning generic email protections which use the From: field. I've learned to write specification for the long-term, notably trying to avoid ephemeral references that won't apply years later. The proposal here stands on its own. Motivated by DMARC issues, but I'd argue not dependent on it. Another use case of Author: is to indicate multiple authors. That's supported by the draft spec, since it copied From: syntax. I'd support making that a WG I-D. Thanks. IMHO, it could be standard track and modify RFC 5322 if accepted. The mail header is extensible. Addition of header fields does not require modifying the base specification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field
On 7/13/2020 10:15 AM, Hector Santos wrote: Before more review,just to confirm: 1) draft-crocker-dmarc-author A proposed new 5322.Author header? Yes. Is is required to be hash bound to DKIM signature? No. In fact the DKIM requirement to include From: in the set of hash-bound text was a last-minute imposition by an area director, rather than a functional need set by the working group or larger community. That said, of course I'd expect signers to choose to include it. Will be make it a MUST NOT modified NOR rewrite it? No idea where this would be mandated or why. 2) draft-crocker-dmarc-sender A proposal to somehow shift DMARC to DNS UP the sender domain for DMARC policy? "DNS UP"? It's a proposal to have DMARC use the Sender: field, in preference to the From: field. Does this mean the Sender header is now required to be hash bound to the signature? cf, above, about the nature of the requirements. Again, it would make sense to bind it, but mandating is a separate issue. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field
Before more review,just to confirm: 1) draft-crocker-dmarc-author A proposed new 5322.Author header? Is is required to be hash bound to DKIM signature? Will be make it a MUST NOT modified NOR rewrite it? 2) draft-crocker-dmarc-sender A proposal to somehow shift DMARC to DNS UP the sender domain for DMARC policy? Does this mean the Sender header is now required to be hash bound to the signature? -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field
On 7/13/2020 7:46 AM, Doug Foster wrote: Let's clarify the purpose of DMARC and the problem of MLM edits: Thanks for the response. What confusion about DMARC is there, that you felt needed clarifying, and how does it relate to the details of this proposal? Also, in terms of threats, how does my proposal make them different from what is already considered acceptable? In particular, the current actions by Mediators that rewrite the From: field is, apparently, considered acceptable. Modifying in-transit messages is a threat vector for both sender and recipient. Technically, they are not 'in transit'. In basic email terms, they've been delivered and then re-posted. Also, since mailing lists have been in operation for about 45 years, and since they are such a threat, perhaps you can point to some documented abuses by them? Lastly, I apologize, but I could not discern any specific substance in your note that relates to the substance of my draft. Please clarify. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-crocker-dmarc-author-00
On 13/07/2020 05:10, Dave Crocker wrote: I've just submitted an initial draft to define an RFC5322.Author field: https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/ Dave, since you also posted a second draft, I'd strike considerations about the Sender: from this one. In particular, the 4th paragraph of the Introduction, "Because the current [...]", is distracting and unhelpful. I'd explicitly mention DMARC, rather than use circumlocutions mentioning generic email protections which use the From: field. Another use case of Author: is to indicate multiple authors. Like From: and unlike Sender:, Author: supports a list of mailboxes. Since, DMARC filters don't behave well with multi-address From:, using Author: can be a handy alternative for those joint messages. In fact, the current spec says: o Messages bearing a single RFC5322.From field containing multiple addresses (and, thus, multiple domain names to be evaluated) are typically rejected because the sorts of mail normally protected by DMARC do not use this format; I submitted ticket 74[*] to address the latter point, which is inconsistent as either all or none of the mail belonging to a given domain is subject to DMARC filtering. There is no way to define which sorts of mail is "normally protected". The quoted rule deviously restricts the format of From:. I'd support making that a WG I-D. IMHO, it could be standard track and modify RFC 5322 if accepted. Best Ale -- [*] https://trac.ietf.org/trac/dmarc/ticket/74 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field
Let's clarify the purpose of DMARC and the problem of MLM edits: Modifying in-transit messages is a threat vector for both sender and recipient. The ability to constructively modify a message is also the ability to maliciously modify a message. And the ability to maliciously modify a message is also the ability to create a new message which looks like a forwarded message. In this respect, a content-editing MLM is indistinguishable from a content-fabricating spammer. Senders do not want to be misrepresented, and do not want their good reputation to be exploited by those with a negative reputation. Recipients do not want to be misled. Consequently, sender and recipient agree to enforce DMARC policy, to prevent this from happening. If a message is altered in transit, or forged in its entirety, the message will be rejected. There are very few ways to fix this: - MLM must gain the trust of the sender and recipient, so that it can be distinguished by a spammer. - Sender and recipient must be duped into accepting content that they do not want. RFC 7960 is worded to suggest that DMARC is to blame for the problem. The real problem is that MLMs have made their operating practices dependent on weak security. Santa Claus could run into the same problem: At least in the USA, he comes down chimneys, because they are unsecured and his intentions are only good. If criminals figure out how to enter and exit through the chimney, homeowners will start placing locked grates on top of the chimney. Given the choice between "both criminals and Santa" or "neither criminals nor Santa", most homeowners would be willing to give up Santa. Of course, Santa could ask for a key, which would create a key management nightmare. Or he could ring the doorbell, show credentials, and wait to be admitted. The MLMs are like Santa. They are trying to do a good thing. But the criminals want to use the same weaknesses that the MLMs want to use. Given the choice between "both" and "neither", DMARC-enforcing domains are choosing neither. Inducing or coercing them to use "both" mode is an incorrect solution to the MLM problem. DF -Original Message- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dave Crocker Sent: Sunday, July 12, 2020 11:20 PM To: IETF DMARC WG Subject: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field FYI, I've posted an initial draft for having DMARC use the Sender: field: https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/ d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
