Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field
On 7/14/2020 2:52 AM, Alessandro Vesely wrote: And phishers can also send mail From: fm.bank and Sender: regleissei.icu. To publish a DMARC policy would avail Farmers & Merchants nothing, then. If regleissei.icu publishes a DMARC record and indicates support for use of Sender:, per the proposal, please explain exactly what bad things will happen, in the case you offer. 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 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
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 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
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
[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-ietf] draft-crocker-dmarc-author-00
FYI, I've just submitted an initial draft to define an RFC5322.Author field: https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/ d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Integrated scanrios (was: Re: Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt)
It occurs to me that discussion about how this latest proposal might or might not have similarities to ARC should encourage everyone making a proposal to add commentary that gives a full sense of end-to-end use. That is, distinguish the details of how the specific mechanism works, from how it integrates into end-to-end service. How is it expected to get used and why is that believed to be practical (as well as useful?) 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-kucherawy-dkim-transform-01.txt
On 7/6/2020 10:41 AM, John R Levine wrote: On Mon, 6 Jul 2020, Dave Crocker wrote: Perhaps, like some others, I'm not understanding this correctly, but I think the proposal has nothing at all to do with what the recipient sees. Rather, I've understood this as an attempt to reverse additions made by a Mediator, with the goal of validating the origination DKIM signature. Presumably that is so as to use the origination domain's reputation and even permit DMARC to validate. But why would I want to do that? I wasn't advocating or criticizing. Just trying to synchronize that nature and purpose of the task. ARC lets a credible mediator say this message was OK before I munged it. That's a very different trust model from allowing a means to directly vet the original signature. This proposal lets a sleazy mediator say the same thing, with advice on how to verify mechanically. Actually, it doesn't. The sleazy mediator cannot somehow forge an originator's signature so it validates. A sleazy mediator takes a message from Paypal and wraps a big blob of HTML spam around it that will display on top of the original message. I get the spammy message, look at the signatures and find yup, there's a real Paypal message inside the spam. What should I do with it? It's unlikely the Paypal message was intended for me. A worthy scenario to worry about, but completely different from the nature of what ARC does and its likely benefits and weaknesses. 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-kucherawy-dkim-transform-01.txt
On 7/6/2020 10:03 AM, John R Levine wrote: No, I'm not saying render them differently. I'm saying that if the second signature passes, then the second one signed the bolted-on spam but also told you how to strip it away to get the original. So, do that; if the author signature now passes, you have the original "clean" message to show instead of the hijacked message. If not, you have a spammy message to deal with, as before. I don't understand this scenario at all. Why would I want to show my user a message forwarded by a spammer? If the original sender wanted me to see it, she could have sent it to me directly, or through a legit mailing list. Perhaps, like some others, I'm not understanding this correctly, but I think the proposal has nothing at all to do with what the recipient sees. Rather, I've understood this as an attempt to reverse additions made by a Mediator, with the goal of validating the origination DKIM signature. Presumably that is so as to use the origination domain's reputation and even permit DMARC to validate. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] What if... Sender:
On 6/25/2020 3:58 PM, Scott Kitterman wrote: Why would I be expressing an interpretation of the charter that I didn't think is correct? That's not what i said. I mean that you are asserting a requirement as if it were established, based on your interpretation. the requirement is not established and, of course, i believe it won't be. Absent direction from the chairs, of course I'm going to operate on the basis of my interpretation (although I think it's less interpretation and more reading what's explicitly there, I'd imagine you would view it differently). The point is needing to be more tentative. Opinions are of course fine. The state of being an opinion is transitive. It flows onto any assertions made based on it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] What if... Sender:
On 6/25/2020 3:33 PM, Scott Kitterman wrote: True, but I think it's on topic for a DMARC replacement working group, not this one. You have just crossed over from expressing a personal interpretation of the charter, to declaring your interpretation as correct, in spite of having a competing interpretation also having been expressed. Please don't do that. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] What if... Sender:
On 6/25/2020 2:10 PM, Scott Kitterman wrote: I would encourage people to review the working group charter. I think dumping 5322.From and aligning to something else is well outside of it. Not saying we couldn't recharter, but I'm skeptical of the value of this entire thread. What is it about Item 1 in the charter that precludes this work? What is it about Item 2 in the charter that precludes this work? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] What if... Sender:
On 6/25/2020 8:10 AM, David I wrote: From: Dave Crocker set a 'From' they're not entitled to use that's of a trusted contact, and the DMARC associated with the abused domain in the 'From' has no effect and can't be used for filtering. So while you could so a similar filter on Sender, it wouldn't be as useful, and would provide less security benefit. Why is it useful in the From:? Seriously. Because the claimed author is an important aspect of any kind of trust calculation on an email, human or automated. So an aligned, authenticated 'From' is a strong signal. 1. Signal to what and how is it used for filtering? 2. Why isn't an aligned Sender: just as strong? 3. Arguably the actual semantics of an aligned From:, for DMARC, is for an aligned Sender:, since the semantics of DMARC concern the organization and not the author. Remember that From: typically conflates both author and operator information. Since the utility of DMARC has nothing to do with recipient end-user decision-making, I don't really understand this assertion. The DMARC spec suggests for p=quarantine that unauthenticated mail ends up in a spam folder. It's assumed that users are less likely to open and trust mail in their spam folder (though it's not 100% of course). So yes, the utility of DMARC has something to do with end-user decision making. Users open mail in the spam folder all the time. why is DMARC's use of From: automatically better than having DMARC use Sender:? Because the From field is used by software to understand where an email came from, and apply UI, filters, and warnings. 1. "Warnings" have no reliable utility. 2. UI behavior is what From: field alignment is breaking, given the workarounds that MLMs have to do 3. Filtering engines use a wide array of information; there is nothing magical about their use of From. Also note item #3, from above. Attackers do all sorts of bad things. Some of those bad things don't actually matter. They might be unauthorized, ill-intended, and even make you or me uncomfortable. But they don't actually have any effect on getting bad mail delivered to recipients nor an effect on those recipients. Bad actors try all sorts of stuff. Agreed. It's possible for bad actors to compromise mailboxes to bypass current DMARC based filtering. So is DMARC pointless? No, because it increases the cost and complexity of the attack, which is a positive thing. I think you missed my point. My point was that some of what attackers do doesn't matter. It upsets us when we hear about their doing it, but it doesn't affect discoverability and it doesn't affect recipient behavior. We should worry about their actions that actually have a bad effect, not worry about actions we just don't like. So pointing out what an attacker might or will do doesn't end the argument. What matters is the /effect/ of their actions, not the theory of their actions. The effect would be to phish people more successfully by evading the current DMARC checks on From alignment and filters/detections based on cousin domains. Your claim of 'successfully' means you have objective data substantiating the successes. Please circulate it to us. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] What if... Sender:
On 6/24/2020 12:24 PM, Jim Fenton wrote: You have explained why Sender: is better than From: (which I agree with) but not why specifically Sender needs to be used. Existing practice is less risky than new practice. The existence and semantics of Sender: has been around for 45 years. Its semantics match what is I see the use of a long-standing header field as being a disadvantage, not an advantage, because of potential obscure uses we don't know about. That line of logic means we should never modify or add to any existing practice. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] What if... Sender:
On 6/25/2020 3:14 AM, Alessandro Vesely wrote: Frequently, an inbound message has one or more valid DKIM signatures, and/or passes SPF, yet it fails DMARC; that is, the authenticated domain(s) are not aligned with From:. Now it's obvious that any of those authenticated domain(s) could as well have set a Sender: pointing to itself. Hence, the net effect is equivalent to dropping the alignment requirement. It's not. Remember that the From: field is typically also the Sender: field. Again: The actual semantics of DMARC have to do with the organization's domain, not the author's mailbox. So, really, DMARC concerns an operational identifier, not a content creator. The suggestion, therefore, is to retain alignment, but move it to a field that has to do with operations, not content. Sender: has a display name and an address, just like From:. Don't we risk to double phishing opportunities? If Sender: and From: domains disagree, are both going to get reports? Why would there be a DMARC report on From:? Reports are supposed to be consumed by the originator. You didn't actually answer my question. Let's try a more complete question: If DMARC reports refer to the Sender: aligned domain, and reports refer to that, why is a report on the From: field also required? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] What if... Sender:
On 6/25/2020 1:54 AM, David I wrote: Without forcing alignment to 'From', an attacker can set their own 'Sender', set a 'From' they're not entitled to use that's of a trusted contact, and the DMARC associated with the abused domain in the 'From' has no effect and can't be used for filtering. So while you could so a similar filter on Sender, it wouldn't be as useful, and would provide less security benefit. Why is it useful in the From:? Seriously. Since the utility of DMARC has nothing to do with recipient end-user decision-making, why is DMARC's use of From: automatically better than having DMARC use Sender:? Attackers do all sorts of bad things. Some of those bad things don't actually matter. They might be unauthorized, ill-intended, and even make you or me uncomfortable. But they don't actually have any effect on getting bad mail delivered to recipients nor an effect on those recipients. Bad actors try all sorts of stuff. So pointing out what an attacker might or will do doesn't end the argument. What matters is the /effect/ of their actions, not the theory of their actions. I suspect that very little -- if any -- of the current use of DMARC relies on an end-user's address book. It's definitely the case that there are popular email services doing filtering/alerting based on addressbooks/known contacts, and I'm confident that DMARC's ability to force use of cousin/alternative domains makes this more effective. I did not say that address books are not used in some filtering work. I said that I doubted that it is relevant to DMARC use. Feel free to document counter-examples. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] What if... Sender:
On 6/24/2020 4:12 PM, Douglas E. Foster wrote: If DMARC settles on Sender, what tool will validate the relationship between Sende and From? None. Please explain why you think it has to. Not in terms of theory but in terms of observable practice. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] What if... Sender:
On 6/24/2020 11:35 AM, Jim Fenton wrote: On 6/23/20 9:19 PM, Dave Crocker wrote: On 6/23/2020 4:14 PM, Jim Fenton wrote: I do have a concern about Sender:. It has existing semantics defined in RFC 5322 Section 3.6.2, and this proposal might conflict with that I don't think it conflicts at all. So it will help for you to explain your concern in detail. Quoting RFC 5322 Section 3.6.2: For example, if a secretary were to send a message for another person, the mailbox of the secretary would appear in the "Sender:" field and the mailbox of the actual author would appear in the "From:" field. and If the from field contains more than one mailbox specification in the mailbox- list, then the sender field, containing the field name "Sender" and a single mailbox specification, MUST appear in the message. In the latter example, the From: header field could contain addresses from different domains, and the Sender: header field would indicate which of them actually sent the message. Not 'which of them', but 'who'. The point of the second quoted text is to mandate a separate Sender:, when the From: contains more than one address. But it does not specify a different semantic for Sender: If either message in question goes to a mediator, the Sender address in the original message would be lost and replaced by the email address of the mediator, and the original information would be lost. I'm not sure if that's a significant problem in practice, but pointing out the possible conflict with currently specified usage. One can indeed imagine a scenario where it matters, but no, it's not likely. In any event, the mediator is posting a new message and has a 'right' to retain or modify whatever it wishes. So if this is the 'conflict' you see, I'll disgree. Rather: Replacing Sender: is vastly better than modifying From:. That's the entire motivation for my suggesting DMARC switch to Sender:. Please explain why it is important that specifically the Sender: header field be used for this. From: is demonstrably problematic. Sender: isn't. Sender: is a long-standing field, similar to From:, but without it's history of interesting MUA-level use that DMARC is well-established as creating problems for. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] What if... Sender:
On 6/24/2020 9:31 AM, Alessandro Vesely wrote: On Tue 23/Jun/2020 20:49:11 +0200 Dave Crocker wrote: So if Sender: wouldn't be as useful as From:, why not? I'm a bit skeptic. The assertion that "DMARC protects the domain name in the address part of the From:" would have to be dropped. Of course. But why is that a 'problem' rather than just a fact? An obvious challenge in this type of discussion is to distinguish surface issues from underlying issues. So for every observation like this, about documentation language, we need to ask a version of "so what?" That is, how does it affect actual DMARC efficacy? The requirement that From: domain be "the identifier used for all message validation operations, as it is the single identifier in the message likely to be visible to the user" was among the founding intuitions of DMARC. We used to blame MUAs which don't display such datum... Don't we risk to loose design consistency with that move? Except that DMARC doesn't care about or use the MUA. Which is why I keep claiming that referencing the MUA in DMARC discussions is a distraction. Sender: has a display name and an address, just like From:. Don't we risk to double phishing opportunities? If Sender: and From: domains disagree, are both going to get reports? Why would there be a DMARC report on From:? Would that become v=DMARC2, or shall believers of strict From: have no chance? Modifying the protocol for such a minor issue as mailing lists sounds a bit of an overkill. I made a point of not trying to offer the specification details, yet, because those choices need to flow from an agreement on the basic conceptual change I'm suggesting. (My personal view is that it won't be necessary to declare a version change, but really let's wait on discussing the details, pending agreement to consider use of Sender:. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] What if... Sender:
On 6/24/2020 8:09 AM, Dotzero wrote: Sender: is completely irrelevant to the use of DMARC now. Actually, I'm claiming it isn't. Or rather, I'm claiming there is a failure to appreciate that it is really Sender information that is important, not author information. The fact that DMARC only has to do with a domain name tells us that this is about an organizational actor and not a person. My claim is that it is sufficient to focus on the operations actor rather than the author actor. Again, note that RFC 733 (on up through RFC 5322) permit Sender: and From: to be conflated. I'm suggesting making sure they are separated, and then adjusting the DMARC focus -- and especially discussion -- from author to operator. (Well, not so much adjusting the focus as correcting the error of thinking that it's the author that matters.) As you have mentioned many times in the past, the burden is on the person making the assertion. You have not provided a compelling case that Sender: would be a more useful value to validate on than From:. We have substantial enough experience on the value of the use of From: and the only experience with Sender: (SenderID) was in essence a failure. We know that the use of From: causes some serious problems. Using Sender: would eliminate them. I'm not clear why that seems an insufficient justification. (Unless there a demonstration that using Sender: rather than From: alters DMARC's observable -- rather than supposed -- efficacy.) Again: end-user recipient decision-making is irrelevant to meaningful email abuse handling. While this may in fact be true now, it may be a function of the presentation of the information to the end user rather than the content of the information itself. I think I don't understand what that means. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] What if... Sender:
On 6/24/2020 7:04 AM, Jesse Thompson wrote: On 6/23/20 1:49 PM, dcroc...@gmail.com wrote: So... what if DMARC's semantic were really for the Sender: field? If a message has no separate Sender: field, then of course the domain in the From: field is used. Wouldn't MUAs need to consistently display Sender? They don't consistently display From: More importantly, MUAs are essentially -- or completely -- irrelevant to the use of DMARC now. I don't see why that should change. Again: end-user recipient decision-making is irrelevant to meaningful email abuse handling. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] What if... Sender:
On 6/24/2020 2:56 AM, David I wrote: Specifically, alignment on 'From' allows automated checks against addresses of known, trusted contacts from addressbooks So does alignment on Sender. Yes, the addresses in From: vs. Sender: might be different, but that doesn't mean the same assessment mechanisms that can be used on a From: address can't also be used on a Sender: address. If the authentication is of a value which isn't related to the entry in the addressbook, I don't see how this kind of checking/filtering can be done, and so wouldn't be as useful. Unless there's a way I've missed? I suspect that very little -- if any -- of the current use of DMARC relies on an end-user's address book. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] What if... Sender:
On 6/23/2020 4:14 PM, Jim Fenton wrote: I do have a concern about Sender:. It has existing semantics defined in RFC 5322 Section 3.6.2, and this proposal might conflict with that I don't think it conflicts at all. So it will help for you to explain your concern in detail. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] What if... Sender:
Folks, This note is partially triggered by Mike's note this morning, but isn't specifically responding to it. Rather it tries to elaborate on a premise I've been implying but haven't been explicating: What if the rfc5322.Sender field were typically/always present? Or at least, what if it were always present for domains publishing DMARC records? What if messages generally had Sender: fields, even when they are the same as the email address of the From: field? So for such domains the From: really would only be the author information and the Sender: would be the operational handling/sending information.(*) The thrust of my reference to making a separate Sender: field prevalent is an assumption that the patterns of evaluating email addresses could adapt to take advantage of the reliable distinction. For one thing, it could clarify the nature of the information used for filtering. Currently we conflate 'handling agent' (or 'transmission agent') information with 'authoring agent' information. This leads to statements about end-user effects that actually are fundamentally wrong, even as the use of supposed author address information is demonstrating filtering efficacy. What would happen if filtering agents had an explicit distinction between 'author' and 'sender'? It might be claimed that they already do, since the DKIM d= field refers to a handling agent, rather than author, and is explicitly independent of any other message address information. So, why isn't it reasonable, for example, to have DMARC publish a record declaring a requirement for a DKIM or SPF record, independent of From: field alignment? That is, publish a record that says all mail by agents of that domain is always authenticated? It's because the signature needs to be tied to a field that is already 'interesting' and always present. Otherwise there is no way to know what domain name to look for. In practical terms, the only available choice has been From:. First, it certainly has an interesting semantic -- but really semantic/s/ -- for the address, and second, it's always present. So... what if DMARC's semantic were really for the Sender: field? If a message has no separate Sender: field, then of course the domain in the From: field is used. The would produce obvious possibilities: From: someone@goodplace.example Sender: someone@goodplace.example and From: somone@goodplace.example Sender: some...@mlm.example.com where there might be a dmarc record for mlm.example.com The modification to DMARC would be "look for Sender: and if it isn't present, look for From:. Obviously, mlm.example.com might instead be badactor.example.com. but we already have to deal with cousin domains, and DMARC does nothing about them. So if Sender: wouldn't be as useful as From:, why not? d/ (*) Mike took exception to my using "processing" as a term for Sender:. He's probably right and it might be worth some separate discussion to make sure there is useful and precise language to cover what the semantic of Sender: should/must represent. There is a continuing problem in the industry that the word "sender" is used to cover all sorts of agents, from author, to originating MTA, to Mediating MTA. Should it be 'any agent that touches the message' or 'any agent the does a sending operation of the message' or 'the specific agent the posts the message into the mail handling system' or something else? Note that for mail going through a mediator, there are at least two entities qualifying for the 'posting' definition: The author's originating MSA and the MLM's MSA. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mediation
On 6/21/2020 4:35 PM, Murray S. Kucherawy wrote: Armed with such a list and a plan, I can see what the IRTF Chair thinks of the idea. cool! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
smitter always has their messages properly signed by the domain in the From: address". For reference, I consider this an accurate summary of why I say that the From: field semantic is changed as a result of DMARC. Specifically so that mailing list mail can be delivered. Sender: was not meant to be the transmitter in that sense. It was meant to be the secretary who writes on behalf of a responsible person or system. RFC 5322 has preserved the semantic of the Sender: field: "The "Sender:" field specifies the mailbox of the agent responsible for the actual transmission of the message. " I consider that to be exactly the role the MLM is performing. RFC 5322 says display names are "associated" to a mailbox. I don't see such language in RFC 5322. In fact, other than the ABNF for display-name, I don't see any explanation of its semantic. Certainly, changing just the addr-spec breaks the association and wreaks havoc to address books. Exactly. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mediation
On 6/20/2020 1:08 PM, Murray S. Kucherawy wrote: It wouldn't be hard to put a draft together that described the trivial things like Subject field tagging and "two dashes at the end mark the start of a signature', and maybe a couple of popular and mostly harmless mutations the popular list servers do. I might know someone who could help with such a publication. (I can hear Dave and Pete, and perhaps Jim, chortling at my altruism...) Were I to chortle about any of this, it would be at the idea that any serious effort associated with email authentication could be considered altruistic... In terms of pragmatics, I think the issues here are time and risk. To get to a useful point will take too long for the current working group effort, and, given history and environment, its likelihood of being successful seems pretty low. That doesn't mean that none of it is worth pursuing, but rather than it might be worth considering independently of the current work and initially as IRTF-ish work, rather than IETF-ish. Perhaps if the effort were viewed as a staged sequence, over an extended time. Staging along the lines of: * Document a modest number of highly common 'patterns' of mailing list patterns. * Get reasonable community support (rough consensus) for the document -- including from MLM developers and operators * Formulate survivable authentication choices * Get reasonable community support for that approach * ... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mediation
On 6/19/2020 5:48 PM, Murray S. Kucherawy wrote: I wish in hindsight I'd tried it anyway as an experiment, with maybe a couple of senders, receivers, and mailing lists as participants. While I can imagine devising something that would look appealing, I believe it would have had a foundation of sand, in terms of operational realities, since none of what it would be relying on was documented standards and, again, there was (and I suspect remains) a view that mailing list operators did not make good candidates for reliable adherence to IETF 'standards'. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mediation
On 6/19/2020 3:13 PM, Brandon Long wrote: There were several attempts to come up with alternative signing schemes that would allow messages to pass through mailing lists and still be verified as "untampered" with, and we were unable to come up with such a thing. Perhaps we could have constrained ourselves to a 80 or 90% solution, and that would have been sufficient and a better solution than From header rewriting. Everyone has their opinion on the must haves for mailing list message modification, and it becomes quickly intractable. There's a chance that it is possible to specify a small range of modifications and arrange a style of signing that could survive them. So for originating and mediating sites that conform to that range, a 'preserved' original authentication might be possible. However... I don't remember enough detail from the original dmarc discussions, so I don't remember how much of this was discussed, but I vaguely think it was covered. Anyhow, there is a long track record of difficulties getting mailing list systems and operators to adopt external standards, and it isn't clear (to me) that the small range would be useful enough. These risk factors do not encourage pursuing the complexities and costs of a global standard. That leaves just a staged trust model, establishing a basis of accountability (and reputation) for the mediator sequence. Hence, ARC. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mediation
On 6/19/2020 2:20 PM, Pete Resnick wrote: Crap. My deepest apologies to Dave. I am very embarrassed by fat fingering that. It is not the worst private thing I've ever sent to a list, but still. A bigger concern should be with thinking that such paternalism is appropriate. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mediation
On 6/19/2020 12:02 PM, Pete Resnick wrote: On 19 Jun 2020, at 13:38, Dave Crocker wrote: The description of what a Mediator might do is not incompatible with also viewing it as having characteristics of a publisher: ### [5.3](<https://tools.ietf.org/html/rfc5598#section-5.3>). Mailing Lists ... In addition to sending the new message to a potentially large number of new Recipients, the Mailing List can modify content, for example, by deleting attachments, converting the format, and adding list- specific comments. Fair enough, but as you mention below, in the case of the common mailing list, the intent is simply to redistribute the message with minimal change (hence the retention of the Message-ID: and the From:). While, yes, that's the goal of some and probably most lists, that isn't quite what I said. Please re-read my text, which notably did not contain the word 'minimal' and frankly had a different focus. That focus doesn't exclude minimality, but it wasn't the point. That said, I do disagree with the reasoning given with regard to why 5321.MailFrom has changed: It's not because of the authorship, but rather because it is responsible for the submission onto the network, just as the ReSender is in 5.2. I did not anything about MailFrom, or for that matter anything about any field with an identifier. I'm guessing that your reference is to the fact that a mailing list service might put its own address into the MailFrom, so it gets handling error messages? That issue and behavior predates DMARC by a lot. Probably two decades. Maybe more. Note that in terms of email transport, it is posting a new message. Strictly in terms of transport, yes. But in terms of the layer above (the 5322 layer), it is usually the same message; see the second Note: in RFC 5322 section 3.6.4: Note: There are many instances when messages are "changed", but those changes do not constitute a new instantiation of that message, Except that there are many instances when messages might be changed that DO constitute a new instantiation of that message, and 5322 gives no guidance about what determine one versus the other. None of which is relevant to the point that a mailing list service has its own agency and is free to do what it wishes to and with the messages it is re-posting. That most seek to preserve essentially all of the author's text is fine, but whether and how much is more of a 'business' decision than a technical one. Mediators really have complete freedom to do whatever they want. If describing the full range of what a publisher might do, it would cover the same range. Well, "complete freedom" in the sense that no Internet police prevent such actions. I didn't mean anything so nit-picky. I mean that they are providing a value-added service to users and have their own agency to decide what that service looks like. If they want to do assorted message modifications that are substantial, and if users of the service like the nature of those modification, the service is free to do them. There is no specifications that dictate or even suggest, what one of the services must, or even should, do. So your reference to Internet police is ironic, because there is nothing to guide enforcement. But for most mediators, large substantive (for interesting definitions of "substantive") changes are outside of the scope of their definitions, and would probably invite someone to say, "That's not being a mediator." Certainly that would happen in the case of an alias or a resender. If there is a specification that would move such a declaration out of people's personal opinions and into objective, technical assessment, I apologize that I don't know what it is. But typical mediators are trying to maintain a sense and ability for the original author and the final recipient to experience an end-to-end message exchange. Yep. That's the point I was trying to make. Except you seem to be pressing this as essentially a requirement they have whereas I'm pressing it as a business decision, not something inherent in the nature of mailing list behavior. The degree to which the mediator asserts itself more visibly to the recipient is probably the degree to which it looks more like a publisher and less like a simple relaying service. And eventually, I would contend, less like a mediator. I probably wouldn't like it either, but we don't have objective criteria for accurately and reliably applying or withholding the term, do we? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On 6/19/2020 11:22 AM, Jim Fenton wrote: That comes back to the question of whether the domain in the From header is visible in the MUA, and if visible, does it alter user behavior (e.g., discourage users from clicking phish links). Different people have different opinions on that. A small point that keeps being ignored is that there is quite a bit of objective information showing that it does NOT have an effect. As far as I'm aware, there is no objective data that it DOES have an effect. So, no, this is not just a matter of differing 'opinions'. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On 6/19/2020 10:41 AM, Todd Herr wrote: Not only that, but DMARC is the only one of the three that is necessarily tied to the domain in the (usually) visible in the MUA From header. Todd, There is no evidence that end-users are relevant to manipulated/fraudulent From: fields or that DMARC's "certifying" the domain name of the From: field is relevant to reducing end-user vulnerability. There is quite a bit of evidence that improving trust signals to end users has no significant effect. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Mediation (was: Re: Header munging, not ARC, can solve the mailing list problem)
On 6/19/2020 9:40 AM, Pete Resnick wrote: On 19 Jun 2020, at 10:38, Alessandro Vesely wrote: consider a mailing list as a publishing organization, which is what it is. No, it isn't. It is a Mediator. See RFC 5598. The description of what a Mediator might do is not incompatible with also viewing it as having characteristics of a publisher: 5.3 <https://tools.ietf.org/html/rfc5598#section-5.3>. Mailing Lists ... In addition to sending the new message to a potentially large number of new Recipients, the Mailing List can modify content, for example, by deleting attachments, converting the format, and adding list- specific comments. Note that in terms of email transport, it is posting a new message. Mediators really have complete freedom to do whatever they want. If describing the full range of what a publisher might do, it would cover the same range. But typical mediators are trying to maintain a sense and ability for the original author and the final recipient to experience an end-to-end message exchange. The degree to which the mediator asserts itself more visibly to the recipient is probably the degree to which it looks more like a publisher and less like a simple relaying service. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On 6/18/2020 10:16 PM, Jim Fenton wrote: On 6/18/20 7:35 PM, Dave Crocker wrote: vulnerability? Yes. When bad actors (your choice of words) can work around an aspect of the specification that is depended upon to enable differential handling by a receiving filtering engine (again your choice of words), that is a vulnerability. Thanks for explaining what vulnerability means, but my question was meant to prod you to explain what vulnerability you claim is there. I've looked over your postings of the last few days and somehow I'm not seeing that described. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On 6/18/2020 4:01 PM, Jim Fenton wrote: It would be remarkable for IETF to achieve rough consensus on a specification with a known vulnerability while we "wait for the bad actors to catch on." Particularly when that vulnerability relates to an aspect of the specification that has caused widespread deployment problems. vulnerability? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On 6/18/2020 2:10 PM, Jim Fenton wrote: On 6/17/20 12:11 PM, Pete Resnick wrote: On 17 Jun 2020, at 13:27, Dave Crocker wrote: DMARC has nothing to do with display of author information to a recipient, and everything to do with differential handling by a receiving filtering engine. Were the Sender: field always present, that would be the one that DMARC should have used. It could have chosen the more complicated, "Sender unless not present, in which case From". But yes, this bit I get. That said, there are people who have argued that From: was chosen because Sender: was not displayed. I think that's a silly argument, but it's one that people still believe. I'm trying to understand why alignment to any header field is important to DMARC in that case. Because operators have found useful correlations in distinguishing between messages that are aligned and being 'genuine' versus ones that are not aligned. In the abstraction of theory, you are correct that it shouldn't matter. In the brutality of practice, it appears that it does. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On 6/17/2020 9:56 AM, Pete Resnick wrote: No, the semantics of From: have not changed generally. It's that some mailing lists have to change the semantics of From: in the face of the inability of DMARC to express the semantics that they want. The two sentences seem to be in conflict. If there is a degree of practice that creates a different semantic for the field, then its semantics have changed, at least for the portion of email traffic. Here's a simple operational test: MUAs typically can aggregate messages 'from' the same author. After all, that's always been the primary role of From, to indicate who created the content. Such aggregation is usually found to be helpful. Historically -- for 40+ odd years -- this has worked for mail going through mailing lists. Now it usually doesn't. I'd appreciate an explanation of how that does not constitute a change in semantics. Have a folder with a variety of messages from correspondents, where some of a person's messages are sent directly to you and some of their messages are sent through mailing lists that adapt the From: field content in order to avoid DMARC rejection. The MUA will handle mail from the same person, but that went through these two different paths, as being from different sources. DMARC relies on From: because it is the only field with an identifier that is always present. Sender is not reliably present, except virtually. The nature of what DMARC is actually doing looks more like relying on the operations-related Sender: field than the author-related From: field. DMARC has nothing to do with display of author information to a recipient, and everything to do with differential handling by a receiving filtering engine. Were the Sender: field always present, that would be the one that DMARC should have used. So, really, DMARC has altered the semantics of the From: field to be the Sender: field. The nature of the hack that mailing lists do, when altering the From: field, makes this clear: They alter information about the operator handling the message, destroying the original information about content authorship. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On 6/14/2020 10:29 PM, Jim Fenton wrote: On 6/13/20 8:17 PM, Dave Crocker wrote: On 6/13/2020 7:53 PM, Jim Fenton wrote: Alas, others do, Other groups do all sorts of things. They once mandated OSI, for example. Please explain how that is relevant, here and now. The WG needs to consider the operational impact of DMARC deployment if it is going to publish DMARC as a WG document. Are you perhaps suggesting that the technical work of the IETF should worry less about technical quality and more about possible use/abuse by other agencies? That is a false dilemma. We can (and should) consider possible use/abuse of specifications we publish, but that does not imply worrying less about technical quality. Some people send spam. We'd better deprecate all the email specifications. Some agencies make silly or terrible rules. And there are so many agencies. We'd better shut down the IETF because any specification can be abused and probably will be. Perhaps you can offer a rather more focused, specific and deterministic concern? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] why ARC
On 6/14/2020 10:25 AM, Kurt Andersen (b) wrote: On Fri, Jun 12, 2020 at 5:52 PM Dave Crocker <mailto:dcroc...@gmail.com>> wrote: > ARC lets the recipient look back and retroactively do the filtering > the list didn't. The concern about the creator of an ARC chain spoofing the purported origin of a message is valid. By "creator" do you mean "initiator" (aka, the source of the first ARC set, i=1)? yes. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On 6/13/2020 7:53 PM, Jim Fenton wrote: Alas, others do, Other groups do all sorts of things. They once mandated OSI, for example. Please explain how that is relevant, here and now. Are you perhaps suggesting that the technical work of the IETF should worry less about technical quality and more about possible use/abuse by other agencies? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] why ARC
ARC lets the recipient look back and retroactively do the filtering the list didn't. The concern about the creator of an ARC chain spoofing the purported origin of a message is valid. The above statement is correct, but needs to be augmented: Based on the reputation of the creator of an ARC chain, ARC let's the receiving filtering engine do filtering based on the proffered address of the originator. (Recipient end-users are irrelevant to this process.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC bis: ticket 66: define what is means to implement DMARC
On 6/8/2020 11:18 AM, Scott Kitterman wrote: I was trying to suggest that the topic of this ticket (defining conformance requirements) should wait for a BCP and that as a separate topic the terminology should be fixed in the DMARC bis effort. I think we agree. ahh. yes. conformance is indeed quite separate. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC bis: ticket 66: define what is means to implement DMARC
On 6/8/2020 10:49 AM, Scott Kitterman wrote: I think your point that the terminology needs improvement is valid, but I don't think it's this issue specifically. I think it would make this issue easier to solve in an eventual BCP, but I think it stands on it's own as something we should look into for this document, not just a future one. Separating basic terminology from basic technical specification doesn't make much sense to me. Terminology and its use is established in the specification of architecture, format, and protocol, not some possible, later document about operational issues. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC bis: ticket 66: define what is means to implement DMARC
On 6/8/2020 10:21 AM, Seth Blank wrote: As Chair, what I'm hearing is that this is a real issue, and may need clarification in a BCP, not the primary document. Assuming the base DMARC document is modified, I'd strongly suggest making these terminology distinctions in that document. Especially since it already has a section discussing 'implementation'. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC bis: ticket 66: define what is means to implement DMARC
On 6/8/2020 9:54 AM, Scott Kitterman wrote: Conformance requirements to support contracting is not something the IETF typically does. I think deferring this to a follow-on BCP is appropriate. While true, of course, there is a continuing confusion between the two sides of protocol exchanges, especially the indirect kind involving a DNS entry. Some specification help make the distinction rather clear, such as calling one client and the other server. DKIM distinguishes 'signing' from 'verifying'. DMARC seem to provide clear labels for making the distinction. Worse, section 8 on implementations conflates send and recieve (and doesn't even comment on the DNS record.) So public discussion might be aided by having and using some clear, consistent language, along the lines of: 1. DMARC Owner Record 2. DMARC Report Sender 3. DMARC Report Receiver 4. ...? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On 6/7/2020 8:04 PM, Murray S. Kucherawy wrote: If I wanted an organization policy that controlled when Friendly Name was displayed or DMARC status was displayed, I would have to find and distribute plug-ins to all of these products. As best as I have been able to tell, no such plug-ins even exist for Outlook and the other products do not accept extensions. There is an opportunity here for valuable standardization. The IETF has routinely punted, at least in the email space, on the idea of prescribing or proscribing user interface behaviors because we are protocol engineers, not human factors experts. Are you claiming that's changed? A 'friendly' amendment, or rather addition: The origination side of an email exchange has no authority over the reception side. Different administrative authorities. Compliance with DMARC is voluntary -- and receiving administrations often implement behaviors that differ from what is requested via DMARC. There is no basis for believing that requests about MUA display will achieve meaningful support on the receive side, nevermind whether they would be at all useful. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On 6/7/2020 2:40 PM, John Levine wrote: I believe the real question is*whether* to show trust data to users and the consensus seems to be don't bother, it only confuses them. It's not that it 'seems to be'. It isn't nearly that soft. It is that there have been multiple efforts over the years and none has demonstrated efficacy. Anyone claiming the contrary needs to provide objective data to substantiate a claim of efficacy. Adding a capability or relying one carries an affirmative obligation to provide a basis for knowing that the cost is justified. So far, there isn't one, for end-user trust notifications. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] About user notification in the MUA
On 6/7/2020 4:04 PM, Douglas E. Foster wrote: Given that market reality, I conclude that most vendors and their customers believe that user-signalling is useful. The signalling system does not have to prevent every mistake for the signal to be useful. What you are describing has nothing at all to do with system-provided trust assertions. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On 6/7/2020 10:53 AM, Stan Kalisch wrote: Assuming this can be practically done, I would rephrase this, "...[E]stablish how MUAs should display trust data to users." Since there has been a demonstrated lack of efficacy in this sort of display, there needs to be an objective basis for knowing that any new such requirement will be useful. Good luck with that. On 6/6/2020 2:42 PM, Scott Kitterman wrote: 1. I think the domain displayed to the end user matters. In my sample size of 1, it matters to me. I know I'm not the average user, but independent of t I might be wrong, but I believe the IETF does not intend to make global standards on the basis of possible utility for only one engineer working on the specification. Or two. Or three. cf, above. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On 6/6/2020 2:23 PM, Scott Kitterman wrote: If things like DMARC, SPF, and DKIM do nothing more than get abusers to use different domains than they would otherwise, I think that's a win. The issue here is DMARC, not SPF or DKIM, since DMARC is the only one of the 3 that restricts the choice of domain name. With that in mind, I'll ask you why you think the kind of change you cite is a win. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On 6/3/2020 10:20 AM, Alessandro Vesely wrote: On Wed 03/Jun/2020 18:43:16 +0200 Dave Crocker wrote: On 6/3/2020 9:38 AM, Alessandro Vesely wrote: MUAs should be discouraged from displaying or using Author:, unless (verifiably) signed by a trusted domain or otherwise configured by the user. Why? That avoids the dreaded back-to-square-one path that Brandon conjectured. It prevents attacks based on this field, while maintaining the DMARC paradigm. The barrier you specified sounds reasonable. But it isn't. Any signature put in place when the Author: field is created is likely broken by the time it gets to the recipient. That's the entire problem that necessitates rewriting the From: field. We do not require 'signatures' on Subject: or the Body or Date:. This is just one more field. The concern about square one is misguided, apparently mostly because it continues the erroneous belief that the validation work is done for the end user, rather than the filtering engine. Besides that, it ignores the fact that authentication mechanisms are presumably still in place. Users are tricked by the content of the message, not by the From: (or Author:) field. On the other hand, a clean From: (or Author:) field enables consistent MUA organizing of messages. Messing with the From: (or Author:) field by intermediaries defeats that. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On 6/3/2020 9:38 AM, Alessandro Vesely wrote: MUAs should be discouraged from displaying or using Author:, unless (verifiably) signed by a trusted domain or otherwise configured by the user. Why? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On 6/2/2020 5:45 PM, Seth Blank wrote: There's a lot of clear and generally consistent data that shows From: header field spoofing leads to outsized impact on end users. Odd that I've never seen it. Odd that it didn't surface during the literature search that was done when BIMI was started. Again: Please point to work that is specific to this issue and, just in case it is part of a larger tome, please point to the specific place in the document that is relevant to this issue. However, if by "credible" you mean peer reviewed and not presented by someone with something to sell in preventing the problem, that may be missing (although, it only tends to be systems with a part to play in preventing abuse that are even capable of seeing and distinguishing the issues) and could be an interesting independent study to run. People with something to sell often do serious research. And they often document it. But this is quite different from marketing literature or hallway discussion. I'm asking to see the research writeups. (I made that plural since you are so firm in saying there is lots of supporting research.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On 6/2/2020 5:13 PM, Seth Blank wrote: On Tue, Jun 2, 2020 at 4:02 PM Dave Crocker <mailto:dcroc...@gmail.com>> wrote: On 6/2/2020 3:53 PM, Seth Blank wrote: > The point I was trying to make is that consumers are susceptible to > fraud, Of course they are. Unfortunately, that point is irrelevant, because it isn't the question at hand. Dave, this is exactly the point where I think we're on different pages. The From: domain matters because its contents affect user behavior. Apparently I wasn't simple enough, so let's reduce this to the absurd reality that typically applies: If a user doesn't see it, how can it affect their behavior? Alignment matters, because it ensures that the domain which is authenticated matches what the user sees in the inbox (because, rightly or wrongly, inboxes show the contents of the From: header field). Except that most users don't see the From: domain name. When this match fails, a message can be rejected before it's ever in front of a user and capable of causing confusion or fraud. Exactly. What matters is that unalignment is presumed to demonstrate bad faith by the originator. THAT is what significant. And it's significant to the filtering engine, not the recipient user. The point is NOT to change user behavior due to what is presented in the From:, it is to prevent manipulation of user behavior by only allowing From: domains to be displayed if they have been authenticated. Yeah, but that's quite different from saying that a user who sees a bad from: field is manipulated. Your argument seems to be that you don't believe that spoofing the From: domain leads to user impact, or am I completely misunderstanding you? Where is the clear and credible research data that says that a bad From: field domain name specifically tricks end users? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On 6/2/2020 3:53 PM, Seth Blank wrote: The point I was trying to make is that consumers are susceptible to fraud, Of course they are. Unfortunately, that point is irrelevant, because it isn't the question at hand. and the system needs to stop these messages before they ever get in front of a user. Exactly. And that's why claiming that making the From: field domain name better (or worse) in changing recipient user behavior is wrong. The signal I was talking about is from the data: when something tries to authenticate to an MTA but then tell the user it's someone else. That's what alignment fixes and what's so powerful about DMARC. Seth, your statement is so confused, I'm not sure I can fix it up. "Authenticate to the MTA?" DKIM and DMARC don't do that. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On 6/2/2020 2:42 PM, Seth Blank wrote: Also, from literally today: https://www.justice.gov/usao-sdtx/pr/man-admits-spoof-email-fraud-scheme-and-more Oh my. Is it really that difficult to understand the difference between choosing to take an action, versus being affected by your taking that action. Let's keep this simple: 1. Most users do not see the domain name in the From: field. So how could using a cousin domain or any other misbehavior with the domain name, cause the recipient to be tricked? 2. Nothing in that article demonstrates that a recipient was tricked into misbehavior by the presence of a problematic From: field domain name. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
Wow. I'll ask folk to reread my text, here, carefully, since it specified something quite narrow and concrete, but is somehow being taken to have meant something broad and general: On Tue, Jun 2, 2020 at 1:46 PM Dave Crocker <mailto:dcroc...@gmail.com>> wrote: However there appears to be no actual evidence that lying in the From field affects end user behaviors, and certainly none that lying in the From field about the domain name does. And again, there are all sorts of threats and all sorts of bad behaviors, but the question is whether a particular kind of bad actor behavior affects recipient end-user behavior. And the specific kind is lying about the From: field domain name. Please point to specific research -- not an extended report with lots of varying content. On 6/2/2020 2:30 PM, Seth Blank wrote: There are decades of data that prove just this. As I said, we did an extensive literature search at the beginning of the BIMI and there was no supporting research. So now let's look at the purported counter-example you provided: On the abuse side, Microsoft, Google, Proofpoint, Mimecast, and others (including Valimail) have all published reams of research reports over the years. On the marketing side, there's another decade or two of data about how properly crafting the From materially impacts open rates on messages, which means user behavior is certainly impacted by what's in the From and display name. There's more data here than can be meaningfully summarized. So to pick one at random about usage of these methods in abuse, read page 11 of this report: https://www.proofpoint.com/sites/default/files/pfpt-us-tr-q117-threat-report.pdf Doesn't contain the word 'behavior'. Doesn't contain 'from:' Only 'author' is reference to malware creators, not recipients. 'Recipeint' gets a brief sidebar reference to mail pretending to be from a top executive. Another sidebar with the word explains 'spoofing' as impersonation (which, of course, is what it means in the real world, but not in the email abuse world, which has a much broader definition. I'll stop now and note that the reference you gave appears to have nothing to do with the specific behavioral issue I cited. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On 6/2/2020 1:36 PM, Murray S. Kucherawy wrote: On Tue, Jun 2, 2020 at 11:01 AM Dave Crocker <mailto:dcroc...@gmail.com>> wrote: Your comment implies that what is displayed to the user is important in anti-abuse efforts, but there is no data to support that view, and some significant data to support the view that that's wrong. (cf, the extensive literature review that was done during early BIMI discussions.) That's a curious assertion given all of the energy that's gone into complaining about but never really resolving the "display name" problem over the years. I thought that was a key part of the vector of many successful phishing attacks. In the world of Internet protocol standards, there is a common problem in discussing anything involving users, failing to distinguish between the mathematics of abuse from the actual effects. That is, if I lie about the author, that's abuse in an absolute sense. But that can be quite different from whether that lie has any effect on the recipient. So, yes, lots of people have been upset constantly over the years about all sorts of abusive behaviors. However there appears to be no actual evidence that lying in the From field affects end user behaviors, and certainly none that lying in the From field about the domain name does. And since my notes on this thread seem to be having a difficult time being understood, I'll stress that my reference is specifically to end-user behavior. There other abuse factors, separate from that, which DMARC apparently correlates usefully with, which is why it apparently really is useful to the filtering engine. But not the recipient user. I suppose it's possible that operators came up with this problem and decided it needs solving, with no user complaints like "I was fooled by this fake From, can't you do something about that?" on which to base that. Exactly. Hasn't M3AAWG at least had something other than anecdata that this is a true source of pain? No. As I mentioned in the previous note, there was a literature survey done at the start of the BIMI work, and it produced no evidence to support claims of improved end user behavior. The canonical example of this issue was the EV web domain name exercise. DMARC is a triumph of infrastructure operator demands over end-user experience. it's created a markedly Procrustean email identification environment. The standards and the practice, for 45 years, have permitted certain freedoms in the From: field and DMARC eliminated them. It's easy to be cavalier about this, since some operators run highly controlled environments and have no incentives for paying attention to those who have used those freedoms legitimately, for 45 years. No reply here, just felt like citing this again. ditto. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On 6/2/2020 12:32 PM, Pete Resnick wrote: On 2 Jun 2020, at 13:29, Dave Crocker wrote: On 6/2/2020 11:12 AM, Pete Resnick wrote: On 2 Jun 2020, at 13:01, Dave Crocker wrote: There's no reason that DMARC couldn't have included the sender or tried to have some kind of PRA like spf v2... but that's not the goal. But the Sender: field is not reliably present and, of course, DMARC needs an identifier that is reliably present. Dave, could you explain that? Coding-wise, there's surely no reason that an implementation can't say, "if 5322.sender is present then sender = 5322.sender else sender = 5322.from". So you could say that the identifier of sender is reliably present, since it's taken from 5322.from if 5322.sender isn't present. But maybe I'm missing something. Please explain. Not sure what you are asking. What I mean is that it isn't always present. If Sender: contains the same address as From:, then Sender does not have to be present, and often/usually isn't. Well, that's the field, not its value. So when someone comes along and changes From: -- such as to hack around the DMARC problem for intermediaries -- the semantic of the Sender information is lost. If you do change the From, you should always add a Sender. (Or is your point that implementer's don't, and that's the problem?) Except that there's nothing that specifies that and I believe it isn't common practice. Worse, creating that field in mid-stream does not fix the problem that now the author information is lost. The actual requirement is to have the Sender field always be present at the time of original posting, and have DMARC work from the Sender field. But since none of that is going to happen, I'm looking for a path to providing clean original-author information that is practical. What I'm missing is why the lack of an actual Sender: header field is problematic. Because DMARC should have focused on the Sender field, not the From field, since it is really about the email operator, not the author. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On 6/2/2020 11:12 AM, Pete Resnick wrote: On 2 Jun 2020, at 13:01, Dave Crocker wrote: There's no reason that DMARC couldn't have included the sender or tried to have some kind of PRA like spf v2... but that's not the goal. But the Sender: field is not reliably present and, of course, DMARC needs an identifier that is reliably present. Dave, could you explain that? Coding-wise, there's surely no reason that an implementation can't say, "if 5322.sender is present then sender = 5322.sender else sender = 5322.from". So you could say that the identifier of sender is reliably present, since it's taken from 5322.from if 5322.sender isn't present. But maybe I'm missing something. Please explain. Not sure what you are asking. What I mean is that it isn't always present. If Sender: contains the same address as From:, then Sender does not have to be present, and often/usually isn't. So when someone comes along and changes From: -- such as to hack around the DMARC problem for intermediaries -- the semantic of the Sender information is lost. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On 6/2/2020 10:11 AM, Brandon Long wrote: And if the mail client displays the Author, then we're kind of back to square one with displaying unvalidated data to the user. No we aren't. Your comment implies that what is displayed to the user is important in anti-abuse efforts, but there is no data to support that view, and some significant data to support the view that that's wrong. (cf, the extensive literature review that was done during early BIMI discussions.) What matters is what is done by your filtering engine -- and what is in the message content -- not what is displayed to the user in the From field. I understand that DMARC has been useful, but I believe this is confusing correlation with causation. The cause is down in the filtering engine. There's no reason that DMARC couldn't have included the sender or tried to have some kind of PRA like spf v2... but that's not the goal. But the Sender: field is not reliably present and, of course, DMARC needs an identifier that is reliably present. At some point, you're going up against the existing mail client design and of course how users act, and of course all of that is messy. The "clean" strictness and mechanical nature of DMARC is ultimately up against the fuzzy ux design and fuzzier humans. DMARC is a triumph of infrastructure operator demands over end-user experience. it's created a markedly Procrustean email identification environment. The standards and the practice, for 45 years, have permitted certain freedoms in the From: field and DMARC eliminated them. It's easy to be cavalier about this, since some operators run highly controlled environments and have no incentives for paying attention to those who have used those freedoms legitimately, for 45 years. On top of that, the author domains basically want to control who can send on their behalf, which is a reasonable goal as well. That's a rather small subset of domain owners. While DMARC was original developed for that select community, its vastly broader use results in over-applying that restriction. AGAIN, I'm not suggesting changing DMARC or the current reality for the From: field. RATHER, I'm suggesting making it possible for recipients to regain usefulness of the author information that the From: field was intended to provide but no longer does. FOR THOSE FEW DOMAINS that really want to get strict about who gets to claim to be an author associated with a domain, then do something like add a DMARC option that prohibits use of the Author: field. (Note that just having DKIM and ARC pre-sign a non-existent Author field accomplishes this, too...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On 6/2/2020 9:44 AM, Jesse Thompson wrote: I'm relaying these DMARC questions/concerns on behalf of an email admin at another university. I quickly searched this list's archives for the Sender header vs DMARC alignment issue and don't see much aside from a conversation in May 2015. Is it worth further discussion and/or an issue in Trac? I think I know the answer to the second concern, but I'll defer to people more adept at explaining the nuance. See below... Thanks, Jesse Thompson UW-Madison " I don't see on the list of issues the most fundamental problem of DMARC, namely that it conflicts with RFC 5322 on the use of the From and Sender header fields [1] and possibly with RFC 6326 as to the significance of DKIM fail [2]. The former is the more serious problem. Making DMARC alignment part of a standard for Internet messages requires a revision of RFC 5322. I'd love to see this resolved. As one of the folk who created the Sender: construct in RFC 733, I'll suggest that the concern raised here has merit, though dealing with the fact isn't straightforward. It's an issue I've been wrestling with for a couple of years. In reality, all of the current email anti-abuse authentication methods concern the email operator, not the author. The problem is that, in the message, the only identifier that is reliably present is the rfc5322.From field email address. The underlying design choice in RFC733 -- 45 years ago -- was in making Sender: optional when it's content is the same as the From: field. It never occurred to us that one of them might need changing along the handling path. The lesson to future designers is to strongly resist conflating otherwise-independent semantics for "efficiency". DMARC enforcement requires that the DKIM/SPF domain be the same as the author From:. That is, the folk doing email operations have to be able to sign the DMARC aligned domain. Hence the From: field is now really the Sender: field. The From: field fixup hacks that are needed by intermediaries, to avoid DMARC-based rejections, makes this fact painfully clear, even as they serve to undermine recipient use of the From field for author-related message management. Given the depth and momentum of DMARC's effects, I don't think it's realistic to try to fix this via changes to the From: field. The only suggestion I've been able to formulate is: create a new field, such as Author:. (Give it a simple, clean, appropriate name, rather than something like Original-From.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?
On 5/20/2020 8:29 AM, Kurt Andersen (b) wrote: Agree 100% This looks like it has a strong constituency against the proposal, a much smaller constituency in favor of it, and little or no offered benefit. Yes? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?
On 5/15/2020 9:54 PM, Hector Santos wrote: Protocols should be flexible. Adding it doesn't mean replace. Explain the need. Convince plenty of folk that it is necessary enough that they are inclined to write the code, deploy it, and use it. Adding things is expensive. Flexibility that does not have a clear need is especially expensive. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?
On 5/15/2020 3:09 PM, Murray S. Kucherawy wrote: +1, unless there are known cases where the XML payload size is a problem that switching to JSON would solve. For any interesting specification, there are many ways to improve it. The question is whether the improvement is worth the effort. So, when someone suggests a change, there should be an expectation of an accompanying explanation that makes the change compelling. A particular trap is changes that are fashionable rather than important. That is, they suit the tastes of the day, but they don't really fix a problem or makes things markedly better. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Composition Kills: A Case Study of Email Sender Authentication
h DKIM signatures to theiroutgoing emails, enabling the attackers to impersonate otherusers of the email provider The writing of the paragraph's conclusion seems to be fundamentally misleading or wrong. It seems to be saying that the DKIM signature will be for the domain in the From: field, which it won't. Security requirement.To achieve this goal, I'm not sure exactly what goal they are referring to. (1) TheFromheader of the email thatSsends matches theauthenticated username (other users ofScannot spoof Alice’saddress); This requirement applies only in the presence of DMARC. (3) SPF/DKIM and DMARCcomponents inRconsistently authenticate the same identifier Except that SPF and DKIM are permitted to validate other identifiers, not just the one in the rfc5322.From field. This require-ment, although intuitive, implies a set of semantic bindingrelations that every component in the email processing chainmust respect. This is imposing a requirement for deep, internal systems knowledge about features that are not, in fact, deeply embedded in email history or processing. Arguably, the demand for having every component enforce this model is a basic mistake. Rather the requirement is to prevent assumptions inside the system that serve to violate the policies needed at evaluation points. > robust principle robustness https://en.wikipedia.org/wiki/Robustness_principle be permissive in how they process malformed inputs No, Postel did not direct accepting 'malformed' inputs. And RFC 1122, Section 1.2.2 elaborated on this issue very helpfully: Software should be written to deal with every conceivable error, no matter how unlikely; 4.1 HELO/MAIL FROM confusion This seems to imply that tightening is needed in DMARC, so that it uses an SPF domain that SPF has actually been validated? I think the issue is that SPF validation needs to inform DMARC what domain it has validated, rather than have DMARC decide which domain to fetch. SPF implementations treat “(a...@legitimate.com” as anempty MAIL FROM address, and thus forward the resultsof checking HELO to the DMARC component, because thestring in the parentheses can be parsed as a comment ac-cording to RFC 5322 [10]. Some DMARC implementations,however, may take it as a normal non-empty address, 1. This issues goes away if SPF supplies DMARC the domain name, rather than DMARC having to fetch it 2. I doubt this otherwise needs changes to language in the DMARC spec, but it's worth making sure. 4.3 Authentication results injection Another focus on what results are communicated and how. The paper asserts that AR is used as DMARC input. I suspect that is rarely, if ever, true. Yes? No? Generally, we can divideFromheader-relatedprocessing into two phases: 1) parsing a MIME message to extract the Fromheader; The rfc5322.From: field is independent of MIME. MIME pertains only to the body. Microsoft:disregarded our report (which included our pa-per and a video5demoing theA10attack) because the threatsrely on social engineering, which they view as outside thescope of security vulnerabilities. That's oddly impressive. Improving MUA display We note however that experiences with suchapproaches for promoting HTTPS (via browsers displayingtrusted icons for websites with valid TLS certificates) havedemonstrated the challenges of ensuring that users correctlyinterpret the icons and do not get fooled by imposters "Challenges" is incorrect. "Failure to be useful" is more appropriate language. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Summary comments on draft-ietf-dmarc-psd
er term, these operations are regulated. The domain suffixes > that PSD attends to are not public registries. > I suspect the name used derives from the name of the resource to which DMARC attached itself early on, namely the Public Suffix List. Debating its name is probably out of scope here. It's not, because the term facilitates a basic misunderstanding about the nature of the domain names involved here. That's why I am raising a concern about the term's use. And as Alessandro pointed out, the PSL was made for a different purpose and DMARC simply decide to use it to meet its own goals, which in turn supports DMARC distancing itself a bit. I believe where this is leading, though, is toward the notion that the use of the PSL should be considered external to DMARC. I don't think anyone has disagreed with that assertion. And yet both DMARC and PSD have text tied to the term and its function. > 2. Externalizing internal difficulties > > Some organizations have sub-groups to which various administrative > responsibilities have been delegated. In general, there can be many > levels of such delegation. Not just two. > > For the cases the PSD specification is intended to cover, > PSD seeks to adapt to slow DMARC adoption or non-existent domains for > one of its delegated sub-groups, by looking for an even-higher-level > encompassing record under a next-level Organizational Domain. That is, > PSD is specifying using two different Organizational Domains. The usual > one and its parent. > > A difficulty within the organization is being externalized to a burden > for everyone else on the net. Can you expand on how you see abuse of non-existent domains to be an exploitation of an internal problem? Specifically, what's the internal problem being exploited? I apologize for not being more clear about what I meant. I hope that the above effort elaborate on this suffices. Basically it concerns an organization's inability to get its subordinates to publish DMARC records and problems with PSLs that lead to identifying the wrong domain as an OD. Or somesuch... > 5. There is little engagement with the PSD technical effort > > It is easy to see why owners of some domains would want a mechanism like > PSD. As noted, they do have a real and significant problem. So, > statements of support from such folk merely confirm their need. (As an > aside I'll note that historically the IETF hasn't been all that > interested in simplistic statements of support but, rather, actual > involvement in the engineering discussion.) > > What such statements do /not/ provide is any indication that the broader > Internet community has an interest in adopting this. > > First, where are the statements of actively engaged support from an > interesting set of organizations on the other side of these queries? In > general, there has been a track record of limited adoption for anything > that changes infrastructure services, in the absence of a very > widespread perception of need, benefit, and tractable operational cost.. I don't think that accurately characterizes the situation for PSD. I think there's some validity here at least in the claim that the purported interest has not made itself both visible and enthusiastic. Such dearth absolutely does not rise to the level of supporting something on the standards track, to be sure, but that wasn't the goal here either. Heh. An IETF-approved 'experiment' is not a casual activity. A lack of a substantial and wide base of support normally has been significant, even for an IETF-track experimental RFC. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Summary comments on draft-ietf-dmarc-psd
this specification as an 'experiment' the specification does not give me a clear and concrete understanding of exactly what will be evaluated, or how, and what constitutes satisfactory accomplishment. I'm posting this primarily to finish an obligation and place it into the working group record, rather than from an expectation that it will be acted upon. Absent any indication of serious interest in serious and constructive discussion, I won't be pressing this further, other than possibly posting a pointer to it during IETF Last Call, as a formality. d/ - (1) The draft credits me for the term "public suffix". So I should apologize, since it is now clear to me that these suffixes are very much NOT public. They are private or governmental. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
On 2/5/2020 6:40 AM, Dave Crocker wrote: Help me understand. I'll try with the no idea why my text got truncated. what I typed was: I'll try with the other response I'm considering. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
On 2/4/2020 10:13 PM, Scott Kitterman wrote: On Tuesday, February 4, 2020 10:20:14 PM EST Dave Crocker wrote: I don't recall that scaling limitation was an embedded and acknowledged fact about that spec. And with a quick scan I don't see anything about that in the document. There is a difference between having some folk be critical of an experiment, versus have its non-scalability be an admitted limit to its future. That is, you or I or whoever might know a spec sucks and can't succeed, but that's different from having the formal process declare that an experiment is /intended/ not to scale, which seems to be the case here. This claim seems to me to be unrelated to anything in the draft. Would you please point to where you found this? Murray's 12/3 email: "I don't think it's based entirely on naivety. I think there's a healthy dose of feeling that the experiment as it's currently designed couldn't possibly scale to "the entire domain namespace" and/or "all servers on the Internet", so in that sense from where I sit there's a built in safeguard against this becoming a permanent wart." Why would the expectations for Experimental be higher than for Informational? LMTP is Informational, and it certainly needs to succeed. As a rule -- or certainly a solid pattern -- Experimental means that the document wants to be standards track or BCP but needs some vetting before being permitted that honor. Informational docs don't have an expectation of making it to standards track. Would you withdraw your objections if we made this informational? It would eliminate my concerns about this being Experimental, of course. With an equal 'of course', it would not affect the technical concerns. Help me understand. I'll try with the other note I'm considering. However my intent for that note is as a summary, not as offering some new material. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
(I am trying to formulate a response on the higher-level technical and process issues under consideration, but decided to respond now on these particulars, since they are more focused...) On 2/3/2020 10:47 AM, Murray S. Kucherawy wrote: Dave, On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker <mailto:dcroc...@gmail.com>> wrote: Nothing I've worked on at the IETF with such a label is something I would necessarily stand behind as Internet-scalable. Such as? RFC 6541 comes to mind. To the best of my knowledge, it's an experiment that never even ran. I don't recall that scaling limitation was an embedded and acknowledged fact about that spec. And with a quick scan I don't see anything about that in the document. There is a difference between having some folk be critical of an experiment, versus have its non-scalability be an admitted limit to its future. That is, you or I or whoever might know a spec sucks and can't succeed, but that's different from having the formal process declare that an experiment is /intended/ not to scale, which seems to be the case here. Implementations shipped, but its use on the open Internet was never detected or reported. And I had my doubts about the scalability of the second DNS check that was added to it, but it didn't seem like it could go forward without. One that wasn't mine: RFC 6210, an experiment to prove how bad something can be. There is a reasonable argument to be made that little about /any/ security spec actually scales well, but that's such a cheap shot, I wouldn't dream of taking it. However, yeah, "to find out how bad including hash parameters will be" does seem to provide an existence proof for using IETF Experimental to bench-test something rather than as a gateway to standard for that something. sigh. But I would probably expect something at Informational probably to scale, and anything with "Standard" in it certainly to scale. Laying any general expectation on an IETF Informational RFC would be a mistake, because there is so much variety in their content and intent. Why would the expectations for Experimental be higher than for Informational? LMTP is Informational, and it certainly needs to succeed. As a rule -- or certainly a solid pattern -- Experimental means that the document wants to be standards track or BCP but needs some vetting before being permitted that honor. Informational docs don't have an expectation of making it to standards track. So: Can you propose any sort of specific restructuring of the document or the experiment that achieves the same goal as the current version while also resolving your concerns? I'm pretty sure I've raised fundamental concerns about this work and that those concerns have not been addressed. The simple summary is that the way to restructure this work is to go back to first principles. But there doesn't seem to be any interest in having that sort of discussion. I thought we were having that sort of a discussion right here. Your position as I recall is that we have no choice but to take all of this back to first principles and separate DMARC from the determination of Organizational Domain (i.e., make them separate documents) before PSD can proceed. Unfortunately, that's accurate. At the least, I'd expect to see thoughtful responses and some breadth of support for those responses, countering the fundamental concerns I expressed. I don't recall seeing responses with such substance. (One of the challenges for me, in trying to formulate the 'thoughtful' response I'm considering is to provide/repeat a concise summary of those fundamental concerns. As I recall they were both architectural and operational.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
On 1/17/2020 12:06 AM, Murray S. Kucherawy wrote: On Mon, Dec 9, 2019 at 8:44 AM Dave Crocker <mailto:dcroc...@gmail.com>> wrote: The IETF does not typically -- or, as far as I recall, ever -- promote specifications known not to scale. (While I think of this concern as foundational to the IETF, it's a bit odd that nothing like it is included in the IETF's "Mission and principles" statement.[1]) I'm not sure that I would reasonably expect anything labeled "Experimental" to scale, especially if it were to make very explicit claims to the contrary. As a standalone bit of thinking that sounds reasonable, but it does not match my sense of IETF history, nor my sense of application of that model in the case of X-. What you describe makes sense for something out of the IRTF, not IETF. As for IETF history, while there certainly have been IETF Experimental RFCs that have failed, I don't recall their being /expected/ to fail. (I'm counting inability to scale as failure. If anyone has a different view of inability to scale, there needs to be a separate discussion...) For the latter: X- was an email header field construct design to make an explicit statement that something was /not/ a standard header field. I was added to the RFC 822 spec, though I do not remember who first suggested it, other than it wasn't me. I thought it a fine and reasonable idea, as did many others. Note that it was eventually deprecated. Because it did not work as intended: People using X- fields came to rely on them, creating defacto standards. That's the danger with an IETF stream RFC, especially one coming out of a working group: Those implementing and using an IETF published specification tend to come to rely on continuing to use it. Nothing I've worked on at the IETF with such a label is something I would necessarily stand behind as Internet-scalable. Such as? But I would probably expect something at Informational probably to scale, and anything with "Standard" in it certainly to scale. Laying any general expectation on an IETF Informational RFC would be a mistake, because there is so much variety in their content and intent. > Comparing it to the "obs" grammars of days of yore, the PSD proposal > is much too expensive to become engrained as-is, whereas the old > grammars were relatively easy to carry forward. I don't quite grok the reference to "obs", and mostly think of the introduction of that construct in RFC 2822 as an interesting idea that, itself, failed. (I see it as being instructive on the challenges of designing for transition from an installed base.) That was indeed the intended reference. I don't understand how you see benefit in citing a reasonable idea that failed -- obs- did not serve its intended purpose and was in a standards track specification: The obs- rules both weren't deprecated from later work and continue to be relied on. If anything, it validates my concern about entrenched use. All sorts of experimental specs fail. But they aren't /expected/ to fail. And they aren't expected to be unable to scale. This one isn't expected to fail, If it is known that it can't scale, that's inherent failure for IETF work. but its mechanism is not (as far as I can tell) intended to be permanent, nor could it become so. You keep making statements that warrant this as IRTF work, not IETF work. Since one of your core assertions is that the IETF shouldn't publish things like this, I have suggested that, as a compromise, interested parties proceed with the experiment using the document in its draft state. Sounds like a fine idea, to me. Unfortunately I am also regularly reminded that there are organizations wishing to participate in this experiment and related work but which simply cannot, by reason of policy, do so without this document being first approved for publication. That should raise some very bold, very large red flags about publishing this as an IETF stream RFC. So: Can you propose any sort of specific restructuring of the document or the experiment that achieves the same goal as the current version while also resolving your concerns? I'm pretty sure I've raised fundamental concerns about this work and that those concerns have not been addressed. The simple summary is that the way to restructure this work is to go back to first principles. But there doesn't seem to be any interest in having that sort of discussion. The real challenge for most IETF specs is community engagement, not engineering adequacy. Interestingly I would claim we have clearly achieved the former here, though obviously not the latter. My sense is -- as has become common in the IETF -- an extremely small core of folk interesting in promoting this work, rather than extensive community interest.
Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
On 12/9/2019 4:41 PM, Brandon Long wrote: I mean, the PSL is already a maintained object. Is this new detail something that has different ownership/privacy/etc concerns than the existing details? So, ummm, you want to replace one problematic operation with another? On the consumption side, I've only heard comments that the PSL has problems. On the provision side, I've heard vigorous and repeated claims of overwork of the the volunteer force, sufficient that there is no bandwidth for dealing with revision/replacement efforts. I'm sure I probably missed this, but couldn't we avoid this question by just mandating no reporting for non-existing organizational domains? Is that a non-starter? Without commenting on the merits of that suggesting, I'll offer that it is an example of why this spec is -- at its very best -- still incomplete, or at least the thinking about how it will get used is incomplete. (if workable at scale.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
On 12/3/2019 11:42 PM, Murray S. Kucherawy wrote: >I think there's a healthy dose of feeling that the experiment as it's currently designed couldn't possibly scale to "the entire domain namespace" and/or "all servers on the Internet", so in that sense from where I sit there's a built in safeguard against this becoming a permanent wart. Rather, it's primed as a possibly useful data collection exercise. The IETF does not typically -- or, as far as I recall, ever -- promote specifications known not to scale. (While I think of this concern as foundational to the IETF, it's a bit odd that nothing like it is included in the IETF's "Mission and principles" statement.[1]) Perhaps even more importantly, I don't recall the IETF ever promoting a specification that was /expected/ to be thrown away, in favor of then doing the 'real' specification. I do believe such work is sometimes done in the I/R/TF. Note that, for example, this view of throwing a spec away and starting over is quite different from wanting to let the market choose between competing specs. Also, viewing this scaling limitation as a safeguard has recently and notably proved wrong. cf, DMARC. It was designed for a very limited scenario. Then it got re-purposed in the field, by some operators having significant leverage. Worse, publishing a spec always carries the likelihood of operational momentum. If the spec has real utility, it tends to get implemented and used. That creates pressure against replacing it, because that's expensive and possibly disruptive. Comparing it to the "obs" grammars of days of yore, the PSD proposal is much too expensive to become engrained as-is, whereas the old grammars were relatively easy to carry forward. I don't quite grok the reference to "obs", and mostly think of the introduction of that construct in RFC 2822 as an interesting idea that, itself, failed. (I see it as being instructive on the challenges of designing for transition from an installed base.) Perhaps there are exampls of IETF experiments that have permitted entirely starting over, but mostly those only happen when there is a complete failure, and those typically are called experiments. ATPS (RFC 6541) was Experimental, and it flatly failed. For a more visible example, Sender ID was Experimental, and I would argue it did too. Should they not have been? All sorts of experimental specs fail. But they aren't /expected/ to fail. And they aren't expected to be unable to scale. Mostly, IETF/Experimental is used to check whether a spec is operationally viable -- it's expected to be but the community isn't quite sure -- or to check for community interest. The latter constitutes market research, not technical research. A pointedly friendly reading of the relevant Guidelines might seem to support the publication under IETF/Experimental being proposed here, but a more critical one probably doesn't and I think that this use of the label doesn't really match common practice.[2] On 12/7/2019 12:11 PM, Scott Kitterman wrote: Remind me again the the additional work is that might be too much? Isn't it just another DNS lookup for the org domain -1... of which there are maybe a couple thousand and easily cacheable? This seems way less than say the additional work for ARC. It's slightly more. There's also a check to see if a LPSD (org -1) is a PSD > DMARC participant. Exactly how to document that is the major unresolved question that we should evaluate experimentally. It might be one of three things: First, this sort of exchange highlights the need for considering basic operational issues carefully and before publication. Second, it highlights the challenges of doing that in a way that isn't myopic. What is easy/cheap for highly motivated, expert, well-resourced participants might not be all that easy or cheap for the larger Internet community. (This is the operational side of scalability.) The real challenge for most IETF specs is community engagement, not engineering adequacy. Some additional thoughts: The example that Tim added, of RFC 7706, is of an efficiency mechanism, not a basic and required addition to the architecture. The difference is important here. Also, any suggestion to rely on a published list ignores the history of problems with such lists, as well as at least requiring a careful specification for the list and a basis for believing it will be maintained well. d/ [1] Mission and principles [2] https://ietf.org/standards/process/informational-vs-experimental/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] From: rewriting, was Email standard revision
On 12/2/2019 8:29 AM, Dave Crocker wrote: It will help to have folk comment on the IETF mailing list, so that Klensin's comments don't just get responses from me. Sorry, wrong venue. The discussion is on the ietf-smtp mailing list, but the request for others to participate remains! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] From: rewriting, was Email standard revision
On 12/2/2019 7:56 AM, Kurt Andersen (b) wrote: There's also already RFC7960 which expands upon 5598 with specific reference to DMARC's impact. ahh. thanks. It will help to have folk comment on the IETF mailing list, so that Klensin's comments don't just get responses from me. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] From: rewriting, was Email standard revision
On 11/30/2019 4:40 AM, Alessandro Vesely wrote: Let me quote this from the ietf-smtp mailing list: On Sat 30/Nov/2019 00:12:53 +0100 John C Klensin wrote: --On Friday, 29 November, 2019 11:16 -0600 Pete Resnick wrote: [...] Even the "From: rewriting" issue is a gatewaying issue, not a message format issue per se. That is less clear. It fits into the gray area that has existed for years about just exactly what a mailing list exploder / redistribution system really is. This view is reasonable only if one re-defines accepted terminology and ignores some basic technical facts. A user specifies a recipient address. The message is posted and then delivered to that address. That simple process describes basic email handling, and has been the accepted view for roughly 40 years. And it describes the /first/ leg of a message sent /through/ a mailing list. For the second leg, a bot at that address /re-/posts the message. In simple, formal email technical terms, this is an entirely new email transaction. It isn't 'gatewaying' per se, since that term applies to transit between heterogeneous systems, but it /is/ a higher-level process. If only we had a document that discussed all this coherently, defined basic terminology, and had undergone IETF review and approval. If only we had RFC 5598... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
On 11/11/2019 2:21 PM, Dave Crocker wrote: and those typically are called experiments. /not/ called. (sorry) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
On 11/11/2019 7:46 AM, Kurt Andersen (b) wrote: I do have a problem with the conflation of the org domain with a super-organizational "realm" (?) that may impose conditions upon organizations that fall within their jurisdictional purview. This goes to the essential challenge of a proposal like PSD. It embodies a particular model, in the absence of clarity about the model or broad-based discussion of its appropriateness. (Note, for example, that my review offered some discussion of that sort but got no comment on that discussion.) In effect, it creates a strategic solution -- that is, a long-lived and embedded mechanism -- without a clear and broad understanding of the organizational space it is working in. On 11/10/2019 11:34 PM, Murray S. Kucherawy wrote: * add text to the PSD draft making it clear that what it's describing is an experiment whose outcome will be taken only as feedback to the revision of the standard (i.e., this is not intended to be the final form of anything), and it is not intended to be deployed outside of the experiment's participants; Forgive me, but while everyone involved in this has extensive experience and is trying to solve a real and serious issue, this is an astonishingly naive view. The IETF does standards, not experiments. Not /real/ experiments. What it calls an experiment mostly serves as market testing, with a smidgen of engineering tuning later. For the most part, IETF experiments produce an accepted/failed/needs-small-revisions range of results. What it does /not/ produce is results along the lines of "that was interesting, now let's start fresh and do the real standard." Perhaps there are exampls of IETF experiments that have permitted entirely starting over, but mostly those only happen when there is a complete failure, and those typically are called experiments. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Question regarding RFC 8617
On 11/7/2019 3:16 PM, Brandon Long wrote: On Thu, Nov 7, 2019 at 9:28 AM Dave Crocker <mailto:dcroc...@gmail.com>> wrote: On 11/6/2019 9:43 AM, Brandon Long wrote: > What's more, the point of including Subject and other mutable headers is > the same as it is for DKIM, those are the headers which are important to > the receiver, so they should be validated. This being a technical list, I'm going to get picky and note that DKIM does not 'validate' those fields. There is a derivative data integrity benefit, between signing and validated, for such fields, but that is quite different from any claim that the contents of those fields are 'valid'. Some signing sites have much more stringent uses of DKIM than are provided by the standard. That's fine, of course, but it has nothing to do with the standard. Hence any receive-side reliance on such signer data validation is outside the DKIM standard. I should have said "covered by the signature". And I think they are important to both the sender and receiver, your DKIM RFC calls them "core to the message content" and so the "core of the message is valid"... which is different than validated, of course. yeah. really unfortunate language. over the course of different DKIM docs, I kept finding language that needed to be /much/ better. Only some of it now is. That's not one of them, since the context was of that bit of text was meant to assert transit integrity rather than data 'validity'. sigh. At least there is some comfort that that section makes clear it's concern is replay protection, rather than semantic validity. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Question regarding RFC 8617
On 11/6/2019 9:43 AM, Brandon Long wrote: What's more, the point of including Subject and other mutable headers is the same as it is for DKIM, those are the headers which are important to the receiver, so they should be validated. This being a technical list, I'm going to get picky and note that DKIM does not 'validate' those fields. There is a derivative data integrity benefit, between signing and validated, for such fields, but that is quite different from any claim that the contents of those fields are 'valid'. Some signing sites have much more stringent uses of DKIM than are provided by the standard. That's fine, of course, but it has nothing to do with the standard. Hence any receive-side reliance on such signer data validation is outside the DKIM standard. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
On 9/5/2019 2:49 PM, Scott Kitterman wrote: I don't think so. The draft defines PSD as org - 1. Writing a definition for something you don't control and that can (and has) change tends to be problematic. As it is here. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
On 9/4/2019 6:28 AM, Dave Crocker wrote: ence my current view that: 1. The change to DMARC should be limited to permitting the query for the organization domain to be anywhere in the DNS tree, including a TLD. Within DMARC this would not look like 'extra' mechanism. 2. The mechanism that processes that query should be cast strictly as a PSL enhancement, independent of DMARC. Trying to refine things further: DMARC does not care about the PSL. What DMARC cares about is the Organizational Domain (OD), as a fallback when no DMARC record is found at the desired domain name. That is, PSL is literally outside the scope of DMARC. At the least, therefore, the DMARC specification should define a distinct interface to the outside functionality that tells DMARC where the OD is, which will return what suffix of the full domain name is the OD -- eg, getOrgDomain(full-domain) -> org-domain-suffix The PSL-related side of that interface should be a separate specification, so that changes to its behavior -- such as has been happening with the introduction of ODs that are TLDs or are otherwise 'above' where DMARC has been guessing the OD to be -- are isolated from DMARC. The current problems are that DMARC has embedded too much detail about the PSL world, yet DMARC has no involvement in that world. The current proposal embeds assumptions of PSL knowledge further, rather than separating PSL knowledge out. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
Murray, Thanks for the diligent reply. (As a matter of etiquette, I will again apologize for not having submitted my concerns earlier. Partially, this was because my assessment of the work did not gel until recently.) Some responses: On 9/3/2019 8:57 AM, Murray S. Kucherawy wrote: From a higher level view, the experiment can be seen as the temporary construction of an augmented PSL (i.e., the actual PSL coupled with the queryable registry described in Appendix B), which DMARC then can consume to resolve the use cases that have appeared which now need to be addressed. The portion of the experiment comprising an augmentation to DMARC’s algorithm would therefore not be part of DMARC permanently. Then, if the experiment proves effective, that would become prima facie evidence that the PSL, augmented with this additional information, would enable DMARC to resolve those use cases. Such an augmented PSL would still conform to the desirable separation of functions to which you alluded. This model of iterative design does not match my own sense of IETF work, experimental or otherwise. Simply put, 'temporary' is an appealing but highly misleading construct, in the form and scale of a standards body.[*] The closest reality comes to matching that term is when the 'experiment' fails utterly and the effort must completely restart. When work like this operates over a period of years and at Internet scale, nothing is temporary. If an experiment succeeds, the specified work will have become entrenched and there will be significant resistance to making major changes. With respect to the use of this work as a model for changes to the PSL, unfortunately the spec is not written in a fashion to support that. This really is a core concern, in my view: the work needs to have a basic model that really is expected to be appropriate for the long term; hence my suggestion to highly limit any changes to DMARC and, instead, cast the bulk of the work as augmenting the PSL. That said, and as for getting changes to the PSL, based on my interactions with that community, I think it unlikely. There does not seem to be the interest or resources for such work. Strategically, that's the biggest hurdle to overcome, IMO. In addition, there are a few very large players in the space who are unfortunately reticent to declare publicly that they are interested in seeing this evolutionary experiment proceed. These include large email providers and operators of sizable TLDs in need of the capabilities pursued here. This provides some weight to the idea that this will not be simply a niche experiment. Good to hear. Lastly, we note that the idea of “walk up one node” came from an email thread in December[1] wherein you suggested that approach, and which the PSD draft now follows. We are thus a little surprised by the assertion that it should not proceed at all. Was there some content of that thread that was not taken into account that would make it palatable? .. [1] https://mailarchive.ietf.org/arch/msg/dmarc/pQpKag3acqIISxb-SOrJ3mHFayI Sigh. Yeah. Still again, sorry. Mostly this is a case of letting an idea simmer for a while, to think about it more. My feeling is that the idea does not adequately attend to the items 1 and 2 I listed in that note. Hence my current view that: 1. The change to DMARC should be limited to permitting the query for the organization domain to be anywhere in the DNS tree, including a TLD. Within DMARC this would not look like 'extra' mechanism. 2. The mechanism that processes that query should be cast strictly as a PSL enhancement, independent of DMARC. d/ [*] Note the 'obsolete' construct in RFC 5322. It was introduced in RFC 2822, as a revision to RFC 822, 20 years ago. As is obvious, it's intent was to eliminate use of the portions of RFC 822 deemed obsolete. Yet these portions still haven't been eliminated from the specification. Twenty years later. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
On 8/15/2019 3:20 AM, Alessandro Vesely wrote: I hope large fragments of it will make their way to either the PSD draft or the reviewed DMARC spec itself. Thanks for the kind words, but they actually run counter to the larger message I meant to impart: The entire PSD approach is problematic. This is not fixable. A different approach is needed. Making the draft Experimental is actually counter-productive, in that regard. It puts a stamp of IETF approval. The fact of Experimental is less significant than the fact of an IETF consensus stamp of encouragement. There is also the small matter of a small (actually tiny) base of demonstrated support for this proposal. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Comment on draft-ietf-dmarc-psd
ffix List rather than DMARC.) The modification to DMARC, then, is to allow this 'suffix' part to be empty, in order to support top-level domains that operate as organizational domains. This produces zero change to DMARC's lookup behavior and almost no change to its specification. d/ (*) Public Suffix List <https://publicsuffix.org/> -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication
On 6/11/2019 8:12 AM, Alessandro Vesely wrote: On Mon 10/Jun/2019 22:17:01 +0200 Dave Crocker wrote: On 6/10/2019 1:17 AM, Alessandro Vesely wrote: On Sat 08/Jun/2019 18:49:03 +0200 Dave Crocker wrote: Except that most users don't actually see that address because these days most MUAs only display the display address. We often came across this realization. Since DMARC hinges on that field, I think the spec should include some advice to MUA implementation. Unfortunately there is no 'advice' to give that has any utility. If you feel otherwise, please try to formulate it, including the basis for believing it useful, and then try to get community support for it. I'd propose bullets like the following for Section 12.4: o In the MUA, it is safe to only show the display name if its Sorry, but I asked for evidence of utility. My guess is that you are only thinking in terms of information theory, rather than human factors usability. These produce very, very different results. To my knowledge, there is no empirical evidence at all of what RFC5322.From display strings are safe or dangerous to show. o The authentication status of the message should be visible. Why? What's your empirical evidence of utility for this? A trust on first use (TOFU) approach would seem to be possible. In practical terms, what does that mean? Who does what, exactly? A discrepancy can be enhanced by bold characters, by a pop-up, or by a beep and an alert message. Anything but silently displaying a familiar name which actually stands for something else. I suspect you are not familiar with a related effort that was pursued for the web, distinguishing domain names that had ave been vetted vs. those that have not. It did not go well. A user can then arrange her address book so as to make it clear to the MUA that a class of email addresses are equivalent to one another, in order to avoid meaningless alerts. What makes you think users want to do this extra work or that they will. Evidence to date is that they don't and won't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication
On 6/10/2019 1:17 AM, Alessandro Vesely wrote: On Sat 08/Jun/2019 18:49:03 +0200 Dave Crocker wrote: Except that most users don't actually see that address because these days most MUAs only display the display address. We often came across this realization. Since DMARC hinges on that field, I think the spec should include some advice to MUA implementation. Unfortunately there is no 'advice' to give that has any utility. If you feel otherwise, please try to formulate it, including the basis for believing it useful, and then try to get community support for it. A trust on first use (TOFU) approach would seem to be possible. In practical terms, what does that mean? Who does what, exactly? What is the basis for believing anyone will actually do it? On getting the same display name linked to a different domain part, a user would be required to configure the MUA's behavior for this particular name / domain. Specifying user behavior is both outside the usual scope of IETF work and a task with frustratingly poor utility. Does this subject deserve a ticket? Since it has nothing to do with errors or problems with the current spec, I don't see how to justify a ticket. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mandatory Sender Authentication
On 6/6/2019 7:09 PM, Douglas E. Foster wrote: 1. By 'sender', which actor in the sequence do you mean? The term is highly ambiguous. By Sender Authentication, I mean message "From Address" authentication. This involves two rules: * The sending IP address is known to be authorized to send for the SMTP Sender-Address because of MX or SPF, and MX does not 'authorize' sending by an IP address, although some receivers do check for MX as a heuristic. But a heuristic is outside of any 'standard'. SPF does register IP to domain name for sending. * the SMTP Sender-Address is known to be authorized to send for the Sorry, but the term "SMTP Sender-Address" does not have any specified or reliable meaning. message from Address because of either o domain alignment or o a verifiable DKIM signature for the domain of the message From-Address. The message From-Address is what the user sees, so it seems important to know that the user is not being deceived by an impersonator. I assume you mean the RFC5322-level From: field, as opposed to the RFC5321-level Mail From command. Except that most users don't actually see that address because these days most MUAs only display the display address. As for end users being deceived, there's quite a bit of experience that showing users indicators doesn't alter their behavior. 2. Your certitude presumes an empirical foundation, given how often good theory does not make good practice. People have been working in this space for a very long time and one might have expected the industry to have latched on such a simple requirement were it that clear it was /the/ essential requirement. Please document the basis for your certitude. What I actually intend is that "a recipient has a viable option to implement mandatory sender authentication." I don't understand what it means to have an option to implement something that is mandatory. It's mandatory. Also by saying 'recipient' rather than 'receiver' you appear to be indicating the end users will do meaningful filtering based on this kind of information. They won't. This i equivalent to enforcing basic DMARC rules whether the sender has a DMARC policy or not. This requires: That means you are seeking to alter fundamental email semantics by fiat, globally. Surely you jest. 4. Consider the limitations to 'sender' authentication. I am spending a lot of time thinking about the limitations of sender authentication. For a spammer domain, SPF / DKIM / DMARC are easy. What do you mean? For impersonation, Friendly Name and embedded logo images can be pretty effective without violating SPF / DKIM / DMARC. That's correct. And there has been extensive discussions looking to do something about that but there are no proposals on the table, because so far none has looked viable. This means that Sender Authentication may produce more false positives No it doesn't. The existing authentication mechanisms do a good job of authenticating what they are authenticating. It appears that you are seeking to use the information far beyond what is valid. To minimize false positives, I would like to see: * Pressure on list forwarders to either not break signatures, or follow the IETF example of replacing the original from with the list domain and signing the new message with the list domain. You want to bring pressure on list processing developers and/or operators. Good luck with that. * Advice to senders to reduce signature complexity. In the general What does that mean? What specific proposal do you have? mail stream, the purpose of the DKIM signature is to authenticate You appear to misunderstand the semantics of DKIM. Please re-read its specification and supporting document, because they have simple, concise language about what it does. But I have already been told that IETF is not interested in Recipient product problems, and is not concerned with security, which has left me very disappointed. I suspect you have been told nothing of the sort. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Endless Loops with DKIM reports
On 6/6/2019 10:08 AM, John R Levine wrote: If people follow the spec there will be fewer loops, but it won't reduce the number to zero. Forgive me, but I believe there is currently no spec to follow. Yet. I took this thread as raising the issue that there needs to be an effort that specifies how to avoid dmarc report loops. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Endless Loops with DKIM reports
On 6/5/2019 10:06 PM, John Levine wrote: In article <29174612-a051-8066-9dde-2afaf181c...@dcrocker.net> you write: The high-level point I'm trying to make is that control messages -- such as DMARC reports -- need to be handled in a fashion that works automatically and at scale. Since looping is a well-known problem for such messages, they need to be generated and handled in a way that prevents the problem. Right. you can give all the advice you want about sending stuff in ways that's intended to prevent responses, but since some people will always ignore your good advice, and any single party only controls one leg of the loop, the only unlateral way to limit the damage is rate limiti Taking your note's plain language, you appear to be of the rather peculiar view that specifying standards doesn't matter, since people won't follow them. Looping is a classic problem. It has classic solutions. Getting the details of one specified for this case is, of course, different from getting people to adopt it, but the start is with specifying it. Having additional, ad hoc mechanisms for dealing with non-compliance is quite a separate matter. It's fine to tell people to use null bounce addresses and from: addresses that don't ask for dmarc reports, but you need to rate limit anyway. I looked at the rest of this thread, to see where this point had already been made, since your note seems to have a tone implying it's an established point, but I couldn't find it. So again, ad hoc mechanisms might also be useful, but they are separate. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Endless Loops with DKIM reports
My comment was meant about the DMARC report being sent without a return (envelope from) address, the same as is already true for other email infrastructure control messages. DMARC reports are triggered based on the domain in RFC5322.From address and are sent to DMARC reporting address from DMARC record for RFC5322.From address. If one DMARC reports triggers another DMARC reports, the second report will be sent to DMARC reporting address, not to return-path. That's an issue only if the report is sent from an address that has a DMARC record. Which might be a good reason NOT to send from such an address. The high-level point I'm trying to make is that control messages -- such as DMARC reports -- need to be handled in a fashion that works automatically and at scale. Since looping is a well-known problem for such messages, they need to be generated and handled in a way that prevents the problem. in this case SPF is checked against HELO and, in practice, many seders do not have SPF configured for HELO name and SPF failure can trigger a report. I don't understand how the HELO domain name is relevant to this discussion, since it isn't a full email address. DMARC reporting can report and SPF or SPF alignment failure (RFC 7598 sections 4.2, 6.3) . According to section 2.4 of RFC 7208 (SPF) Yes, but how is that relevant to the problem of DMARC report looping? It's merely one of the causes of a DMARC failure, but sources of failure isn't the issue with respect to report looping. d/ -- -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Endless Loops with DKIM reports
On 6/4/2019 1:48 PM, Vladimir Dubrovin wrote: Reports are not sent to Return-Path address, empty return path does not prevents report from being sent. Actually, report with empty My comment was meant about the DMARC report being sent without a return (envelope from) address, the same as is already true for other email infrastructure control messages. envelope-from has higher chances to generate a reverse report, because I don't understand how it is possible to send a report when there is no address to send it to. in this case SPF is checked against HELO and, in practice, many seders do not have SPF configured for HELO name and SPF failure can trigger a report. I don't understand how the HELO domain name is relevant to this discussion, since it isn't a full email address. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Endless Loops with DKIM reports
On 6/4/2019 11:27 AM, Дилян Палаузов wrote: A DKIM failure report is sent, on which a bounce is generated The rule for mail-handling notification messages has been that they do not contain a return address, in order to avoid looping. Shouldn't that apply to DMARC reports, too? If not, why? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Endless Email Loops with Aggregate Reports
On 6/1/2019 5:38 PM, Murray S. Kucherawy wrote: My understanding matched Dave's originally, but then I found this: https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/ Interesting. I've never seen that before. I suspect few others have. I was educated on the model I described by having a design change -- I don't remember whether it fixed a design error or added an enhancement -- refused for the errata record and I was told errata were only for documentation errors -- that is for cases in which the document did not adequately described "what was intended". So, anything that alters what was intended by the wg and/or authors was declared out of scope. While this was some years ago, I'm quite sure it was long after the date of the IESG document. FWIW, it strikes me as a little crazy to have errata admittance rules be different for different streams. What is the possible benefit that is major enough to warrant the additional complexity? But that's just me. Taking the current case, while it's nice that Alexey is friendly to adding this item as a hold, I'll suggest that the decision should rest with the troops already tasked with assessing the submission. There doesn't seem to be a good reason to require an AD to make that decision. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Endless Email Loops with Aggregate Reports
On 6/1/2019 10:13 AM, Murray S. Kucherawy wrote: On Fri, May 31, 2019 at 10:55 AM Dilyan Palauzov mailto:dilyan.palau...@aegee.org>> wrote: Shall I submit an erratum to RFC7489? I would, yes. And this should certainly be recorded as something we need to fix for standards track DMARC, whether by chasing down RFC7489 errata or via a dedicated issue in this WG's tracker. Hmmm... The formal rule for errata in the RFC system is rather constrained: Only errors that mis-specify what was intended are permitted. So, errors in thinking or failures to provide for cases don't count as errata. What this means is that there is no standard way to record the need for better-performing capabilities or addition of new capabilities or the like. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion
On 5/31/2019 5:08 AM, Doug Foster wrote: Tactically, what I meant was "IETF should be able to ensure that IETF messages are only released with verifiable IETF signatures". I'm not exactly sure what the above sentence means, in terms of technical details. So while the language all sounds fine, its meaning is far more ambiguous that I suspect you intended. In any event, are you aware of the recent work on ARC? For some case(s) of what you might mean, above, that's it's goal. This would mean that either the first signature is not applied, the message is not altered after the first signature is applied, or the first signature is removed after the message is altered. The current configuration leaves open the suspicion that IETF has rogue software operating in its A message from the IETF list processor has an ietf.org DKIM signature. How does that support your concern? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
