Re: [dmarc-ietf] Why are MUAs hiding or removing the From address?

[Jesse Thompson]

On 7/21/20 6:05 AM, Douglas E. Foster wrote:
> I would like a better understanding of why MUAs are hiding or removing the 
> FROM address.
> 
> I have one mail store that formerly used hover-to-view, but recently changed 
> to always-show.   This was done in response to a client request on their 
> support forum.  I have never seen a user ask for the From address to be 
> hidden or removed.  I wonder if this trend is driven only by attempts to 
> optimize display space.   It would be a shame to weaken our protocols in 
> response to this trend, if the trend lacks a theoretical foundation.
> 
> I also wonder if the trust indicator research is being over-applied when it 
> is applied to the From Address.    From Address is a unique identifier, while 
> Friendly Name is not.   A trust indicator is like putting a green check mark 
> next to the From Address as a trust indicator.   They have different levels 
> of relevance.   
> 
> One attack method steals a contact list, then emails people in that contact 
> list using friendly names of others in that list.   Hiding the From Address 
> plays into that attack.
> 
> This trust-indicator research also promotes despair.  The conclusion is that 
> users process information poorly.   This result then becomes an excuse to 
> withhold information from those users, or to allow misleading information to 
> be presented to them.    I am not convinced that those are appropriate 
> responses.   "Never" is a hard thing to prove.  So it is risky to say users 
> "Never" use available information correctly, and "cannot be taught" to do 
> better.
> 
> Attack filtering is designed on a layered defense and a sequence of 
> probabilities:
> 
>   * What is the probability that this attack will get through my spam filter?
>   * What is the probability that the user will read the message?
>   * What is the probability that the user will click on the hostile link?
>   * What is the probability that my web filter will allow access to the 
> hostile website?
>   * What is the probability that the web filter will allow the attack to be 
> downloaded?
>   * What is the probability that my antivirus program will allow the attack 
> to proceed?
> 
> The goal is to decrease the probability of a wrong decision at each point in 
> the process.   All I need is for some people to act smarter on some occasions 
> in response to some available clue.   But this cannot happen if the clue is 
> not provided..

I like this way of thinking, and it seems like a good time to mention the 
following anecdote for the sake of the "end-users can't make security 
decisions" argument...

Specifically to address BEC we strip the friendly from (at our MTA gateways 
prior to ingestion to O365) conditionally (one example: from domains of free 
email providers) to force the MUA (Outlook and everything else) to show the 
From address.  

It works because now the victims just see "wisc.edu.provos...@gmail.com" 
instead of "Office of the Provost" and are more likely to consider the message 
hostile, less likely to click on the weird link, less likely to buy gift cards, 
and so on.  

I can count on one finger how many people have noticed that we're doing it (it 
wasn't an end-user, but it was our CRM team who uses friendly from to soft 
match on contacts) for a population of 150,000 mailboxes.  Meanwhile, we get 
very few people claiming that we aren't somewhat mitigating BEC scams.

Note that other institutions are tagging Subjects and bodies with EXTERNAL 
warnings, either to all external sourced email or based on some conditional 
rules, but they are not directly addressing the display name spoofing itself.  
I suspect that people learn to ignore those warnings over time and still fall 
victim to some well crafted scams from a spoofed VIP in their organization.  

I can't say with certainty which tactic works better (DKIM signature breakage 
is a wash), but I think forcing the MUA to reveal the sender's identity is more 
effective, less disruptive, and dovetails nicely with DMARC and the security 
marketing of the DMARC vendors.

Jesse

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Dave Crocker]

On 7/21/2020 1:42 PM, Brandon Long wrote:
I'd be curious when MLMs modifying the mail going through them became 
a thing, I guess I assume it wasn't 45 years ago, but I know it's 
irrelevant.



When I said 45 years, I wasn't not kidding...

The Subject line and the To: field were modified, here:


Date: 7 JUN 1975 1432-PDT
Sender: FARBER at USC-ISI
Subject: MSGGROUP# 001 TCTALK
From: FARBER at USC-ISI
To: MessageGroup:
Message-ID: <[USC-ISI]7-JUN-75 14:32:54-PDT.FARBER>


There is a distributed network teleconferencing facility oriented
to networks experimentally  avilable  called  TCTALK.  It was the
result of a thesis of Jim  Calvin  at  BBN. It can be accessed at
the ISIA site via  TCTALK. questions relative to it
can be answered by Calvin  or  Geoff at SRI-AI. I would recommend
that you try it if you have not. Improvements are being made on a
time available basis by Calvin.

The full discription of TCTALK is available via the net and is in
essense Calvins CASE thesis. Contact CAlvin for that.

Dave


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Douglas E. Foster]

Your credit card scenario is one legitimate way of viewing the problem.   I 
have also been thinking about a credit card scenario, but coming to a different 
conclusion:

For many years, Bill Smith has been using the credit card of his sister-in-law, 
Tracy Jones.   This is an informal arrangement because Bill does not want a 
card of his own.He faithfully pays Tracy for all of his charges.   No 
cashier has ever asked Bill for any ID other than his credit card.

Suddenly, the bank reissues all cards with photos, in an attempt to reduce card 
fraud.   Cashiers begin looking at the photos and will not let Bill use Tracy's 
credit car anymore.   Bill cries foul because he has the cardholder's 
permission.Bill has the trust of Tracy, but he does not have the trust of 
the bank, and as a result, he does not have the trust of the retail clerk.

Should the bank remove those photos to accommodate Bill?

DF


From: Dave Crocker 
Sent: 7/21/20 3:45 PM
To: Dotzero 
Cc: IETF DMARC WG 
Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 
security considerations
On 7/21/2020 12:32 PM, Dotzero wrote:

On Tue, Jul 21, 2020 at 2:06 PM Dave Crocker  wrote:
On 7/21/2020 10:58 AM, Dotzero wrote:
For this case, DMARC externalizes that internal personnel problem.

But it does not fit the definition of "spoofing".

Please note that I did noy use either the word "spoof" or "spoofing".  You 
wrote "MLM is authorized by the user". Someone without authority cannot 
authorize. In this case the user externalized the problem, not DMARC.

That's simple incorrect.

I give you my credit card, telling you to use it only for gasoline purchases 
while running errands for me.  You take the car on a cross-country joyride, 
running the cc charges for gasoline up.  The stations that  charged the gas to 
the card did nothing wrong.  The problem is internal, between you and me.

The MLM's did not do any spoofing.  They acted appropriately, as they have for 
45 years.

If the domain owner has a problem with the user's behavior, that's internal, 
between the domain owner and the user.

Using language that casts the MLM as doing something wrong is a fundamental 
misrepresentation of the situation.

> If that is the problem, why did you participate in the original DMARC
> effort? The issue was clear even back then.

The original DMARC effort was, in fact, to detect actual cases of
spoofing, namely unauthorized use of a domain name by outside actors.

Different problem.

Actually, part of the effort was to enable Sending domains to identify their 
own mail that was being sent without aligned DKIM signing or from places not 
authorized through SPF - in other words, not properly authorized but 
legitimate, hence feedback loops.

This was a point of significant confusing during the initial effort.

It is not reasonable to impose a substantial and permanent cost on the external 
internet, for an organization's inability to monitor and regulate behavior 
within the organization.

Whereas it is entirely reasonable to have a standard that facilitates detecting 
externally-generated traffic that has unauthorized use of a 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] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Dave Crocker]

On 7/21/2020 12:32 PM, Dotzero wrote:



On Tue, Jul 21, 2020 at 2:06 PM Dave Crocker > wrote:


On 7/21/2020 10:58 AM, Dotzero wrote:
For this case, DMARC externalizes that internal personnel problem.

But it does not fit the definition of "spoofing".

Please note that I did noy use either the word "spoof" or "spoofing".  
You wrote "MLM is authorized by the user". Someone without authority 
cannot authorize. In this case the user externalized the problem, not 
DMARC.


That's simple incorrect.

I give you my credit card, telling you to use it only for gasoline 
purchases while running errands for me.  You take the car on a 
cross-country joyride, running the cc charges for gasoline up.  The 
stations that  charged the gas to the card did nothing wrong.  The 
problem is internal, between you and me.


The MLM's did not do any spoofing.  They acted appropriately, as they 
have for 45 years.


If the domain owner has a problem with the user's behavior, that's 
internal, between the domain owner and the user.


Using language that casts the MLM as doing something wrong is a 
fundamental misrepresentation of the situation.




> If that is the problem, why did you participate in the original
DMARC
> effort? The issue was clear even back then.


The original DMARC effort was, in fact, to detect actual cases of
spoofing, namely unauthorized use of a domain name by outside actors.

Different problem.


Actually, part of the effort was to enable Sending domains to identify 
their own mail that was being sent without aligned DKIM signing or 
from places not authorized through SPF - in other words, not properly 
authorized but legitimate, hence feedback loops.



This was a point of significant confusing during the initial effort.

It is not reasonable to impose a substantial and permanent cost on the 
external internet, for an organization's inability to monitor and 
regulate behavior within the organization.


Whereas it is entirely reasonable to have a standard that facilitates 
detecting externally-generated traffic that has unauthorized use of a 
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] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Dotzero]

On Tue, Jul 21, 2020 at 2:06 PM Dave Crocker  wrote:

> On 7/21/2020 10:58 AM, Dotzero wrote:
> >
> >
> > On Tue, Jul 21, 2020 at 11:52 AM Dave Crocker  > > wrote:
> >
> > The mail is not spoofed.  Consider the definition of the word. Then
> > consider that the MLM is authorized by the user with the address in
> the
> > original From field.
> >
> > This is an interesting statement and raises a question.. Does a user
> > have the authority to authorize (some) use of a domain in a manner
> > contravening the express statement (p=reject) of the domain
> > owner/administrator? I'm going to have to say no.
>
> The user is authorized to use that address.  The problem here is not
> 'spoofing' but rather an internal personnel problem, with the user not
> adhering to the policies of the organization that authorized the user.
>
> For this case, DMARC externalizes that internal personnel problem.
>
> But it does not fit the definition of "spoofing".
>
> Please note that I did noy use either the word "spoof" or "spoofing".  You
wrote "MLM is authorized by the user". Someone without authority cannot
authorize. In this case the user externalized the problem, not DMARC.


>
> >
> > Also then consider that the existing MLM behavior has existed and
> been
> > useful for roughly 45 years.
> >
> > Slavery existed for a long time (still does in some places) and was
> > useful (for some) for a long time. Things change and evolve.
> >
> > The problem, here, is DMARC's imposing a change in email semantics.
> >
> >
> > If that is the problem, why did you participate in the original DMARC
> > effort? The issue was clear even back then.
>
>
> The original DMARC effort was, in fact, to detect actual cases of
> spoofing, namely unauthorized use of a domain name by outside actors.
>
> Different problem.
>

Actually, part of the effort was to enable Sending domains to identify
their own mail that was being sent without aligned DKIM signing or from
places not authorized through SPF - in other words, not properly authorized
but legitimate, hence feedback loops.

Michael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Joseph Brennan]

On Tue, Jul 21, 2020 at 2:08 PM Hector Santos
 wrote:
>


> Second, DMARC is imposing a new security protocol based on the premise
> the "From" is not expected to be changed. How will the MLM/MLS fit?
>
> It can:
>
> 1) Supports the security protocol and the problem is solved.
> Exclusive domains made a published policy statement for exclusive
> signing.  The Exclusive Domains does not expect its users to be using
> their domains outside the work place. The policy is honored.

My understanding of DMARC's purpose was to protect transactional
messages from sources like banks, credit card issuers, online shopping
venues, and the like. It supposed that those messages should pass only
directly from the source to the end point, and that that was so
important to security that transport through any intermediary should
be rejected as possible forgery. For example my bank statements come
from a different domain than mail from a person at the bank.

What blew it away was Yahoo's implementation of DMARC on end user
personal mail. It was at first believed by many that Yahoo would have
to roll it back when their users could not contribute to mailing lists
or send mail to people who had old-school forwarding. Instead the
industry started developing ways to get around DMARC by changing RFC
822 From headers and RFC 821 MAIL commands... which pretty much un-did
the DMARC concept of authorization.

It has been demonstrated that #1 is not happening, and it's because
sheer deliverability of legitimate email is the priority.


-- 
Joseph Brennan
Lead, Email and Systems Applications

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Why are MUAs hiding or removing the From address?

[Joseph Brennan]

On Tue, Jul 21, 2020 at 1:28 PM Brandon Long
 wrote:
>
> Do sms/mms programs show the phone number any more?  I think there's been a 
> deliberate strategy to make email clients more like
> other messaging clients, and the technical parts like the actual address are 
> details that most of the time aren't useful to the user... when
> they're not being spoofed, of course, or otherwise need to differentiate 
> between multiple addresses for the same person.
>
-

I think you're right about how non-email messaging clients have
influenced email.

But even in email, Microsoft's Outlook, with its roots as an
intraoffice memo client, has shown only display name as far back as I
know, except when Internet mail comes in with a From header that has
no display name to show. For all its quirks, Outlook is the only
client I can think of that shows the content of the RFC5322 Sender
header, even if it is in the peculiar "x on behalf of y" notation,
which shows display name when there is one and address otherwise.

But we are digressing into a proposal for an Internet Email Client standard.



Joseph Brennan
Lead, Email and Systems Applications

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Hector Santos]

On 7/21/2020 11:51 AM, Dave Crocker wrote:


Also then consider that the existing MLM behavior has existed and been
useful for roughly 45 years.

The problem, here, is DMARC's imposing a change in email semantics.


Dave, there are different ways of looking at this. I've work with and 
developed MLM/MLS for as many years, and there are "mail engineering 
ethics" here to consider.


The first is Mail Tampering, which is part of 1986 US ECPA guidelines, 
  Mail Tampering was an exception, not a rule, with the MLM/MLS to 
allow for body changes. This was not a normal expectation except to 
allow a very basic overhead level with headers/footers. Absolutely no 
tampering with the context, the "gist" of the copyrighted messages, is 
never expected to be altered. It was never expected for the Author 
field to be changed unless you had a digest or something like it where 
clearly the mail was not coming from you.  In general, it would have 
been a US ECPA violation.  It was not something you often seen done, 
if ever.  The Newspaper Publisher industry is the only industry where 
legal concept of "Print To Fit" was acceptable for 100+ years.  But if 
a MLM/MLS is considered a publisher, would it be exempt?  Even then, 
the From is not changed in your letter to the editor.


Second, DMARC is imposing a new security protocol based on the premise 
the "From" is not expected to be changed. How will the MLM/MLS fit?


It can:

1) Supports the security protocol and the problem is solved. 
Exclusive domains made a published policy statement for exclusive 
signing.  The Exclusive Domains does not expect its users to be using 
their domains outside the work place. The policy is honored.


2) Unintentionally ignorant of the security protocol, does nothing. 
This is your true legacy system.


3) Intentionally ignorant of security protocol while continue to 
resign mail. This is not a legacy system if it has adapted to resign 
mail and chose to neglect and ignore the security protocol.


4) Same as #3 but also rewrites From field.

#1 and #4 will resolve the problem.  The proper protocol engineering 
fit is with #1. While #4 resolves the issue, it is perpetuating an 
undesirable design that can have serious mail engineering consequences 
simply by watering down the value of persistent 5322.From.  The #2 and 
#3 MLM/MLS will be remain as problems until they change or the user is 
made aware he can't use his exclusive domain on a public forum.



--
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] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Dave Crocker]

On 7/21/2020 10:58 AM, Dotzero wrote:



On Tue, Jul 21, 2020 at 11:52 AM Dave Crocker > wrote:


The mail is not spoofed.  Consider the definition of the word. Then
consider that the MLM is authorized by the user with the address in the
original From field.

This is an interesting statement and raises a question.. Does a user 
have the authority to authorize (some) use of a domain in a manner 
contravening the express statement (p=reject) of the domain 
owner/administrator? I'm going to have to say no.


The user is authorized to use that address.  The problem here is not 
'spoofing' but rather an internal personnel problem, with the user not 
adhering to the policies of the organization that authorized the user.


For this case, DMARC externalizes that internal personnel problem.

But it does not fit the definition of "spoofing".




Also then consider that the existing MLM behavior has existed and been
useful for roughly 45 years.

Slavery existed for a long time (still does in some places) and was 
useful (for some) for a long time. Things change and evolve.


The problem, here, is DMARC's imposing a change in email semantics.


If that is the problem, why did you participate in the original DMARC 
effort? The issue was clear even back then.



The original DMARC effort was, in fact, to detect actual cases of 
spoofing, namely unauthorized use of a domain name by outside actors.


Different problem.

d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Dotzero]

On Tue, Jul 21, 2020 at 11:52 AM Dave Crocker  wrote:

> On 7/21/2020 8:48 AM, Jesse Thompson wrote:
> > On 7/20/20 7:55 AM, Douglas E. Foster wrote:
> >> I am advocating for MLMs to stop spoofing and make their peace with
> DMARC.
> > Maybe the recommendation should be that MLMs (or any ESP, for that
> matter) should never send as a domain they do not directly own unless it's
> authorized to send aligned mail as that domain.  (I say this as I have a
> distinguished PhD (not of CS) complaining to me that when he sends spoofed
> email from his Gmail account the messages go into spam because of DMARC.
> Why do these ESPs even allow it in the first place, putting the domain
> owner's decision to adopt DMARC as the boogieman?)
>
>
> This being a technical forum, we need to be careful and precise about
> terminology and history and, well, quite a bit more.
>
> The mail is not spoofed.  Consider the definition of the word. Then
> consider that the MLM is authorized by the user with the address in the
> original From field.
>
> This is an interesting statement and raises a question.. Does a user have
the authority to authorize (some) use of a domain in a manner contravening
the express statement (p=reject) of the domain owner/administrator? I'm
going to have to say no.


> Also then consider that the existing MLM behavior has existed and been
> useful for roughly 45 years.
>
> Slavery existed for a long time (still does in some places) and was useful
(for some) for a long time. Things change and evolve.


> The problem, here, is DMARC's imposing a change in email semantics.
>

If that is the problem, why did you participate in the original DMARC
effort? The issue was clear even back then.

Michael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Dave Crocker]

On 7/21/2020 8:48 AM, Jesse Thompson wrote:

On 7/20/20 7:55 AM, Douglas E. Foster wrote:

I am advocating for MLMs to stop spoofing and make their peace with DMARC.

Maybe the recommendation should be that MLMs (or any ESP, for that matter) 
should never send as a domain they do not directly own unless it's authorized 
to send aligned mail as that domain.  (I say this as I have a distinguished PhD 
(not of CS) complaining to me that when he sends spoofed email from his Gmail 
account the messages go into spam because of DMARC.  Why do these ESPs even 
allow it in the first place, putting the domain owner's decision to adopt DMARC 
as the boogieman?)



This being a technical forum, we need to be careful and precise about 
terminology and history and, well, quite a bit more.


The mail is not spoofed.  Consider the definition of the word. Then 
consider that the MLM is authorized by the user with the address in the 
original From field.


Also then consider that the existing MLM behavior has existed and been 
useful for roughly 45 years.


The problem, here, is DMARC's imposing a change in email semantics.

d/

--

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Jesse Thompson]

On 7/20/20 7:55 AM, Douglas E. Foster wrote:
> I am advocating for MLMs to stop spoofing and make their peace with DMARC.

Maybe the recommendation should be that MLMs (or any ESP, for that matter) 
should never send as a domain they do not directly own unless it's authorized 
to send aligned mail as that domain.  (I say this as I have a distinguished PhD 
(not of CS) complaining to me that when he sends spoofed email from his Gmail 
account the messages go into spam because of DMARC.  Why do these ESPs even 
allow it in the first place, putting the domain owner's decision to adopt DMARC 
as the boogieman?)

The DMARC conditional rewriting logic that the MLM providers implement inhibits 
larger DMARC adoption because it segregates people into two camps, based solely 
on their domain owner's stance towards DMARC.  If a large enough group of 
stakeholders fall into the camp of "this domain I'm using to subscribe to lists 
isn't and should never be subjected to DMARC rewriting", they will push back on 
the domain owner's attempts to publish DMARC.

Maybe this ties back into the DMARCbis discussion about pct=0.  We use pct=0 
specifically to reduce end-user confusion about MLM rewriting behavior.  Could 
the behavior induced by pct=0 be the default, somehow, rather than p=none?

Jesse

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Why are MUAs hiding or removing the From address?

[Douglas E. Foster]

I would like a better understanding of why MUAs are hiding or removing the FROM 
address.

I have one mail store that formerly used hover-to-view, but recently changed to 
always-show.   This was done in response to a client request on their support 
forum.  I have never seen a user ask for the From address to be hidden or 
removed.  I wonder if this trend is driven only by attempts to optimize display 
space.   It would be a shame to weaken our protocols in response to this trend, 
if the trend lacks a theoretical foundation.

I also wonder if the trust indicator research is being over-applied when it is 
applied to the From Address.From Address is a unique identifier, while 
Friendly Name is not.   A trust indicator is like putting a green check mark 
next to the From Address as a trust indicator.   They have different levels of 
relevance.

One attack method steals a contact list, then emails people in that contact 
list using friendly names of others in that list.   Hiding the From Address 
plays into that attack.

This trust-indicator research also promotes despair.  The conclusion is that 
users process information poorly.   This result then becomes an excuse to 
withhold information from those users, or to allow misleading information to be 
presented to them.I am not convinced that those are appropriate responses.  
 "Never" is a hard thing to prove.  So it is risky to say users "Never" use 
available information correctly, and "cannot be taught" to do better.

Attack filtering is designed on a layered defense and a sequence of 
probabilities:
What is the probability that this attack will get through my spam filter?What 
is the probability that the user will read the message?What is the probability 
that the user will click on the hostile link?What is the probability that my 
web filter will allow access to the hostile website?What is the probability 
that the web filter will allow the attack to be downloaded?What is the 
probability that my antivirus program will allow the attack to proceed?
The goal is to decrease the probability of a wrong decision at each point in 
the process.   All I need is for some people to act smarter on some occasions 
in response to some available clue.   But this cannot happen if the clue is not 
provided..

Doug Foster


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Agenda requests for Madrid IETF

[Alessandro Vesely]

On Mon 20/Jul/2020 20:36:21 +0200 Seth Blank wrote:
We have a session on the books for IETF108, and would like suggestions from the 
group for the agenda, otherwise the chairs will choose relevant topics. Items 
in tickets or from the past month are all fair game.



I think *The fate of From:* can be a fair title for summarizing the WG feelings 
about relaxing rules in favor of Sender: (#73), as well as other issues about 
this field, such as multi-address (#74) and the companion Author:.  It'd be 
appropriate to air this topic also in next day's emailcore session.



Best
Ale
--


































___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Laura Atkins]

> On 21 Jul 2020, at 02:18, Murray S. Kucherawy  wrote:
> 
> On Mon, Jul 20, 2020 at 1:59 AM Laura Atkins  > wrote:
> There was a research project done by an inbox provider and a major supporter 
> of DMARC presented at a MAAWG meeting a few years ago. They tried adding 
> trust indicators to the message list but found no statistically significant 
> behavioral changes by users. Given the conference policies, I hesitate to 
> mention it here, but there is research. There’s also a conference paper I 
> found, done by a computer science research team at VA Tech that looked at 
> this as well. 
> 
> I remember something about the former.  I'll see if I can find a public 
> reference to it.
> 
> "Data, data, data; we cannot make bricks without clay."

https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-hu.pdf 
 
is the conference talk I was mentioning. 

I’ll be honest, I do think both phishing and UX has evolved significantly since 
DMARC was initially announced. The protocol has not kept up with the evolution 
and it’s benefits are much less obvious than when it was initially launched. 
We’re forcing a lot of damage on normal email usage, for non-obvious benefits. 

>   
> Most clients these days seem to be hiding the RFC5322.From domain from the 
> individual end users. Mail.app on OSX does unless you change that setting 
> specifically (and it seems every few upgrades they reset the setting and then 
> hide the checkbox again). The iOS mail app doesn’t even have a setting to 
> change that I’ve been able to find. I seem to remember the last time I set up 
> a mailbox on Thunderbird (pre-2016 election as I was tracking some candidate 
> mail) they also hid the 5322.From address. 
> 
> I could be wrong but I seem to recall that at the time DMARC was published, 
> this wasn't the case.  (See my previous remarks about Gmail.)  But I agree 
> that it does seem to be the case now.

I don’t remember, either. I think clients were going down that route, though. I 
know, for instance, that the iOS mail client has never shown the email address, 
always the friendly from. 

> I'm not sure we've ever fully faced the idea that what MUAs choose to display 
> needs to be factored into the evolution of these protocols.  For as long as 
> I've been working on this, it's been the opposite.

When we’re basing a protocol on “what the user sees” and “what the user can 
trust” then I think we have to. DMARC says “users can trust that mail from 
@domain.example is really from @domain.example” but if the user never sees 
that, how do they know? 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Laura Atkins]

> On 21 Jul 2020, at 00:20, Brandon Long  
> wrote:
> 
> 
> 
> On Mon, Jul 20, 2020 at 2:00 AM Laura Atkins  > wrote:
> 
>> On 19 Jul 2020, at 19:08, Murray S. Kucherawy > > wrote:
> 
>>>I'm less convinced by the notion that all of the RFC5322.From is 
>>> disregarded by the preponderance of users when deciding what level of trust 
>>> to put in the message's content. That suggests we blindly open and read 
>>> absolutely everything, and I suspect that isn't the case.
>> 1. That's not what it suggests, at all
>> 
>> Then I don't know what else you might mean by "end users do not reliably 
>> make trust decisions based on /any/ of the information in the rfc5322.From 
>> field".  What other data exist upon which to make trust decisions in the 
>> display of a mailbox?
> 
> There was a research project done by an inbox provider and a major supporter 
> of DMARC presented at a MAAWG meeting a few years ago. They tried adding 
> trust indicators to the message list but found no statistically significant 
> behavioral changes by users. Given the conference policies, I hesitate to 
> mention it here, but there is research. There’s also a conference paper I 
> found, done by a computer science research team at VA Tech that looked at 
> this as well. 
> 
> Was it us?  If so, I can push on folks to find and make it releasable, but I 
> don't recall that we had such a presentation but I've also been out of the 
> loop for a while and wasn't there are
> the beginning of DMARC either.  Ie, I know the ecert goldkey stuff failed on 
> this, but don't think I ever saw the data.

Wasn’t Google (which doesn’t mean Google hasn’t done similar work. Following up 
offlist. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc