Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

[Dave Crocker]

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 D

[Douglas E. Foster]

I don't understand why this topic is debatable.

We are faced with a constant stream of mail which we do not want. We need to 
block the nuisance stuff as well as the dangerous stuff, so that the important 
stuff gets processed in a timely manner, and so that our labor efforts can be 
spent on things more productive than reading nuisance emails. Ergo, if a 
message contains a lie, I want to block it. If the identifier is a lie, the 
content will not be any better. IETF settled on standards for filtering 
identifiers because it is simply more feasible than filtering free-form text.

As to consequences: Was no one present during the 2016 election cycle, when a 
phony GMAIL password reset compromised a U.S. Presidential campaign? I'll admit 
that I have not seen that specific message's From header, but supposedly it 
convinced John Podesta and his I.T. person, so I am pretty confident the From 
domain was "@gmail.com", not sstealyourd...@badguys.r.us"

Someone said that the Sender Address is all we can trust. Nonsense. The only 
thing that is "true" in an email header is the IP Address, and that is true 
only if the recipient assumes that no nation state has a NAT-translating device 
in front of their internet connection. Everything else can and will be 
fraudulent at times.

As to identifiers: The RFC 5321 MAILFROM sender is intended, at least in my 
understanding, to represent the login account used to create the message, while 
the RFC 5322 From Header represents the "speaker", the person whose ideas are 
being represented by the content. It matters if someone puts words in someone 
else's mouth, and From fraud is exactly that type of fraud.

It is reasonable to require senders to demonstrate authority to speak on behalf 
of someone else. DMARC provides two ways to demonstrate that authority: if 
there is domain alignment, the implication is that the security environment of 
the sender domain has chosen to allow one sender to act as agent for another, 
because it would be in their power to prevent him from doing so.. Therefore 
intra-domain agency is not a significant concern to the recipient. However, 
when the sender address (login account) represents a different security domain 
than the sender address, the recipient has no reason to ignore the discrepancy. 
The DKIM signature is the alternative credential which demonstrates authority 
to send on behalf of the From address entity..

I simply cannot grasp how DMARC conflicts with RFC 5321 or RFC 5322, inhibits 
authorship, or creates any other attribution problem. This assertion was simply 
not explained.

Feel free to do this test to see if From address matters: Start sending 
inflammatory stuff with a From address @WHITEHOUSE.GOV to major news 
organizations or foreign governments around the world. See how long it takes 
the Secret Service to pay you a visit.

As to visibility: The business world still runs on Microsoft Outlook, and 
Outlook presents the From Address when a message is read. So it is odd to 
assert that no one ever sees that data. The real scandal is that the Sender 
Address is never displayed. It would be very interesting if MUAs would say
From: market...@bigretailer.com
by: bigretai...@massmailer.com
Whose ideas was it to keep the sender secret?

If the integrity of identifiers does not matter, why are we here?

Doug Foster


___
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

[Seth Blank]

Thanks for bearing with me, Dave.

On Tue, Jun 2, 2020 at 5:26 PM Dave Crocker  wrote:

> 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.
>

Yes, we're agreed 100% here.


> 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?
>

There's a lot of clear and generally consistent data that shows From:
header field spoofing leads to outsized impact on end users. 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.

Seth
___
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

[Dave Crocker]

On 6/2/2020 5:13 PM, Seth Blank wrote:
On Tue, Jun 2, 2020 at 4:02 PM Dave Crocker > 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

[Seth Blank]

On Tue, Jun 2, 2020 at 4:02 PM Dave Crocker  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. Unless I'm
deeply misunderstanding your earlier posts (and I'm glad to be wrong here),
you don't appear to believe this to be true.

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). 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.

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.

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?

Seth
___
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

[Dave Crocker]

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

[Seth Blank]

On Tue, Jun 2, 2020 at 3:42 PM Dotzero  wrote:

> Actually Seth, you are flat out wrong. I was there and part of it. It was
> not about signaling. It was implemented at the MTA  level and was about
> preventing the "badness" from reaching the end user rather than signaling
> to the end user.
>

Michael, there's a crossed wire here-- I didn't mean to communicate that
DMARC is in any way about signaling. I'm in complete agreement here. The
point I was trying to make is that consumers are susceptible to fraud, and
the system needs to stop these messages before they ever get in front of a
user. 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.


> Google experimented with displaying "keys" and Microsoft experimented with
> displaying "shields". Neither of those efforts were integral to the DMARC
> effort. My own experience is that a significant percentage of end users
> will click on just about anything. This was validated in the 2007 timeframe
> during some phishing runs where the bad guys actually left some tracking
> code on a fake WWW landing page the email links led to. It was also
> validated during the Storm Worm when the links used IP Addresses. This
> issue has been validated at other points and times. Individual sending
> organizations and receiving domains have been generally reluctant to
> release data because it might expose company confidential information.
> Aggregated isn't so useful because there are significant variations in
> company efforts - not just with DMARC - that impact outcomes. So far,
> signaling to the end user doesn't have a particularly good track record.
>
> DMARC started as a private effort among a handful of private parties. when
> it was successful in stopping direct domain abuse for a handful of sending
> domains at a handful of receivers we started discussing whether the
> approach could be codified as a standard to enable others to benefit from
> the approach. The origins and history are important in understanding why
> DMARC is what it is.
>

I'm in complete agreement with this, and didn't mean to convey otherwise.


>
> Michael Hammer
>
>>
___
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

[Dotzero]

On Tue, Jun 2, 2020 at 5:31 PM Seth Blank  wrote:

> As an individual:
>
> On Tue, Jun 2, 2020 at 1:46 PM Dave Crocker  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.
>>
>
> There are decades of data that prove just this. 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
>
> And on the marketing side, after a 2 second google search, here's some A/B
> testing:
> https://blog.influenceandco..com/how-to-optimize-your-email-open-rate-with-friendly-froms
> 
>
> 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.
>>
>
> The history of DMARC is the exact opposite. There was a mountain of phish
> impersonating well known companies that was defrauding consumers to the
> tune of hundreds of millions of dollars, and the companies involved got
> together and asked the major mailbox providers to work with them to
> determine the appropriate signals needed to prevent the phishing using
> their domains. DMARC is the result of a multi-year comprehensive data
> investigation here.
>
>

Actually Seth, you are flat out wrong. I was there and part of it. It was
not about signaling. It was implemented at the MTA  level and was about
preventing the "badness" from reaching the end user rather than signaling
to the end user. Google experimented with displaying "keys" and Microsoft
experimented with displaying "shields". Neither of those efforts were
integral to the DMARC effort. My own experience is that a significant
percentage of end users will click on just about anything. This was
validated in the 2007 timeframe during some phishing runs where the bad
guys actually left some tracking code on a fake WWW landing page the email
links led to. It was also validated during the Storm Worm when the links
used IP Addresses. This issue has been validated at other points and times.
Individual sending organizations and receiving domains have been generally
reluctant to release data because it might expose company confidential
information. Aggregated isn't so useful because there are significant
variations in company efforts - not just with DMARC - that impact outcomes.
So far, signaling to the end user doesn't have a particularly good track
record.

DMARC started as a private effort among a handful of private parties. when
it was successful in stopping direct domain abuse for a handful of sending
domains at a handful of receivers we started discussing whether the
approach could be codified as a standard to enable others to benefit from
the approach. The origins and history are important in understanding why
DMARC is what it is.

Michael Hammer

>
___
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

[Dave Crocker]

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

[Kurt Andersen (b)]

I'm sorry to pile on but could not restrain myself:
https://www.bmj.com/content/327/7429/1459?ijkey=c3677213eca83ff6599127794fc58c4e0f6de55a=tf_ipsecsha

I get Dave's point, but at the same time, it is well known that copy tweaks
can have significant effects on conversion rates. Whether the specific
tweak of the 5322.From header field's SMTP domain from  to
 has an effect separate from any
other subterfuges that might be being employed by the miscreant is probably
hard to disambiguate, especially since in the real world, it is rare to
have bare SMTP addresses in that header field.

--Kurt


On Tue, Jun 2, 2020 at 3:01 PM Dave Crocker  wrote:

> 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  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.
>
___
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

[Dave Crocker]

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 > 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

[Seth Blank]

Also, from literally today:
https://www.justice.gov/usao-sdtx/pr/man-admits-spoof-email-fraud-scheme-and-more

On Tue, Jun 2, 2020 at 2:30 PM Seth Blank  wrote:

> As an individual:
>
> On Tue, Jun 2, 2020 at 1:46 PM Dave Crocker  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.
>>
>
> There are decades of data that prove just this. 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
>
> And on the marketing side, after a 2 second google search, here's some A/B
> testing:
> https://blog.influenceandco.com/how-to-optimize-your-email-open-rate-with-friendly-froms
>
> 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.
>>
>
> The history of DMARC is the exact opposite. There was a mountain of phish
> impersonating well known companies that was defrauding consumers to the
> tune of hundreds of millions of dollars, and the companies involved got
> together and asked the major mailbox providers to work with them to
> determine the appropriate signals needed to prevent the phishing using
> their domains. DMARC is the result of a multi-year comprehensive data
> investigation here.
>
>
>> 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.
>>
>
> Trust indicators that require users take appropriate action are doomed to
> fail, and as you mentioned the data concurs. See your EV example and the
> reason that padlock icons are going away.
>
> But the flipside is not true. What users see can certainly trick them into
> doing the wrong thing, especially if they believe they're doing the right
> thing, and especially if a wide net is cast. This is why CEO-CFO and gift
> card scams are so prevalent and effective. Again, grabbing a random example
> from another 2 second google search, a few years ago the FBI said this type
> of scam resulted in $2.3 billion worth of damages:
> https://www.fbi.gov/contact-us/field-offices/phoenix/news/press-releases/fbi-warns-of-dramatic-increase-in-business-e-mail-scams
>
> Or:
> https://ottawa.ctvnews.ca/city-treasurer-sends-128-000-to-fraudsters-in-email-phishing-scam-1.4370829
> (although it's unclear if DMARC would have solved this attack, the point is
> that the treasurer thought it was from the mayor).
>
> M3AAWG has shared mountains of data that DMARC solves a materially
> significant problem, and this has been presented on again and again and
> again. Governments are increasingly mandating it, and more industry
> organizations are requiring it for all members. This is a source of real
> pain which goes far beyond anecdotes.
>
> Seth (hatless, and trying to understand your comments)
>
>
___
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

[Seth Blank]

As an individual:

On Tue, Jun 2, 2020 at 1:46 PM Dave Crocker  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.
>

There are decades of data that prove just this. 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

And on the marketing side, after a 2 second google search, here's some A/B
testing:
https://blog.influenceandco.com/how-to-optimize-your-email-open-rate-with-friendly-froms

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.
>

The history of DMARC is the exact opposite. There was a mountain of phish
impersonating well known companies that was defrauding consumers to the
tune of hundreds of millions of dollars, and the companies involved got
together and asked the major mailbox providers to work with them to
determine the appropriate signals needed to prevent the phishing using
their domains. DMARC is the result of a multi-year comprehensive data
investigation here.


> 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.
>

Trust indicators that require users take appropriate action are doomed to
fail, and as you mentioned the data concurs. See your EV example and the
reason that padlock icons are going away.

But the flipside is not true. What users see can certainly trick them into
doing the wrong thing, especially if they believe they're doing the right
thing, and especially if a wide net is cast. This is why CEO-CFO and gift
card scams are so prevalent and effective. Again, grabbing a random example
from another 2 second google search, a few years ago the FBI said this type
of scam resulted in $2.3 billion worth of damages:
https://www.fbi.gov/contact-us/field-offices/phoenix/news/press-releases/fbi-warns-of-dramatic-increase-in-business-e-mail-scams

Or:
https://ottawa.ctvnews.ca/city-treasurer-sends-128-000-to-fraudsters-in-email-phishing-scam-1.4370829
(although it's unclear if DMARC would have solved this attack, the point is
that the treasurer thought it was from the mayor).

M3AAWG has shared mountains of data that DMARC solves a materially
significant problem, and this has been presented on again and again and
again. Governments are increasingly mandating it, and more industry
organizations are requiring it for all members. This is a source of real
pain which goes far beyond anecdotes.

Seth (hatless, and trying to understand your comments)
___
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

[Dave Crocker]

On 6/2/2020 1:36 PM, Murray S. Kucherawy wrote:
On Tue, Jun 2, 2020 at 11:01 AM Dave Crocker > 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

[Murray S. Kucherawy]

On Tue, Jun 2, 2020 at 11:01 AM Dave Crocker  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.

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.

Hasn't M3AAWG at least had something other than anecdata that this is a
true source of pain?

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.

-MSK
___
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

[Dave Crocker]

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

[Pete Resnick]

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?)


What I'm missing is why the lack of an actual Sender: header field is 
problematic.


pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

___
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

[Dave Crocker]

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

[Pete Resnick]

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.


pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

___
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

[Dave Crocker]

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

[Dotzero]

On Tue, Jun 2, 2020 at 12:44 PM 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.
>
> [1]
> The "From:" field specifies the author(s) of the message,
>that is, the mailbox(es) of the person(s) or system(s) responsible
>for the writing of the message.  The "Sender:" field specifies the
>mailbox of the agent responsible for the actual transmission of the
>message.
>
> [2]
> signature verification failure does not force rejection of the message;
> "
>

We went through this with SenderID and it's use of Sender in PRA. Back in
the day I upset the folks at Microsoft responsible for evangelizing
SenderID by sending emails to them using their name an email in the From
field and myself in the Sender field. My emails would consistently get a
neutral rating under SenderID because of how PRA worked.

As part of the original DMARC team, the goal was to make clear whether the
email was authorized by the domain being used, hence the reliance on SPF
and DKIM. These are clearly under the domain owner/administrator's control
to the extent they choose to exercise that control. There was much
discussion in the community at the time to use thei= field to enable more
granular signing. it never gained traction. Because the intent was to
protect end users from fake emails purporting to be from (primarily)
commercial domains such as financial institutions, greeting card companies,
etc., the Sender field was not a significant issue. Also, when the Sender
is in the same domain as the From, there is no DMARC issue.

Michael Hammer

If you really want to enable someone to send on your behalf then a) give
them direct access to send from your account; b) give them your private
DKIM signing key (which allows them to sign for any account in that domain
or c) delegate a subdomain to them so they can generate their own SPF or
DKIM records.
___
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

[Dave Crocker]

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

[dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

[Jesse Thompson]

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.

[1]
The "From:" field specifies the author(s) of the message,
   that is, the mailbox(es) of the person(s) or system(s) responsible
   for the writing of the message.  The "Sender:" field specifies the
   mailbox of the agent responsible for the actual transmission of the
   message.

[2]
signature verification failure does not force rejection of the message;
"
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc