Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[Douglas E. Foster]

Indirect mail flows are difficult to detect.   SMTP address rewrite is already 
common practice for forwarding.More to the point, John's interest is finding 
ways to increase the trust level for forwarded mail, while your idea says that 
direct mail is more trusted than indirect maill, which is the problem he is 
trying to overcome.We need to be able to evaluate indirect mail based on both 
the submitter MTA. and the originator MTA.   ARC gets us started in that 
direction.   I think more filtering data is needed and am working on a proposal 
to that effect.Doug

 Original message 
From: Alessandro Vesely  Date: 
11/25/20  6:28 AM  (GMT-05:00) To: dmarc-ietf  
Subject: [dmarc-ietf] A policy for direct mail flows only, was ARC 
questions 
On Mon 23/Nov/2020 22:27:41 +0100 John Levine wrote:
> ARC deals with the problem that most list software forwards everything
> with a subscriber's address on the From: line and does a lousy job of
> spam filtering. The question is if the entity sending the message to
> the list was who it purported to be.
>
> For example, if a message from a list fails DMARC alignment, but ARC
> says it was aligned on the way in, it's likely a real message from a
> subscriber. If it was unaligned on the way in, it's likely spam.


I publish p=none in order to avoid spurious rejections due to casual message
modifications that happen in transit.  However, I'm quite confident that SPF or
DKIM verify, since users submit messages through the right mail server.

Couldn't I address direct flows only?  Doing so would prevent a casual spammer
from abusing mailing lists I'm subscribed to by simply faking From:.

A direct flow is one were SPF credentials (helo name or return address) are
aligned with From:.  That includes some simple forwarding, but not mailing list
traffic.  Direct policy could be expressed as dp=.  Authenticate as usual,
either SPF or DKIM.  On failure, discard only if direct flow.  For example:
   v=DMARC1; p=none; dp=reject;

Makes sense?

Best
Ale
--






















___
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] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd

[Douglas E. Foster]

My longest addresses are from SalesForce.com, with 6 segments.
Relatively small dataset.



From: Laura Atkins 
Sent: 11/23/20 8:19 AM
To: "Murray S. Kucherawy" 
Cc: IETF DMARC WG 
Subject: Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for 
draft-ietf-dmarc-psd

On 22 Nov 2020, at 06:06, Murray S. Kucherawy  wrote:

On Sat, Nov 21, 2020 at 6:23 PM John Levine  wrote:
It is my impression that most real From: domains are pretty short. I
don't think I've ever seen one more than four labels long that wasn't
deliberately contrived. Anyone got data on that?

I'd bet there are some in .gov or .mil, especially the latter, but otherwise I 
think the longest one I've seen is five, and that was not a host that receives 
mail.

I'm sure we can all scrape our own mail logs for evidence either way.

This might be a place where one (or more) of the big ESPs can help. They're 
going to have billions of email addresses and know which ones have MXs. I'm 
happy to ask for that data if it would be of use.

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] ARC questions

[Douglas E. Foster]

Apologies.Either I read an obsolete version of the document, an unrelated 
document, or have a hallucinating memory.   Hoping it is not my mind going 
south...

Doug



From: "John Levine" 
Sent: 11/22/20 3:01 PM
To: dmarc@ietf.org
Cc: m...@mtcc.com
Subject: Re: [dmarc-ietf] ARC questions

In article  you write:
>-=-=-=-=-=-
>
>
>On 11/22/20 11:18 AM, Douglas E. Foster wrote:
>> ARC has a very limited set of items included in the signature.? ?Body
>> hash is purposefully excluded.? So it is the same signature algorithm
>> but with different parameters and a different purpose.? Therefore it
>> has a different header label .
>
>Now wait, Kurt just said that the body hash is included. Somebody has to
>be wrong here.

Doug is mistaken. The ARC-Message-Signature (AMS) header has the same
body hash as a DKIM signature.

___
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] ARC questions

[Douglas E. Foster]

ARC has a very limited set of items included in the signature.   Body hash is 
purposefully excluded.  So it is the same signature algorithm but with 
different parameters and a different purpose.  Therefore it has a different 
header label .Sent from my Verizon, Samsung Galaxy smartphone

 Original message 
From: John R Levine  Date: 
11/22/20  2:14 PM  (GMT-05:00) To: Michael Thomas , 
"Kurt Andersen (b)"  Cc: dmarc@ietf.org 
Subject: Re: [dmarc-ietf] ARC questions 
> Is there a reason that there is a separate ARC-signature rather than 
just
> using the DKIM signature that is normally created for the new message? Since
> ARC is new, you'd not want the intermediary to stop DKIM signing the message
> so you end up with essentially two signatures doing essentially the same
> thing?

The ARC signature has a sequence number so you can track the chain of
custody.  You are right that it is similar to the DKIM signature but the
extra ovehead doesn't seem excessive.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
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] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

[Douglas E. Foster]

I am arguing for the position that all unregistered domains are inherently 
invalid, because they are not registered.

PSD for DMARC proposes that non-existent domains should be blocked.In their 
discussions, I remember the UK government reporting that they had registered 
27,000 domains simply so they could publish SPF -ALL, in an attempt to block 
spammers from spoofing their government agencies.   I have a problem with the 
definition they chose in their document, but I fully agree that this is a 
problem that should be fixed.

They have also suggested that their "np" policy has general applicability, an 
argument which I find compelling.   By "general", I mean non-existent TLDs, 
non-existent public suffixes below the TLD, non-existent organizations, and 
non-existent subdomains of organizations.

Their experience demonstrates that an undefined domain is very difficult to 
protect.


On tree walk, I was working from John Levine's proposal, which assumes that a 
tree walk has to be distance limited for performance reasons.   He tentatively 
proposed four levels.   If you walk up the tree and find no DMARC entry, the 
walk stops with the conclusion that no policy has been issued.   This approach 
works if (and only if) the tree exists, so that the organization can place a 
policy at every fourth level.   The approach cannot work if the tree can be 
extended with non-existent domains.It also conflicts with the PSD proposal 
which requires checking the top of the tree structure.

I had considered the top-down approach also, for the same reasons as you 
mentioned.   I assumed that it would be rejected because of the load placed on 
upper levels of the DNS hierarchy.

But when mulling the PSD problem with the tree-walk problem, I realized the 
unifying problem in all of these scenarios was unregistered domains.   
Eventually the problem became further defined as, "Why should unregistered 
domains be considered acceptable by default, despite a network-wide requirement 
for all domains to be registered."

For the moment, it is a DMARC issue to me because DMARC has accepted the notion 
that unregistered domains are acceptable by default.   If that can be changed, 
I agree that there are other documents that need to be updated as well.

DF



From: "Murray S. Kucherawy" 
Sent: 11/21/20 8:05 PM
To: Doug Foster 
Cc: "dmarc@ietf.org" 
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

On Sat, Nov 21, 2020 at 5:02 PM Murray S. Kucherawy  wrote:

On Sat, Nov 21, 2020 at 3:12 PM Douglas E. Foster 
 wrote:

- If unregistered domains are tolerated, PSD for DMARC helps address the 
problem of a unauthorized domains underneath a public suffix, such as 
"example.uk".  But what DMARC policy will solve the problem of an invalid TLD, 
such as "example.q"?

Why is this a DMARC problem that needs solving?

- If unregistered domains are tolerated, then a limited-scope tree walk becomes 
unusable.   A spammer would be able to  fabricate a few levels of non-existent 
subdomains, and suddenly PayPal.com becomes a domain tree with no detectable 
DMARC policy.

You're going to have to give us an example of what you're imagining here.  
Presumably fabricating a few levels of non-existent subdomains of paypal.com 
would look like foo.bar.baz.paypal.com; a simple tree walk then would be to 
look for records in these places:

foo.bar.baz.paypal.com
bar.baz.paypal.com
baz.paypal.com
paypal.com

I would expect a policy to be present at least at "paypal.com", so the walk 
stops there.  How is that "unusable"?

Someone in DNSOP, I think, proposed doing the tree walk in the other direction. 
 The reason: If you're going to get an NXDOMAIN, it is more likely to come 
earlier, and it's dispositive that way.  For instance, if the above sequence is 
reversed, you would probably get an NXDOMAIN at the second query 
("baz.paypal.com") and then you know you don't need to look any further.

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

Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

[Douglas E. Foster]

What are the complications to DMARC of tolerating unregistered domains?

- If unregistered domains are tolerated, PSD for DMARC helps address the 
problem of a unauthorized domains underneath a public suffix, such as 
"example.uk".  But what DMARC policy will solve the problem of an invalid TLD, 
such as "example.q"?

- If unregistered domains are tolerated, then a limited-scope tree walk becomes 
unusable.   A spammer would be able to  fabricate a few levels of non-existent 
subdomains, and suddenly PayPal.com becomes a domain tree with no detectable 
DMARC policy.   Besides, a scope-limited tree walk conflicts with the 
requirements of PSD for DMARC.   An unlimited-scope tree walk has performance 
risks to both the evaluator and the DNS infrastructure.

Doug Foster



From: "Murray S. Kucherawy" 
Sent: 11/21/20 2:12 PM
To: Doug Foster 
Cc: Doug Foster , IETF DMARC WG 

Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

On Sat, Nov 21, 2020 at 9:02 AM Douglas E. Foster 
 wrote:

Restating what we all know:
- The Internet is dependent on the reliable operation of the DNS name system.
- The DNS name system is dependent on the reliable operation of the name 
registration processes.
- The registrars are given ownership of all unregistered domain names within 
their portion of the hierarchy.
- The public evidence of registration is the existence of a DNS entry, and a NS 
record is always the first one configured.

Conclusions
- Unregistered use of any domain name is an attack on the architecture of the 
Internet.
- PSD for DMARC is asking us to give public suffix operators what they are 
supposed to already have:   control over unregistered names.
- We should implement new and universal policies:- Unregistered names used as 
SMTP addresses MUST generate SPF FAIL and SHOULD be rejected.

That is certainly a defensible assertion, but I would claim it is out of scope 
for DMARC.  You're talking about a detail of SPF or perhaps of SMTP in general, 
although one could also even argue that this is a local policy decision and 
outside the scope of those protocols.  I suspect the SMTP greybeards would 
claim that this is not part of SMTP, but rather an enforcement choice made by 
implementations.

I believe this falls within the realm of what the IETF calls an Applicability 
Statement, which would be a standards track document (if you could get 
consensus for it).  You could also include this in the DMARC usage document, or 
as non-normative advice in DMARC itself with an explanation of why it's a good 
idea, if you can develop consensus to do so.

You also need to account for transient DNS outages.  If your resolver 
temporarily thinks "gmail.com" doesn't exist, you will bounce all mail coming 
from that domain, and you might seriously piss off your users.  There's a 
backscatter problem here too: If I send mail to a list you're on and you 
temporarily think my domain doesn't exist and you bounce mail coming from me, 
the list will unsubscribe you.
- Unregistered names used as message From header addresses MUST generate DMARC 
FAIL and SHOULD be rejected.

This is more in scope for DMARC discussions, though also arguably outside of 
the protocol itself, for the same reasons.  I would suggest that it's a viable 
discussion for the DMARC usage document, whenever we get around to working on 
that again.  But you could certainly test the working group opinion on this 
point.

Protecting the integrity of the name registration system is not an optional 
activity to be implemented by a few organizations with the most sophisticated 
implementations of the DMARC specification.   It should be a mandatory duty of 
every legitimate participant on the network.

Starting from the assumption that unregistered domains might be allowable 
creates many problems when trying to design solutions for protecting the names 
that are registered.   This assumption needs to be rejected.

These are both probably true statements, but is DMARC the right place to wage 
this battle?  For example, isn't it also true for TCP connections for which PTR 
records make false claims (or no claim)?

Addressing some straw-man questions:
Q:  The idea is fine for public suffixes, but my organization doesn't need to 
do that for subdomains under its control.
A:  Every level of the DNS tree needs coordination of name usage.Publishing 
an NS record for an organization subdomain proves that the organization's 
process has been followed.   Besides, the boundary between public suffixes and 
organizational domains is imprecise, so recipients cannot be expected to apply 
differential expectations.

I still don't understand what the presence or absence of NS tells you that the 
presence or absence of MX/A/ doesn't.  If you have a message that fails the 
latter test but passes the former, does that change your handling decision?  If 
not, why do it

Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

[Douglas E. Foster]

Does a transient outage report NXDOMAIN, or a different status?

 Original message 
From: "Murray S. Kucherawy"  
Date: 11/21/20  2:12 PM  (GMT-05:00) To: Doug Foster 
 Cc: Doug Foster 
, IETF DMARC WG 
 Subject: Re: [dmarc-ietf] Second WGLC for 
draft-ietf-dmarc-psd: Definition of NP 
On Sat, Nov 21, 2020 at 9:02 AM Douglas E. Foster  wrote:

> Restating what we all know:
> - The Internet is dependent on the reliable operation of the DNS name
> system.
> - The DNS name system is dependent on the reliable operation of the name
> registration processes.
> - The registrars are given ownership of all unregistered domain names
> within their portion of the hierarchy.
> - The public evidence of registration is the existence of a DNS entry, 
and
> a NS record is always the first one configured.
>
> Conclusions
> - Unregistered use of any domain name is an attack on the architecture 
of
> the Internet.
> - PSD for DMARC is asking us to give public suffix operators what they 
are
> supposed to already have:   control over unregistered names.
> - We should implement new and universal policies:
> - Unregistered names used as SMTP addresses MUST generate SPF FAIL 
and
> SHOULD be rejected.
>

That is certainly a defensible assertion, but I would claim it is out of
scope for DMARC.  You're talking about a detail of SPF or perhaps of SMTP
in general, although one could also even argue that this is a local policy
decision and outside the scope of those protocols.  I suspect the SMTP
greybeards would claim that this is not part of SMTP, but rather an
enforcement choice made by implementations.

I believe this falls within the realm of what the IETF calls an
Applicability Statement, which would be a standards track document (if you
could get consensus for it).  You could also include this in the DMARC
usage document, or as non-normative advice in DMARC itself with an
explanation of why it's a good idea, if you can develop consensus to do 
so.

You also need to account for transient DNS outages.  If your resolver
temporarily thinks "gmail.com" doesn't exist, you will bounce all mail
coming from that domain, and you might seriously piss off your users.
There's a backscatter problem here too: If I send mail to a list you're on
and you temporarily think my domain doesn't exist and you bounce mail
coming from me, the list will unsubscribe you.

- Unregistered names used as message From header addresses MUST
> generate DMARC FAIL and SHOULD be rejected.
>

This is more in scope for DMARC discussions, though also arguably outside
of the protocol itself, for the same reasons.  I would suggest that it's a
viable discussion for the DMARC usage document, whenever we get around to
working on that again.  But you could certainly test the working group
opinion on this point.

Protecting the integrity of the name registration system is not an 
optional
> activity to be implemented by a few organizations with the most
> sophisticated implementations of the DMARC specification.   It should be 
a
> mandatory duty of every legitimate participant on the network.
>
> Starting from the assumption that unregistered domains might be 
allowable
> creates many problems when trying to design solutions for protecting the
> names that are registered.   This assumption needs to be rejected.
>

These are both probably true statements, but is DMARC the right place to
wage this battle?  For example, isn't it also true for TCP connections for
which PTR records make false claims (or no claim)?

Addressing some straw-man questions:
> Q:  The idea is fine for public suffixes, but my organization doesn't 
need
> to do that for subdomains under its control.
> A:  Every level of the DNS tree needs coordination of name usage.
>  Publishing an NS record for an organization subdomain proves that the
> organization's process has been followed.   Besides, the boundary 
between
> public suffixes and organizational domains is imprecise, so recipients
> cannot be expected to apply differential expectations.
>

I still don't understand what the presence or absence of NS tells you that
the presence or absence of MX/A/ doesn't.  If you have a message that
fails the latter test but passes the former, does that change your 
handling
decision?  If not, why do it?

Q. How do we get all incoming filters to change to default block for
> unregistered domain names?
> A.  I would suggest using the CVE/CCE process.
>

That seems like a big hammer, and certainly outside of the IETF's purview.
We're not the protocol police.  You might try having this discussion in a
context like M3AAWG though; many large operators congregate there to
discuss stuff like this.

-MSK

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

Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

[Douglas E. Foster]

Restating what we all know:
- The Internet is dependent on the reliable operation of the DNS name system.
- The DNS name system is dependent on the reliable operation of the name 
registration processes.
- The registrars are given ownership of all unregistered domain names within 
their portion of the hierarchy.
- The public evidence of registration is the existence of a DNS entry, and a NS 
record is always the first one configured.

Conclusions
- Unregistered use of any domain name is an attack on the architecture of the 
Internet.
- PSD for DMARC is asking us to give public suffix operators what they are 
supposed to already have:   control over unregistered names.
- We should implement new and universal policies:- Unregistered names used as 
SMTP addresses MUST generate SPF FAIL and SHOULD be rejected.- Unregistered 
names used as message From header addresses MUST generate DMARC FAIL and SHOULD 
be rejected.

Protecting the integrity of the name registration system is not an optional 
activity to be implemented by a few organizations with the most sophisticated 
implementations of the DMARC specification.   It should be a mandatory duty of 
every legitimate participant on the network.

Starting from the assumption that unregistered domains might be allowable 
creates many problems when trying to design solutions for protecting the names 
that are registered.   This assumption needs to be rejected.

Addressing some straw-man questions:
Q:  The idea is fine for public suffixes, but my organization doesn't need to 
do that for subdomains under its control.
A:  Every level of the DNS tree needs coordination of name usage.Publishing 
an NS record for an organization subdomain proves that the organization's 
process has been followed.   Besides, the boundary between public suffixes and 
organizational domains is imprecise, so recipients cannot be expected to apply 
differential expectations.

Q: My business partner and I exchange information using unregistered 
subdomains, and it is working fine.   Leave me alone.
A: Of course, senders can register with recipients, to obtain a filtering 
exception, as an alternative to registering in the public DNS.   But the 
default behavior should be to block messages.   Note that private use of 
unregistered subdomains may cause subsequent conflicts if the organization 
assigns the name to another purpose.

Q. How do we get all incoming filters to change to default block for 
unregistered domain names?
A.  I would suggest using the CVE/CCE process.

Q. What does this mean for the PSD for DMARC process?
A.  I think it becomes unnecessary.   Getting all participants to block all 
unregistered domains is a better goal, and can probably be achieved more 
easily.   It should involve relatively simple software changes, minimal DNS 
load, and minimal evaluation-time overhead.

Doug Foster



From: fosterd=40bayviewphysicians@dmarc.ietf.org
Sent: 11/20/20 8:58 AM
To: 
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

To return briefly to the muddy waters that I created. John is correct that
"mail enabled" is not useful for the RFC5322.From address, and my last note
expanded on reasons why that is correct.

However, spoofing of non-existent subdomains is a potential problem for the
RFC5321.MailFrom domain, which then becomes an attack vector for the
RFC5322.From address as well. The problem exists because because SPF has no
organizational default.

We need to think about intermediate nodes, non-mail leaf nodes, and
non-existent subdomains. Assume that a spammer tries to spoof a legitimate
organization by using a non-mail or non-existing node for both the SMTP
MailFrom address and the message From Address. The message will be
evaluated as
- SPF=None,
- DomainAligned=True, and
- (if checked by some unknown algorithm) OrganizationReputation=good.

Can we assume that all such messages will be blocked by all recipients? It
seems better to have a published policy to say that it should be blocked.
Based on existing specifications, the organization has these defenses:

- All possibilities are protected if the organization DMARC sp policy is
enforceable (p<>none and pct<>0). However, we know that this is
problematic for many organizations.

- Mail-enabled nodes should have an SPF record, so those domains will be
protected.

- Existing but non-mail domains are only protected if they have an SPF -ALL
policy. This may be difficult and error-prone for the organization to
maintain.

Conclusions:
Assuming that many organizations are still at sp=none, we have an attack
surface from non-existent domains. The "must exist" policy provides the
only defense for non-existent nodes when the DMARC sp policy is
non-enforcing.

Assuming that many organizations will have trouble managing deployment of
SPF -ALL universally, we have an attack surface for non-mail subdomains.
The "must be mail enabled" policy provides a simpler 

Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

[Douglas E. Foster]

I fear that I muddied the waters by asking about the RFC5321.MailFrom address.  
 Let's return to the main issue of the RFC5322.From address which DMARC 
protects.

This is not an edge case.   If spam filters were already blocking messages with 
RFC5322.From addresses with non-existent domains, we would not be having this 
discussion.

The RFC5322.From address can be very ethereal.   Consider the following 
situation:

The marketing department of Example.com hires a mass mailer to do a campaign 
from market...@christmassale.example.com.
ChristmasSale.Example.Com does not currently exist.
The email service provider does its due diligence during account setup:

- The client has sent email communication from example.com and account 
paperwork for the same organization.   I have the client identified correctly,.
- The client has no DMARC policy on Christmas.Example.com, and an organization 
or PSD DMARC policy of SP=none, so I do not need to acquire a DKIM signing key.
- But the organization or PSD policy does specify NP, so I need the client to 
prove that ChristmasSale.Example.Com exists.

Requiring the client to create a bogus host record with a bogus IP address 
makes no sense, and is likely to be rejected by the client DNS administrator.

Requiring the client to create a name server record to prove domain existence 
does make sense, and should be easily approved and implemented by the client 
DNS administrator.

Ergo, defining the NP policy based on A, , and MX is not appropriate.

Doug Foster



From: eric.b.chudow.civ=40mail@dmarc.ietf.org
Sent: 11/20/20 6:30 AM
To: 'John Levine' , "'dmarc@ietf.org'" 
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

Thank you, John. I agree that it's an edge case and not worth addressing 
separately.

Eric Chudow
DoD Cybersecurity Mitigations

-Original Message-
From: John Levine 
Sent: Thursday, November 19, 2020 11:04 PM
To: dmarc@ietf.org
Cc: Chudow, Eric B CIV NSA DSAW (USA) 
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

In article 
<553d43c8d961c14bb27c614ac48fc03128116...@umechpa7d.easf.csd.disa.mil> you 
write:
>Section 2.7. defines a non-existent domain as "a domain for which there
>is an NXDOMAIN or NODATA response for A, , and MX records. This is
>a broader definition than that in NXDOMAIN [RFC8020]." This should be 
>sufficient for determining that the domain is not intended to be used and 
>therefore could have a more stringent policy applied.
>
>The idea of looking for a "mail-enabled domain" based on if an "MX record 
>exists or SPF policy exists" is interesting.
>Although there may be domains that send email but not receive email and so may 
>not have an MX record.

These days I think you will find that if the domains in your bounce address and 
your From: headers don't have an MX or A record, very few recipients will 
accept your mail. This seems like an edge case. In practice I find that the 
domains caught by the Org domain or I suppose PSD have A records but no mail 
server because they're actually web hosts rather than mail hosts.

We have the Null MX to indicate that a domain receives no mail and SPF plain 
-all to indicate that it sends no mail so I hope we don't try to reinvent these 
particular wheels.

R's,
John

___
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] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

[Douglas E. Foster]

Thank you for the pointer Eric.

Can someone explain why the chosen algorithm, which requires testing multiple 
conditions, is preferable to a single query for a name server record?   
Minimizing DNS traffic has been part of our recent discussion, and minimizing 
software complexity is always a good thing.

Can someone also explain why the DMARC appendix takes such a strong stance 
against all queries for non-existent domains, regardless of technique?  It 
seems like the philosophical incompatibilities need to be addressed before both 
documents advance.

DMARC is specified only as a test for the RFC5322.From domain.   
RFC5321.MailFrom domains may also be non-existent.  They will return SPF NONE, 
but that is an ambiguous result, and SPF has no organization default mechanism. 
 

- Is there data to indicate whether evaluators have found that checking the 
RFC5321.MailFrom for non-existence is useful?
- Suppose that the NP policy becomes generalized, and a domain has asserted a 
"must-exist" DMARC policy.   Should a non-existent subdomain used in the 
RFC5321.MailFrom address be treated skeptically?

I can imagine a scenario where a spammer uses a bogus subdomain of a legitimate 
organization, in an attempt to get whitelisted by spam filters which primarily 
evaluate the RFC5321.MailFrom address.   This attack could be paired with an 
unrelated and non-DMARC RFC5322.From address which is newly minted or otherwise 
not generally known to be suspicious,   So my instinct is that some extension 
of DMARC to the SMTP address will be beneficial.

Doug Foster



From: "Chudow, Eric B CIV NSA DSAW (USA)" 
Sent: 11/19/20 5:31 PM
To: 'Doug Foster' , 'IETF DMARC WG' 

Cc: "'dmarc-cha...@ietf.org'" 
Subject: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

Section 2.7. defines a non-existent domain as "a domain for which there is an 
NXDOMAIN or NODATA response for A, , and MX records. This is a broader 
definition than that in NXDOMAIN [RFC8020]." This should be sufficient for 
determining that the domain is not intended to be used and therefore could have 
a more stringent policy applied.

The idea of looking for a "mail-enabled domain" based on if an "MX record 
exists or SPF policy exists" is interesting. Although there may be domains that 
send email but not receive email and so may not have an MX record. Also, even 
if there is no SPF record, the domain may still send email, but then it might 
be held to a more stringent DMARC policy that would further penalize it for not 
having an SPF record.

Also, for the revision of the document I like the way that the three parts of 
the experiment are now laid out more clearly. My only comment is that the title 
of Appendix A is overly specific to just one of the experiments and so should 
be broader.

Thanks,

Eric Chudow
DoD Cybersecurity Mitigations

From: Doug Foster 
Sent: Tuesday, November 17, 2020 9:46 AM
To: 'IETF DMARC WG' 
Cc: dmarc-cha...@ietf.org
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

I did not see a definition of a "non-existent domain" (the np policy).   A 
definition is needed.

To my thinking, the obvious rule should be to query for a NS record for the 
domain.  If the record exists, then the domain owner could create a DMARC 
record for that domain, or could create a default entry for the domain at the 
organizational level.  If no record exists, it is because the domain owner 
chose to not create one.

However, the DMARC Bis document conflicts strongly with this.  In section A.4, 
it suggest several ways to do a test of this type, then repudiates all of them. 
 NS lookup is not one of the mentioned options.

There is a possible second-level policy test for a "mail-enabled domain".  I 
would define that test as "MX record exists or SPF policy exists".That 
could be an additional option to NP, but should not be a replacement for it.

PSD for DMARC clearly intends for the NP policy to be a general solution to a 
general problem.If there are still objections to it becoming a general 
solution, this should be addressed soon.

Doug Foster

From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Tim Wicinski
Sent: Friday, November 13, 2020 1:42 PM
To: IETF DMARC WG
Cc: dmarc-cha...@ietf.org
Subject: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd

All

During the IESG reviews of draft-ietf-dmarc-psd, there were several issues 
raised with some of the document.   Most of them are editorial but the one big 
item was the description of the Experiment.   The chairs sat down and broke out 
the experiment section into three separate experiments, and included language 
on how to capture the data to confirm how the experiment worked.

It's enough of a change that we wanted to do a second working group last call 
to make sure the working group agrees with our changes. The diff of the current 
version with the previous version is here:

[dmarc-ietf] tree walk and DNS optimization

[Douglas E. Foster]

Performance is probably a BCP issue.   However, since DNS performance concerns 
are a limiting factor on our specification options, the topic seems relevant 
menioning now.

In my mail stream, only a small subset requires a DMARC policy lookup to 
determine disposition.   I wonder if others have similar or different results.

- One large portion of mail is sent direct:   SPF-compliant and domain aligned, 
so it passes DMARC criteria without checking signatures.   This includes both 
spam and legitimate mail.

- Another large portion is from major email service providers and mailbox 
providers:   Based on observation and provider reputation, I have concluded 
that the RFC5322.From address accurate reflects the providers client domain.
This observation includes ESPs that service both spammers and legitimate 
clients, where I need to filter on the RFC5322.From to determine whether the 
message is wanted or unwanted.   In ESP messages, the presence of a valid 
signature for the client domain is correlated with a DMARC-enforcing policy, 
and the absence of a signature is correlated with non-enforcing client domains.

- A third portion is spam which we block based on nominal source identity.  
When blocking on source identity, we do not worry about verifying whether the 
unwanted source is valid or spoofed.

A smaller fourth portion includes messages from trusted senders that have 
configuration errors which cause SPF or DMARC policy failure.   I whitelist 
them based on verified characteristics, without needing to check DMARC policy.

For all four of these message groups, policy lookup is not needed during 
message processing.Consequently, the DMARC lookup can be deferred until the 
preparation of the RUA report, and duplicates can be eliminated to minimize DNS 
traffic when that report is being prepared.   This approach minimizes resource 
usage during message processing, so it seems in the interest of DMARC 
developers as well as DNS operations.

If developers will optimize in this way, the aggregate DNS workload will be 
significantly reduced, regardless of the algorithms specified.

Doug Foster

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Douglas E. Foster]

I beleive that we can and should address the Columbia University problem.  Here 
are some thoughts:

Policy Types
=---
We have three types of policies:

- "p=" policy for a specific domain
- "sp=" policy for subdomains that do not enumerate their own
- "sp=" policy for non-existent subdomains

Deploying a specific "p=" to every node will provide granular control for 
subdomains that exist, but it does not solve the problem for non-existent 
subdomains.

Non-Existent Domains
--
In almost every case, the policy for non-existent subdomains should be stricter 
than the one for existent subdomains, so sharing one policy for both purposes 
is problematic.   I created ticket #83 last night with a proposal to define a 
policy option for non-existent domains.

Roll-up Policy
--
When rolling a security policy up from leaf nodes upward toward higher level 
nodes, the weakest policy is the one that has to forwarded upward, unless there 
is a mid-tree override mechanism.  By allowing a lower-level subtree to apply a 
different policy than the parent, we allow the stricter policy to flow upward 
while the weak subtree retains its carve-out exception.

If a subtree needs a weak policy and that setting can only be accomplished at 
the top of the domain, then the entire organizaiton's security is weakened for 
the sake of the problematic leaf node.   This is exactly the situation that 
causes sp=none to persist indefinitely.

Inheritance
---
For subdomains that actually exist, one has to ask whether it is reasonable to 
expect an organization to implement a DMARC policy at every node of its domain 
tree.   In the event that a reporting address changes, the organization has a 
lot of changes needed to propagate that change everywhere. We would benefit 
from providing an ability to inherit from an upper-level entry using syntax 
like "inherit=N", where N is an integer number of domain levels.The 
evaluator determines the values for sp, rua, and ruf at the referenced domain, 
and uses the sp result for p and sp on the referencing subdomain.   Similarly, 
the rua and ruf values from the referenced domain are used to supply those 
values if they are not specified on the referencing subdomain DMARC record.   
Since the flow is only upward, the maximum number of iterations is limited, 
even if nested inheritance is allowed.   However, nested inheritance could be 
limited to a maximum number or disaloowed completely.  This approach allows 
subtrees to configure different reporting than the top-level of the 
organization.

Inheritance provides a more efficient method of walking up the domain tree, as 
compared to sequential iteration, for subdomains that actually exist and have 
an inheritance record defined..

QueryDown
--
Walking down the tree has some possibilities as well.

Assume that the top of the organization is located using the PSL, but as in the 
Columbia University example, the sp policy at that level is not necessarily 
determinative.A  token of the form "querydown=1" instructs the evaluator to 
accept the sp policy at this level as a candidate policy, but to check the next 
level down to see if an override applies.   If the token is missing or 0, then 
this record is determinative and the search stops.

- If the next level down is the original domain, then of course the process 
stops because this domain has already been checked for a p policy and been 
found lacking.
- If the next level down produces a DMARC record, the sp at this level becomes 
the new candidate policy, subject to checking for another querydown token.
- If the next level down does not have a DMARC record, the search stops and the 
last candidate policy is the effective policy.
In most cases, this process will end quickly because it will either exhaust the 
domain string, encounter a missing DMARC record, or encounter a DMARC record 
with querydown=0 (or missing).

If the querydown parameter is larger than one, the evaluator can jump down that 
many levels, eliminating intermediate ones.   Again, if this positions the 
match at or below the original domain or below, then the search stops and the 
last candidate policy is applied.

Again, a limit on the number of downward iterations would be applicable.   If 
an "inherit=n" token is being used to walk up the  tree, then the querydown 
parameter would be ignored.

Hope this helps,

Doug Foster



From: Joseph Brennan 
Sent: 11/12/20 9:24 AM
To: IETF DMARC WG 
Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On 
splitting documents and DBOUND

On Wed, Nov 11, 2020 at 4:21 PM Dave Crocker  wrote:
Just to invoke a bit of ancient history, here, you are saying that if
there was the domain name:

engineering.sun.com

people would be surprised that the organization domain is

oracle.com

As another case, would people be surprised that email for the 

Re: [dmarc-ietf] On splitting documents and DBOUND

[Douglas E. Foster]

Can we eliminate the PSL problem simply by adding some DNS queries?

Isn't there a maximum depth to the PSL, so that the evaluator can simply walk 
up the top N levels of the domain tree to find either an organizational DMARC 
entry with sp= or a PSD DMARC entry with sp=?   It looks like currently, n=4, 
because the published suffixes appear to extend to 3 levels.

DF



From: Dave Crocker 
Sent: 11/11/20 8:43 AM
To: John Levine , dmarc@ietf.org
Cc: dotz...@gmail.com
Subject: Re: [dmarc-ietf] On splitting documents and DBOUND

On 11/10/2020 6:24 PM, John Levine wrote:
> In article 
>  you 
> write:
>> This actually makes sense because there are other potential documents/uses
>> besides DMARC that could reference PSL-type mechanisms.
>
> Remember that this is a well-known swamp of despair. We had a whole
> DBOUND working group that failed to define a PSL-like thing.
>
> I am inclined to do nothing at this point, and if someday we actually
> succeed in doing DBOUND, whateever we define can update 7489bis to say
> to use it.

There is a difference between "splitting out existing text, on topic x"
from "revise text on topic x".

The current suggestion is to take the org domain text that is current in
the DMARC spec and to split it out, so that the core DMARC spec does not
contain specification language about organization domain, other than
"find the organizational domain".

That's a documentation hack, making later changes easier, rather than a
current attempt to devise better OD specification.

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

[dmarc-ietf] Separate document for policy?

[Douglas E. Foster]

Regarding Dav's comment:A claim that DMARC isn't DMARC unless there is policy 
seems an odd view,given p=none.I impute some social norms to the DMARC process: 
  The domain owner says to the receiver, "I want to help you block threats from 
spoofed messages (by providing policy), but I need your help (by providing 
feedback)".    In this context, p=none is implied to mean, "I want to help you, 
but I need you to help me first, while I am transitioning to full enforcement". 
 This assumes that the domain  owner intends to proceed to enforcement, which 
may not be true.This of course enables a free-rider mode:  "I am not interested 
in helping you.  I will be using p=none forever, simply because I want you to 
help me collect delivery statistics".     But even though it is possible, I 
don't think it is something that IETF should explicitly encourage,   I do not 
see policy as a sufficiently complex topic to warrant a separate document, 
especially if the separation is intended to communicate that free-rider mode is 
encouraged.Doug
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Optional p= makes no sense

[Douglas E. Foster]

Exactly. I was speculating.  What reasons could possibly exist for a domain to 
be given another method for not saying anythng?  You make my point - there are 
no valid reasons to do so.Sent from my Verizon, Samsung Galaxy smartphone

 Original message 
From: Dotzero  Date: 11/7/20  
1:34 PM  (GMT-05:00) To: IETF DMARC WG  
Subject: Re: [dmarc-ietf] Optional p= makes no sense 
..

>
> p=none probably means "I am trying to get my administrative controls in
> place, but I am not there yet", which still supports my earlier comment
> that "I don't know how to advise you on whether to accept or reject this
> message".
>

p=none simply means "This domain is not asserting policy". Reading anything
more than that into it is pure speculation.

Michael Hammer
___
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] Optional p= makes no sense

[Douglas E. Foster]

The report receiver verification step was referenced in the response.   This 
was the pointer:

https://tools.ietf.org/html/rfc7489#section-7.1.

It requires a DNS entry at: . _report._dmarc., type 
TXT, value "v=DMARC1"  (No other content is specified.)

Since the DNS location, the purpose of the entry, and the content are all 
different, I do not see that it has any bearing on the question of whether "p=" 
is required or not.

p=none probably means "I am trying to get my administrative controls in place, 
but I am not there yet", which still supports my earlier comment that "I don't 
know how to advise you on whether to accept or reject this message".

If p=missing means, "I am trying to get my administrative controls in place, 
but I am so chaotic that I cannot construct a compliant DMARC record", then I 
don't know why I should take the policy seriously.

If p=missing means "I am not trying to get any administrative controls in 
place, but I like to know whether my bot network is successful", then it is 
still not a DMARC record that I want to take seriously.

Overall, it is a small requirement to insist that the domain owner publish a 
compliant DMARC policy.

In addition, I propose making rua reporting mandatory.   A domain owner that 
does not want to learn about, and correct, his configuration errors cannot be a 
reliable source of policy information.   False positives will persist 
indefinitely, and therefore the policy record itself cannot be trusted.  Domain 
owners with persistent errors made SPF pretty much useless until DMARC came 
along.   I don't want to see it repeated.

Doug Foster



From: Steven M Jones 
Sent: 11/7/20 4:54 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Optional p= makes no sense

On 11/7/20 1:11 AM, Alessandro Vesely wrote:
> On Fri 06/Nov/2020 14:57:46 +0100 Todd Herr wrote:
>> On Fri, Nov 6, 2020 at 7:27 AM Douglas E. Foster wrote:
>>
>>> It makes no sense to allow "p=" missing.   Why would we suggest that
>>> all
>>> existing implementations alter their code to tolerate additional
>>> unnecessary complexity, rather than requiring domain administrators
>>> to key
>>> a few more characters so that code changes will not be necessary?
>
>
> Are there really implementations that choke on missing p=?
>
> How about "v=DMARC1; p=none; p=quarantine;"?

I'm pretty sure both cases would be invalid as DMARC policy records, in
which case they should be ignored. If an implementation is trying to do
something with invalid records like these, particularly one with
multiple "p=" tags, then that would be a problem.

>
>
>>> I also don't understand this comment from Alessandro :
>>>
>>>> "Operators who don't need policy, for example external report
>>>> receivers who just want to publish verification records, would find
>>>> the relevant
>>>> info in the base spec." >>
>>> There is only one policy record, published by the domain owner.  The
>>> DNS
>>> record either suggests enforcement (p=quarantine, p=reject) or it
>>> does not
>>> (p=none, p=missing, no DMARC record).
>>>
>>>
>> I can't speak for him, but I believe he's referring to the records
>> that a
>> report consumer outside the authority of the domain at issue might
>> publish,
>> as documented currently in
>> https://tools.ietf.org/html/rfc7489#section-7.1.
>> In those cases where, for example, foo.com publishes a DMARC policy
>> record
>> with a rua= value of say "repo...@bar.org", there must exist a TXT
>> record
>> of "v=DMARC1" at foo.com._report._dmarc.bar.org in order to confirm that
>> bar.org is consenting to receive these reports.
>
>
> Exactly!  Dropping the requirement allows the definition of DMARC
> record to be unique.  Not a terrific gain, just a little simplification.

I'm not aware of any requirement for third party report receivers to
publish a DMARC policy record for their domain, in order to operate as
report receivers. If that's what you meant, Ale, can you tell us where
it appears in RFC7489 or the -bis spec?

--S.

___
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] Optional p= makes no sense

[Douglas E. Foster]

I am just catching on to the implications of this discussion, and I must 
disagree

It makes no sense to allow "p=" missing.   Why would we suggest that all 
existing implementations alter their code to tolerate additional unnecessary 
complexity, rather than requiring domain administrators to key a few more 
characters so that code changes will not be necessary?

There is no functional difference between "p=" missing and "p=none".  Both 
configurations state: "I don't know what to tell you, you are on your own."

I also don't understand this comment from Allesandro :

"Operators who don't need policy, for example external report receivers who just
want to publish verification records, would find the relevant info in the base
spec."

There is only one policy record, published by the domain owner.  The DNS record 
either suggests enforcement (p=quarantine, p=reject) or it does not (p=none, 
p=missing, no DMARC record).

Let's not add code complexity when it provides no benefit.

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

[dmarc-ietf] RESENT fields?

[Douglas E. Foster]

Are the RESENT fields from RFC 5322 an interesting idea that everybody has 
ignored?For purposes of this discussion, they interest me because they 
provide a way of documenting changes to the SMTP sender, the From Header, and 
the recipient list.  RFC 5322 Section 3.6.6 says they SHOULD by added whenever 
a message is re-introduced to the transport system.   Mailing list activity 
seems to fit the language and intent of this section.   But I do not see any 
RESENT fields on the most recent posts to this list.   In fact, I am not sure 
that I have ever seen a message anywhere with these fields.

Application:
For forwarded messages, I don't want to trust the forwarder's spam filter, so I 
want to reconstruct the message identity as it appeared when the message 
entered the forwarder's ADMD.   The Resent fields would allow that logic to be 
developed, but I would also need forwarders to use those fields.   The usage 
would also need to apply to auto-forwarders, even though they are explicitly 
exempted from the RESENT header recommendation in the current RFC.

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Douglas E. Foster]

>From Rewrite
--
The need for From rewrite was predictable, based on the experience with SPF.  
It should have been included in the original specification.

SPF says that "The last domain to handle this message must authenticate 
itself."   If the message is sent directly, this is achieved by the domain 
owner's server identity, SMTP MailFrom identity, and SPF policy.   If the 
message is relayed for any reason, the SMTP MailFrom must be rewritten while 
also protecting the Return-Path.   SRS is the most common implementation for 
doing this, but there are other possibilities.

DMARC says that "The last domain to alter this message must authenticate 
itself."   If the message is sent without modification, the domain owner's DKIM 
signature authenticates the message whether it is sent directly or relayed.   
If it is altered in transit by a mediator, the mediator must rewrite the From 
address while protecting the recipient's perception of authorship and also 
protecting the Reply-To.The most common method seems to be 
user=domain@listdomain, but there are other possibilities, including my 
suggestion of useralias.listname@listdomain.

These requirements are inevitable consequences of the criterion being imposed.  
  So an important question is whether the end-user's dislike of From rewrite is 
sufficient reason to ignore the security benefits that DMARC provides.

Exception Mechanisms
---
Both SPF and DMARC are subject to configuration errors by the domain owner, as 
well as abuse by "essential" sources of incoming mail.  Therefore 
implementations SHOULD provide an exception mechanism which does not create 
side-effect risks.   I have major grievance with commercial products that do 
not provide safe and sufficient exception mechanisms.  I would like the 
specification to document exception handling as a requirement.

ISP Limitations

I am told that Office365 allows clients to place their own email filter in 
front of the one provided by Microsoft.  I don't know whether that solves the 
black box problem that Jesse raises.

Consensus
---
I thought the group had informally agreed that none of the alternative 
authentication mechanisms had a reasonable expectation of widespread 
implementation.   If so, the discussion comes down to those who believe DMARC 
is a disaster that needs to be undone, and those who believe that DMARC is a 
good thing that needs to be formalized.   I see no available path to consensus 
between those two positions.

Doug Foster



From: jesse.thompson=40wisc@dmarc.ietf.org
Sent: 10/5/20 8:22 PM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender 
Header Field

On 9/28/20 10:35 AM, Kurt Andersen (b) wrote:
> On Sun, Sep 27, 2020 at 11:23 AM Scott Kitterman  > wrote:
>
> On Sunday, September 27, 2020 1:16:11 PM EDT John Levine wrote:
>
> Agreed.  Maybe it would help if someone who takes the latter view would
> explain what they think RFC 7489, Section 6.6.2, Step 6 is for:
>
> >6.  Apply policy.  Emails that fail the DMARC mechanism check are
> >disposed of in accordance with the discovered DMARC policy of the
> >Domain Owner.  See Section 6.3 for details.
>
> I don't think that says "then toss the results into your classifier".
>
>
> You completely ignored section 6.7 (Policy Enforcement Considerations) which 
> states:
>
>> Final disposition of a message is always a matter of local policy.
>
> Local policy could be considered "the output of some classifier" or other 
> mechanics left to the invention of the receiver.
>
> This is a part of the documented DMARC spec, not a change.

Reading this thread, it comes to my mind that the "fundamental disconnect" that 
John raises is partly caused by an externalized factor: the shift to cloud 
mailbox hosting. The roles, responsibilities, and assumptions have changed.

The receiver, who is now a customer of an ISP, does not have the ability to 
"invent mechanics" because the tools aren't provided by the ISP. The ISP, of 
course, has a good reason to K.I.S.S. for support.

It means that the ISP takes over responsibility for local policy mechanics to a 
greater extent. Falling short of providing their customers a platform to invent 
mechanics the ISP will just implement the none|reject|quarantine mechanics and 
say they "support DMARC".

Even if the ISP has proprietary local policy mechanics that they apply to all 
of their customers' inbound mail, they aren't likely to document it in great 
detail or offer many exemptions. It's a black box.

e.g. I find it hard to imagine that an ISP would have the willingness to exempt 
a boutique MLM for all of their customers, so ARC, in and of itself, doesn't 
really help MLMs move away from From munging. Does it make sense to suggest 
that in order for ARC to succeed, then ISPs need to offer 

[dmarc-ietf] Weakend Signatures vs Experimental draft

[Douglas E. Foster]

Weakened signatures seem capable of getting to the desired goal more quickly 
than the draft under consideration.

Building on prior discussions of conditional signatures, I define a "weakened 
signature" as:
one where SUBJECT is omitted from the header list, and l=0 is included to 
exclude the body content.   The protected user-visible content becomes limited 
to From, To, and Date headers.

Benefits
==

Legitimate edits are allowed.
Mailing lists, auto-forwarders, and other mediators can edit subject and body 
content without invalidating the signature.
DMARC policy can still be set to p=reject or p=quarantine.

Only Mediators can use the weakened signature
To benefit from the weakened signature, a system must be in possession of a 
validly-signed message.

Time-Limited
A weak signature is only valid until is expiration time.

No specification needed
This approach can be implemented immediately, by anyone.

Disadvantages


Replay Attacks are possible.
Any attacker who gains possession of a weakened-signature message can use it to 
send an unlimited number of messages, using the same From/To/Date combination, 
until the signature expiration.   Since the SMTP Recipient address is not 
required to align with the Message To header, the attacks could include 
recipients unrelated to the original message.

Potentially-wide scope:
Every recipient of a mailing list message is a potential source for leakage of 
signature information, so the message is at risk both when in transit and when 
at rest in destination systems.

Mitigation Options
==

Sender-side mitigations by the Domain Owner

Limited Deployment
A sender could choose to only apply the weakened signature when the destination 
is a known to need to make changes and is trusted to do so.   This limits the 
opportunity for messages to be intercepted for use in a replay attack.

Dual Signatures
A sender could apply a weakened signature and a traditional signature, to 
permit recipient systems to evaluate messages based on the strength of the 
signature used.   By using different selectors for the two signatures, DMARC 
reporting would help identify which mediators are making signature-altering 
changes.  To help ensure that a traditional signature is detected and used 
first by the receiving system, the traditional signature should appear first, 
followed by the weakened one.

Recipient-side mitigations

A recipient could check signature parameters to determine whether it was 
weakened or traditional, and prefer the traditional signature when both are 
valid.When only a weakened signature is valid, the recipient can perform 
differential handling, based on the reputation of the submitting server and 
other factors.

Changes required:
==

Sending Domains
Senders would need to choose to participate in this scheme by applying a 
weakened signature.
Conditional use of a weakened signature may require software changes.
Simultaneous application of weakened and traditional signatures may require 
software changes.

Mediators
Mediators would need to test for the presence of a weakened signature, and use 
that result to decide whether From-rewrite could be avoided.

Recipient Domains
Recipients can be assumed to participate immediately, on the assumption that 
very few recipients currently apply differential handling of traditional and 
weakened.
Software changes may be needed, if recipient domains wish to implement 
differential handling of traditional and weakened signature.

Comparison to Crocker Draft
==
Draft proposal requires sender domains to opt-in by configuring a DNS entry, so 
all outbound messages are affected.
Draft proposal allows impersonation by any system which can apply a Sender 
header and a valid signature for the sender domain, so the range of possible 
spoof sources is unlimited once a domain opts-in.
Draft proposal can be used to impersonate without intercepting a valid message.
Draft proposal requires recipient domains to opt-in, and to implement new logic 
when doing so.
Draft proposal does not provide a way for mailing lists to know or assume that 
the recipient domain is participating.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Douglas E. Foster]

I'm confused.

I thought we all agreed that From represents the author who is responsible for 
the content, and consequently it had importance to both the filtering process 
and the user.   I thought the issue at hand was that DMARC-induced header 
munging made the From address into something different then the address which 
best represents the author.   So it seemed like we had a lot to agree on.

Also, I thought a trust indicator was a statement like
"The From Address is DMARC-verified",
rather than
"This message is from user@domain"

Which leads me to several questions
- Does the research support the idea that the From address is a trust indicator?
- Is so, does it show that the only purpose of the From address is as a trust 
indicator?
- If "From" has purposes other than as a trust indicator, does it matter 
whether the value is correct or not?
- If it is true that the From address serves no purpose to the user, then is 
header munging really a problem?

DF



From: Dave Crocker 
Sent: 9/27/20 1:26 PM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender 
Header Field

On 9/27/2020 10:16 AM, John Levine wrote:
> I suppose both are right to some extent, but they have very different
> implications for the design.

Except they aren't both right.

We know that it is used by filtering engines.

There is no evidence it is used by end-users. And there is a pretty long
history indicating such information is NOT used by end users.

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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Douglas E. Foster]

My apology, Dave, for letting my frustration get the best of me.

Doug Foster



From: Tim Wicinski 
Sent: 9/26/20 12:33 PM
To: fost...@bayviewphysicians.com
Cc: "dmarc@ietf.org" 
Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender 
Header Field

And here we were getting along so well!

Mr Foster, it's perfectly fine to disagree with Mr Crocker technical points, 
and you are
welcome to have your own opinion on whether he chooses to hear or not.  But 
those opinions should
be kept to yourself.

I see a lot of these heated discussions as a sign that people really care about 
this issue. That's
a good thing.

For the record, I'm a DNS person.  I see most problems as being solved with 
more DNS, or less DNS.
I will say that I have had "passionate discussions" with Mr Crocker on several 
issues and I found that
it was not that he did not listen, but figuring out how to better explain my 
point of view.
Surprisingly to many, he does listen.

Whether this work is in scope for DMARC or not, I would plead guilty for not 
considering this carefully.
In the DNSOP working group I co-chair, *everything* DNS is in scope, until it 
is not in scope.
These types of discussions I was leaning on Seth, Alexey and of course Murray 
the AD.

thanks for listening.
tim

On Sat, Sep 26, 2020 at 8:55 AM Douglas E. Foster 
 wrote:

The problems with your proposal have been well documented, but you apparently 
choose not to hear.   The single paragraph that Scott quoted has multiple 
problems within it.

The group has considered other and better technical proposals (conditional 
signatures, ATSP, RHSWL), but they have all been dropped because the group did 
not believe that Domain Owners would have any desire to implement them, and 
because Mailing List Operators would have no way of knowing which mailing lists 
had implemented the new feature.

If you have solutions to these problems, please put them forward.   Otherwise, 
why are we dragging this back up?



From: Dave Crocker 
Sent: 9/25/20 11:04 PM
To: Scott Kitterman 
Cc: IETF DMARC WG 
Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender 
Header Field

On 9/25/2020 4:21 PM, Scott Kitterman wrote:On Friday, September 25, 2020 
7:05:22 PM EDT Dave Crocker wrote:I think the obligation to justify is on the 
advocate for change.
That means you are demanding I prove  negative.  Which, of course, is an 
impossible assignment.

Rather, the obligation is on the person claiming the affirmative, which in this 
case means the claim that this proposal somehow 'breaks' or otherwise hurts 
DMARC.

Because the current email protection behavior involves the
RFC5322.From field, and pertain to the human author, it is common to
think that the issue, in protecting the field's content, is behavior
of the human recipient.  However there is no indication that the
enforced values in the RFC5322.From field alter end-user behavior.
In fact there is a long train of indication that it does not.
Rather, the meaningful protections actually operate at the level of
the receiving system's mail filtering engine, which decides on the
dispostion of received mail.

Please provide references for your long train of indications, speaking of
making overly broad assumptions.  If that's accurate, I'd like to understand
the data that tells us that.
I'm not going to do that, because there's a long history of that work being 
ignored, in spite of it being reviewed repeatedly in thse and related fora over 
the years.  It's gotten tiresome to have people claiming an effect that they 
lacks evidence for, and the data to the contrary that they are somehow unaware 
of.

Again, the real requirement is focus on the affirmative.

In this case, an affirmative claim that end-users are relevant to the efficacy 
of DMARC.  I don't recall seeing any research results validating such a view, 
but perhaps I missed it.

Well, ok, here's one that shows lack of efficacy, and it's a big one:  EV-certs

Google to bury indicator for Extended Validation certs in Chrome because users 
barely took notice

https://www.theregister.com/2019/08/12/google_chrome_extended_validation_certificates/

"The reason is simple. "Through our own research as well as a survey of prior 
academic work, the Chrome Security UX team has determined that the EV UI does 
not protect users as intended... users do not appear to make secure choice..."

If this is just an input into an algorithm, then your assertion that you are
only providing another input is supportable, but that's contrary to the DMARC
design.
Perhaps you have not noticed but the demonstrated field use of DMARC, to date, 
tends to be contrary to the design, to the extent anyone thinks that the design 
carries a mandate that receivers follow the directives of the domain owners.

So the text in the draft merely reflects real-world operational styl

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Douglas E. Foster]

The problems with your proposal have been well documented, but you apparently 
choose not to hear.   The single paragraph that Scott quoted has multiple 
problems within it.

The group has considered other and better technical proposals (conditional 
signatures, ATSP, RHSWL), but they have all been dropped because the group did 
not believe that Domain Owners would have any desire to implement them, and 
because Mailing List Operators would have no way of knowing which mailing lists 
had implemented the new feature.

If you have solutions to these problems, please put them forward.   Otherwise, 
why are we dragging this back up?



From: Dave Crocker 
Sent: 9/25/20 11:04 PM
To: Scott Kitterman 
Cc: IETF DMARC WG 
Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender 
Header Field

On 9/25/2020 4:21 PM, Scott Kitterman wrote:On Friday, September 25, 2020 
7:05:22 PM EDT Dave Crocker wrote:I think the obligation to justify is on the 
advocate for change.
That means you are demanding I prove  negative.  Which, of course, is an 
impossible assignment.

Rather, the obligation is on the person claiming the affirmative, which in this 
case means the claim that this proposal somehow 'breaks' or otherwise hurts 
DMARC.

Because the current email protection behavior involves the
RFC5322.From field, and pertain to the human author, it is common to
think that the issue, in protecting the field's content, is behavior
of the human recipient.  However there is no indication that the
enforced values in the RFC5322.From field alter end-user behavior.
In fact there is a long train of indication that it does not.
Rather, the meaningful protections actually operate at the level of
the receiving system's mail filtering engine, which decides on the
dispostion of received mail.

Please provide references for your long train of indications, speaking of
making overly broad assumptions.  If that's accurate, I'd like to understand
the data that tells us that.
I'm not going to do that, because there's a long history of that work being 
ignored, in spite of it being reviewed repeatedly in thse and related fora over 
the years.  It's gotten tiresome to have people claiming an effect that they 
lacks evidence for, and the data to the contrary that they are somehow unaware 
of.

Again, the real requirement is focus on the affirmative.

In this case, an affirmative claim that end-users are relevant to the efficacy 
of DMARC.  I don't recall seeing any research results validating such a view, 
but perhaps I missed it.

Well, ok, here's one that shows lack of efficacy, and it's a big one:  EV-certs

Google to bury indicator for Extended Validation certs in Chrome because users 
barely took notice

https://www.theregister.com/2019/08/12/google_chrome_extended_validation_certificates/

"The reason is simple. "Through our own research as well as a survey of prior 
academic work, the Chrome Security UX team has determined that the EV UI does 
not protect users as intended... users do not appear to make secure choice..."

If this is just an input into an algorithm, then your assertion that you are
only providing another input is supportable, but that's contrary to the DMARC
design.
Perhaps you have not noticed but the demonstrated field use of DMARC, to date, 
tends to be contrary to the design, to the extent anyone thinks that the design 
carries a mandate that receivers follow the directives of the domain owners.

So the text in the draft merely reflects real-world operational style.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC bis: revisiting ticket 66

[Douglas E. Foster]

Steven Jones observes correctly that
"DMARC is a _cooperative_ endeavor"
between the Domain Owner and the Mail Receiver.   This is true once DMARC is 
operational.

But before DMARC becomes operational, it is a cooperative effort between the 
mail system owner and the software developers.By defining functional 
groups, I believe IETF can facilitate the development of usable products and 
facilitate the intelligent purchase of suitable products by organizations that 
wish to implement DMARC.

As a particularly bad example:  I have access to a product that has a single 
checkbox for enabling DMARC.When it is on, messages that do not pass DMARC 
verification are blocked or quarantined,   When it is off, DMARC is not 
evaluated.   It provides no ability to test the impact of DMARC evaluation 
prior to activating the feature.   The logging subsystem is just a capture of 
the SMTP chatter, so finding all of the DMARC failures would be difficult.   
Depending on the reject codes used, it may not even be possible to identify 
which messages are blocked because of DMARC.   Once found, there is no 
mechanism for creating exceptions to correct false positives.  There is no 
configuration of whether SPF evaluation is strict or relaxed.   In short, the 
implementation is useless in the real world.   But it can be marketed as 
"implements DMARC" (without outbound reporting), simply because the developers 
coded something that complies with part of the specification.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC bis: revisiting ticket 66 - DMARC compliance levels

[Douglas E. Foster]

Rather than approaching the topic based on the degree of completeness that has 
been achieved, I prefer to approach it from the perspective of functional 
components that should be implemented jointly.   I propose six function groups. 
  The grouping and the justification for that grouping appear below.

Doug Foster

Sender:  Capabilities required prior to publishing a DMARC policy

- Sender should assume that some recipients may uplift from p=none to 
p=quarantine or uplift p<100 to p=100.   To minimize the risk of blocked 
messages, known mail sources should be configured with DKIM signatures before a 
DMARC policy is published.

- Sender should assume that, on initial implementation, the domain will have 
some legitimate but not-verifiable messages.   Therefore an rua=address 
destination must be configured in the policy to become aware of those problems. 
  Recipients which detect a DMARC policy without any rua=address can assume 
that the sender is not serious and the policy is not trustworthy.

- Sender should have a process in place for reviewing DMARC reports to detect 
and correct errors that cause DMARC verification failures.

Sender / Mediator:   Capabilities required for a DMARC-aware outbound gateway

- Sender / Mediator should be aware that transmitting messages which fail DMARC 
verification could lead to reputation problems, ranging from individual 
messages being rejected to the source domain's servers being blacklisted.

- Therefore, outbound traffic should be handled as follows:- Determine whether 
each message's source domain has a DMARC-enforcing policy.  - If required, 
implement one of these compliance measures:- Ensure that a valid DKIM signature 
is present, based on a known-good configuration flow or based on a test 
verification.- Add a valid DKIM signature if one is not present and a DKIM key 
is available.- Rewrite the From address to the local domain, and preferably add 
a DKIM signature for the local domain, so that the message will pass DMARC when 
it is received.- Reject the message as undeliverable.

Recipient:  Capabilities required for a DMARC-aware incoming gateway.

- Recipient should assume that some legitimate senders will have configuration 
errors, even if sender policy asks for enforcement.Any DMARC-enforcing 
implementation should have an exception mechanism for overriding p=quarantine 
or p=reject for specific MailFrom + From combinations.

- Recipient should consider that whitelisting a trusted sender is only safe if 
spoofing risk has been ruled out.   DMARC-verified combinations of Mail>From + 
From provides the recipient with the spoof-safe information needed to support 
whitelisting when whitelisting is desired.   Any DMARC-enforcing implementation 
should allow DMARC verification status to be included in a whitelisting policy 
rule.

Recipient:   Capabilities required for an incoming gateway with DMARC "rua" 
reporting

- Incoming gateway must accurately test incoming messages for DMARC policy 
compliance
- Incoming messages and their DMARC status must be logged into a database that 
supports reporting.
- An automated process must be in place to parse the database to generate the 
DMARC "rua" reports on the required schedule.
- An automated submission process must be in place to transmit the generated 
"rua" reports when they are generated.

Recipient:   Capabilities required for an incoming gateway with DMARC "ruf" 
reporting

- Incoming gateway must integrate DMARC-policy checking with message threat 
assessment.
- Incoming gateway must provide configuration mechanism to specify whether or 
not a specific ruf-requesting domain should actually be given such notices.   
The reporting policy will depend on the recipient's perception of the source's 
good administrative intentions.
- Incoming gateway must provide configuration mechanisms to specify which types 
of undesired messages will trigger an "ruf" report.
- Incoming gateway must be able to generate and transmit an "ruf" report in a 
timely manner after a problem message has been received.
- Incoming gateway must provide throttle controls to avoid backscatter from 
excessive "ruf" reporting.   This must include, but need not be limited to, any 
throttling rules provided in the DMARC specification.

Sender:  Capabilities required for receiving "ruf" reports

- Sender must provide an "ruf" destination mailbox.
- "ruf" mailbox must be integrated into a security monitoring and alarming 
environment, so that corrective action begins in a timely manner after an alarm 
is received.
- "ruf" mailbox management must be prepared to cope with high message rates 
because an infected account might generate a high rate of objectionable 
messages, which may in turn generate a high rate of "ruf" reports.



From: seth=40valimail@dmarc.ietf.org
Sent: 9/23/20 5:50 PM
To: IETF DMARC WG 
Subject: [dmarc-ietf] DMARC bis: revisiting ticket 66

As Chairs, we'd like to push for 

Re: [dmarc-ietf] DMARC and Gateways?

[Douglas E. Foster]

Yes, I understood the section to be referring to those types of gateways.  I 
just don't understand where the problem occurs.   There may be other gateways 
in the future, so I am reluctant to say it ceases to be important.

I will try to phrase the question better:

It seems that there are three elements of a gatewayed address:   The remote 
technology destination address, the gateway / boundary device identifier, and 
the TCP domain that is used for incoming traffic.

One possibility is that the TCP domain is dedicated to the gateway function.   
Mail-to-SMS gateways work this way.   They are not a perfect example because I 
don't think SMS can send to TCP.   But if they did have outbound capability, 
the TCP Domain that is dedicated to the gateway function would be able to 
comply with DMARC by applying DKIM signatures and publishing an SPF address as 
well.   Just as importantly, the domain is not shared so it would have the 
option of not publishing a DMARC policy at all.

Another possibility is that the gateway ID is a dedicated subdomain of the TCP 
domain.   If the parent domain publishes a DMARC policy that the gateway cannot 
implement, then the subdomain could publish a p=none policy.

The third possibility is that the gateway ID is in the local-part of the TCP 
address, so gateway mail is obligated to meet the DMARC policy of the TCP 
domain.   But even here I have trouble understanding where the problem occurs.  
Email to the gateway must route through the TCP domain's MX record, so I would 
expect that return traffic would route back through the same path, and the 
parent domain could ensure DMARC compliance when outbound mail is released to 
the Internet.   But if the gateway bypasses the TCP domain and submits using a 
gateway associated with the destination email address, then that system should 
know that the message is coming from the other technology and DMARC is not 
applicable.

The only scenarios where I can generate a DMARC problem are:
- a message is sent from a gateway directly to the destination domain, 
bypassing the From domain, and then the message is auto-forwarded to a 
different administrative domain.   The auto-forward destination will see a 
DMARC failure.
- routing is asymmetric, where incoming messages flow through a specific TCP 
domain but outbound messages are sent directly from a public gateway to any 
address on the Internet.  The destination domain will see a DMARC failure 
because the public gateway is impersonating the SMTP-equivalent address of 
every user on the other technology.

Perhaps asymmetric routing was normative for some of those older technologies.  
 I just don't know.

DF


From: ken=40wemonitoremail@dmarc.ietf.org
Sent: 9/15/20 9:01 AM
To: "dmarc@ietf.org" 
Subject: Re: [dmarc-ietf] DMARC and Gateways?

If you are referring to section 3.2.4. then I'm pretty sure that's referring to 
gateways in the protocol sense (see RFC 5598, section 5.4.) which convert 
internet mail into a different messaging protocol, such as SMS/MMS or 
(historically) UUCP. The interoperability concerns are still valid though there 
is much less of this in wild than there was 10 years ago and (for sending) you 
can normally put a compliant MTA in front of them.

Ken.



From: dmarc  On Behalf Of Douglas E. Foster
Sent: Tuesday 15 September 2020 11:59
To: dmarc@ietf.org
Subject: [dmarc-ietf] DMARC and Gateways?

I was surprised to see email technology gateways included in RFC 7960.

I would expect that a public gateway would use a from address within the 
gateway domain name, so that it can accept replies.   A gateway dedicated to a 
single organization would release messages into that organization on a trusted 
path, and anything forwarded out of that organization would be signed at the 
outbound mail gateway.

Can anyone who was involved with RFC 7960 comment on whether the gateway 
problem still exists?

DF

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

Re: [dmarc-ietf] DMARC as Signal to MLMs for Rewrites (or not)

[Douglas E. Foster]

I had been working on proposed language to strengthen section 5, which has a 
very weak justification of the use of the From address, because the prior 
discussion has left the issue hanging.The current text is followed by my 
proposed replacement text.   Perhaps the group and the chairs are ready to 
address issue 73?

Doug Foster

Current language:

5.  Use of RFC5322.From

One of the most obvious points of security scrutiny for DMARC is the

choice to focus on an identifier, namely the RFC5322.From address,

which is part of a body of data that has been trivially forged

throughout the history of email.

Several points suggest that it is the most correct and safest thing

to do in this context:

*  Of all the identifiers that are part of the message itself, this

is the only one guaranteed to be present.

*  It seems the best choice of an identifier on which to focus, as

most MUAs display some or all of the contents of that field in a

manner strongly suggesting those data as reflective of the true

originator of the message.

The absence of a single, properly formed RFC5322.From field renders

the message invalid.  Handling of such a message is outside of the

scope of this specification.

Since the sorts of mail typically protected by DMARC participants

tend to only have single Authors, DMARC participants generally

operate under a slightly restricted profile of RFC5322 with respect

to the expected syntax of this field.  See Section 6.6 for details.

Proposed

5.  Use of RFC5322.From

DMARC's use of the RFC5322.From address has been challenged as arbitrary, 
especially since many MUAs display it only upon request.However, the 
RFC5322.From has consistently been understood to represent the person or other 
entity who is the author of the content and for whom responsibility should be 
attributed, so the integrity of RFC5322.From is critical to the credibility of 
the content.  If the content is to be reliably attributed, the FC5322.From 
address needs to be reliably verified.   Only the RFC5322.From address can 
serve this purpose.

The RFC5322.From has all of the necessary characteristics for the purpose of 
attribution.  First, it is a globally unique identifier.   Secondly, it is 
stable over time.  Because it is unique, it distinguishes this author from all 
other authors with similar names.   Additionally, because many users have 
multiple email addresses for different purposes, the RFC5322.From address also 
distinguishes between different roles taken by a single individual.   For all 
of these reasons, it is very useful for searching and sorting.  The 
RFC5322.From address is the only identifier that is presented to the user which 
can be verified.  The RFC5322.From address is the value which the user expects 
will be used for replies to the message.

A successful spoof of the RFC5322.From address permits the attacker to "put 
words in the mouth" of the spoofed individual, an action which could cause 
great harm to the sender's reputation.   If the recipient of the spoof replies 
to the spoofed originator, the recipient might also suffer significant 
embarrassment.

By comparison, the Friendly Name provides no uniqueness, has no settled format, 
has no verifiability, and has no permanence.Since the Friendly Name is 
usually configured in the MUA, the Friendly Name may change randomly based on 
the MUA currently being used by the sender, and the sender can alter it at any 
time to any value for any reason.   Attackers have been known to mimic the 
Friendly Name of someone known to the recipient to increase the effectiveness 
of the attack.  When a user sees suspicious content from a trusted Friendly 
Name, one appropriate response is to compare the Friendly Name to the 
RFC5322.From address to test for logical consistency.  Often, this is 
sufficient to detect the deception.

The value of the RFC5322.From address has been established by two disparate 
groups:  users of mailing lists and criminal actors.  Neither of these groups 
can be considered supporters of DMARC.  Mailing list users have complained 
vigorously because DMARC enforcement has caused mailing lists to alter the 
RFC5322.From address in ways that make sorting, searching, and other actions 
more problematic for them.Criminal actors have responded to DMARC by using 
look-alike domains that seek to impersonate the identity of a well-known domain 
without being subject to DMARC controls.   This action demonstrates that the 
criminal subculture, which DMARC seeks to restrict, knows that a successful 
spoof of the RFC5322.From address will be beneficial to their efforts.



From: listsebby=40me@dmarc.ietf.org
Sent: 9/17/20 6:10 PM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] DMARC as Signal to MLMs for Rewrites (or not)

On 17 Sep 2020, at 20:59, Jesse Thompson 
 wrote:
> On 9/17/20 2:11 PM, Sabahattin Gucukoglu wrote:
>> Wouldn't it be nice if you could ask for MLMs to 

[dmarc-ietf] DMARC and Gateways?

[Douglas E. Foster]

I was surprised to see email technology gateways included in RFC 7960.

I would expect that a public gateway would use a from address within the 
gateway domain name, so that it can accept replies.   A gateway dedicated to a 
single organization would release messages into that organization on a trusted 
path, and anything forwarded out of that organization would be signed at the 
outbound mail gateway.

Can anyone who was involved with RFC 7960 comment on whether the gateway 
problem still exists?

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

Re: [dmarc-ietf] Issue submission - Mailing list security and potential solutions using DMARC

[Douglas E. Foster]

This is very much in scope.

Sometime back, I argued that the difference between "user@domain" and 
"user=domain@listdomain" was a matter of mailing list user preferences, and 
user preferences were not a relevant concern of IETF.   I also noted that I had 
additional user preference topics that I could propose if we were going to head 
down that path.I had two people oppose my comment, and no supporters.
One of those responses said that we could discuss additional mailing list user 
preference issues as long as they were registered with the chairs.   We have 
spent months talking about the equal sign in the From address.   I am 
introducing a user preference issue that has much greater importance than an 
equal sign.

Additionally, the chairs have told us that we must address RFC 7960, 
particularly as it affects mailing lists, or we will never reach standards 
track.   So there is no reason to "move on to other topics", because we have 
nowhere to go.

At the beginning of this discussion, mailing lists had these options:

- Reject subscriptions from domains that enforce DMARC.
- Ignore DMARC and accept the impact on delivery to some destinations.
- Rewrite the From address for the sole and distasteful purpose of 
accommodating DMARC.

Based on the premise that a mailing list's only real problem was DMARC-imposed 
delivery obstacles, we have spent months trying to find a way to give them what 
we want.   All of those approaches involved asking the entire Internet to 
implement new code and new configurations to please the mailing lists.   I 
believe the group has reluctantly concluded that none of those proposals have 
any useful potential.We started from incompatible requirements:   DMARC 
prohibits impersonation that is not authorized by the domain owner, while 
mailing lists require impersonation on single-user authorization, an 
authorization given via unverifiable mechanisms.   So failure was not 
surprising.

But every solution is constrained by the way that the problem is framed, and 
this exercise has been constrained by the assumption that the equal sign was 
the whole problem.   Asking the larger question of "what other problems might 
be important to mailing list users?" allows us to rethink our solution 
strategies.The alias-based private list approach which I have suggested 
addresses those other problems while incidentally making the DMARC problem 
unimportant.   The From address is still rewritten, but it is rewritten for 
reasons that are in the interest of the subscribers.   It is an OPTION for the 
mailing list, and therefore it complies with the charter requirement to give 
the mailing list operators a better option.

But the OPTION is not possible unless somebody provides MLM software that can 
implement that OPTION.   If the software vendors have not implemented this idea 
in the last 40 years, then an IETF specification might be the necessary 
incentive to create both demand and supply.

I will be loudly objecting if this option is excluded as out of scope, and then 
subsequent reviewers object to our product because we did not respond to RFC 
7960.

To finish the RFC 7960 response, we also need to address technology gateways 
and Sieve engines.  Then we need to decide whether the responses go into the 
main specification or a standalone document.

Doug Foster



From: Dotzero 
Sent: 9/11/20 8:05 AM
To: "Douglas E. Foster" 
Cc: "dmarc-cha...@ietf.org" , "dmarc@ietf.org" 

Subject: Re: [dmarc-ietf] Issue submission - Mailing list security and 
potential solutions using DMARC

This proposal is way outside the scope of DMARC and the scope of the effort for 
this group. Let's not try to boil the ocean.

Michael Hammer

On Thu, Sep 10, 2020 at 6:51 PM Douglas E. Foster 
 wrote:

Recently, I have become worried about the risks associated with using my 
regular email on this list, especially since everything goes into a long-term 
archive.   I am wishing that I had subscribed using a disposable account.   
A general safety principle is to limit how and when one's email address is 
released, because once it is released, it cannot be taken back. There are a 
number of potential problems associated with releasing actual email addresses 
onto a mailing list.
Address Harvesting

Any subscriber could potentially be harvesting email addresses from the list, 
and forwarding them to a spam source.   The spammer can tune his attacks more 
closely using other information gathered from list posts, including the list 
area of interest and other information disclosed in the course of list 
discussions.   If the harvesting is occurring, list participants and list 
operators have no method for identifying and closing the leak.

Badly Behaved Subscriber / Stalking

If a subscriber starts behaving badly toward another member, particularly in 
some form of cyber-st

[dmarc-ietf] Issue submission - Mailing list security and potential solutions using DMARC

[Douglas E. Foster]

Recently, I have become worried about the risks associated with using my 
regular email on this list, especially since everything goes into a long-term 
archive.   I am wishing that I had subscribed using a disposable account.   
A general safety principle is to limit how and when one's email address is 
released, because once it is released, it cannot be taken back. There are a 
number of potential problems associated with releasing actual email addresses 
onto a mailing list.
Address Harvesting

Any subscriber could potentially be harvesting email addresses from the list, 
and forwarding them to a spam source.   The spammer can tune his attacks more 
closely using other information gathered from list posts, including the list 
area of interest and other information disclosed in the course of list 
discussions.   If the harvesting is occurring, list participants and list 
operators have no method for identifying and closing the leak.

Badly Behaved Subscriber / Stalking

If a subscriber starts behaving badly toward another member, particularly in 
some form of cyber-stalking, the list operator can discharge the perpetrator 
from the list.   Unfortunately, the discharge action does not cut off access to 
the victim, because the victim's personal email address has already been 
disclosed.

Malicious Content filtering

A well-run list will implement a variety of techniques to prevent hostile 
content from being distributed.However, once personal addresses have been 
disclosed, a bad actor can bypass those filters by sending the same prohibited 
traffic directly to any subscribers who have posted to the list.
Consequently, the burden of defense remains on the recipient organization, 
because the list defenses are too easily evaded.

List Spoofing

A well-run mailing list is likely to breed an elevated level of trust among the 
participants.   As a result, a successful spoof of the mailing list is that 
much more likely to be successful.To the recipient, the DMARC list is 
primarily identified by the subject tag and the IETF footer.   The absence of 
attachments and the text-only format are additional clues.   These are arguably 
"trust indicators", and we have discussed that trust indicators have limited 
effectiveness.For example, many MUAs will make URLs in a text-only message 
into a clickable link, blurring the visual distinctiveness between text and 
html messages.An attacker could potentially replicate the subject tag and 
footer, apply a non-DMARC address, and send it from his own server.The 
incoming email filter is unlikely to have the sophistication to recognize that 
this format is only supposed to come from IETF, so the message is likely to be 
allowed and the users are at risk of being duped.

The Alternative

All of these problems can be avoided if the subscriber is given an alias at 
enrollment, and the alias is used for all messages relayed on the subscriber's 
behalf.For this list, my alias could be dougf.dm...@ietf.org.   Messages 
sent to an alias address must be submitted through the list operator, and the 
list manager should have logic to reject messages from a non-subscriber that 
are targeting a subscriber alias.

Because the personal email address is only known to the list operator, 
harvesting is impossible.   Any aliases that are harvested from the list will 
be unusable by a spammer operating outside the list.

For the same reason, if a misbehaving subscriber is ejected from the list, he 
immediately loses access to the people who were the victims of his actions.

List spoofing becomes less effective as well.   Legitimate list messages can be 
validated using DMARC with p=reject on the list domain.Spoofed messages 
that reach the user will not have a From address in the list domain and will 
not follow the pattern of list aliases.

Overall, I conclude that mailing lists have much to benefit from intelligent 
use of DMARCv1 as previously specified.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] AutoForward problems - Change log benefits to mailing lists

[Douglas E. Foster]

I entirely agree that a confirmed identity is useful because it allows us to 
whiteliist safely.   I became alienated from my commercial products because 
they did not understand that whitelisting should require confirmed identity.  I 
think they should understand security principles if they are in that 
business.My commercial products also choke when the blacklists grow large.  
Once I found a customizable filter, I moved my rules into database tables.   I 
use segment matching, instead of ends-with matching, to ensure indexed queries. 
  It no longer matters if a blacklist has 500 entries or 15,000.IP blocking is 
the best way to prevent domain churning, but domain blocking helps prevrnt IP 
churning.   I try to blacklist both at the same time.Most of my spam arrives 
either as first-party mail (SPF Pass with domain alignment) or as a client of 
an ESP, mostly Sendgrid, (with SPF Pass and no DMARC policy.)   Commercial 
products that ignore Message From are unable to handle ESP-based spamming.   
ESP-based spamming also evades some URL filtering, because all of the URLs 
point back to the ESP.My vendors say that malicious Office365 accounts are the 
new attack vector, but I have not seen it yet.   When it happens, my filter 
rules change to full address blacklists instead of domain blacklists.DFSent 
from my Verizon, Samsung Galaxy smartphone

 Original message 
From: "Murray S. Kucherawy"  
Date: 9/8/20  4:31 PM  (GMT-05:00) To: Doug Foster 
 Cc: IETF DMARC WG 
 Subject: Re: [dmarc-ietf] AutoForward problems - 
Change log benefits to mailing lists 
On Tue, Sep 8, 2020 at 5:09 AM Doug Foster  wrote:

> However, I disagree about negative reputation.Content filtering alone
> is insufficient and even more error prone.   In the last year, I have had
> spam campaigns about LED lighting, stand-up desks, touchless thermometers,
> and knife sharpeners.  I cannot anticipate all the ways that spammers will
> hide their dirty deeds.   But I know it is spam, not merely unwanted
> advertising, because of receiving many similar messages from many different
> domains using many different servers.   Third-party RBLs help but are
> insufficient.   I am gradually building my own reputation database based on
> the traffic that I am receiving.   By blocking the problem sources, I have
> been able to get the spam problem under something approaching good control.
>   Content filtering is a useful tool for day-zero detection of a new spam
> source.   Once a source is detected, it needs to be blocked.
>
>
>
> Whether a message passes SPF and DMARC criteria is part of my search
> critieria for unwanted traffic, but definitely not the only one.   As has
> been observed, actual spoofing of the From address is not a huge part of my
> problem at present.   This is largely because spammers have easy enough
> tools in Friendly Name spoofing and corporate logo misuse.   But I also
> attribute that low volume to the existence of SPF and DMARC.
>

Suppose I'm one of your touchless thermometer spammers.  Your system
identifies me and the DKIM signing domain I'm using.  I notice, through
well-established means, that my spam is no longer getting through to you.
So I register a brand new junk domain name, perhaps sadehaiuhfiewn.com or
whatever a few smashes of the keyboard yields, and start signing with that
instead of whatever domain I was using before.  For a couple of bucks, I
have now escaped my negative reputation in your system.  Maybe I bounce it
through a botnet too, so that you can't catch me with an IP reputation
either.

Negative reputations are trivially shed.  It follows that it's not terribly
useful to track them, at least not long-term.  You end up with records of
spammy domains that you'll notice only sent mail for the shortest of time
ranges, long enough to get in undetected or under the guise of "too new to
block", and then abandoned when they stop working.  Blocking domains you've
never heard of before is often disruptive when, say, you join a loyalty
program for some vendor you've never dealt with before and actually do want
their mail, so you're between a rock and a hard place.

Instead, positive reputations are the things on which you can reliably act,
giving such messages preferential treatment.  It's generally a much higher
bar, plus the namespace of domains that manage to earn positive reputations
is small, and they tend to be well-behaved over longer periods of time.

Content filtering is a different matter.  It's focused on what's in the
message, irrespective of where it came from.  But that's a whole new game
to play, and definitely not anything in which DMARC is interested.

-MSK
___
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] AutoForward problems - Change log benefits to mailing lists

[Douglas E. Foster]

What I am trying to accomplish is different than what can be accomplished with 
the canned-modifications indicator.To explain, I need to digress into my 
theory of operation for spam filters:

1) Source identification allows assignment of a Source reputation.  Source 
reputation is more important than content filtering, because hostile content 
always comes from a source that should not be trusted.   Content filtering 
always produces false positives and false negatives, and the workarounds to 
those errors are always dependent on source identification

2) Impersonation is always attractive to an attacker because it allows him to 
exploit the reputation of the impersonated identity.   Therefore impersonation 
is an inherently untrusted activity.

3) Spam filtering will assign sources to three reputation groups:   negative 
reputation (rejected), neutral reputation (acceptance depends on content 
filtering), and positive reputation (some or all content filtering bypassed.)   
SPF and DMARC are designed to block impersonation, and mailing lists look like 
impersonated traffic, so the message moves from neutral to negative reputation. 
 How to overcome that?

One solution is to use out-of-band information to justify overlooking the 
negative clues, then implementing local policy based on that informatoin, so 
that traffic is moved from negative reputation to positive reputation.   ARC 
and canned-modification tagging are approaches to providing in-message data 
intended to support application of that local policy.But we have found no 
way to ensure the out-of-band information flow needed to justify the local 
policy, for all of the mediators that need that status.   We have also 
identified no method for the recipient to notify the mediator that the local 
policy is established, although this could also be handed out-of-band.  
However, these techniques have the benefit of depending on the mediator and the 
recipient, and not on the sender.

A second solution depends on explicit sender authorization to eliminate the 
apparent impersonation.   This category encompasses conditional signatures, 
ATSP, RHSWL, DKIM delegation, and SPF inclusion.   These approaches require the 
involvement of sender, list, and recipient.   We have concluded that these 
approaches are victims of unlikely participation by senders, and further 
limited because the list does not know if a recipient will recognize the 
sender's authorization.Finally, I observed that this solution cannot help 
with the problem created by spam filter tagging prior to an auto-forward, so it 
cannot solve the whole problem.

A third solution is to abandon DMARC and allow impersonation to be unrestricted.

I am suggesting a fourth approach.   This one seeks to address the 
impersonation problem by clearly identifying each part of the message to its 
source, so that impersonation is not an issue, and each source's contribution 
is evaluated based on that source's reputation and that source's content.  The 
goal is to move the imputed source reputation from negative to neutral, rather 
than from negative to positive.   If the source reputation can be defaulted to 
neutral, the approach can be used by any mediator without prior registration 
with recipients and without any prior authorization by senders. 

But on continued reflection, I realize that this approach requires complete 
isolation between the content added by a mediator and the content provided by 
the originator.   Any other changes to the original content could maliciously 
alter the original intent of the author, and an automated spam filter has no 
ability to identify changes of intent.  So is there a group of mediators who 
only require the ability to add a subject prefix, subject suffix, body header, 
or body footer?

- The better spam filters offer URL rewrite, which alters original content.
The weaker spam filters may only use these four features, but they are the ones 
that are least likely to add an exotic new feature like dual authorship 
detection.   So I reluctantly conclude that there is no significant opportunity 
for using this approach on the "spam filter with auto-forward" problem.

- But is there is a group of mailing lists that only need these four 
capabilities?   I was hoping so.

DF



From: Alessandro Vesely 
Sent: 9/5/20 5:36 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] AutoForward problems - Change log benefits to mailing 
lists

On Fri 04/Sep/2020 04:05:24 +0200 Douglas E. Foster wrote:
>
> Of the three types of content changes that I proposed, the easiest to specify
> and get implemented is the first type, where the mediator only adds content,
> adds a change log indicating the additions, and signs the result.   I am 
> hoping
> and assuming that if mailing lists have freedom to add their branding to the
> subject and body, most lists would not need to make more comple

Re: [dmarc-ietf] AutoForward problems - Change log benefits to mailing lists

[Douglas E. Foster]

Although I re-raised the change log issue as part of the auto-forward problem, 
I am hoping that it will have significant benefit to the mailing list community 
also.

Of the three types of content changes that I proposed, the easiest to specify 
and get implemented is the first type, where the mediator only adds content, 
adds a change log indicating the additions, and signs the result.   I am hoping 
and assuming that if mailing lists have freedom to add their branding to the 
subject and body, most lists would not need to make more complex changes.

The signed change log would allow participating recipients to identify the 
signed additions added by the list or other mediator, while also identifying 
the signed original after the list additions are virtually removed.   Once the 
additions and the original are reliably identified to a source domain, 
suspicion of spoofing is no longer a concern.  Each chunk of content can be 
evaluated based on the reputation of the verified source domain and the 
specifics of the content.

Nested additions are possible.Each new signature adds an entry to a 
verification stack.   Any change can be removed, virtually or actually, by 
reversing the change at each level, working backwards from last to first.   In 
practice, the stack is expected to be short.  To prevent malicious misuse, the 
specification should put a small limit on the number of layers in the stack.

Just as importantly, I believe it solves the problem of letting the list know 
whether From rewriting is necessary or not.   I argue that there is no 
information-leakage risk associated with a domain publishing a DNS entry that 
says "This domain understands multi-author documents of type 1".This type 
of flag says nothing about what the domain will do with any particular message 
with multiple authorship.  The recipient domain will have the option of passing 
the entire message, stripping the wrapper and passing the original, or blocking 
the whole thing.   But it will not be blocking a message because it does not 
understand the message's actual identity, which is the cause of our current 
problem.   Once a list knows that its identity will not be misjudged, it gains 
the freedom to assume that its content will be judge fairly, so "From" 
rewriting should not be necessary when sending to domains that have published 
this flag.

Because this approach adds confidence rather than risk, I am hopeful that even 
AOL would be willing to implement support for it.

The more complex changes, edits and deletions, require a more complex 
specification and more complex code.   That level of specification will be 
needed to provide a solution to spam filters that do URL rewriting.   But that 
complexity can wait for another day while we try to get a level 1 change log 
accepted.

John, I am hoping that you find some opportunity here.   Do you?

Doug Foster



From: "John Levine" 
Sent: 9/3/20 6:44 PM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] AutoForward problems

In article <767e2dcc-e87c-1e90-2f86-486e51a3c...@wisc.edu>,
Jesse Thompson  wrote:
>I realize that John's message in the other thread probably wasn't referencing 
>auto-forwarding, but I think his point
>dovetails to the auto-forwarding issue:
>
>> As always, as I hope we all remember DMARC alignment doesn't mean not spam,
>> and you still do all of the stuff you do to sort your mail. ...

As you say, it's the same problem, it's what people see as the same
message but with changes that fail with current authentication
schemes.

>a) It assumes that the domain owner has the ability and desire to authorize 
>every potential forwarder, even though
>auto-forwarding is a user-level decision.

It's not the domain owner, it's more likely the MTA deciding what signatures to 
apply.

>c) Selectively allowing forwarding at the user level is difficult because 
>users are gonna do what they wanna do (you
>try telling faculty they can't forward). It's not the case that all 
>enterprises want to prohibit all of their users
>from auto-forwarding (even though that's the answer you may get if you survey 
>the CISO community)

Yeah. The likely damage from allowing wisc.edu to forward seems pretty
low, the damage from outlook.com or gmail.com considerably more.

R's,
John
--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

___
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

[dmarc-ietf] AutoForward problems

[Douglas E. Foster]

For mailing lists, we have pushed the limits of authorization.   But there is 
another class of problems where sender authorization is not feasible:   mail 
which is auto-forwarded after a spam-filter has made content-altering changes.

In some respects, the problem is similar to a mailing list.   This mailing list 
adds a prefix to the subject, adds a footer to the body, and converts content 
to text.   The first two changes are potentially reversible, while the last one 
is not.   Commonly used spam filters may add a prefix to the subject, a header 
or footer to the body, and rewrite embedded URLs to provide time-of-click 
protection.Again, the first two changes are potentially reversible, while 
the last is more difficult.

Because an auto-forward has the potential for senders from any source, 
third-party authorization of the forwarding domain is not possible.   Instead 
the mechanism requires either that the recipient domain provides a DMARC 
exception for the forwarding stream, or the forwarding domain must remove the 
spam-filter's changes so that signature integrity is restored.

In general, the changes provided by a spam filter are intended for the 
subscribed client, so it is an interesting licensing question whether those 
protections should extend to external non-subscriber addresses that are served 
via auto-forwarding.   But for our purposes, removing those edits would solve 
the DMARC problem by restoring signature integrity.   So I think we need to 
re-examine rollback options

I think it is useful to categorize the types of edits that may occur:

- A simple insertion of new text.
A change log which documents the start point and length of insertion would be 
sufficient to identify the added text separately from the prior text.   If the 
document is signed after the changes are applied, an MUA could potentially 
separate the contents of each author, with author identification.   This may 
actually enhance efforts to use spam-filter additions as a trust indicator.   
An MTA could evaluate the original content against the original signature, or 
could remove the added content to restore the original message.
- A replacement or removal of text, where the original content can be 
represented in a message header.In this case, the change log would include 
the starting point of the change, the length of the new text, and the entirety 
of the original text.An MTA could reverse the changes or evaluate the 
original signature after applying a virtual reversal of the changes.   An MUA 
would probably not be able to identify the changed regions to the user, 
especially if the changes were in the non-visible portion of an HTML component.
- A replacement or removal of text, where the original content is too complex 
to be stored in the message header.   In this case, the original content can 
only be recovered if the original content is retained external to the message 
in a proprietary data store.Since many organizations use the same vendor 
for both inbound and outbound gateways, external data stores are plausible.

In the absence of such techniques, the forwarding system (or the outbound 
gateway) needs to be aware that a message has been forwarded after 
content-altering changes.   When this is the case, the message either requires 
a known exception at the receiving system or a From address rewrite so the 
message will pass DMARC.   At minimum, our DMARC specification should make this 
clear.

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

Re: [dmarc-ietf] draft-levine-dkim-conditional-04, was third party authorization, not, was non-mailing list

[Douglas E. Foster]

This all looks workable to me, if it can gain support from senders, recipients, 
and mailing lists.

But as I have said before, the last part of the protocol needs to be a way for 
the mediator to know that the recipient will accept the message.   This could 
be because:
Recipient honors conditional signatures (or any other future third-party 
authorization system.)Recipient has whitelisted the mailing list, so DMARC will 
not be enforced against the list.Recipient does not enforce DMARC at all.
The first option is the most complicated, because it requires the list to 
change behavior based on both sender and recipient configuration.   The latter 
two only require knowledge of the recipient configuration, and could be 
implemented today.   But early in this discussion, John implied that 
recipient-specific tailoring of the From address is outside the capabilities of 
modern mailing lists.   To get IETF backing, the signalling between lists and 
recipients also needs to scale, which implies a high level of automation.

Is there any way to solve this part of the problem?

DF


From: "John Levine" 
Sent: 8/30/20 12:28 PM
To: dmarc@ietf.org
Cc: fen...@bluepopcorn.net
Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-04, was third party 
authorization, not, was non-mailing list
In article <46d35938-50ee-871d-d88b-e93c68555...@bluepopcorn.net> you write:
>But what I was getting at is that the "weak" signature might not have to
>be any different from any other DKIM signature (except possibly to
>specify the authorized mediator). It's just that a verifier might fully
>verify the mediator's signature, and verify the original signature but
>not check to see if the body hash matches. ...

I just sent in a slightly refreshed version of my conditional signature draft
which says exactly that.

It's not very different from the orginal version I sent in over six years ago.

https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/

R's,
John

___
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] third party authorization, not, was non-mailing list

[Douglas E. Foster]

Since we are designing a system that allows a mediator to alter Subject and 
Body, it should be no surprise that the conditional signature has the potential 
for re-use.   A well behaved mediator must be assumed before any such trust 
delegation is granted.I see no way to ensure that the conditional signature is 
single-use. As long as all of the signature's hashed cntent can be replicated 
onto another message, the signature can be reused.The more important question 
is whether conditional signature could be subject to third-party attacks.  Does 
the limited and predictable content of a conditional signature intcrease the 
risk that a bad guy could use guess-and-test to construct a valid  signature 
block for someone else?  DKIM uses the body content in two different hash 
calculations.  This severely limits the ability of an attacker to find and 
exploit a hash collision.   The conditional  signatures seem unlikely to have 
that strength.Sent from my Verizon, Samsung Galaxy smartphone

 Original message 
From: Jim Fenton  Date: 
8/29/20  7:11 PM  (GMT-05:00) To: fost...@bayviewphysicians.com, 
dmarc@ietf.org Subject: Re: [dmarc-ietf] third party authorization, 
not, was non-mailing list 
On 8/29/20 12:42 PM, Douglas E. Foster wrote:
> To elaborate on my question and Michael Hammer's answer:
>
> To be unique, a signature needs a unique dataset from which the hash
> is computed.   The weak signature will not be unique because it will
> be computed on non-random content such as From, To, and Date.

Unique != random. A time stamp (with enough precision) might be unique,
even though it is not random. For that matter, DKIM signatures don't
include any random values either.

But what I was getting at is that the "weak" signature might not have to
be any different from any other DKIM signature (except possibly to
specify the authorized mediator). It's just that a verifier might fully
verify the mediator's signature, and verify the original signature but
not check to see if the body hash matches.

The one problem is that some mediators add things like [dmarc-ietf] to
the subject line, and that's usually signed.

-Jim



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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Douglas E. Foster]

To elaborate on my question and Michael Hammer's answer:

To be unique, a signature needs a unique dataset from which the hash is 
computed.   The weak signature will not be unique because it will be computed 
on non-random content such as From, To, and Date.

However, the signature can only be used by the designated domain.   So the 
worst possible "misuse" would be for the designated domain to use the signature 
on other messages.   This seems unlikely, and the worst-case use is no 
different than what ATSP would authorize.   But the weak signature has less 
information leakage, since nothing is published in DNS about the signature 
technique.   So I agree that the approach is a good one for those who want to 
provide mailing-list authorization.

The remaining challenge is to communicate between recipient domains and mailing 
lists so that the list knows whether the recipient will honor the weak 
signature system.

Doug Foster


From: Jim Fenton 
Sent: 8/26/20 5:01 PM
To: Dotzero 
Cc: IETF DMARC WG 
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
On 8/26/20 10:54 AM, Dotzero wrote:

On Wed, Aug 26, 2020 at 1:32 PM Doug Foster 
 wrote:

Are the weak signatures vulnerable to a replay attack?I thought that one of 
the reasons that DKIM signatures included the whole body was to prevent the 
signature from being reused.



DF

Not particularly vulnerable. The requirement is that you have the "weak 
signature" plus the intermediary full DKIM signature. This let's the 
validator/receiver know that the originating domain knew that the intermediary 
might break the originating domains DKIM signature but the validator/receiver 
would have the DKIM signature of the intermediary. The "weak signature" is only 
validated against that specific message and headers it signed and that specific 
intermediary. It's not a generic/general signature.

It sounds like the weak signature is just a regular DKIM signature plus the 
designation of the intermediary, and the "weak" part is that you don't check 
the body hash against the body. Have I got that right?

-Jim


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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Douglas E. Foster]

Something seems inconsistent:

- The people who have implemented DMARC do not see any significant problems, 
and as a result they are not interested in a third-party authorization scheme.

- Yet adoption is very slow, especially for anything other than p=none

Are we to assume that mailing list compatibility explains the slow adoption?   
If not, what other obstacles do we need to be considering?

DF


From: "Murray S. Kucherawy" 
Sent: 8/24/20 11:21 AM
To: Brandon Long 
Cc: IETF DMARC WG , Tim Draegen , Alessandro 
Vesely 
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
On Thu, Aug 20, 2020 at 2:01 PM Brandon Long  wrote:
I tend to agree with the negative stance on third party auth, but SPF obviously 
has the include: statement which is third party auth at the most basic 
level...atps[1] is the obvious equivalent for DKIM.  I don't know if atps 
failed because it wasn't all that useful, or if it was tied in folks minds to 
adps, or the failure of the follow-on reputation system stuff..

Neither atps or spf include are really designed for large scale usage across 
thousands of "relays" etc, and I don't think they should be used for that, but 
for a bunch of small to medium entities, it could be the thing that makes 
higher p= possible.

ATPS was designed as a proof of concept to see if third party policy was 
conceptually useful at all.  Scale could come later if the initial experiment 
had a positive result.  The industry, however, apparently didn't even have 
appetite to try, so we may never know.

-MSK


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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Douglas E. Foster]

Instead of immediately deciding which ideas can and cannot work, I suggest that 
we create an extension mechanism for DMARC and then let the market decide.  
Perhaps someone will find traction for an idea that is useful to a subset of 
users even if it is not useful for every sender-receiver pair.

The extension mechanism could be as simple as an "add-ons=Y" clause in the 
DMARC record.

If a receiver has implemented ANY add-on method, this flag tells him to check 
all of the options that he supports.   Most likely this will require one or 
more additional DNS lookups to determine which add-on technique is supported by 
the sender.The result of those lookups will determine if the sender and the 
receiver support any of the same techniques.   When there is a match on 
supported techniques, the logic for that technique is invoked.But when the 
flag is absent, no resources are wasted on checking add-on methods that can 
only apply to a subset of all messages.

This approach separates the DMARC spec, which focuses on two specific 
authentication strategies, from add-on methods that invoke alternate 
authentication strategies, so that the DMARC specification can move forward.

It leaves room for all of the ideas mentioned so far, and for those that have 
not yet been suggested.   It also leaves room for a good-but-neglected idea to 
gain traction based on future events.

The details of those other implementations can be determined by private 
agreement or by RFC.

DF


From: Alessandro Vesely 
Sent: 8/21/20 4:58 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
On Fri 21/Aug/2020 01:55:52 +0200 Dotzero wrote:
> On Thursday, August 20, 2020, Jesse Thompson  wrote:
>> On 8/20/20 4:00 PM, bl...@google.com wrote:
>>> Neither atps or spf include are really designed for large scale usage
>>
>> That's my conclusion, as well. I don't want to authorize every potential
>> MLM to use all addresses in all of our domains cart blanch, even if I would
>> otherwise trust them (e.g. their purported ARC results).
>>
>> I *do* want to authorize our *own* MLM(s) to use our own domains for
>> *internal* use... so I thought for a minute... maybe ATSP has merit for
>> small scale usage, as an alternative to SPF include?

Besides limiting the recourse to hashes, w.r.t ATPS my proposal provides for a 
rhswl zone which can be outsourced.

>> But no, I don't know if any MLM has a way to check to see if they
>> are authorized via any mechanism, so they will continue to munge
>> the From header for our DMARC-enabled domains anyway.

That is going to be true for /any/ method we devise now. From: rewriting is not 
going to stop on the next day. We must tune aggregate reports so that MLMs can 
tell if it's still necessary. It may take decades... still better than ∞.

>> So, for this *internal* use case, maybe I'll just check the ARC
>> result from the trusted MLM and replace the From header with the
>> value of Reply-to/X-Original-From, and call it a day.

Restoring From: at the MDA is certainly a good idea.

However, the need to whitelist each MLM is not much viable for a number of 
operators. And, in case, I'd adopt John's broad brush: If I went so far as to 
whitelist the MLM, why should I take the burden to scrutinize the way it 
applied policies? It seems more sound to allow my recipients to see the same 
messages as every other subscriber.

> This is why I proposed a tag that would have a value consisting of the
> authorized intermediary domain. It would only be valid for that message.
> Because the tag is signed separately from the rest of the message, it
> should survive even if the intermediary modifies other parts of the
> message. If the intermediary DKIM signs the modified message with their own
> signature, that provides some assurance to the receiver.

That was described on June 26, here:
https://mailarchive.ietf.org/arch/msg/dmarc/wM97DmQ6-FEgMD7wkEKtk1PdBbU/

It requires modifying signer behavior. AIUI, the sender recognizes that one of 
the recipients is an allowed mailing list, and adds that tag to that copy of 
the message. It looks less outsourceable than an external whitelist.

Let me call weak signature this concept. As it is very similar to 
dkim-conditional, either one or the other should be adopted.

By contrast, a somehow limited Sender:, dkim-transform, Author:, as well as 
weak signatures can all be adopted concurrently.

> I haven't seen enough favorable response to justify working on a detailed
> submission to the group. I'm not an IETF standards wonk.

I'd support weak signatures, in either embodiment. I don't think it needs to be 
linked to the Sender: field.

Best
Ale
--

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


___
dmarc mailing list
dmarc@ietf.org

Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01

[Douglas E. Foster]

For incoming mail, you determine what constitutes legitimate mail.You 
choose whether to enforce DMARC generally.  If you enforce DMARC at all, you 
also choose what exceptions to apply.

But outgoing mail is different.   The sender has no guarantee of delivery.   
The sender has to convince the recipient that the message is legitimate and 
desirable.  (Plenty of advertising messages are sent legitimately, but still 
get blocked by my spam filters.)

For mailing list mail, there are two messages.   The first one goes from your 
user to the mailing list.  The mailing list has various rules about whether the 
message is acceptable or not.   For openers, the sender must be a registered 
subscriber to the list.   Additionally, there may be limits on attachments or 
limits on swear words.The subscriber knows these rules, or learns them 
quickly, and complies.

The second message is from the mailing list to the subscribers.   As with every 
other message, the mailing list sender needs to determine host to satisfy the 
requirements of the recipient system.   Maybe the recipient system has a longer 
list of swear words.   Or maybe the recipient system enforces DMARC.   Whatever 
the rule, the burden is on the sending mailing list to get the message 
delivered by satisfying the screening criteria of the recipient systems.

One important way to demonstrate legitimacy is to provide a verifiable 
identity.  Verified identity allows a reputation to be assigned, which then 
determines which content filtering rules will (or will not) be applied.   If a 
mailing list knows that the recipient requires a verified identity, but fails 
to provide a verifiable identity, whose fault is it when the message does not 
get delivered?

The working assumptions are that a mailing list must alter the received 
content, the mailing list must not reformat the From address, and nonetheless 
the recipient system must assume, without supporting evidence, that the message 
is legitimate.

Assuming that mailing lists deserve a privileged role, we still need a way to 
demonstrate that any specific message deserves that role because it is from a 
trusted mailing list and not from an attacker.

Doug Foster


From: Joseph Brennan 
Sent: 8/19/20 8:07 PM
To: "dmarc@ietf.org" 
Subject: Re: [dmarc-ietf] Revisiting the Race Condition in 
draft-crocker-dmarc-sender-01

I've been running email servers for 25 years. My number 1 priority is that 
legitimate mail gets through. Stopping the bad stuff is very important but not 
number 1. Does DMARC causes legitimate mail to fail? Yes, so to me it's a fail.

I can understand the transactional mail case, as I stated in previous messages. 
The burden is on the businesses implementing DMARC protection to inform 
customers to give their real end-point email addresses and not any vanity 
forwarding services. Any two sides can agree between them on some optional 
additional security measure. It's a good thing.

For general end-user mail? It's a bad thing. It will cause email to fail, and 
it will cause people not drinking the DMARC kool-aid to implement crazy 
non-standard things with From headers to make email work the way it should work 
without crazy workarounds. I see no reason that the DMARC standard should not 
spell out explicitly the use case that it is intended to meet, and recommend 
against using it for other use cases.

I realize that this was said ten years ago (or whatever it was) when yahoo/aol 
began abusing DMARC. But see how that went. The problem was not really DMARC at 
all, it was abuse of DMARC.

--

Joseph Brennan
Lead, Email and Systems Applications
Columbia University Information Technology


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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Douglas E. Foster]

My two cents.

1) What has changed since 2012 is DMARC, including the ability through DMARC to 
obtain feedback.  "New ATPS" would have to be implemented as a DMARC option, 
not a new thing.

2) A lot of organizations seem to be stick at p=none.   Maybe that means they 
want it that way.   Maybe it means that they are being courteous to mailing 
lists.   But maybe it means something about DMARC is too hard.   I am assuming 
that all of the problems with DMARC are related to third-party authorization, 
and something needs to be done to make it easier.

3) Delegation with an ATPS-type email entry seems functionally equivalent to 
DKIM scope delegation, with several benefits:
Easier and cheaper for the third-party to implement.   The third-party only 
needs to apply its own domain's signature.   Simpler means quicker 
implementation.  Private keys are never exchanged.

Third-party is only responsible for its own key.A big organization like 
Constant Contact or SendGrid could end up holding hundreds of thousands of DKIM 
keys, and that becomes an attractive target for attackers.  If a delegated DKIM 
key store is stolen from a third party, the attacker knows every domain that 
has been compromised.   If an ATPS-delegated third party has a corporate DKIM 
key stolen, the attacker knows that he has struck pay-dirt, but he does not 
have an immediate enumeration of compromised organizations..   That enumeration 
will require an additional data collection process, which might buy time for 
the affected organizations to take evasive measures.

An ATPS-type scope delegation could be designated for a specific user, which I 
assume will represents an application. ("SMTP address must be 
applicationname@vendordomain").   This information is something that the 
receiving system can enforce and report.   It is a weak enforcement tool, but 
limiting scope of delegation seems likely to satisfy some of the auditor 
concerns associated with any third-party delegation.  This is also a new ideas 
relative to the original ATPS.   Of course, a domain level delegation should 
also be an option for situations that the authorizing domain deems appropriate. 
 ("SMTP address must be *@vendordomain")

ATPS-type delegations could be given a pre-defined expire date (if specified 
with that feature).  This would be particularly appropriate where a third-party 
authorization is linked to a time-limited contract.   When the contract lapses, 
the authorization lapses, unless both the contract and the DNS entry are 
renewed.   This limits risk associated with the possibility of 
delegated-but-forgotten authorizations.   DKIM delegations are always 
good-til-cancelled (by removing the DNS public key).

Both DKIM and ATPS can be revoked easily, subject only to the limits of DNS 
propagation.

DKIM delegation becomes impossible if the third-party is not cooperative.   
ATPS-type delegation can be done unilaterally by the owning domain.I am 
thinking of Proofpoint in particular.   They violate my DMARC policy when my 
users, who are non-clients, respond to a secure message from one of their 
clients.   Author self-copies arrive at my gateway looking like spoof, but I 
can fix this with local policy.   When my user uses reply-all to a message with 
many recipients, those other domains will see my p=reject, which may mean that 
messages are not delivered and my user does not know that it happened.   Maybe 
all those other domains will have a Proofpoint exception as well, impossible to 
say.   Maybe Proofpoint will begin header munging, but they have not done so 
yet.
So the big benefit for DKIM is the i= clause, but I think the sender-limiting 
potential with ATPS is superior to the impersonation-limiting capability of 
DKIM.   Besides, it seems generally agreed that i= has very limited use.   On 
all other risk-management concerns, an ATPS -type signature seems preferable.

Implementation obstacles and notes:

When a domain implements an ATPS signature, it must set the corresponding DMARC 
policy to p=none.  Otherwise, sites that are DMARC-aware but ATPS-blind will 
block ATPS-authoized transactions.   Consequently, this option will only 
interest organizations that are currently at p=none or that have no DMARC 
policy.

If a new feature such as ATPS is implemented, senders have a problem knowing 
whether their recipients understand it or not.   This dilemma would be helped 
if recipients published a DNS token to indicate that they understand the new 
feature.   Some will consider this inappropriate information disclosure, 
although I am currently having a hard time seeing the risk in the release of 
that information.By and large, senders will want confidence that the new 
feature is widely deployed before they will begin depending on it for outbound 
delivery.In the absence of recipient reporting, change may never happen.

Doug Foster


From: "Murray S. Kucherawy" 
Sent: 8/19/20 2:38 PM

Re: [dmarc-ietf] DMARC failure scenarios

[Douglas E. Foster]

You cannot make sense of it, John.   I understand the difference between 
submssion and SMTP.

The asserted increase in complexity is not from adding a single signature, it 
is the requirement to apply a different signature to every message depending on 
the generated From domain.
Are applications like the one the Alessandro mentioned readily available and 
easily implemented, so that conditional signatures are no hindrance to DMARC 
compliance?   If so, is third-party cooperation easily achieved and no obstacle 
to DMARC implementation?
These are questions for the consultants who have done a lot of this work.

DF


From: "John Levine" 
Sent: 8/17/20 10:12 PM
To: dmarc@ietf.org
Cc: fost...@bayviewphysicians.com
Subject: Re: [dmarc-ietf] DMARC failure scenarios
In article <0762f9ada48c4c9eaef06e16a49a2...@bayviewphysicians.com> you write:
>-=-=-=-=-=-
>
>Does this scenario correctly characterize how organizations may be unable to 
>move past p=none with breaking things?

As far as I can made sense of it, no.

>a) A vendor application detects an event, looks up in a database for sender 
>name (client contact) and recipient list.
>
>b) The application connects to a mail server via IMAP, and sends the message 
>using something like application@vendordomain
>for the SMTP from and cllentcontact@clientdomain as the Message from. The 
>client domain becomes especially important if
>the recipients are in a different domain than the client. An example might be 
>an HVAC system operated by a vendor, on
>behalf of the building manager, which needs to communicate with the building 
>tenants. ...

Again, no. You're confusing submission with SMTP. I have a printer
that sends me e-mail when it's out of paper, which it does by sending
mail to my submission server, not directly to me. If I were checking DMARC
on the messages, they would easily pass since the submission server adds
DKIM signatures.

>Then the client wants to implement DMARC
>--
>
>d) The client develops a list of all of its third-party mailers and tells the 
>third parties to begin applying the client's
>DKIM signature to their messages. This adds a boatload of complexity to the 
>vendor's application, since he needs a
>different applied signature for each client. It requires either major changes 
>to the application, a more sophisticated
>mail server, or a special box simply to sit in front of the mail server to 
>detect and apply the correct signature. None of
>these seem like generic off-the-shelf solutions. I would not know where to buy 
>that capability if I needed it today.

Again, no. I believe that devices that send mail do what they've
always done, send it to a submission server for further delivery. The
"special box" has been there all along.

R's,
John


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

[dmarc-ietf] DMARC failure scenarios

[Douglas E. Foster]

Does this scenario correctly characterize how organizations may be unable to 
move past p=none with breaking things?

Before DMARC


a) A vendor application detects an event, looks up in a database for sender 
name (client contact) and recipient list.

b) The application connects to a mail server via IMAP, and sends the message 
using something like application@vendordomain for the SMTP from and 
cllentcontact@clientdomain as the Message from.The client domain becomes 
especially important if the recipients are in a different domain than the 
client.   An example might be an HVAC system operated by a vendor, on behalf of 
the building manager, which needs to communicate with the building tenants..   
The message passes SPF based on the SMTP From address in the vendor domain.   
The client domain is not enforced.

All of this can be implemented with generic off-the-shelf technology.

Then the client wants to implement DMARC
--

d) The client develops a list of all of its third-party mailers and tells the 
third parties to begin applying the client's DKIM signature to their messages.  
 This adds a boatload of complexity to the vendor's application, since he needs 
a different applied signature for each client.   It requires either major 
changes to the application, a more sophisticated mail server, or a special box 
simply to sit in front of the mail server to detect and apply the correct 
signature.  None of these seem like generic off-the-shelf solutions.   I would 
not know where to buy that capability if I needed it today.

e) If the client attempts to comply, it may take a long time and add a lot of 
cost.   If the client cannot comply, switching vendors is also complex and time 
consuming.

So in the end, a hypothetical U.S. government agency may end up telling 
Homeland Security that it cannot meet the DMARC deadline because of an 
application that runs in Peoria Illinois which cannot implement DKIM delegation 
signing.   Of course, if that does not fly, the p=reject goes into effect 
anyway and the folks in Peoria hope that the intended recipients will implement 
an exception in their incoming gateway.

In sum, DMARC participation is not fully in the control of the organization 
that wants to implement it.We need to make DMARC participation a process 
where the participating organization has control over its own success and 
carries the costs of becoming compliant.   DKIM scope delegation does not get 
us there.

DF


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

Re: [dmarc-ietf] Time for a change

[Douglas E. Foster]

The reality is that IETF has mostly provided followership, not leadership, on 
matters of security.  This forum is replicating history.   As has been 
mentioned in the historical review, SPF, DKIM, and DMARC were independently 
successful projects, as was SSL.  IETF provided after-the-fact blessing.   It 
is time to follow the same model.

If there is an opportunity to accelerate DMARC adoption, I think it is in the 
area of third-party authentication, presumably based on ATSP.   To move the 
possibility forward, we need to move off this list.  The target audience for 
this capability will be organizations that are non-DMARC or DMARC p=none 
specifically because DKIM delegation is an obstacle.I have no idea whether 
that category is a trivial or non-trivial group, so we would need to find out.  
Major ESPs are successfully implementing DKIM scope delegation to comply with 
DMARC, so maybe it is not the issue.   DKIM delegation creates complexity which 
becomes an obstacle to new entrants, so big ESPs may like the status quo just 
fine.   These are all things need to be assessed, and are more important than 
writing a new specification.

Then, we need to expand the base of participants to include people who would be 
willing to implement the third-party authentication scheme after it is defined. 
  I think that list would need to look something like this:

A national government representative to ensure that any new proposal is not 
vetoed, A financial services industry representativeAn Email Service Provider 
industry representativeA large organization that is holding back on DMARC 
p=reject because DKIM delegation is an obstacle.One or more commercial product 
representativesI would love to have Verizon Media participate, but I have asked 
and had no response.
If you want to participate, send me a direct email.More importantly, if you 
have connections with people who could play the role of influencers, reach out 
to them.

If there are other topics that would move DMARC forward, we can put them up for 
consideration.  If you want to discuss special treatment for mailing lists, you 
are specifically disinvited.

Doug Foster


From: hsantos=40isdg@dmarc.ietf.org
Sent: 8/16/20 1:19 PM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
On 8/13/2020 8:21 PM, Murray S. Kucherawy wrote:
> On Mon, Aug 10, 2020 at 10:27 AM Dave Crocker  > wrote:
>
> > We have had a lot of attempts at third-party authorization schemes
> .
> > With this in mind, I cannot see any point in designing yet another
> > vouching or authorization scheme unless we have evidence that an
> > interesting fraction of the world's mail systems want to use it. I
> > don't see that, and honestly see no chance that we ever will.
>
> +1
>
>
> I'm disappointed that the experiment never really got its day in
> court,

+1 and I want to give you credit for trying. Without you, I might
have been long gone from the DKIM project WGs. So I thank you for
keeping it interesting, but

> but the consensus is clear. +1.

Here I have to disagree. I don't ask anyone to agree with me but to
understand my viewpoint as a long time participant and advocate of the
DKIM Policy Model. Early on, we had limited policy proponents. But
not today.

I have a different viewpoint, a viewpoint that really that was blocked
by the two controlling cogs who had DKIM interest else where, namely
Levine, Crocker. Crocker has been more open ended. Not Levine. Since
day 0, Levine never liked policy and to his credit, he admitted it as
much. He killed SSP with the "poison pill" (crippled draft) ADSP
replacement he knew would never make it pass LC. Levine was always
for the 3rd party trust/list signer idea - never a 1st party
authorization. But he narrowed down the scope to the restrictive
policy, removing any 3rd party consideration. The same will most
likely be true with DMARC with the same problems. Yet, why would any
list developer deny new security options for list operations? I never
got that and that was before ADSP or even ATPS. When it comes to
DKIM, if Levine didn't like it, it simply wasn't happening. Sad to say
and I don't see that changing. So now that we have the top three cogs
DKIM agreeing, there is not much reason to even bother anymore when
one of them is the AD. What is one to think at this point? "Follow
the Chieftain" syndrome?

Just consider, we are 15+ yrs into all this and nothing was
accomplished with DKIM in regards to LIST systems. DMARC, with the
same exact problems as ADSP, snuck on via an informational status.
Nothing wrong there, but it was pushed as a standard and ventures were
started. Who wins? who loses?

I believe it would be prudent for the AD to look at the reasons why
the IETF has failed with this DKIM Project. If a cog is not for ADSP
but for DMARC with the same problems, then what is that to say about
this process? It 

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Douglas E. Foster]

My comments about From validation were based on the wording of the RFCs, so I 
stand by what I said.

But are your really arguing that no one in the Mailing List business paid 
attention to the concerns about the fraud and spoofing problems with email?

This morning I had a conversation with the CEO of a company that was hit by 
ransomware which arrived with the help of a single email.   He is slowly 
getting his company back after paying a lot of money to people who want to 
destroy us.

That is the problem we should be worried about.   And that is why I am letting 
my emotions show.  This WG is playing the fiddle while Rome burns.

Doug


From: "John Levine" 
Sent: 8/15/20 6:53 PM
To: dmarc@ietf.org
Cc: fost...@bayviewphysicians.com
Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender 
Header Field
In article <6755d0cef49e465bbf2bd170dbdc6...@bayviewphysicians.com> you write:
>Based on the discussions here, it appears that the notion of From address 
>validation was envisioned from the
>beginning Sender Authentication discussions. We have written evidence that 
>Form address validation was
>anticipated in the DKIM and ATPS RFCs prior to DMARC.

Not really. DKIM was deliberately designed not to be tied to any
visible part of the message. ADSP was a poorly designed hack that was
never implemented other than small experiments, and that I don't think
many people understood. I got a lot of grief for making the most
strict policy "discardable" even though that's obviously what it was.

R's,
John
--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Douglas E. Foster]

Based on the discussions here, it appears that the notion of From address 
validation was envisioned from the beginning Sender Authentication discussions. 
   We have written evidence that Form address validation was anticipated in the 
DKIM and ATPS RFCs prior to DMARC.So we have more than a decade of warnings 
that From address validation was coming.   While not everybody has time to read 
every RFC, the Mailing List trade press must have should have been reporting on 
it as something to watch.

Even after DMARC was in use, it appears that nobody in the mailing list 
community felt inconvenienced until the AOL/Yahoo hack and their decision to 
implement DMARC with p=reject.   This was the moment of Unhappy Surprise.
Bad guys had obtained many valid email addresses, so one of the concerns was 
how to prevent them from spoofing those users to send spam.   They could not 
use those address in the SMTP address because of SPF, but only DMARC could 
prevent those addresses from being misused in the Message From address. It 
was the obvious thing to do and it would have been reckless for them to do 
otherwise.   Can you at least admit that the mailing list community was 
surprised because they failed to prepare for this contingency?

But that moment is now in the rear view mirror.Mailing lists can get 
delivery to all subscribers by confirming to the requirements of the 
DMARC-participating domains, by using their own domain in the From address, at 
least for those domains.I assume that there are still mailing list 
operation that are not unable to comply with DMARC-participant expectations, 
because they have failed to upgrade.   But an individual organization’s failure 
to adapt is not a problem worthy of a standards body.   I liked XP just fine 
and hated Vista, like Windows7 OK but hated Windows 8.   But Microsoft killed 
support for XP and Windows 7 and my organization is adapting.Life is 
unfair.  COVID-19 is unfair and has caused a lot of problems.   Every 
organization has problems, and we all have jobs so that we can help solve them. 
   The time to cry in your beer is over.  Mailing lists have a interoperability 
solution, and they should use it whether they like it or not, because that is 
what is necessary to get their mail delivered according to the requirements of 
the recipient organization.As a result, mailing list operators really have 
no standing in this discussion, although they can certainly speak as unhappy 
individual users and on behalf of their unhappy users.

Consequently, the real problem before us becomes the existence of users who are 
unhappy because the From address on some mail does not meet their preferences.  
  I have to ask why that is a problem worthy of a standards body? I have 
about 8 different scenarios in my head where a user might be have unmet 
expectations with the format of the From address, or might experience mailing 
list deliverability problems because of the email filtering policy of its 
domain relative to the addressing practices of his mailing list.   If our 
requirement is to make every user happy, shall we head down the path of all 8 
problems, not just this one?

This project was supposed to discuss moving DMARC from informational to 
standards track.   It has been hijacked by those who, to paraphrase 
Shakespeare, “have not come to praise DMARC, but to bury it.”   This has been 
abetted by the chair’s assertion that we must square a circle – meet the MLs 
requirement for them to impersonate without authorization while continuing to 
advance the DMARC requirement to prohibit impersonation without authorization.

As part of that hijacking, we have been inundated by Mr. Crocker’s assertions 
that the message From Address does not matter.  All the years of theoretical 
analysis that preceded DMARC and all of the operational success from 
implementations of DMARC are just wrong, simply because he says so.   Worse 
yet, he asserts without justification that the message From address should be 
unimportant to everybody except mailing list subscribers, for the simple reason 
that the Message From is so very important to his Mailing List subscribers.   
It is comparable to asserting that the earth is flat, for everyone except 
astronauts.This is sheer nonsense.

More importantly, this discussion has failed to address the actual objective, 
which is to solve the asserted Mailing List problem as it relates to 
AOL/Yahoo/Verizon.   That enterprise does not seem to be involved in this 
process, and no one has offered reason why they will be swayed by anything said 
here.The strategy seems to be that if we tell these people how stupid they 
are, that they will do whatever we tell them they must do, even if the solution 
is to weaken security for everyone on the Internet.That is not a winning 
strategy.

DMARC has been mandated by at least three national governments,, by a variety 
of businesses, and by this one 

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Douglas E. Foster]

Michael Hammer / Dotzero writes:

"Earlier in my DMARC journey I felt that MLMs should adjust and send list mail 
as themselves. Now I have come to the conclusion that they should reject list 
submissions from accounts at domains which publish a DMARC policy of p=reject. 
Domains should not be able to externalize their internal problems to others."

My DMARC reports show no authorized transactions being rejected, but I do have 
two servers in Japan that are actively spoofing my organization's identity.  
How is that an "internal" problem?

DF


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

[dmarc-ietf] Firing the vendor

[Douglas E. Foster]

Yours is the better answer!DF

 Original message 
From: Dotzero  Date: 
8/13/20  5:54 PM  (GMT-05:00) To: dmarc@ietf.org 
Subject: Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ? 

On Thu, Aug 13, 2020 at 5:43 PM Kurt Andersen (b)  
wrote:

> On Thu, Aug 13, 2020 at 2:33 PM Doug Foster  40bayviewphysicians@dmarc.ietf.org> wrote:
>
>> The current DMARC architecture supports authorizing a vendor to mail on
>> behalf of their clients if the client includes them in their SPF policy 
or
>> delegates a DKIM scope to them and they use it.
>>
>>
>>
>> I agree that SPF is too limiting (including hard limits on complexity),
>> and DKIM is too complex for an uncooperative vendor.
>>
>>
>>
>> In most cases, a solution would be a controlled third-party signature
>> authorization along the lines of RFC 6541.
>>
>> The client would configure the authorization in his own DNS and the and
>> the vendor would only need to sign with their own DKIM signature.
>>
>
> If "DKIM is too complex for [this] uncooperative vendor", why would 
having
> the "vendor...sign with...DKIM" be workable?
>

Wrong answer. If the vendor is uncooperative then fire the vendor. 4-5
years ago it was difficult to find vendors who were willing to deal with
DKIM and able to do a good job in implementing. The common mantra was "how
does this fit into my business model". These days I would consider it 
table
stakes.

Michael Hammer

>
>
___
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] non-mailing list use case for differing header domains

[Douglas E. Foster]

Alessandro observed:
>>  However, that kind of hush hush is not deterministic, since the
>> protocol does not define the "external information". Providing for a
>> URL pointing to such external source might help.

Even an external reputation system requires recipient participation.   That is 
why I suggested both a send3="parameters" clause to indicate sender support for 
third-party authorization and a verify3="parameters" clause to indicate 
recipient support for third-party authentication.When both are visible to 
the non-domain message source, that source can have confidence that the message 
will be handled as authorized.

We have a very complete specification for ATSP signature delegation.
Do we have a similar document for your RHSWL approach?
Do we have a similar document for lookup into a trusted-forwarders list, 
assuming a service like that can be revived?

If ATSP and RHSWL solve essentially the same problem, we need to do an analysis 
of which is more likely to succeed, and proceed with that winner.

Third-party lookup is a very different approach than ATSP, so they can 
supplement each other.

DF


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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Douglas E. Foster]

The unifying principle is that we need a third-party authentication method, a 
need which is not adequately satisfied with SPF and DKIM.   The standard can 
support multiple options, such as the following

send3="method=ATPS,p=reject,sp=quarantine;  
method=reputation,p=quarantine,dns=uri; method=RHSWL, sp=reject"

where:
"method=ATPS" means RFC 6541 third-party signatures, as suggested by 
Hector"method=reputation" means a trust service like trusted-forwarders.org, as 
suggested by John"method=RHSWL" means the whitelist system suggested by 
Alessandro
Usage:
If multiple methods are specified, the receiver checks all of the methods that 
it is willing and able to use.If p= is missing, the third-party authentication 
method is not supported for primary domains.If sp= is missing, the third-party 
verification method is not supported for subdomainsIf any method passes, the 
message passes.   No other checks need to be performed.   If all methods fail, 
the strictest policy is the recommendation action.If any third-party 
authorization method is supported, the DMARC policies should be p=none and 
sp=none, to avoid false positives by entities that do not know how to check the 
third-party method.
A domain could optionally advertise which third-party methods it is willing to 
check using a similar keyword structure:
verify3="method ATPS;  method=reputation; dns=uri; method=RHSWL".
This would allow senders to limit third-party impersonation to those recipients 
that will accept the impersonation as legitimate.

It would be desirable for DMARC feedback reports to indicate which third-party 
methods were checked.   Updating the reporting specification might be more 
complex than specifying the verification method itself.

Do we move forward with an approach like this?


From: Alessandro Vesely 
Sent: 8/8/20 5:52 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains
On 2020-08-08 4:27 a.m., John Levine wrote:
>
> Some years back people kept asking Spamhaus to set up a whitelist, so
> they hired me to do it. Technically it worked fine, but it soon became
> apparent that the only people who were interested weren't people who
> we'd want to whitelist. The good quality senders get their mail
> delivered already, the terrible ones didn't bother, and all we heard
> from were people who sometimes sent some spam along with the good mail
> but assured us they were nice people.

I'm not clear why that failed. Personally, I was puzzled by the .com
suffix, which somehow sounded like pay for being whitelisted.

> I think you'll find that all of the existing whitelist like things
> are a sideshow to the company's real business of deliverability
> consulting.

Of course whitelisting can easily become ESPs combat zone.

> For DMARC, it would be nice if there were a shared list of credible
> forwarders, not to automatically accept their mail, but just to say
> they're good enough that you can believe what's in their ARC seals
> when you're doing the usual spam filtering.

Trusted-forwarder.org still exists...[*]

Automatically accept is not the same as override DMARC policy. The
latter can cure some of MLM and non-MLM problems.

I proposed snd=rhswl.zone.example. The difference w.r.t.
trusted-forwarder.org is that some sites can start building their own
right hand side whitelists (RHSWL). Specifying the zone in the
protocol makes it visible, so lazy admins can help themselves to
quickly build their not-so-strict DMARC policy by using someone else's
RHSWL.

Combining lists could also become possible, once there is a decent
amount of them. There is already An Architecture for Reputation
Reporting, RFC 7070/3, which could support exchanging entries among
similarly scoped RHSWLs.

> You can't just let people sign themselves up for a list like that,
> since every dodgy bulk mailer will figure this will get them an
> extra 2% delivery, and we've never gotten past a vague hope that we
> could canvass people we know to make a combined set of mailing
> lists hosts we know.

Seeking how to make that hope less vague should be a highly commended
task.

Best
Ale
--

[*] http://multirbl.valli.org/detail/wl.trusted-forwarder.org.html

___
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] non-mailing list use case for differing header domains

[Douglas E. Foster]

Murray, I  have most recently used this link at AOL/Yahoo:  
https://postmaster.verizonmedia.com/sender-request

I have considered using the more complete "Complaint Feedback Loop", 
https://postmaster.verizonmedia.com/cfl-request  but have never completed the 
process.

Maybe they are the last to offer this type of feature.  Or maybe my memory is 
imagining things   Now that you have pressed me, I cannot remember whether I 
have had success with other services or not.

My heart is not in prior registration either, but I was trying to lay out the 
next-best alternative for those who want an alternative to using the MLM domain 
identity.

The goal of DMARC is to end spoofing, which requires everyone to send using 
their own domain, even when performing a favor for someone in another domain.   
A recipient domain owner has the right to define the rules for getting into its 
network.Those who want into that network should play by the rules of that 
network, whether the rules are liked or disliked.

An incoming email is a take-it-or-leave-it proposition for most recipients.   
My domain does not have the market power to alter sender behavior.   When I 
receive a spoofed message that the recipient actually wants, I end up creating 
an exception to allow the spoof.   Spoofing senders are counting on their 
ability to force me to do that.   However, Microsoft is powerful enough to 
engage in a standoff.Those who want to send to Microsoft destinations will 
need to not violate DMARC.   I hope and expect that they will win this battle.

DMARC is not new.   Products that have not become DMARC-aware are as obsolete 
as WindowsXP.   Unfortunately, that does include a lot of products.

Over a year ago, I was about to recommend Proofpoint as our new email filtering 
vendor.   But the next morning I realized that their secure email service will 
spoof the identity of non-clients when they respond to a message from a client. 
  I had a real problem with a vendor promoting their ability to enforce DMARC 
on incoming mail, while also violating DMARC on their secure email service.   
Then I saw that Cisco Ironport did the same thing.   I raised CIRT issues with 
both vendors, but nothing has changed.   Maybe Microsoft will be able to change 
their attitudes.
DF


From: "Murray S. Kucherawy" 
Sent: 8/7/20 7:16 PM
To: Doug Foster 
Cc: Dave Crocker , IETF DMARC WG 
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains
On Sun, Aug 2, 2020 at 5:44 PM Douglas E. Foster 
 wrote:
Murray took server too literally.   I have expressed before that a system could 
do a sender authentication lookup on List-ID as easily as on From.   In this 
respect, it is similar to Dave's proposal, without the added complexity of 
additional identifiers.   So think "Registerd List-ID plus DKIM signature (or 
SPF, but DKIM seems both sufficient and preferable.)

If we take "server" to mean a tuple made up of a List-ID value and a "d=" value 
from a validated DKIM signature, which I believe is what you're saying here, 
the first occurrence of this necessarily has no internal value (or history) 
attached to it.  That means the operator has to develop meaning for it over 
time, which doesn't tell it how to handle the first N such messages.  Err on 
the side of openness and you have a spam or attack vector; err on the side of 
defense and you irritate your users by denying them some list traffic until a 
reputation can develop.

And it's probably actually a three-tuple, with the third part being the 
recipient.  Otherwise, I could register (or trigger the auto-registration of) 
any two-tuple I want and thus intentionally let in my preferred list streams, 
good or bad, which affects every other user.

Plus, you're trusting users to get this right.  For a manual registration 
scheme, every time they get it wrong by entering the wrong data or failing to 
even do it at all, you've got a failure mode to deal with, usually in the form 
of user complaints which require other humans to resolve.  That makes it 
relatively expensive.

And finally, lists change once in a while, maybe to a new signing domain, maybe 
to a new name, maybe both.  Every time that happens, the process has to start 
over.  Naturally lists won't want to do this because of the sterling 
reputations they've developed, but the pain reappears whenever the process 
needs to be repeated for whatever reason.

I'm not saying such a system can't or won't work.  I'm also not saying I have a 
better idea.  I am saying there's multi-faceted pain in every direction in this 
space, and this is no exception.  Whatever path we choose to deploy here has to 
account for those choices and their side effects, and the ways they might be 
gamed.

I am not sure what "Internet Scale" means to you.   Most of the major 
recipients have bulk mailer registration systems.   It does not guara

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Douglas E. Foster]

Murray took server too literally.   I have expressed before that a system could 
do a sender authentication lookup on List-ID as easily as on From.   In this 
respect, it is similar to Dave's proposal, without the added complexity of 
additional identifiers.   So think "Registerd List-ID plus DKIM signature (or 
SPF, but DKIM seems both sufficient and preferable.)

I am not sure what "Internet Scale" means to you.   Most of the major 
recipients have bulk mailer registration systems.   It does not guarantee 
whitelisting, but it tends to produce that effect.   I have had occasion to 
register with most of them.   So "does not scale" is not obvious to me.

Even more to the point, check out this link:
https://blog.postmaster.verizonmedia.com/post/616023179026202624/increasing-relevance-performance-through-vto

Verizon appears to be offering a service (probably for extra cost) which is 
based on:
(a) a well-defined mail stream from a known sender, and
(b) a mailbox user identifying that mail stream as subscribed, and therefore 
desirable.

It appears that the target senders are retailers who want to ensure that their 
sale announcements are read before the sale is over.   It is an "Internet 
scale" application of the type of registration I was suggesting:   
Well-identified senders, coupled with end-user endorsement, receive preferred 
treatment.

As to the transparency question, it should be clear that there will be no 
simple solution to the ML problem.  As long as mailing lists appear identical 
to a malicious spoofer, their only protection is their own sterling reputation. 
  But the only way to establish an acceptable reputation is to either register 
with the receiver directly, or register with the sender in a way that the 
receiver will honor.Your proposal does nothing to distinguish mailing lists 
from malicious spoofers, so it does nothing to solve the problem.   Mailing 
lists either need to send using the ML domain as the From address, not modify 
the message, or establish a credible reputation.   There are no other 
possibilities on this side of FantasyLand.

DF


From: Dave Crocker 
Sent: 8/2/20 5:29 PM
To: IETF DMARC WG 
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains
On 8/2/2020 2:22 PM, Murray S. Kucherawy wrote:
> Ignoring for the moment the problems of scale with any "register your
> lists" solution, I don't think users can reasonably be expected to
> keep such a registration current if, say, the servers were to move.
> Such a migration would no longer be transparent, as it is today.

+1

When someone proposes a scheme, it will help for them to list who the
relevant actors must be and what they must do and then deal with the
question of scaling.  That is, how will it be possible for this to work
at Internet scale?

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] non-mailing list use case for differing header domains

[Douglas E. Foster]

Is it fair to say that AOL/Yahoo/Verizon is the core of the problem for you?

If they would provide a way to register a mailing list and the servers from 
which it comes, and allow DMARC exceptions for traffic from those registered 
lists, your situation would be much easier?

DF


From: "John Levine" 
Sent: 8/2/20 12:58 PM
To: dmarc@ietf.org
Cc: fost...@bayviewphysicians.com
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains
In article  you write:
>I wonder if this is typical - are mailing list subscribers more likely to be 
>on DMARC-enforcing domains than the general population?
>
>Do the mailing list operators have data about what percentage of their 
>subscribers (or percentage of unique domains) have DMARC policy enforcement in 
>place?

In my experience it completely depends on the list. I have a list of
folk dancers with a lot of old AOL and Yahoo addresses with DMARC
policies, and I have other lists where it's mostly gmail and
Hotmail/Outlook, without.

R's,
John


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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Douglas E. Foster]

I have reviewed recent posts to this mailing list:   Submissions have come from 
39 different people on 34 unique domains.   Of these, 11 have munged headers, 
indicating that they use an enforceable DMARC policy.   This is a much higher 
percentage than your general survey.

I wonder if this is typical  - are mailing list subscribers more likely to be 
on DMARC-enforcing domains than the general population?

Do the mailing list operators have data about what percentage of their 
subscribers (or percentage of unique domains) have DMARC policy enforcement in 
place?

DF


From: Neil Anuskiewicz 
Sent: 8/1/20 9:27 PM
To: Luis E. Muñoz 
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains
I looked at ~3.5 million domain names and here's some of what I found. This 
data might be useful to the discussion. As for me, I'm lurking and learning.

Anyway, I looked at ~3.5 million domain names and here's some of what I found:

FTSE DMARC Adoption
 DMARC Policy10/18/2019
 No record   56%
 none34%
 quarantine  1%
 reject  9%

F500 DMARC Adoption

 DMARC Policy10/18/2019
 no record   49%
 none37%
 quarantine  4%
 reject  9%

ASX DMARC Adoption

 DMARC Policy10/18/2019
 no record   59%
 none33%
 quarantine  1%
 reject  7%

On Sat, Aug 1, 2020 at 12:57 PM Neil Anuskiewicz  wrote:

I looked at ~3.5 million domain names and here's some of what I found.. This 
wasn't a random sample but perhaps this data will be useful in this discussion:

FTSE DMARC Adoption
 Snapshot (10/18)

 No record   56%
 none34%
 quarantine  1%
 reject  9%

F500 DMARC Adoption
 Snapshot (10/18)

 no record   49%
 none37%
 quarantine  4%
 reject  9%

ASX DMARC Adoption
 Snapshot (10/18)

 no record   59%
 none33%
 quarantine  1%
 reject  7%

Thanks.

Neil
On Thu, Jul 30, 2020 at 6:02 PM Luis E. Muñoz 
 wrote:

On 30 Jul 2020, at 15:52, Jim Fenton wrote:

There's an underlying assumption here that I don't agree with: that
DMARC adoption equates to the publication of a p=reject DMARC policy,
and that everyone (or at least all Fortune 500 companies) should be
doing that. p=reject should only be used when the usage patterns of the
domain support that policy. I'm more inclined to say that 85% of Fortune
500 companies are savvy enough not to publish a policy that doesn't fit
their usage patterns.

I am currently observing ~215.5 million domain names. Out of those, ~64
million have a seemingly valid SPF record and ~113 million with at least one MX 
record.

This is a current breakdown of the (valid) DMARC records I am observing over 
the general domain population above. This amounts to an adoption rate of ~1.7%.
pcount
 none2715614
 quarantine  238584
 reject  726045

It is interesting that roughly half of those are not taking advantage of the 
reporting. Here are the counts for those with neither rua= nor ruf= in the 
DMARC records:
pcount
 none1092990
 quarantine  107767
 reject  307614

I do not have a definitive list of Fortune 500 domain names, but I compile a 
rolling list of domain names with most traffic using multiple sources, which 
currently holds ~1.8 million unique domain names.

The breakdown of DMARC records from that high-traffic population is shown 
below, and it amounts to about 6.3%.
pcount
 none79367
 quarantine  18094
 reject  15875

For completeness, here is the same report, counting only those that have 
neither rua= nor ruf= in the DMARC record. The ratio of silent p=quarantine and 
p=reject seems around half as in the case of the general population.
pcount
 none32561
 quarantine  4534
 reject  2760

It would seem that those high-traffic domains are ~5x more likely to adopt 
DMARC. To me, these numbers speaks of thoughtful and deliberate deployment that 
outpaces the general domain name registrations.

That said, I cannot claim whether the list of high-traffic domains is actually 
a good proxy for the domain portfolio of the Fortune 500 companies.

Best regards

-lem

___
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] non-mailing list use case for differing header domains

[Douglas E. Foster]

On the issue of spoofing, only two security postures are possible in the 
incoming mail gateway:
We allow spoofing by default, then block problematic spoofing as detected, on a 
case-by-case basis.We disallow spoofing by default, then allow desired mail as 
needed, on a case-by-case basis.
Only the second security posture is credible in a security audit.   DMARC v1 is 
the most effective tool for implementing that security posture.   The proposed 
"new" DMARC returns us to the first security posture.

Incoming email can be divided into these categories:
Messages that have confirmed identitiesMessages that appear to be spoofing but 
actually contain desired content from valued senders.Messages that appear to be 
spoofing and are unwanted.Messages where spoofing cannot be evaluated.
Security posture 2 will be associated with these policies:
Message category 1 will be allowed or blocked on other criteria.In 
particular, confirmed identity allows preferred message handling to be 
implemented safely.Message category 2 will be handled through the receiving 
organization's exception process.   Message category 3 will always be blocked.  
  Message category 4 may be reviewed, as time permits, to determine a local 
policy which moves it into category 1 or 3.
If there are category 2 problem cannot be solved between a recipient user and 
his email security team, we need to document when and why this is happening,

However, the expectation is that senders in category 2 and 4 will have 
incentive to move into category 1 over time.   To the extent that this has not 
happened, it is a great misfortune.

An excess of category 2 messages can contribute to an organization choosing to 
delay or abandon implementation of security posture 2.   This increases their 
risk.   Indirectly, category 2 messages serve to facilitate the dirty work of 
category 3 messages, in exactly the same way that a large enough crowd can 
become an enabler for looters and arsonists.

DF


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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Douglas E. Foster]

Calender invites are a known issue, and the issue is mentioned in RFC 7960.

The exact scenario is:
User A creates a meeting and invites User B who is in a different email 
domain.User B forwards the invite to User C, who is in a different 
administrative domain than User B.  The invite is sent using User A as the 
sender, so the invite fails DMARC tests.
The problem does not occur if User A extends the invite to User C.
The problem does not occur if User B and User C are in the same administrative 
domain,on the assumption that DMARC is not checked or enforced on messages that 
are internal to the administrative domain.

For invitations that are relayed across administrative boundaries within the 
organization, email filtering exceptions should work around the problem.  If 
not, the organization needs a different email filtering product.

For invitations that are relayed outside the organization, the policy of the 
receiving domain will determine whether the message is blocked or allowed..  I 
would expect that most DMARC enforcers have encountered this problem and have 
developed a workaround to it.

Or course, this WG or a spinoff could investigate ways for cooperating MUAs, to 
send invites that do not encounter this problem.

As Laura Atkins said, DMARC implementation is not easy.  Nonetheless, 
deployment is slowly increasing, not decreasing.It seems unlikely that 
DMARC enforcement will go away.


From: atyrsalvia=40agari@dmarc.ietf.org
Sent: 7/28/20 2:54 AM
To: "dmarc@ietf.org" 
Subject: [dmarc-ietf] non-mailing list use case for differing header domains
Hello,

I recently had a conversation with Dave Crocker about proposed changes for 
DMARC, and mentioned a use case to him that is not well served by the current 
situation that is not a mailing list. He said it might be useful to share this 
to this list, so I'm writing it out here.

A customer of mine is a large financial services company. Like many in that 
field, they have acquired several other companies over the years, and now 
operate multiple different brands, which send email using different domains... 
While many companies like this maintain one primary domain for corporate email 
and others only for marketing purposes, this company maintains multiple 
distinct domains even for corporate workplace email.

The challenge is that they have many administrative assistants who send out 
meeting calendar invitations on behalf of the executives they support, and the 
executive and the assistant do not always use the same email domain. The 
resulting messages are not aligned, so they fail DMARC.

To put it another way:
assist...@firstbrand.com is organizing a meeting for 
executive@secondbrand.comassist...@firstbrand.com sends out a calendar invite 
from their own messaging client, using execut...@secondbrand.com in the From: 
fieldThe resulting message uses execut...@secondbrand.com in the friendly From: 
field, but firstbrand.com in the SMTP MAIL FROM domain, so the headers are no 
longer aligned for SPF.Both firstbrand.com and secondbrand.com are set to DMARC 
p=reject.Messages like this are then rejected by receivers that validate DMARC 
results.

Whenever possible, they tell me they change the assistant's email domain to 
match the executives they support, but as people leave or change departments, 
they sometimes end up with assistants supporting executives across multiple 
different domains, so they can't ensure they always have the same domain.

Maybe the ultimate answer for this customer and others in a similar situation 
is simply that this is a use case that can no longer be supported due to 
evolving security needs, and yet if that's the case, I thought it would be 
helpful to share a real world scenario that is currently impacted that isn't 
part of the previously existing discussion around mailing lists.

Thanks,

Autumn Tyr-Salvia
atyrsal...@agari.com
Agari Principal Customer Success Engineer


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

The link provided by Laura Atkins on 7/21 is relevant and worth 
reading.Sent from my Verizon, Samsung Galaxy smartphone

 Original message 
From: Dave Crocker  Date: 
7/26/20  2:35 PM  (GMT-05:00) To: hsan...@isdg.net 
Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Response 
to a claim in draft-crocker-dmarc-author-00 security considerations 

On 7/26/2020 11:29 AM, Hector Santos wrote:
> Dave, for a number of years of practice, depending in the system or 
> service, users have been provided with trust-related decisions . Do 
> you need real examples? 


There is a difference between providing a signal, versus its getting 
received and use.

Please provide objective data that these signals are being perceived and 
used effectively by end users.

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

[Douglas E. Foster]

Recipient domains determine what messages they will accept or reject.Fairness 
and precedence are not necessarily applicable.I suggest that the DMARC 
standards track be placed on hold for at least a year.   It is not clear to me, 
from this group's membership, that DMARC implementers feel an urgent need for 
standard status, so a delay should be tolerable to them.A Mailing List 
Protection WG should be formed to develop his ideas into an informational or 
experimental RFC.   Then that RFC can be promoted to see if it wins over any 
current users of DMARC Sent from my Verizon, Samsung Galaxy smartphone

 Original message 
From: Dave Crocker  Date: 
7/26/20  9:50 AM  (GMT-05:00) To: Brandon Long  
Cc: IETF DMARC WG , Dotzero  
Subject: Re: [dmarc-ietf] Response to a claim in 
draft-crocker-dmarc-author-00 security considerations 
On 7/21/2020 1:42 PM, Brandon Long wrote:
> Stricter validation is not an uncommon addition to protocols over the
> last 45 years.


If there are examples of adding stricter validation in a way that
essentially requires changing the semantics of the payload, in order for
the payload to survive, I can't think of any. Not TLS, not DNSSec, not
S/MIME or PGP.

DMARC essentially enforces a semantic on the From: field as a handling
identifier, rather than an author identifier.

When activity that has a long history of semantic validity and a
continued desire for operation is forced to break the denotational
source of authoring information, in order to get the mail delivered,
then we are in new territory.

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] Fwd: Agenda requests for Madrid IETF

[Douglas E. Foster]

I support an initiative to validate other parts of the mail message, to inhibit 
the ability of criminal actors to spoof recipients.   The topics that I think 
need attention include:
Control untrusted content in the Friendly Name.   As suggested, a mechanism is 
needed to hide or remove untrusted Friendly Names.  This seems to require a way 
to sign the message with and without the Friendly Name included, as well as 
methods to configure policy defintions for Friendly Name trust.

Obstruct hijacking of corporate logos.   Existing work with Digital Rights 
Identifiers seems to be the starting point for this effort.

Validate routing paths and detect suspicious routes.ARC seems to provide 
this opportunity.Currently, any Received header, prior to the first one, 
cannot be fully trusted, because it might be spoofed.   This is a source of 
concern even if criminals are not yet spoofing this content.ARC provides 
the opportunity to distinguish verified Received headers from unverified ones.  
 The potential benefits of this information for spam filtering are not yet 
clear, but I believe those opportunities will become evident in the future.

Embrace multiple authorship.   We need to provide spam filters, mailing lists, 
and other intermediaries with the ability to add signed content without 
destroying existing signatures,.  This will require MUAs that understand the 
multiple authors and can use that knowledge to display the content of different 
authors with appropriate identifying information.  It will also require 
supporting protocols to allow incoming gateways and individual users with the 
ability to control whether an addition is trusted and visible or untrusted and 
hidden.
These initiatives will add complexity to the email evaluation process.   We 
know that anything which adds complexity will also create risk that email 
gateways will become confused and therefore vulnerable.These initiatives 
must be carefully vetted to avoid creating new attack methods.   The criminals 
seem to have more imagination than the rest of us, so attack methods can be 
difficult to predict.

Doug Foster


From: "Murray S. Kucherawy" 
Sent: 7/25/20 9:49 AM
To: Dotzero 
Cc: IETF DMARC WG 
Subject: Re: [dmarc-ietf] Fwd: Agenda requests for Madrid IETF
On Fri, Jul 24, 2020 at 12:05 PM Dotzero  wrote:
I would like to see an agenda item as to whether work around "Display Name" 
changes are in scope or out of scope for this effort and this working group. It 
would seem to me that any such efforts are more appropriate for the emailcore 
working group.

A quick read of the current charters suggests to me that it's in scope for 
neither.  That seems to be especially true for emailcore.

Do you have such a change to propose?

-MSK


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

[Douglas E. Foster]

The court system is a poor substitute for prior deterrence or attack 
disruption.   DMARC seems to do both.

The Internet limits the utility of legal remedies because of the difficulty of 
attribution, a problem which also DMARC helps to solve.   Litigation is also 
hampered by jurisdictional boundaries that create little risk of consequences 
for the perpetrators of crime.

This forum was proposed for upgrading DMARC from informational status to 
standard status.   Instead, it has become a conspiracy to demolish it.The 
MLM problem will only be :"solved" if DMARC is completely abandoned, so that 
spoofing is once again uninhibited.   Therefore, moving from normal IETF 
"suggestion" mode to "enforced" mode will be necessary to achieve what MLM 
proponents want.   It is not what I am advocating; quite the reverse.   I am 
advocating for MLMs to stop spoofing and make their peace with DMARC.

DF


From: Benny Lyne Amorsen 
Sent: 7/20/20 5:44 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 
security considerations
"Douglas E. Foster"  writes:

> Ultimately, this becomes a question of power. Do domain owners have
> the right, with the help of their correspondents, to prohibit spoofing
> (unauthorized use) of their digital identity?

Domain owners are free to use the court system to assert trademark
rights and copyright. They are also free to apply whichever seals of
digital identity that they want, of course.

> Or since they are technically leaseholders, not owners, are their
> rights conditional?

You seem to be laboring under the impression that domain owners have a
right to compel mail recipients to respect a DRM scheme. This is not the
case. You can try to sue Google to force them to reject incoming email
with your domain in the From: field and no valid DKIM (or whatever)
signature, of course, but I have a hard time imagining which right you
would assert to make the suit successful.

> Specificslly, do Internet insiders have the right to declare their
> spoofing control efforts to be based on foolish premises, both
> unnecessary and inconvenient, and therefore not allowed?

No one, certainly not "Internet insiders" of which I am certainly not
one, is stopping you from doing whichever spoofing control efforts you
want on your systems.

Feel free to keep p=reject on your domains. Many mail servers will keep
using that as a signal among many others, rather than as a blanket
reject.

If you want recipient mail servers to change that policy you can either
do it by convincing their administrators or by getting a law passed. So
far you appear to favour the latter approach, with your focus on
"prohibit" "unauthorized use" and "rights". The IETF is not a lawmaking
body, so it appears there are better venues for you.

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

[Douglas E. Foster]

Ultimately,  this becomes a question of power.   Do domain owners have the 
right, with the help of their correspondents, to prohibit spoofing 
(unauthorized use) of their digital identity?Or since they are technically 
leaseholders, not owners, are their rights conditional?  Specificslly, do 
Internet insiders have the right to declare their spoofing control efforts to 
be based on foolish premises, both unnecessary and inconvenient, and therefore 
not allowed?

 Original message 
From: Dave Crocker  Date: 
7/19/20  8:53 PM  (GMT-05:00) To: "Murray S. Kucherawy" 
 Cc: IETF DMARC WG  
Subject: Re: [dmarc-ietf] Response to a claim in 
draft-crocker-dmarc-author-00 security considerations 
On 7/19/2020 5:04 PM, Murray S. Kucherawy wrote:
> On Sun, Jul 19, 2020 at 11:33 AM Dave Crocker  > wrote:
>
> The track record is that people are unreliable at this.
>
> There is quite a bit of distance between 'unreliable' and 'blindly
> open and read absolutely everything'.
>
> Is there?

Yes.


> If there's no part of the From field that can be considered reliable,
> then by opening even this email am I not exhibiting nearly-blind faith
> that the indicators I can see (in this case the string "Dave Crocker
> (gmail.com )") have not been falsely generated?  How
> is this message, in terms of its trustworthiness, different from any
> other?

It's an act of curiosity, not faith.  You know that mail can be
spoofed.  You might even suspect that I'm capable of lying. (Silly, I
know, but...) Or that I might be wrong. (Truly a foolish thought.)  So
the process of deciding on the validity and worth of my message is
incremental and heuristic.

Human evaluation processes vary, but mostly are pretty complex. Except
when they aren't, though then it's often problematic.

Mostly, your line of comments is trying to apply logical reasoning,
which is rarely helpful in assessing human behavior.

All of which is why this is a really terrible forum for making
assertions or, worse, decisions, about end-user behavior.

Whereas talking in terms of receiving filtering engines is both simpler
and more useful.

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

[Douglas E. Foster]

Yes, Gmail is a win for Dave.   User has to hover to see the from address, 
instead of friendly name, except when the TO does not match the recipient.
null___
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 comments mply that for non-MLM messages, the only purpose of rfc5322.From 
is trust.   A related action would be attribution:  after an attack, whom do I 
blame?  Domain owners do not want to be attributed to someone else's crime.But 
obviously, there are other purposes, such as searching and sorting.   These 
also depend on accurate values.   Consequently, spoofing affects multiple  
functions which are important to domain owners and message readers.  You 
asserted again that nearly all MUAs hide the From address, then ignored 
contrary data.   Gmail and Outlook have significant user bases.   No one has 
identified the long list of MUAs that hide, or indicated the market share of 
those MUAs.What has also not been explained is:   why it is an uncoscienable 
burden for MLMs to use rfc5322.From addresses of the form user=domain@MLM?  Any 
such attempt is weakened by your assertions that From matters to no one.Any MLM 
can create their own rules by operating in a dedicated domain which issues 
domain accounts to its subscribers.  But as long as it chooses to operate in a 
shared realm, it must accommodate the needs of others within the shared 
realm.DF

 Original message 
From: Dave Crocker  Date: 
7/18/20  9:32 PM  (GMT-05:00) To: "Murray S. Kucherawy" 
 Cc: IETF DMARC WG  
Subject: Re: [dmarc-ietf] Response to a claim in 
draft-crocker-dmarc-author-00 security considerations 
On 7/18/2020 5:16 PM, Murray S. Kucherawy wrote:
> At some point in the past, Gmail decided to show the email address
> only unless that address was in the recipient's contact list, or if
> the recipient had replied to that address previously, or something
> like that.  In those cases, the RFC5322.From address was trusted, and
> so the display name was shown.  Is there logic like that still in place?


If end users do not reliably make trust decisions based on /any/ of the
information in the rfc5322.From field, then how is this question
important.  It seems to be seeking precise data about something that
isn't even secondary.

The persistence of thinking that end users are influenced by trust
indicators is pernicious.

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] Setting From: MLM, To: author, Bcc: subscribers

[Douglas E. Foster]

Rewriting the Message To seems to have no characteristics that are likely to 
cause messages to be blocked as not trustworthy.

This approach will not be detected as anomalous by an incoming gateway.   
Messages to BCC recipients and messages to non-modifying distribution lists are 
already received with the message From address being different from the SMTP 
RCPT address.

Since a user knows that a received message is for himself, a message that 
reports "To" as someone other than himself may cause minor confusion, but is 
not likely to cause significant misunderstanding..

In sum, no one seems to be concerned about the integrity of the "To" header 
currently, and there is no obvious reason why we would expect this to change in 
the future.

For mailing lists that are insist on editing submissions, changing SMTP MAIL 
FROM and Message From into the list domain, and the Message To into the author 
domain, will solve the sender authentication problems created by doing so.   
Just as importantly, it requires no special pleading to participant domain 
administrators.

DF




From: jesse.thompson=40wisc@dmarc.ietf.org
Sent: 7/10/20 6:22 PM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers
On 6/29/20 4:18 AM, Alessandro Vesely wrote:
> Hi all,
>
> I mentioned setting To: author instead of From: author-like, near the bottom 
> of a message[*] a week ago, but missed any WG comments on it. That setting 
> would result if I run a mailing list "by hand", using a normal email client. 
> I'd hit reply and then add a bunch of Bcc:'s. Of course, a suitable template 
> would insert a subject tag instead of "Re:", et cetera.
>
> It'd be a cleaner solution than From: rewriting, inasmuch as it saves the 
> association between display names and addresses, for the sake of address 
> books consistency. The anomaly of seeing authors in To: fields, with some 
> getting used to it, may even become a distinguished characteristic of 
> indirect mail flows.
>
> How unbearable would that be? And why? Maybe some comments on this subject 
> can bring out some more details about the rightness or wrongness of the 
> various flavors of From: rewriting.

If nothing else changes; as in: MLMs have to keep promoting the use of From 
munging to their list operators, then I think it would be useful for these MLM 
to also offer (and perhaps default-to-ON if it works well in practice) your 
idea of replacing the To with the author during the munging process.

It would increase the odds that the author will be added to the recipient's 
address book, either manually, or via auto-collection by MUAs when they 
Reply-all (I believe that most MUAs will include the To in the recipient list 
if it differs from the user's own address)

Recipients (and individual list operators) may still complain about the From 
munging, but I like your line of reasoning of getting people used to 
"distinguished characteristic of indirect mail flows".

Recipients will still be saddled with "author via listname" polluting their 
address books (via address auto-collection). This idea doesn't solve that 
problem.

Jesse

___
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] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt

[Douglas E. Foster]

I was convicted that I was working from a reading of the abstract, and not the 
whole document.   So I read the whole document last night, but it did not 
change my understanding.

Given a first occurrence of a message which purports to be from a legitimate 
message-altering MLM, how does the email gateway make a disposition decision?  
ARC does not solve the problem, because the ARC chain does not provide enough 
information to do so.   ARC assumes that initial trust is obtained by another 
method.

Reversible tagging mostly solves the problem if the content is fully 
reversible.   The email gateway can assess both new and old content for risk, 
can assess both before and after signatures for identity verification, and can 
choose which version of content to deliver to the user.   But there are 
questions about whether this solution covers enough of the problem to make it 
the only solution.  We also have the question of whether the tagging would be 
too complex to do correctly.

For a complete solution, the mailing list needs to be able to distinguish 
between these possibilities:
Fiction - the mailing list does not exist, but a spammer wants to look like one 
to evade DMARC filteringUnsafe - the mailing list is poorly managed, so that it 
is little more than an open relay, or the content filtering is inadequate, so 
that it is a likely source of malicious content.Unwelcome - the subscriber 
address is a work account, and the list purpose is not work related.Spoofed 
list - a spammer tries to imitate a trusted list.Legitimate - a trusted and 
wanted list that both subscriber and email administrator want to receive.
I don't see that we have adequately addressed all of these scenarios, but again 
it seems that most of the issue hangs on the trust question.

List spoofing is an issue because we do not yet have a standard for how a list 
ID is associated with an authorized source.  Presumably, we should perform an 
SPF check on the list ID, or find a verified DKIM signature that is domain 
aligned with the list ID.   But there are no requirements on the format of a 
list ID, so we need to start by defining how the list domain is obtained from 
the list ID.

What is the process for obtaining trust (and a supporting exception in the 
email gateway)?
What is the process for notifying the MLM that the exception has been 
implemented?

DF


From: "John Levine" 
Sent: 7/6/20 9:30 PM
To: dmarc@ietf.org
Cc: fost...@bayviewphysicians.com
Subject: Re: [dmarc-ietf] Fwd: New Version Notification for 
draft-kucherawy-dkim-transform-01.txt
In article <3129f12e02434273915ed6f91a998...@bayviewphysicians.com> you write:
>About credible mediators:
>You are right that if an inbound email gateway believes a Mediator is 
>credible, then all that is necessary is for
>the Mediator to prove his own identity. But what is the mechanism by which a 
>Mediator obtains the trust of the
>email gateway? And by what mechanism does the Mediator know that the email 
>gateway has determined it to be
>credible?

Please see previous discussions about the design of ARC. There's
reasons it's not just a whitelist of mailing lists.

--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


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

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt

[Douglas E. Foster]

About discarding From alignment:
DMARC has been sold to big corporations as essential to defending their brand 
identity.In response, they pay serious money to keep Valimail and its 
competitors in business.   I see no way that we can put forward a proposal that 
will put Valimail and its friends out of business, while incurring the wrath of 
C-Level executives and legal teams at Fortune 500 companies.   Not that I have 
any of those people on speed dial, so maybe someone can prove me wrong.   But I 
have been surprised that one of the DMARC reporting companies is not listening 
to this part of the discussion and having alarm bells.

About credible mediators:
You are right that if an inbound email gateway believes a Mediator is credible, 
then all that is necessary is for the Mediator to prove his own identity.
But what is the mechanism by which a Mediator obtains the trust of the email 
gateway?   And by what mechanism does the Mediator know that the email gateway 
has determined it to be credible?

One option is to provide so much information in the email message that the 
email gateway will grant trust on the fly.Murray's approach has appeal 
because, especially when coupled with appropriate LIST-* and RESENT-* headers, 
it provides all of the information needed for a decision to be made.   ARC has 
less appeal because it provides just enough information for the email gateway 
to detect that something deliberate was done, but not much more.   Researching 
the credibility of the list would need to occur out-of-band using LIST-* 
headers as a starting point.   But there is a larger problem.   Even after the 
gateway decides the Mediator is credible, the Mediator is ignorant of the 
gateway's decision, so the Mediator is unable to take advantage of that 
decision.

The other option is for the MLM and the Email gateway administration to 
negotiate credibility in advance, with the subscriber acting as sponsor for the 
discussion.

DF


From: Jim Fenton 
Sent: 7/6/20 2:33 PM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Fwd: New Version Notification for 
draft-kucherawy-dkim-transform-01.txt
On 7/6/20 10:41 AM, John R Levine wrote:
> On Mon, 6 Jul 2020, Dave Crocker wrote:
>>> I don't understand this scenario at all.  Why would I want to show
>>> my user a message forwarded by a spammer?  If the original sender
>>> wanted me to see it, she could have sent it to me directly, or
>>> through a legit mailing list.
>>
>> Perhaps, like some others, I'm not understanding this correctly, but
>> I think the proposal has nothing at all to do with what the recipient
>> sees.  Rather, I've understood this as an attempt to reverse
>> additions made by a Mediator, with the goal of validating the
>> origination DKIM signature.  Presumably that is so as to use the
>> origination domain's reputation and even permit DMARC to validate.
>
> But why would I want to do that?  ARC lets a credible mediator say
> this message was OK before I munged it.  This proposal lets a sleazy
> mediator say the same thing, with advice on how to verify mechanically.

Your use of  "credible mediator" and "sleazy mediator" emphasizes that
we're depending on the mediator behaving responsibly. Given that's the
case, why not just expect a responsible mediator to verify the DKIM
signature (or maybe SPF) on the incoming message, check its alignment
with the From: domain, then make whatever modifications it wants to
make, then re-sign the message with the mediator's DKIM signature
containing a tag that says it did all of the above?

Yes, this is a "get out of DMARC free" card for mediators to use. But
we're already dependent on being able to distinguish between credible
mediators and sleazy mediators, and this tag simply says, "if you trust
that I'm a credible mediator and this message has a valid signature from
me, you should accept the message even if my signature doesn't align
with the From: domain."

This gets us out of the business of trying to define what acceptable and
unacceptable transformations are. If the transformation was done by a
credible mediator, it's acceptable.

Many (most?) mediators do not currently require authentication
(+alignment) on incoming messages. They could continue to forward the
unauthenticated messages, but without the new tag.

-Jim

P.S. I'm still not sold on the value of From: domain alignment, but left
that in here to avoid conflating too many different ideas.

___
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] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt

[Douglas E. Foster]

This surprises me:

This proposal makes lists sort through all of the changes they make
and try to figure out which ones match a tag and which ones don't.
That is surprisingly hard, e.g., I found that when you have
multipart/alternative and add a message header, it edits the header
text into both of the alternative versions. Good luck unscrambling that.

I expected that the tag would be a function of the algorithm used by the MLM or 
forwarder, rather than the particulars of each message.   In a face-to-face 
conversation between MLM and recipient email administrator, the algorithm would 
be the topic of conversation, and would be the determinant of whether trust was 
established or not.

At the same time, you raise an important point:   The tag will be most useful 
if it will be reliably correct, but less useful if it is prone to errors..  In 
practice, the tag is likely to be fraught with human errors which introduce 
another layer of trust confusion:   What do I do when the tag and the 
reversable content of the document are inconsistent with each other?  We have a 
lot of those problems already.

DF


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

[dmarc-ietf] DMARC as an instance of a class

[Douglas E. Foster]

DMARC either introduced or popularized the concept of filtering on the Message 
From.   Low-end gateways that lack DMARC support will typically do nothing with 
the Message From -- the header value does not appear in the message logs and it 
cannot be used for filtering because it is not examined.

Now that the concept has been established, spam defenses based on From 
filtering are a class, of which DMARC is only an instance.Recipient systems 
might choose to:
Enforce DMARC on a domain even if the domain has a DMARC policy with p=none or 
pct=0.Enforce DMARC-equivalent requirements on a domain that has no DMARC 
policy at all.Block based on the TLD of the From addressBlock based on Domain 
reputation lookups using the From address.
This creates a difficult problem for the MLM which wants to use author as the 
From address.   The recipient gateway does not know the universe of all mailing 
list subscribers, and the list changes over time as members subscribe and 
unsubscribe.   The MLM does not know the universe of all domains blocked by the 
recipient gateway, and the list of blocked domains will change over time as 
policies are modified.

These limitations of knowledge will limit our options for solutions.   I see 
four possible recipient configurations with specific implications for what the 
MLM can do.

1. Recipient system does not block based on From address
MLM options are unrestricted
2. Recipient system whitelists mailing list messages based on source server 
identity
MLM server must be reliably identifiable, typically using forward-confirmed DNS 
name.  From address is unrestricted.
3. Recipient system whitelists mailing list messages based on list identity
MLM list id must be reliably identifiable, probably using a SPF lookup on the 
List-ID or a DKIM signature with identifier specified to the list rather than 
the domain.  From address is unrestricted.
4. Recipient system blocks on From address but is unwilling to whitelist (or 
not yet configured to do so)
MLM needs to use its own Domain for the From address and for a verifiable DKIM 
signature.   Alternatively, IETF would need to provide a way to trick the 
recipient into accepting the message in violation of its configured policy, 
which it should not do.

More complicated solutions, like dual signatures, are alternatives for the 
middle of the above list, but are not needed for the first configuration and 
are excluded from the last configuration because of the "not configured" 
assumption.

Filtering on From Address is itself an instance of a larger class: defenses 
based on verified identifiers.
An identifier is useful to the spammer if the identifier might case the 
incoming gateway to allow a message that would otherwise be blocked.An 
identifier is useful to the spammer if it will be displayed to the user by the 
MUA, because then it can be used to perfect the spammer's social engineering 
attacks.
Because of these risks, SPF validation restricts unauthorized use of the RFC 
5321 Mail From, and DMARC validation limits the use of the RFC 5322 Message 
From.   Going forward, we need to look for ways to validate any identifier that 
is used for either message filtering or message display.  If we do not, we 
should expect that some non-IETF source will do so instead.

For the current issue, changing the roles of the Sender and From fields will 
not be a long term solution unless the change includes validation of both 
fields.  The change by itself will attract spammers to whatever field remains 
unvalidated.

DF


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

Re: [dmarc-ietf] What if... Sender:

[Douglas E. Foster]

Scott, Thank you!
>>I think the bar to convince me that it's okay to throw away aligning to 
>>5322.From is in scope for the working group is really
>>high when the charter defines DMARC as "Domain-based Message Authentication, 
>>Reporting & Conformance (DMARC) uses
>>existing mail authentication technologies (SPF and DKIM) to extend validation 
>>to the RFC5322.From field".

Two weeks ago, John  Levine reminded us that DMARC v1 was already deployed and 
this effort was to perfect the wording.   Suddenly, we have a small but 
powerful group insisting that we discard DMARC v1 and turn it into DMARC v2.

This discussion has reviewed the success of DMARC v1, how it has limited a 
whole category of attacks and has helped with law enforcement takedowns.But 
now John Levine wants me to prove that From alignment is important to "most of 
us", a term I used to include myself in the group that has benefited from DMARC 
v1.  Apparently historical results are not relevant.

The supporters of DMARC v2 can certainly navigate the IETF process, but I 
cannot imagine that Google and Paypal, who created DMARC v1, will jump on your 
bandwagon.  Nor can I imagine the US Government, which is requiring DMARC v1 
rollout now, will jump on the v2 bandwagon based on the evidence presented in 
this discussion so far.

I live with the knowledge that every day my mail stream is allowing through 
unwanted and potentially hostile content because the email filtering problem is 
so difficult.  I know that only one hostile message needs to penetrate to 
trigger an attack that destroys my organization.   It galls me that some of 
that criminal content comes from a billion-dollar U.S. company, which acts as  
facilitator for the crooks."From" is the one identity in those messages 
that allows me to filter the utility company mail from the bank fraud email.   
So, yes, FROM is very important to me.

I have pointed out that the mailing list problem can be largely solved with 
user-specific delivery options in the MLM, but that has so far been ignored.   
However, to support any transition to DMARC v2, MLMs will need user-specific 
delivery options to distinguish those recipients that support the new design 
from those who do not.So MLM readiness is not a small issue.

DF




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

[dmarc-ietf] (no subject)

[Douglas E. Foster]

First ler us be clear.  DMARC does not create a significant delivery problem for mailing lists.   They know how to use from rewrite, or should.  Header munging creates a MUA objection for some users, but tbe delivery problem is solvable.The MUA problem can be addressed with user options:- FromRewrite = on (as needed), off, or force.On (default) - Use From=list@listdomain,, but only when DKIM signatures have been broken by list alterations.  Otherwise use From=author@authordomsin.Off - Use From=author@authoordomain always, because DMARC policies are not enforced, or are exempted for this list, at my incoming filter.Force - Use From=list@listdomain always, to prevent messages from being blocked at my incoming filter, ased on author addtess.Since this issue is important to list users, why has this not already been done?   Why is this MLM deficiency worthy of IETFs attention?___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] What if... Sender:

[Douglas E. Foster]

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:

[Douglas E. Foster]

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:

[Douglas E. Foster]

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] Header munging: A solution proposal for alternate authentication

[Douglas E. Foster]

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] Header munging: A solution proposal for alternate authentication

[Douglas E. Foster]

I believe this document provides a path forward for solving this problem, and 
it has relatively low complexity of implementation.

Doug Foster



Current situation

Incoming mail filters options when evaluating mailing list messages:Filter 
evaluates the message as if it is a direct message from the list domainThis 
is the header munging solution that creates problems for the MUA.  This can 
also be achieved if the sender uses SRS encoding of the RFC5321 MailFrom 
address, and the incoming filter does no evaluation of the  “From” header  
address.Filter evaluates the message as if it is a direct message from the 
originator domain, ignoring the evidence that the message came from servers on 
the list domain, but accepting the message as long as it has a verifiable DKIM 
signature for the “From” header address.   This is the situation when a 
DKIM-signed message is relayed without modification.Messages may be blocked 
by the incoming filter because the list members are viewed as unfamiliar and 
therefore untrusted senders..

An ideal filtering configuration should recognize that there are three 
potential mail flows, not two.In an ideal world, all three should be 
identifiable uniquely, since the recipient organization may wish to apply 
differential policies:Direct messages from the list domain.Direct messages from 
the originator domain.Forwarded messages from the originator domain through the 
list.

As long as the mailing list applies signature-invalidating changes, Any option 
requires that the incoming filter chooses to given enhanced trust to the list 
domain.  Specific aspects of that trust:The list performs no deception.  Header 
records are relayed legitimately.The list inserts no malicious content.The list 
has reasonable controls on list enrollment.The list has reasonable controls to 
ensure that list submissions are really from the stated email address.The list 
applies its best effort to block content that the recipient systems would find 
objectionable.If objectionable content is detected, the fault should be 
attributed to the originator, not the list domain, so that list message from 
other originators will continue to be accepted.

Once trust is granted to the list, SPF and DKIM checking of the originator 
becomes relaxed:SPF and DKIM checking can be computed using relayed header 
information, because the incoming filter trusts that the headers are not 
fraudulent, orSPF and DKIM checking can be omitted, because the incoming filter 
trusts the controls applied by the list.

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

[Douglas E. Foster]

To the chairs:
It has become clear that we do not have consensus on the issue of 
content-altering mailing lists.

Despite the diversity of viewpoints the number of persons involve in the 
discussion is fairly small.
Have you identified the stakeholder groups that should be represented in the 
DMARCbis process for it to be considered sufficiently representative?
Have you made any assessment of whether all such groups are in some way 
represented in this discussion?
Do we need to do some outreach to ensure that all stakeholder groups are 
involved

Of course, adding additional voices may make the consensus problem more 
difficult.  What is your mechanism for resolving consensus problems?

Doug Foster


___
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

[Douglas E. Foster]

Dave Crocker writes:The practical problem with From: field munging by MLMs that are otherwise trying to relay a largely-unmodified messages, is that they effective destroy author information, by putting in a different email address. This is helpful for identifying the three key stakeholder needs:1) MLM's such as IETF want to alter the author's submission.  2) Authors like Hector want their submission left unmodified3) Users like Dave want accurate author information in the MUA.There is no legal corollary for "largely-unmodified".  If I use whiteout on a signed document, spill an ink bottle on hallf of the signature, or replace the special lawyer-only staples with standard staples, the document ceases to be trusted and is probably unenforcable.   The nature of the changes made by the IETF mailing list renders the reverse transformation impossible, so there is no way to validate the transformed document against the original unless the original is obtained, yet the purpose of the transformatiin is to hide the original.  A real solution has to eliminate this operation.  Hector is right.MLMs could compare a submission against their screening criteria and reject submissions rather than transforming them.   IETF wants text-only subnissions.  Why not simply require text-only?   Because we have a MUA problem:  Some MUAs, including the one I am using, do not provide an option for sending text on ly.   Fix tbe submitter MUA and you eliminate the need for MLM reauthoring.The recipient need is ironic.   We have established that the MUA's handling of From is unimportant as it has no effect on user behavior, and Dave has been forceful on this point.   But now Dave and others argue that From rewrite is a problem because it reduces the usability of the MUA.  The two positions need to be reconciled.However, the upshot of this issue is that From rewrite creates a MUA problem and it can be solved with MUA changes. I have previously reported that my 3 MUAs present the IETF header information in 3 different ways.  This is ripe for standadization, and the header rewrite objection can be addressed during that process.So we have two MUA problems.  Fixing the latter one provides a quick fix while header rewrite continues.   Fixing the former one and changing MLM behavior will take a little longer, but provides a high-integrity end result over time.IETF also applies Subject tagging, which breaks DKIM signatures.  There are altetnatives for this as well, largely involving MUA tweaks.DF___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation and controlled forwarding

[Douglas E. Foster]

If conditional signatures require the participatuon of the author's MTA, then 
the consent of the domain owner is implied.   DKIM scopes already provide a 
solution for delegating authority, but the MLM problem stems from not wanting 
to seek domain owner involvement.

Just as significantly, tbe MLM does not want to sign the same document as what 
was signed by the author.  If the document is unchanged, a conditional 
signature is not needed.  If tbe document is alrered after the first signature, 
the first signsture is not applicable to the second signature.

On Jun 20, 2020 7:13 AM, Alessandro Vesely  wrote:On Sat 
20/Jun/2020 02:52:55 +0200 John Levine wrote:
> On Fri, 19 Jun 2020, Murray S. Kucherawy wrote:
>
>> A number of drafts were floated, as I recall.  I had a couple.
>
> There's always my conditional signing hack, in which one puts a very
> weak signature on the message which says it only counts if it's
> resigned by X, where X is the expected mediator.


Conditional signatures should be paired with a mechanism that tells
the author's MTA when to apply them.  For example, a water tight
opt-in protocol whereby author, MLM, and author's MTA can do a
three-hand handshake.  Without that, we're back to depending on
reputation, for which simple whitelisting suffices.


Best
Ale
--


























___
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] Mediation (was: Re: Header munging, not ARC, can solve the mailing list problem)

[Douglas E. Foster]

Why is the state of the message-id important?   You have mentioned it twice.It is not a required header.  It often uses a domain portion that is not a registered name.   The recipient has no way to know whether or not it has been changed during forwarding.  I have tried to imagine a way to use message-id in message evaluation, but have given up.___
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

[Douglas E. Foster]

Pete;you have not explained how my inbox filter recignizes a legitimate 
forward of a legitimate message instead of an illegitimate forward or a 
fraudulently manufactured Received-header sequence.

We only have this problem 
with lists that alter the original to destroy DKIM validity.   When this is 
done, the list becomes the author snd the headers should reflect as much.

The referenced spam analysis article notes that infequently seen message 
sources are high probability spam.   If the list postings are from many 
individuals instead of one IETF address, the likelihood of blocked posts is 
significant.  Thus should ne a concern whether DJIM is preserved or not.

On Jun 19, 2020 12:46 PM, Pete Resnick  wrote:On 19 
Jun 2020, at 11:40, Pete Resnick wrote:

> The presumption of all Mediator-type transactions was that the 
> receiving email client was to deal with the message (the thing with 
> the identical Message-ID) with its original semantics, adding only 
> Resent-*: or List-*: fields to add the semantic of the mediation 
> event.

That sentence got munged due to cuts and pastes that didn't all add up. 
It should read:

"The presumption of all Mediator-type transactions was that the 
receiving email client was to deal with the message (the thing with the 
identical Message-ID) with its original semantics, with the sender 
adding only Resent-*: or List-*: fields to add the semantic of the 
mediation event."


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


___
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

[Douglas E. Foster]

DMARC helps establish a verified identity.  Delivery is based on 
reputation.  The two are very different. 

Unwanted mail with DMARC validation will be blocked on the same basis is 
unwanted mail without it.

But a verified identity is helpful for ensuring that wanted mail is not 
blocked.

There is no vulnerability created by DMARC.

On Jun 19, 2020 1:17 AM, Jim Fenton  wrote:On 
6/18/20 7:35 PM, Dave Crocker wrote:
> On 6/18/2020 4:01 PM, Jim Fenton wrote:
>> It would be remarkable for IETF to achieve rough consensus on a
>> specification with a known vulnerability while we "wait for the bad
>> actors to catch on." Particularly when that vulnerability relates to an
>> aspect of the specification that has caused widespread deployment
>> problems.
>
> vulnerability?

Yes. When bad actors (your choice of words) can work around an aspect of
the specification that is depended upon to enable differential handling
by a receiving filtering engine (again your choice of words), that is a
vulnerability.


___
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] Header munging, not ARC, can solve the mailing list problem

[Douglas E. Foster]

There are some basic principles that need to be considered:.

DMARC did not break mailing list privileges, unwanted mail did.

A fully legitimate message has these characteristics:
Intended by the originatorAcceptable to the policies of the domain owner, which 
are partially implemented in its outbound mail filterDesired by the 
recipientAcceptable to the recipient domain owner, as partially implemented in 
its inbound mail filter.
One example of a message that is not acceptable to the originator is a message 
spoofed by an authorized server.   This is one of the problems addressed by 
DMARC.

More specifically, what characteristics make a message acceptable to the 
recipient:
A recognized / trusted senderA message which looks like previous-good messagesA 
message with no identifiable risk factors.
To elaborate, incoming mail filters separate mail into three buckets:
Probably unwantedUnknown and hopefully harmlessDefinitely wanted

The administrators of the incoming mail filter will be continually seeking to 
move traffic from bucket 2 to bucket 1 or bucket 3, so a strategy based on 
bucket 2 is not guaranteed to work indefinitely.

>From the viewpoint of the inbound mail filter, forwarded mail is 
>indistinguishable from spoofed mail using an open relay.   In a world where 
>all mail was wanted mail, mailing lists could do what they want.  But we are 
>not on Arpanet anymore, and unwanted mail is a huge problem.

If a mailing list is violating DMARC, it is likely to be put in bucket 1.   
Once one message ends up in bucket 1, all messages from that source are likely 
to be blocked as well.

For a sender to be promoted from bucket 1 to bucket 2, messages need to 
distinguish themselves from untrusted email.   Preserving DKIM signatures is 
one way of doing so.  Header munging is another way of doing so.

To move into bucket 3, the forwarder needs to obtain a sponsor to negotiate 
with the recipient organization's email security team..

For two messages from the same forwarder to land in the same bucket, both 
messages must have similar qualifying characteristics.

An Example

Consider the risk profile of a request to auto-forward from UserA@DomainA to 
UserB@DomainB

This request could reflect a range of behaviors from low risk to high risk.
UserB actually wants the forward to occur.UserB is the accidental victim of a 
typing error.UserA is going to be used as a proxy to attack UserB.Forwarding to 
UserB is contrary to DomainA policy because it is likely to permit violation of 
DomainA's regulatory obligations under GDPR, PCI DSS, HIPPA, Sarbanes-Oxley or 
something else.Forwarding to UserB is in conflict with DomainB policy for 
whatever reason.UserA is an inside attacker seeking to exfiltrate data to an 
external accomplice.
So both DomainA and DomainB administration have reasons to be involved in this 
request.   Even for legitimate requests, DomainA does not want to forward 
traffic to DomainB if it is unwanted, since unwanted mail may impact the 
reputation of DomainA, and likely cause unwanted blacklisting of other messages.

Therefore, the wisest procedure is as follows:
DomainA detects the forward request and begins an approval workflow.DomainA 
reviews the request to see if they are willing to grant internal 
approval.Postmaster@DiomainA contacts UsersB@DomainB asking them to submit the 
request to their email security team for approval.Administrators for DomainA 
and DomainB communicate to discuss the administrative controls at DomainA as 
well as the fingerprint characteristics of the incoming mail.Upon approval, 
DomainB administration gives DomainA administration permission to proceed.  
DomainA activates the forwarding and notifies the user.DomainA monitors the 
outbound mailstream for deliverability and terminates the forwarding if 
repeated failures occur, or upon request from DomainB administration or 
UserB@DomainB.
I suspect most mailing systems would need a lot of new code to implement a 
workflow like this, but my perspective is limited and may be wrong.

The mailing list scenario is not much different, except that the request 
process begins when UserB@DomainB attempts to subscribe to the mailing list, 
and the approval process involves both the handling of messages coming from the 
list as well as messages going to the list.

The process may be limited by the features of the DomainB email filter.   
Without header munging, fingerprinting the mailing list will require combining 
the list headers with forward confirmed host names, or something along those 
lines.Low-end email filters may be unable to filter on list name, or filter 
on multiple attributes together.

Getting prior approval will be a lot of work, and i wonder how many lists will 
be willing to try. In the absence of prior approval, I see no solution 
better than header munging.   Header munging is an inferior solution because 
neither sender policies nor receiver policies are evaluated or respected, but 
it is 

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Douglas E. Foster]

Other uses of indirect mail:

My university offered an alumni account implemented as a relay to whatever 
hosting service I was using at the moment.   Never took them up on it, and glad 
that I did not.   Perhaps RFC 7960 talked about that scenario, because I think 
I have seen it mentioned in an IETF document.

Header munging vs Alternatives:

Header munging vs.  Perfect author attribution

I have been considering an alternative world where header munging is eliminated 
because author content is not modified and therefore author identified is fully 
verifiable using DKIM and DMARC.   Several concerns come to mind:

We do a fair amount of geographic filtering, so some of the postings to this 
list would be blocked, because of coming from countries where we do not do 
business.  Header munging provides a single point of origin; if one message is 
allowed through the geographic filters, then all messages will be allowed 
through.   If an exception is needed, the list member and system manager can be 
confident that only a single exception is necessary.

One of the reasons that IETF breaks DKIM is because it converts everything to a 
plain text.   This is a significant security benefit, by lowering the threat 
potential of the message.  It makes the IETF messages more trustworthy than if 
they came to me directly from the author.   Other mailing lists may use other 
criteria, but they should all use some sort of filtering to protect their 
reputation and their members.  Header munging allows me to distinguish between 
IETF-filtered traffic and other traffic.

As an extension of that point, successful sender authentication establishes 
identity, but it does not establish trust.   Trust is assigned by the 
recipient, largely based on experience, so message from unrecognized senders is 
given a low trust level by default.I know how to trust IETF.   I do not 
know whether to trust the next random person who contributes to this mailing 
list.

ARC assumes that after a user subscribes to a mailing list, he negotiates with 
his I.T. staff to have the mailing list operator authorized.   I expect this to 
be problematic for many users.
To mitigate these concerns, the non-munging solution would presume that 
recipient systems have the ability to filter differently between ( unknown 
sender + known mailing list ) and ( unknown sender without mailing list ).
To prevent spoofing of the mailing list, list identity would need to be 
verified as well as author identity.   As we add complexity to the inbound mail 
process design, some extra processing logic is applied to all messages, not 
just the mailing list messages.   How many filtering solutions will be unable 
or unwilling to add this complexity?

Others have already noted that the mailing list operator must choose a 
configuration without knowledge of what capabilities will exist in the 
receiving system message filter.   This seems to limit the range of possible 
solutions.

Given all of that, I think a non-munging solution would be more problematic for 
me than what IETF is already doing.

DF


___
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

[Douglas E. Foster]

The "mailing list problem" was introduced into this discussion as an objection 
to DMARCs progresss, by implication suggesting that DMARC must be delayed until 
a solution is found which creates no inconvenience to mailing list operators.

That concerns me, First, a a new solution has not really been proposed; all of 
the discussed options are already available to mailing list operators.  
Secondly, articulating a required mailing list operational mechanism is 
unlikely to produce rapid or uniform adoption.   The supposed problem is not 
big enough to warrant that much control over this initiative.




___
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

[Douglas E. Foster]

About this comment

 If you teach users that "Joe User by Random Intermediary" is the same 
as "Joe User", this expectation is doomed.

Based on the response to my previous post, "Trained User" is not a meaningful 
concept, for purposes of this discussion.   However, a user who subscribes to a 
mailing list should be able to recognize its distinctive message 
characteristics, so I think training is not a significant issue.   I have had 
fun looking at the different ways that IETF mailing list entries are presented 
in my different MUAs.

More to the point:

I suggest that the "Mailing List Problem" is a problem that does not need to be 
solved (and evidence suggests that it cannot be solved.)   I can think of no 
purpose served by a public mailing list, like this one, which is not be better 
solved by a community forum website with user login.   Even in its heyday, I 
think mailing list subscribers were a narrow subset of email users, heavily 
skewed toward Unix-oriented technology people.   Solving the mailing list 
problem seems like saying, "I want a secure and reliable way to order my 
Walmart groceries using the text feature of my flip-phone."  It is time for a 
different technology.

There are other indirect mail scenarios that are problematic, but these seem 
well understood and I do not see that any improvement is available.   These 
include:
DKIM (configured at the sender), SRS Encoding (configured at the forwarder), 
and Trusted forwarder registration or another exception mechanism (configured 
at the recipient filter).Incoming email filters have inadequacies when 
looking backward on a forwarded message, but this mailing list is not concerned 
with specifying the desired features of incoming mail filters.
DF


From: devel2...@baptiste-carvello.net
Sent: 6/13/20 8:04 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list 
problem
Hi,

I'm but a mere user, but I cannot let this be presented as an obvious or
consensual solution. Header munging is inadequate because:

1) It makes the wrong tradeoffs. DMARC started as a solution for a very
specific problem (phishing targetting high impact domains) and made
tradeoffs accordingly. Now that it is deployed as a general anti-spam
tool, the appropriate tradeoffs are different: most users are willing to
live with some degree of spam rather than have their communication
tampered with and their name associated with random intermediaries.
"Fait accompli" is not acceptable, even if you call it "de-facto standard".

2) It buys you nothing. As was discussed last week, DMARC by design
relies on the expectation that users (or their MUA's adress book) will
recognize legitimate From addresses. If you teach users that "Joe User
by Random Intermediary" is the same as "Joe User", this expectation is
doomed.

Cheers,
Baptiste

Le 12/06/2020 à 10:02, Alessandro Vesely a écrit :
> Hi all,
> I'm sorry I didn't queue to talk yesterday. After so many months without
> speaking one word of English, I really didn't feel like...
>
>
> *Why ARC cannot solve the mailing list problem*
> ===
>
> Assume all mailing lists in the world duly did ARC. Somewhat
> science-fictitious, given that some of them are not even able to add valid 
> DKIM
> signatures. Let's hypothesize they all did ARC, anyway. Would the mailing
> list problem be solved? No, because recipients cannot blindly accept DMARC
> failures just because there is an ARC-chain claiming authenticity. Doing so
> would completely defeat DMARC, because ARC chains can be forged.
>
> In order to safely override a reject or quarantine policy based on ARC, a
> receiver needs a complete list of legitimate mailing lists. Conversely, having
> such a list, a receiver can override DMARC failures also based on DKIM or SPF
> authentication. ARC adds nothing to the mailing list problem. (However, huge
> mailbox providers do have a complete list of legitimate MTAs. That's where ARC
> is useful, AIUI.)
>
>
> *From rewriting is the real thing*
> ==
>
> Rewriting From: is the de-facto standard. In a (science-fictitious) scenario
> where all mailing lists rewrite the From: header field, DMARC would just work
> smoothly.
>
> Hence, we have to specify an acceptable way to rewrite From:.
>
>
> I'd have said so.
>
> Best
> Ale
>

___
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] About user notification in the MUA

[Douglas E. Foster]

Stan Kalisch asks:  And you propose the average user can understand, much less 
take the time to understand, the substance?

Yes.   I believe users are worried about spam, and want to make intelligent 
decisions about whether or not email can be trusted.  Unfortunately, our 
present software denies them access to the available information needed to make 
intelligent decisions.

Dave Crocker observes:   There is no basis for believing that requests 
about MUA display will achieve meaningful support on the receive side, 
nevermind whether they would be at all useful.

I was not talking about the sender.   I was talking entirely about the 
receiving organization:its spam filter communicating to its MUA to 
communicate information to the end user based on its local policy.

Dave Crocker also observes about end-user signaling failures:   It's not 
that it 'seems to be'. It isn't nearly that soft.  It is that there have been 
multiple efforts over the years and none has demonstrated efficacy.

Then lets restate that assertion in all its ugly elitism, and put it into 
an RFC:

Incontrovertible research shows that humans will always act on malicious email, 
and cannot be taught to do otherwise.   Organizations should deploy email if 
and only if they have automated tools which provide perfect protection from 
unwanted email. End user training is useless.

I have a higher opinion about my users than that.


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

Re: [dmarc-ietf] About user notification in the MUA

[Douglas E. Foster]

I am trying to play by the rules and not chase topics outside the one assigned, 
but since several have jumped on my comment, I will follow up briefly.

Dave Crocker wrote
Since there has been a demonstrated lack of efficacy in this sort of display, 
there needs to be an objective basis for knowing that any new such requirement 
will be useful.

Every email filtering product that I have examined has provided a 
user-signaling system, using one or more of the following:
tagging the subject, adding text as a body header or body footerconverting the 
suspect message into an attachment of  a replacement message,soft-quarantining, 
where the user has unrestricted control to release the message from quarantine.
Given that market reality, I conclude that most vendors and their customers 
believe that user-signalling is useful.   The signalling system does not have 
to prevent every mistake for the signal to be useful.

The problem with all current notification methods is that they are relatively 
primitive, often communicating nothing substantive about the suspicious message 
characteristics.  They also work against other security mechanisms.
Any form of tagging breaks DKIM signatures, reducing the credibility of the 
message if it is auto-forwarded for any reason.

The tagging also becomes tattooed to the message and its replies, rather than 
being restricted to the trust domain that assigned the tag.   One example 
should suffice:  a message was tagged with [SPAM?] because the sender had an 
error in his SPF record and I was trying to enforce SPF.   Then when my staff 
replied, the originator treated the reply as spam because the word SPAM was 
still in the subject line when he received it!
We need a user notification mechanism that is local to the trust domain and 
does not break DKIM signatures.  You have already done the heavy lifting for 
this interoperability problem with Authentication-Results and ARC   I am not 
expecting a "Standard" that requires every implementation to notify every user 
in the same way.   I am looking for a guidance document that helps vendors to 
deliver products which permit an organization to implement a notification 
policy which they find to be effective and appropriate.   IETF is the right 
organization to take this on because the email filter, the mail system, and the 
multiple MUAs are almost always a multi-vendor configuration.

df


___
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

[Douglas E. Foster]

1) The original assertion, that DMARC creates a conflict with prior 
specifications, appears to be undefended and incorrect.   For From Addressing, 
It merely establishes some boundaries that the sender and the recipient choose 
to consider appropriate.For DKIM, it creates a use-case for a technology 
that was initially defined without any use cases.Consequently, I think this 
topic is ready for closure.

2) Some of the discussion appeared to resolve around the assertion that DMARC 
can have no value.   Since that view is not universal, I think the project can 
continue with those who do believe that it adds value.

3) Some of the discussion has been about how to prevent soclal engineering of 
the recipient user.  This is an important topic, but not directly related to 
the project.  IETF would do well to establish some recommendations about how 
MUAs should behave, so that trust data can be displayed to the user.   A 
typical user will have access to at least three different email clients: one on 
his cell phone, a product-specific web page, and a desktop product like Outlook 
or Thunderbird.If I wanted an organization policy that controlled when 
Friendly Name was displayed or DMARC status was displayed, I would have to find 
and distribute plug-ins to all of these products.   As best as I have been able 
to tell, no such plug-ins even exist for Outlook and the other products do not 
accept extensions.   There is an opportunity here for valuable standardization.


From: Alessandro Vesely 
Sent: 6/7/20 6:19 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of 
the From and Sender header fields
On Sun 07/Jun/2020 00:03:28 +0200 Jim Fenton wrote:
> On 6/6/20 2:42 PM, Scott Kitterman wrote:
>> On Saturday, June 6, 2020 5:26:08 PM EDT Dave Crocker wrote:
>>> On 6/6/2020 2:23 PM, Scott Kitterman wrote:
 If things like DMARC, SPF, and DKIM do nothing more than get abusers
 to use different domains than they would otherwise, I think that's a
 win.>>> The issue here is DMARC, not SPF or DKIM, since DMARC is the only 
 one of
>>> the 3 that restricts the choice of domain name.
>>>
>>> With that in mind, I'll ask you why you think the kind of change you
>>> cite is a win.
>> 1. I think the domain displayed to the end user matters. In my sample size
>> of 1, it matters to me. I know I'm not the average user, but independent of
>> the question of how many users it matters to, there are some.
> Same with me, but again I'm not the average user.

+1, but then we're mailing list subscribers (leaving aside this list's topic.)

>>
>> 2. When abusers use different domains to send mail, it adds more information
>> for filters to work on, so even if this is all about filtering, that works
>> better too.
>
> But when abusers use different domains, the DMARC policy that applies is
> controlled by them and is therefore meaningless. And the reports, if any
> (probably none), are sent back to the attacker or their designate.
>
> Filtering might be done based on the DKIM signing domain or thesimilar
> envelope-from domain if SPF is used, but neither of those require DMARC.

The From: domain was chosen because that's the field that users can see. Now
we conjecture that users don't actually see it. Oh boy. Certainly, if the
From: domain is not visible we could filter on X-Filter-On-Me: and gracefully
avoid the mailing list problem.

On closer view, we seem to be discovering that the From: domain is obscured by
the display name. We always neglected the display name. Furthermore, by
letting the mailing list problem be dodged by creative From: rewriting, such as

From: u...@example.com 

we are granting full citizenship to devious display names. Some clients (e.g.
Thunderbird) can show only display name for people in the address book.[*] A
close, perhaps formally easier, subject is the IDN homograph attack.[†]

Would it make sense to ban, say, the use of the at sign (@) in display names?

Best
Ale
--

[*]
https://support.mozilla.org/en-US/kb/names-bug-no-email-addresses-are-displayed

[†] https://en.wikipedia.org/wiki/IDN_homograph_attack

___
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] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D

[Douglas E. Foster]

MAILING LISTS.

The mailing list problem can be stated as follows:
Domain B wants to operate a mailing list.The list owner will accept messages 
from domain A, alter them, then re-transmit the altered message to member 
C.List owner B wants the mail filter for member C to guarantee that his list 
messages are granted the same trust level as a message sent directly from A to 
C without alteration.
This problem is unsolvable because it is unreasonable.   The options for 
creating trust in indirect mail have been discussed in another RFC.   Applied 
to this issue, the options are:

1) Make List B the originator by changing the RFC 5321 sender address as well 
as the RFC 5322 Message From.   Ideally add a DKIM signature for B, in case the 
message is forwarded downstream.   This is the IETF list behavior and the only 
one that is feasible in practice.
..
2) Require all submitting domains to make List B a trusted sender for their 
domain by including B in their SPF record

3) Configure the list to make no changes, then require all senders to include 
DKIM signatures for their own domain.

4) Require all recipient systems to make special policy accommodations to grant 
trust to messages from List B, simply because it comes from List B.   This is 
feasible, but specific to each participants incoming email filter.

DKIM and IDENTIFIERS

A large portion of legitimate mail is generated by third parties acting as 
agents.   The problem being addressed by SPF / DKIM / DMARC is:
"How can a sender provide information so that a recipient can distinguish 
between an authorized agent and an unauthorized identity thief?"

A subset of this issue is "How do we expect recipient systems to behave?"
This is a rather important detail which this group has explicitly chosen to not 
pursue.   But I can provide these observations based on experience with mail 
filtering:
To avoid false positives on desired messages, messages from some senders must 
be given some filtering exceptions.   For those exceptions to be applied 
safely, the sender must be verified to a degree acceptable to the recipient.  
Depending on the situation, there are multiple ways that a sender can be 
identified.   These include, but are not limited to, SPF, DKIM, and DMARC..  In 
the general case, SPF, DKIM, and DMARC simplify this problem for the recipient.

Although SPF, DKIM, and DMARC are often assumed to be tools for discarding 
fraudulent messages, this is extraordinarily difficult to implement in 
practice.   Too many senders have errors in their SPF / DKIM / DMARC 
configurations, and too many legitimate senders do things that violate a domain 
owner's SPF / DKIM / DMARC policies.   Policy failure has not proven to be a 
reliable indicator of unwanted content.

Without DMARC, SPF and DKIM configuration errors persist because the sender 
obtains no feedback about those errors.  DMARC fixes the feedback problem.
I still do not understand how DMARC does anything other than enhance prior work 
on SPF and DKIM, or how there is any conflict with prior standards.

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 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.ietf.org failed dmarc

[Douglas E. Foster]

I understand your question to be "Why do I see invalid DKIM signatures on 
messages from the IETF mailing list?"  I can provide your answer

The typical message on this mailing list has three signatures:

Signature Analysis:
The first signature is from the submitter's organization.   In your message, it 
was from junc.eu.

The second signature is applied by IETF shortly after receipt of the message.

IETF adds an Athentication-Results header which indicates that the junc.eu 
signature was valid when they checked it
..Then, IETF changes the FROM address to be @dmarc.ietf.org and tags the 
Subject with [dmarc-ietf].   This breaks both of the first two signatures.

Then, IETF applies a second signature which is verifiable.

Integrity Analysis:
The IETF rule is "an unverified signature is the same as no signature."  
Therefore, the invalid signatures can and should be ignored.  It appears that 
your tool is getting confused by the invalid IETF signature and ignoring the 
valid one.

The message passes SPF because the Sender Address has been changed to 
dmarc-boun...@ietf.org.

The second passes DKIM because the second IETF signature verifies.

No official assertion is been made about the sender's domain, so there is no 
need to verify against that domain.   But if you want to do so, you can 
evaluate whether to place trust in the Authentication-Results header applied by 
IETF.

IETF converts all messages to plain text, and strips or blocks attachments, so 
they have minimized the opportunity for malicious submission.
Implications for Email Defenses:

This example is a reminder that every message is a take-it-or-leave-it 
proposition.   You can accept the message or reject it, based on the message 
characteristics, but you will probably be unable to cannot change the sender's 
behavior.   In this situation, you may not like having two signatures from 
IETF, but you cannot change IETF.As a result, any spam filter needs to be 
very flexible about exceptions.   Too many spam filters do not have adequate 
exception mechanisms.

Hope this helps,

Doug Foster


From: me=40junc...@dmarc.ietf.org
Sent: 5/16/20 7:58 AM
To: dmarc@ietf.org
Subject: [dmarc-ietf] dmarc.ietf.org failed dmarc
https://dmarcian.com/domain-checker/ test it there

if not taking ownerships it will get dmarc pass

oh well software testers needs cases to test on its one here then

if its complete impossible to not break dkim i will leave this maillist

___
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] Summary comments on draft-ietf-dmarc-psd

[Douglas E. Foster]

Dave raises some interesting points.

For my part, I am troubled by issues that are created by the DMARC 
specification itself.The fallback rule says we jump directly from the 
domain name to the organization name, which creates the need for a special list 
to know how to find the organization.   As I think you have discussed, there is 
no fully acceptable mechanism for publishing the list and keeping 
implementations of the list current.

If the fallback rule simply told implementations to walk up the domain tree 
until a policy was found, the need for a special list would go away.

The other need for organization knowledge is the domain alignment rule which 
allows for sibling relationships between the signing domain and the From 
domain.   From a technical standpoint, this is unfortunate becomes it 
complicates implementations with the need to determine the organization.

>From the viewpoint of a receiving system, it is not obvious to me why I should 
>assume that division1.divisonA.example.com should be accepted as having 
>administrative authority to send messages on behalf of divisionB.example.com.  
>This is an administrative control issue for the sending organization, and the 
>whole point of DMARC was to help sending organizations improve their 
>administrative control over email.  However, it is a trust issue for the 
>receiving organization, and I have no desire to assume every 
>DMARC-participating organization has perfect administrative control.

But I suppose the DMARC train has left the station, even if the deployment 
process has been slow.

Doug Foster


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

Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working GroupLast Call: draft-ietf-dmarc-psd

[Douglas E. Foster]

About this paragraph:
  
 >> The original pre-standardization version of this protocol included a
  >> mandatory check of this nature. It was ultimately removed, as the
>> method's error rate was too high without substantial manual tuning
>> and heuristic work. There are indeed use cases this work needs to
>> address where such a method would return a negative result about a
>> domain for which reporting is desired, such as a registered domain
>> name that never sends legitimate mail and thus has none of these
>> records present in the DNS.
  
  This section seems to give a free pass to senders who use non-existent 
domains, as if such behavior had no impact on the risk posture of the 
recipient. 
 It seems to say, "You can keep doing this, because so is everyone else."
  
 I would think better language would be along the following lines:

  

 "Senders SHOULD register all domains in DNS, as MTA operators MAY block 
messages that appear to come from non-existent domains.
 Developers of MTA filtering software SHOULD provide MTA operators with the 
ability to block non-existent domains.
 If such ability is provided, the MTA filtering system MUST provide a 
mechanism for overriding the filter rule for messages that are acceptable 
to the recipient organization."
  
 In short, the evaluation of whether manual tuning is worthwhile should be 
left to the discretion of the MTA operator, based on his organization's 
risk tolerance and message characteristics.
  
  

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

Re: [dmarc-ietf] Endless Loops with DKIM reports

[Douglas E. Foster]

Suggestions for eliminating loops:
  
 Best (sender controlled)
 The report-sending account should be from a non-reportable domain or 
subdomain.   Authority to report on behalf of another domain/sub-domain can 
be established with a DKIM signature of the reporting domain.   Of course, 
if the report-sending domain is a subdomain of a reportable domain, the 
sub-domain needs its own DMARC policy to disable inheritance and to disable 
reporting.
  
 The report-sending account could be placed in a domain/sub-domain which is 
send-only (SPF policy but no MX records).   This prevents out-of-office 
messages, NDRs, or spam from being sent to the report-sending account. 
  
 A null sender would be one way of producing this result, but it may be 
difficult to implement in some configurations.   Additionally, messages 
from the null sender are more likely to be rejected by BATV filtering.
  
 Alternate (sender controlled)
  If the report-sending account is in a domain/sub-domain that collects 
feedback, messages sent to the report-sending account must be excluded from 
feedback data collection.
  

  
 Backup (recipient controlled)
 Option 1:  The recipient account should be in a domain/subdomain that does 
not collect DMARC feedback.
 Option 2:  If the recipient account domain does collect feedback data, the 
recipient account must be excluded from feedback data collection.
  
 Since the sender cannot know whether the recipient domain collects DMARC 
feedback, he should not rely on the sender being able to prevent looping.
  
 I think these methods will eliminate the need for rate limiting.
  
 Doug Foster
  
  


 From: "Dave Crocker" 
Sent: Thursday, June 6, 2019 4:28 AM
To: "John R Levine" , dmarc@ietf.org
Subject: Re: [dmarc-ietf] Endless Loops with DKIM reports   
On 6/6/2019 10:08 AM, John R Levine wrote:
> If people follow the spec there will be fewer loops, but it won't reduce
> the number to zero.

Forgive me, but I believe there is currently no spec to follow. Yet. I
took this thread as raising the issue that there needs to be an effort
that specifies how to avoid dmarc report loops.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

Re: [dmarc-ietf] Mandatory Sender Authentication

[Douglas E. Foster]

>> 1. By 'sender', which actor in the sequence do you mean? The term is
highly ambiguous.
  
 By Sender Authentication, I mean message "From Address" authentication.   
This involves two rules:
The sending IP address is known to be authorized to send for the SMTP 
Sender-Address because of MX or SPF, andthe SMTP Sender-Address is 
known 
to be authorized to send for the message from Address because of either 
 
domain alignment or a verifiable DKIM signature for 
the domain of the 
message From-Address.   

 The message From-Address is what the user sees, so it seems important to 
know that the user is not being deceived by an impersonator.

>> 2. Your certitude presumes an empirical foundation, given how often 
good
theory does not make good practice. People have been working in this
space for a very long time and one might have expected the industry to
have latched on such a simple requirement were it that clear it was
/the/ essential requirement. Please document the basis for your certitude.
  
 What I actually intend is that "a recipient has a viable option to 
implement mandatory sender authentication."
 This i equivalent to enforcing basic DMARC rules whether the sender has a 
DMARC policy or not.   This requires:
An email filter that understands SPF, DKIM, and DMARC.  An email filter 
that provides local policy options to detect, evaluate, and override false 
positives.  A sufficiently low level of false positives that the recipient 
organization is willing to commit the administrative resources to 
investigating and correcting false positives. 
 These conditions are sorely lacking, as explained in the next section.

>> 3. What made you think that 'sender' authentication is not already
happening at a sufficient level? What is the basis for believing it
 isn't already being used by filtering agents well enough?
  
 I have been doing a market survey, and it suggests that many vendors do 
not understand the problem or do not believe it needs to be solved.  I 
began with these minimal screening requirements:
  
 Source filtering:
Able to block based on both IP address and Reverse DNS. 
  
 A surprising number of vendors only supported one of these filters.
  
 Sender authentication:
Able to enforce sender DMARC policies.   (No requirement to support 
feedback processing)
Able to override an incorrect SPF policy using a multi-factor rule 
(source server + sender domain).
  
 A surprising number of devices that supported DMARC filtering could not do 
ReverseDNS filtering.
  
 More recently, I realized that the only effective way to correct an SPF 
policy is to use SPF syntax.   I have not yet seen any product that does 
so, but I have more products to review.
  
 For the first pass, I had no filtering criteria related to content 
filtering.
  
 Results
 --
 These vendors could not meet all four criteria:
Barracuda (appliance, hybrid, and cloud products)   Sophos (3 
appliance 
products, 2 cloud products) EdgewaveForcepoint  Fortinet
Trend Micro 
Dell SonicWall  SymantecSpamExperts / SonicWall Mail 
 Some of these were evaluated based on reviews of the administrative 
manuals, others based on a sales process.
  
 On the higher-end solutions:
  
 I discounted Cisco Talos and Proofpoint because their secure email 
solutions do domain spoofing.
  
 BAE Solutions was dropped because their sales process required me to sign 
a non-disclosure agreement.   Based on what we did discuss, it did not 
appear that they could meet the four requirements.
  
 Kaspersky was ignored because of mistrust of the Russian government.
  
 The following products appeared to meet the minimum requirements, but for 
most of them I do not have access to the administrator manual until I 
commit to a product trial.
Cloudswift  MimecastFortinetFireEye 
 I am in early discussions with AT / MessageLabs, but have no asssessment 
yet.
  
  
 >> 4. Consider the limitations to 'sender' authentication.

I am spending a lot of time thinking about the limitations of sender 
authentication.   For a spammer domain, SPF / DKIM / DMARC are easy.   For 
impersonation, Friendly Name and embedded logo images can be pretty 
effective without violating SPF / DKIM / DMARC.
  
 This means that Sender Authentication may produce more false positives 
than true positives.   Given the labor cost of addressing the mistakes, it 
is an open question whether the effort is worthwhile.   For the moment, I 
am hoping so.  I manage two very different mail streams, and the one that 
has higher spam levels appears to benefit from enforcing SPF and DMARC.  
Neither environment has products with adequate tools for implementing SPF 
exceptions, so I do not know how long I can leave the features enabled.   
Since you are involved in the Sender Authentication standards process, I 
assume you agree that 

Re: [dmarc-ietf] Mandatory Sender Authentication

[Douglas E. Foster]

 Original message From: "Douglas E. Foster" 
 Date: 6/3/19  9:59 AM  (GMT-05:00) To: 
dmarc@ietf.org Subject: [dmarc-ietf] Mandatory Sender Authentication Our real 
goal needs to be mandatory sender authentication.    Any secure email gateway 
must go through these steps:


Source Analysis:  Filter message from unwanted sources
Sender Authentication:  Filter messages that are attempting 
impersonation
Content Analysis:  Filter messages with unwanted content


Content filtering always requires exceptions, and those exceptions are granted 
based on the sender.   Such exceptions are only safe and appropriate if the 
sender is verifiable.    If the exception is applied to an unverified sender, 
it is possible for a spamming impersonator to gain the elevated trust and 
reduced filtering which was only intended for the trusted sender.

 

So Sender Authentication needs to become mandatory:


Senders MUST implement SPF or DKIM,  and SHOULD implement both.  
Although the MX list becomes a default SPF list for those who do not publiish a 
policy.
MTAs MUST ensure that DKIM signatures remain verifiable.  If they are 
unwilling or uinable to do so, they should reject the message with a PermError.
Forwarders MUST either forward with breaking DKIM signatures, rewrite 
messages under their own identity, refuse the message, or discard the message 
as spam.
IETF MUST provide a way for intermediate systems (both spam filters and 
list fowarders) to insert content under their own signature, without breaking 
original signatures.    This will have implications for MUAs..


Sure it will be hard, but has this not been what you have been trying to 
achieve for 15 years?  SPF and DKIM provided the enabling technology, but they 
were deployed as sender options.

 

Doug Foster

 

 

 

 

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

[dmarc-ietf] Mandatory Sender Authentication

[Douglas E. Foster]

Our real goal needs to be mandatory sender authentication.Any secure 
email gateway must go through these steps:
Source Analysis:  Filter message from unwanted sources  Sender 
Authentication:  Filter messages that are attempting impersonation  Content 
Analysis:  Filter messages with unwanted content 
 Content filtering always requires exceptions, and those exceptions are 
granted based on the sender.   Such exceptions are only safe and 
appropriate if the sender is verifiable.If the exception is applied to 
an unverified sender, it is possible for a spamming impersonator to gain 
the elevated trust and reduced filtering which was only intended for the 
trusted sender.
  
 So Sender Authentication needs to become mandatory:
Senders MUST implement SPF or DKIM,  and SHOULD implement both.  
Although the MX list becomes a default SPF list for those who do not 
publiish a policy.  MTAs MUST ensure that DKIM signatures remain 
verifiable.  If they are unwilling or uinable to do so, they should reject 
the message with a PermError.   Forwarders MUST either forward with breaking 
DKIM signatures, rewrite messages under their own identity, refuse the 
message, or discard the message as spam.IETF MUST provide a way for 
intermediate systems (both spam filters and list fowarders) to insert 
content under their own signature, without breaking original signatures.
This will have implications for MUAs. 
 Sure it will be hard, but has this not been what you have been trying to 
achieve for 15 years?  SPF and DKIM provided the enabling technology, but 
they were deployed as sender options.
  
 Doug Foster
  
  
  
  
  

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

Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion

[Douglas E. Foster]

 Thank you for the education The IETF list processor seems to be an 
illustration of your point.
It invalidates the orginal sender's signature   Then it adds an 
ietf.org 
signature   Then the message is relayed internally within a single IETF 
server, where the IETF signature is invalidated.The the message is 
signed 
a second time with an valid IETF signature 
 I rather hoped that IETF would be the poster-boy for list processing done 
correctly.  Why is the message manipulation that you describe necessary or 
acceptable?
  
 Deeply puzzled,
  
 Doug Foster

  
  
  


 From: "John R Levine" 
Sent: Thursday, May 30, 2019 5:19 PM
To: "Murray S. Kucherawy" 
Cc: "IETF DMARC WG" 
Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- 
suggestion   
> And as John said, there have been numerous proposals over the years of 
ways
> to annotate a message with what "standard" mutations were done so that 
at
> verification time the receiver could decide which mutations it was 
willing
> to forgive, but the community showed no interest in such complexities.

It is my impression that the proponents of this idea tended not to be very
familiar with mailing list software and imagined that most mutations were
simple, like adding a subject tag or a text footer. Those happen, but
they are the very tip of the iceberg. Modern list managers add, delete,
and reorder MIME parts, flatten HTML into text, and a huge list of other
things that no mutuation catalog could plausibly describe.

That's one of the reasons that ARC doesn't try to say what's changed, just
what the authentication results were before and after.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
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