Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-sender-01.txt
On Tue 28/Jul/2020 19:41:34 +0200 John Levine wrote: In article you write: In the pre-DMARC era, we've been mainly using just From:. Sender: is used by Outlook to display "on behalf of" catchphrase, presumably in an attempt to support the historic Sender-Id protocol. Sorry, no. That is completely wrong. The Sender field has been part of e-mail since RFC 724 in 1977. The now-dead Sender-ID didn't come along until the 2000s. Outlook's annoying "on behalf of" at least matches the intention of the Sender field. You're right. Outlook was using "on behalf of" even before Marid.[*] So perhaps Sender-ID derived from that usage, rather than the other way around. Best Ale -- [*] https://bugzilla.mozilla.org/show_bug.cgi?id=221054 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-sender-01.txt
In article you write: >In the pre-DMARC era, we've been mainly using just From:. Sender: is used by >Outlook to display "on behalf of" catchphrase, presumably in an attempt to >support the historic Sender-Id protocol. Sorry, no. That is completely wrong. The Sender field has been part of e-mail since RFC 724 in 1977. The now-dead Sender-ID didn't come along until the 2000s. Outlook's annoying "on behalf of" at least matches the intention of the Sender field. This might be a good time to read up on mail history rather than guessing. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-sender-01.txt
On 7/27/2020 1:12 PM, Joseph Brennan wrote: Avoiding it by redefining From: to serve the former purpose of Sender: and creating a new Author: to serve the former purpose of From: seems to me to start us down a long road of new header fields every couple of years. Oh? This is cast essentially as a fear. Your basis for believing this is what? As for the re-defining of From:, the premise of the Author: proposal is that DMARC has already effected that change. Verifying that the message really is from phisher.example is a useful data point. The receiving system can choose to mark it with a warning like "you never had mail before from phisher.example". Mark it how and for what use? How does that deal with the user-level problems caused by From:-field rewriting? Consider a DMARC DNS tag for the bank to ask the receiving system to verify the From, while the end-user system would not use that tag. I think this is the distinction that should be made, for mailing lists to work but sensitive data to be more protected than end-user mail. I don't understand what you are suggesting or how it would work usefully. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-sender-01.txt
On Mon 27/Jul/2020 22:12:17 +0200 Joseph Brennan wrote: On 7/27/2020 11:14 AM, Alessandro Vesely wrote: Let's say I have From: real.bank, and Sender: phisher.example. The above text seems to imply the receiver is looking up _dmarc.phisher.example. Correct? Avoiding it by redefining From: to serve the former purpose of Sender: and creating a new Author: to serve the former purpose of From: seems to me to start us down a long road of new header fields every couple of years. They are just names. In the pre-DMARC era, we've been mainly using just From:. Sender: is used by Outlook to display "on behalf of" catchphrase, presumably in an attempt to support the historic Sender-Id protocol. Otherwise, Sender: never had traction. DMARC did put an extra accent on From:, thereby projecting the community into a /new territory/, to use Dave's words. Introducing Sender: and Author: can allow to tone down DMARC rules. They were designed presuming that only a few domains, where email is not used for personal correspondence, would use the protocol. For example, messages cannot have multiple authors, and cannot be forwarded with modifications. Somewhat Procrustean for day to day messaging. From: rewriting is an obnoxious hack. Yet it's the only possibility for MLMs, currently. By (re-)introducing those two header fields, we can bevel DMARC rules, paying attention not to pervert the overall shape. Three identifiers allow better tuning than just one. If we do a good job, it won't be necessary to redo it every couple of years... Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-sender-01.txt
> On 7/27/2020 11:14 AM, Alessandro Vesely wrote: > > > Let's say I have From: real.bank, and Sender: phisher.example. The > > above text seems to imply the receiver is looking up > > _dmarc.phisher.example. Correct? > Avoiding it by redefining From: to serve the former purpose of Sender: and creating a new Author: to serve the former purpose of From: seems to me to start us down a long road of new header fields every couple of years. They are just names. Verifying that the message really is from phisher.example is a useful data point. The receiving system can choose to mark it with a warning like "you never had mail before from phisher.example". Consider a DMARC DNS tag for the bank to ask the receiving system to verify the From, while the end-user system would not use that tag. I think this is the distinction that should be made, for mailing lists to work but sensitive data to be more protected than end-user mail. -- Joseph Brennan Lead, Email and Systems Applications Columbia University Information Technology ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-sender-01.txt
On 7/27/2020 11:14 AM, Alessandro Vesely wrote: In various places, the I-D talks about a /domain owner/, but it is not always so clear whose domain owner is meant, in case they differ. For example, in *Domain Owner Actions*: snd: When present, this tag signals that mail originated by the domain owner MAY have a RFC5322.Sender field, as well as a RFC5322.From field and that evaluation MAY be based on the domain name in the RFC5322.Sender field. This is a parameter for a record under a domain name. Is it really not clear who is referred to by 'domain owner' here? What other interpretation is plausible? However "originated by" is poor wording and should probably be something like "authorized by". I understand that as a permission that a domain owner grants (to anyone?) to resend mail from its domain if it is correctly authenticated. However, following instructions give the opposite impression. In *Determine Handling Policy*: Sender: Extract the RFC5322.Sender domain from the message. Query the DNS for a DMARC policy record. Perform remaining, numbered steps, if one is found and it contains an "snd" tag. Let's say I have From: real.bank, and Sender: phisher.example. The above text seems to imply the receiver is looking up _dmarc.phisher.example. Correct? yes. Next step 4 apparently entails that aggregate reports are sent to both From: and Sender:. That sounds solid, but not practical. A MLM needs to apply From: rewriting until it sees that all (or most) receivers look for Sender:. How? The reality associated with that 'until' is what motivated moving this proposal from using Sender as an /alternative/ to From: to instead being /in addition to/. The heuristic of "until it sees that all (or most) receivers look for Sender:" sounds nice, but is entirely indefinite. Worse, as you note, the 'how' doesn't have an answer. So the spec does not suggest any meaningful endpoint. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-sender-01.txt
On Mon 27/Jul/2020 14:16:58 +0200 Dave Crocker wrote: Forwarded Message Subject: New Version Notification for draft-crocker-dmarc-sender-01.txt Date: Mon, 27 Jul 2020 05:16:07 -0700 From: internet-dra...@ietf.org To: Dave Crocker In various places, the I-D talks about a /domain owner/, but it is not always so clear whose domain owner is meant, in case they differ. For example, in *Domain Owner Actions*: snd: When present, this tag signals that mail originated by the domain owner MAY have a RFC5322.Sender field, as well as a RFC5322.From field and that evaluation MAY be based on the domain name in the RFC5322.Sender field. I understand that as a permission that a domain owner grants (to anyone?) to resend mail from its domain if it is correctly authenticated. However, following instructions give the opposite impression. In *Determine Handling Policy*: Sender: Extract the RFC5322.Sender domain from the message. Query the DNS for a DMARC policy record. Perform remaining, numbered steps, if one is found and it contains an "snd" tag. Let's say I have From: real.bank, and Sender: phisher.example. The above text seems to imply the receiver is looking up _dmarc.phisher.example. Correct? Next step 4 apparently entails that aggregate reports are sent to both From: and Sender:. That sounds solid, but not practical. A MLM needs to apply From: rewriting until it sees that all (or most) receivers look for Sender:. How? A possible solution in my next message. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-sender-01.txt
Forwarded Message Subject: New Version Notification for draft-crocker-dmarc-sender-01.txt Date: Mon, 27 Jul 2020 05:16:07 -0700 From: internet-dra...@ietf.org To: Dave Crocker A new version of I-D, draft-crocker-dmarc-sender-01.txt has been successfully submitted by Dave Crocker and posted to the IETF repository. Name: draft-crocker-dmarc-sender Revision: 01 Title: DMARC Use of the RFC5322.Sender Header Field Document date: 2020-07-27 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-crocker-dmarc-sender-01.txt Status: https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/ Htmlized: https://tools.ietf.org/html/draft-crocker-dmarc-sender-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-crocker-dmarc-sender Diff: https://www.ietf.org/rfcdiff?url2=draft-crocker-dmarc-sender-01 Abstract: Internet mail defines the RFC5322.From field to indicate the author of the message's content and the RFC5322.Sender field to indicate who initially handled the message. The RFC5322.Sender field is optional, if it has the same information as the RFC5322.From field. That is, when the RFC5322.Sender field is absent, the RFC5322.From field has conflated semantics, with both a handling identifier and a content creator identifier. This was not a problem, until development of stringent protections on use of the RFC5322.From field. It has prompted Mediators, such as mailing lists, to modify the RFC5322.From field, to circumvent mail rejection caused by those protections. This affects end-to-end behavior of email, between the author and the final recipients, because mail from the same author is not treated the same, depending on what path it followed. In effect, the RFC5322.From field has become dominated by its role as a handling identifier. The current specification augments use of the RFC5322.From field, by enhancing DMARC to also use the RFC5322.Sender field. This preserves the utility of RFC5322.From field while also preserving the utility of DMARC. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
