Re: [dmarc-ietf] What if... Sender:
In article you write: >The core issue is that most of us want senders to prove their right to send on >behalf of any asserted >identities, of which From is the most important. Could you be more specific about "us" in "most of us"? It sure doesn't include me. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] What if... Sender:
The core issue is that most of us want senders to prove their right to send on behalf of any asserted identities, of which From is the most important.SPF did not solve the problem because validating an invisble field was insufficient for detecting unauthorized identity claims.Turning DMARC into another SPF will emasculate it.You deny anyone the right to care about validating From, and then argue that From is unimportant because no one cares about it. This is claimed even though you care very much about which From address appears on your DMARC mailing list messages, and are determined to weaken DMARC to get what you want.The theoretical problem is that mailing lists cannot demonstrate their authority to send modified content on behalf of the originator domain. This right is explicitly granted or implicitly assumed during the subscription process, but no evidence of that transaction is available to the recipient system when a message is received.To solve the problem correctly, we have to find a way to grant that authority. Right now, that authority is only granted at the sender domain level through DNS, or at the recipient domain level through filtering policies.I do not know how to give indidiuals the right to delegate signing permission for themselves, because individuals do not have DNS control. A whole new trust channel would need to be created.If delegation remains a domain-only authority, then the domain owners need to be involved. That leaves us very few possible scenarios:- the originating domain owner publishes a rights delegation notice, the mailing list does something to claim that right, and the recipient domain does something to calidate that right. John Levine's dual sugnature proposal (which I still have not read) appears to be of this type. DKIM scopes are another example, but already available.- the originatong domain owner does nothing, but the recipient domain owner does something in the email filter to treat the mailing list preferentially. This was my propsal. Of course, all domains act as both originator and recipuent.- the mailing list stops making changes.- the mailing list does header munging forever.Are there any other options?I do not like the last third or fourth options because neither evaluates the originator and forwarder jointly, but the objection is small.The second option seems much easier to implement than the first, and has a stated transition process. I think the first option will encounter significant political objections from domain owners, as well as significant technical issues. My proposal was a serious attempt to addtess your objection.I will support any solution which demonstrates trust in a form acceptable to cooperating recipient systems. I will resist solutions which assert that trust does not matter when the sender mivht be an MLM.DFOn Jun 24, 2020 7:13 PM, Dave Crocker wrote: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 CrockerBrandenburg InternetWorkingbbiw.netOn Jun 24, 2020 7:13 PM, Dave Crocker wrote: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 CrockerBrandenburg InternetWorkingbbiw.netOn Jun 24, 2020 7:13 PM, Dave Crocker wrote: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 CrockerBrandenburg InternetWorkingbbiw.net On Jun 24, 2020 7:13 PM, Dave Crocker wrote: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 CrockerBrandenburg InternetWorkingbbiw.netOn Jun 24, 2020 7:13 PM, Dave Crocker wrote: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 CrockerBrandenburg InternetWorkingbbiw.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:
If DMARC settles on Sender, what tool will validate the relationship between Sende and From? On Jun 24, 2020 2:53 PM, Dave Crocker wrote: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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] What if... Sender:
On 6/24/20 11:52 AM, Dave Crocker wrote: > On 6/24/2020 11:35 AM, Jim Fenton wrote: >> On 6/23/20 9:19 PM, Dave Crocker wrote: >> 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. > You have explained why Sender: is better than From: (which I agree with) but not why specifically Sender needs to be used. 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. -Jim ___ 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:
I doubt that tbe end result is the right one, but you need to articulate the transition process. Your proposal requires that all commercial mail systems be changed so that their DMARC-enabled clients can send this missing field. Simultaneously, all mail filters must be rewritten to use the new algorithm. How does that occur without spam getting through during the switch? When will MLMs know that it is time to stop header munging? On Jun 23, 2020 2:49 PM, Dave Crocker wrote: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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] What if... Sender:
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. 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. Please explain why it is important that specifically the Sender: header field be used for this. -Jim ___ 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 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. 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? 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? 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. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] What if... Sender:
On 6/23/2020 2:49 PM, Dave Crocker wrote:
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
This still presents the unsolved 3rd Party Signature (3PS)
authorization concept again. The problem has always been since Day 1,
"Does goodplace.example authorized mlm.example.com to be a resigner on
its behalf?"
The modification to DMARC would be "look for Sender: and if it isn't
present, look for From:.
Doesn't solve the 3PS problem. Do you know how ATPS worked? It works
like this:
googleplace.example will create a DNS lookup record representing
mlm.example.com. The ATPS algorithm for the DNS record is:
base32(sha1(SIGNER-DOMAIN))._atps.example.com
So for this example, a DMARC extension tag "atps=1" is added to
goodplace.example DMARC record, telling verifiers to test for ATPS 3rd
party signers. The zone node record will be (in MS DNS format)
6f4dvf2bygvf6zkq6kiktk53oajhfvhe._atps TXT ("v=atps01;
d=mlm.example.com;")
Now the 3rd party is authorized deterministically, and if we did this
with the Signer Domain, which I presume would be mlm.example.com then
the same ATPS record will apply and the verifier does not have to deal
with the 5322.Sender header.
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.
Well, there would not be any 1st party authorization for the 3rd party
"badactor.example.com" so for restrictive DMARC records, it would be a
highly detectable deviation of the experted norm offering a negative
classification, i.e. rejection or quarantine.
So if Sender: wouldn't be as useful as From:, why not?
Because we still do not have protocol that can test the assertion that
the 3rd party Sender is authorized by the 1st party. It is the same
problem.
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On Wed, Jun 24, 2020 at 9:43 AM wrote: > Hi, > > just answering this one bit, which I believe is at the heart of the > disagreement: > > > > IMHO "phishing and spam messages" is way too broad a concept to permit > useful discussion. DMARC nowadays addresses a whole range of problems of > varying severity to the end user. > I'm curious, could you please provide us with the " whole range of problems" which you believe DMARC addresses? As far as I know, it only addresses the problem of direct domain abuse, nothing more and nothing less. Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] What if... Sender:
On 6/24/2020 10:07 AM, Dave Crocker wrote: On 6/24/2020 7:04 AM, Jesse Thompson wrote: 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. As a MUA developer, I am not sure this applies as much as it did in the past. Namely because of the different types of MUA which predominately fall into three category: 1) Store and forward, offline capable MUAs where all the possible "decision" data is pushed to the MUA in the RFC822/2822/5322 format. It uses POP3 for pickup and SMTP for sending. The presumption here was that the backend has filtered the mail as much as it could for the user with using both system-wide and per-user-account policies. Generally, when the user picks up mail with POP3, this stream did not include the Spam Box. 2) The Online MUA which doesn't get the possible decision data because the UI is rendered by the backend. The Reader is dumb. If it was text based, it might ANSI/VT100 to place fields on the screens. It could be a web-based interface, etc, overall, offline reader has no control over what is displayed. 3) The Hybrid, that combines elements both 1 and 2. Exchange did this, IMAP does this. The MUA 1 and 3 could do its own display but not MUA 2. The MUA 1 and 3 could do more with email abuse handling that was missing or not done by the backend when it passed the data to the MUA. Unfortunately, we can't do anything legacy systems that were abandoned and not possible to upgrade. But with MUA 1 and 3 types still supported, what we need is technical guidance. If we keep suggesting that this will never work, them of course, it will continue to be an unknown of whats possible. Yes, it is common for us to believe the backend should be "responsible" to do the dirty filtering work. But what if they are not doing all the dirty work? all that is possible, for whatever reason, like the backend doesn't believe in ATPS? There is absolutely no reason why an modern, advanced MUA could not explore ATPS to fill that need. One simple display tibit: ["Message signed with an Authorized domain"].Color = green. ["Message signed with an Unauthorized domain"].Color = red. Sure, people will suggest, the user will not read this. Would that be all or some users? Maybe the MUA developers performs an UI ergonomic survey behind one way mirrors or employed Telemetry to learn how users react. Maybe they will learn simple colorization is not working well and instead they find a Modal Popup window is getting the user's attention: WARNING!---[X]- | Message signed with an Unauthorized domain | |[Continue Reading] [Move to junk box]| --- Sure, maybe the user doesn't want to be bothered with this, so he turned it off in the MUA's DKIM/DMARC options under the View | Preference section. [X] Display Unauthorized DKIM signer warnings With 40 years with no MUA guidance, of course, it will continue to be a status quo of no progress. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] What if... Sender:
On Wed, Jun 24, 2020 at 10:07 AM Dave Crocker wrote: > 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. > Sender: is completely irrelevant to the use of DMARC now. If we were to list all things irrelevant to DMARC now, it would be a very long list. 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. > > 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. That being said, I agree that for purposes of DMARCbis, this should be considered out of scope absent some compelling data points. Michael Hammer > ___ 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/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? Jesse ___ 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] Header munging, not ARC, can solve the mailing list problem
Hi, just answering this one bit, which I believe is at the heart of the disagreement: Le 22/06/2020 à 21:44, Brandon Long a écrit : [...] It's the majority which are routinely subjected to phishing and spam messages... IMHO "phishing and spam messages" is way too broad a concept to permit useful discussion. DMARC nowadays addresses a whole range of problems of varying severity to the end user. When protecting security-sensitive domains like banks, where phishing is a major threat to the end user, a fail-closed policy is a necessity, and incompatibility with some uses is acceptable. However, mailboxes with no special security needs call for a different tradeoff. From the end user's point of view, spam or addressbook-based phishing attempts are small annoyances that they somehow deal with (otherwise, they couldn't be using e-mail today). The goal here is an incremental win over an acceptable statu quo, not a revolution. No legitimate communication should thus be made to ressort to tedious workarounds to send mail (mailing-list users having to send every message twice, really?) or to find out who said what. Cheers, Baptiste ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging: A solution proposal for alternate authentication
Good question, Murray.Please ignore the broken sentence, as I think it was text intended for somewhere else in the document. I just reread and found a few other typos, but not enough to require a resend of the whole document. My proofreading should have been better. Doug Foster From: "Murray S. Kucherawy" Sent: 6/24/20 1:00 AM To: fost...@bayviewphysicians.com Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Header munging: A solution proposal for alternate authentication On Tue, Jun 23, 2020 at 4:08 PM Douglas E. Foster wrote: > A few issues remain: > > How does the incoming filter prove that the message is really from the list, > rather than someone spoofing the list? Since the RFC5321 M and the Was there supposed to be more to this line? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] What if... Sender:
> -Original Message- > From: dmarc On Behalf Of Dave Crocker > Sent: 23 June 2020 19:49 > To: IETF DMARC WG > Subject: [dmarc-ietf] What if... Sender: > > [...] > So if Sender: wouldn't be as useful as From:, why not? > Hi Dave, I don't think this allows some of the important automated filtering which alignment on 'From' does (putting the user-importance can of worms about From aside for a moment, though not conceding it). Specifically, alignment on 'From' allows automated checks against addresses of known, trusted contacts from addressbooks - that an email is authenticated for the domain from the addressbook, and hence likely to actually be from the contact (similarly, it can be used for trusted/known-domains eg same-domain). This can be used for automated scoring/filtering to prevent a malicious (spear)phishing email from appearing in an inbox. 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? David This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to ncscinfo...@ncsc.gov.uk. All material is UK Crown Copyright © ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
