Subject: [dmarc-ietf] p=quarantine

From: Michael Thomas <[email-masked]>
Date: Tue, 8 Dec 2020 09:41:48 -0800

If you take the literal meaning of quarantine, that means that every 
piece of email from this and every other mailing list would end up in a 
quarantine folder, or some such. I'm fairly certain that is not what 
people want, and I'm doubtful that many receivers implement that. The 
question to my mind is whether there actually exists a state between "we 
don't know" and "trash it because it's not from us". "Quarantine" seems 
to mean "be more suspicious of this", but I'm not sure if that is of any 
help to filters. Ultimately it's whether filters find these policies 
useful is what actually matters. Don't we have enough data lying around 
these days to inform us? If filters are ignoring it, then it's rather 
pointless. This discussion (and many others) should be data driven, IMO.

Mike

---

From: Dotzero <[email-masked]>
Date: Tue, 8 Dec 2020 13:50:18 -0500

> pointless. This discussion (and many others) should be data driven, IMO.

And here we get to some of the crucial unresolved questions involving
email: "Does the wishes of a user of an account at a domain supercede the
policies of the domain owner/administrator of a domain?" "Does a domain
owner/administrator have the right to externalize enforcement of their
internal usage policies?" These questions and associated answers go far
beyond DMARC but certainly impact how one views policy statements made by
DMARC.

Michael Hammer

---

From: Dave Crocker <[email-masked]>
Date: Tue, 8 Dec 2020 11:42:38 -0800

On 12/8/2020 10:50 AM, Dotzero wrote:
> email: "Does the wishes of a user of an account at a domain supercede 
> the policies of the domain owner/administrator of a domain?"

It's not only not crucial, it's entirely resolved, and always had been, 
in terms of real-world practice. The view that it hasn't been is frankly 
an arrogance of author domain owners.

Author domain owners do not have a relationship with receivers or 
recipients, so their policies have no enforcement potential. Receivers 
and recipients are completely independent.  They do not 'override' the 
domain owner policies.  Rather, they apply their own policies.  Always have.

This is why the language in DMARC would be far more constructive to 
remove any hint of attempting to direct receiver or recipient behavior, 
and instead merely reflect the domain owner's assessment of message 
validity, along the lines of the language I offered.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
[email-masked]

---

From: Dotzero <[email-masked]>
Date: Tue, 8 Dec 2020 15:11:37 -0500

Note that I asked Two questions. Your answer appears directed to the second
question. The answer to the first question appears fairly clear to me.
Administrators of a system can restrict or delete a user account. It really
is as simple as that. So in that respect the answer is that ultimately an
individual account users do not supersede the wishes/policy of the domain
owners representatives.

The second question is a bit more interesting, but ultimately leads one
back to the first question. As far as being long settled, I would think
that NSF AUP is an interesting precedent.

Michael Hammer

---

From: Benny Pedersen <[email-masked]>
Date: Tue, 08 Dec 2020 21:25:51 +0100

Dotzero skrev den 2020-12-08 19:50:

> the policies of the domain owner/administrator of a domain?" "Does a
> domain owner/administrator have the right to externalize enforcement
> of their internal usage policies?" These questions and associated
> answers go far beyond DMARC but certainly impact how one views policy
> statements made by DMARC.

i have solved it by using fuglu :=)

when i used milters in postfix i just did that in postfix to tell dont 
use milters on maillists ips, pretty simple

but there might be more options, eq dont break dkim

---

From: "John Levine" <[email-masked]>
Date: 8 Dec 2020 19:00:42 -0500

In article <CAJ4XoYdOtNCQWot53qx92akxUWjG3OYDmj2iYYYU=[email-masked]> you write:
>-=-=-=-=-=-
>Administrators of a system can restrict or delete a user account.

It depends what agreements they might have with the users but in general
I agree, users can only do what their system managers permit.

>that NSF AUP is an interesting precedent.

Huh? NSFNET shut down decades ago. I would be surprised if its
agreements with the systems it served, all of which had some
contractual relationship with the NSF, had any relevance beyond
a tiny handful of government funded academic networks.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Wed, 9 Dec 2020 09:40:34 -0800

On 12/8/2020 12:11 PM, Dotzero wrote:
> Note that I asked Two questions. Your answer appears directed to the 
> second question. The answer to the first question appears fairly clear 
> to me. Administrators of a system can restrict or delete a user 
> account. It really is as simple as that. So in that respect the answer 
> is that ultimately an individual account users do not supersede the 
> wishes/policy of the domain owners representatives.
>
> The second question is a bit more interesting, but ultimately leads 
> one back to the first question. As far as being long settled, I would 
> think that NSF AUP is an interesting precedent.
>
> Michael Hammer
>
> On Tue, Dec 8, 2020 at 2:42 PM Dave Crocker <[email-masked] 
> <mailto:[email-masked]>> wrote:
>

Sorry, I misread the text I responded to.  To some extent, we all tend 
to be ambiguous in our references -- though the specific text I misread 
was not -- and it will help if we are all a lot more consistently precise.

For example:

Author: creates content

Author Domain: controls the use of the domain, per the statement I 
misread.  And yes, the domain owner has ultimate authority over polices 
of how the domain is used, by those subject to administration by the 
domain owner.  Obviously the domain owner has no 'authority' over those 
using the domain without authorization.  For this latter set of folk, 
the most the domain owner can do is provide information to receivers of 
unauthorized use.

Receivers: They have full and complete authority over their operations.  
Period, full stop.  There is no 'overriding' the so-called policies of 
anyone with whom they do not have a pre-existing relationship.

Recipients: They are, of course, subject to the policies of the owner of 
the platform being used.  They, to, are not subject to the desires of 
authors or author domain owners, except as the recipient themselves desire.

Really, it will help to be boringly, redundantly precise with every 
reference, to leave no room for misunderstanding which actor is being 
referenced.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: tjw ietf <[email-masked]>
Date: Wed, 9 Dec 2020 12:52:27 -0500

I agree strongly with Dave on creating boring and precise terminology/references, and they are used over and over. 

Tim

Sent from my iPhone

> On Dec 9, 2020, at 12:40, Dave Crocker <[email-masked]> wrote:
> 
>> Note that I asked Two questions. Your answer appears directed to the second question. The answer to the first question appears fairly clear to me. Administrators of a system can restrict or delete a user account. It really is as simple as that. So in that respect the answer is that ultimately an individual account users do not supersede the wishes/policy of the domain owners representatives.
>> 
>> The second question is a bit more interesting, but ultimately leads one back to the first question. As far as being long settled, I would think that NSF AUP is an interesting precedent.
>> 
>> Michael Hammer
>> 
> Sorry, I misread the text I responded to.  To some extent, we all tend to be ambiguous in our references -- though the specific text I misread was not -- and it will help if we are all a lot more consistently precise. 
> 
> 
> 
> For example:
> 
> Author: creates content
> 
> Author Domain: controls the use of the domain, per the statement I misread.  And yes, the domain owner has ultimate authority over polices of how the domain is used, by those subject to administration by the domain owner.  Obviously the domain owner has no 'authority' over those using the domain without authorization.  For this latter set of folk, the most the domain owner can do is provide information to receivers of unauthorized use.
> 
> Receivers: They have full and complete authority over their operations.  Period, full stop.  There is no 'overriding' the so-called policies of anyone with whom they do not have a pre-existing relationship.
> 
> Recipients: They are, of course, subject to the policies of the owner of the platform being used.  They, to, are not subject to the desires of authors or author domain owners, except as the recipient themselves desire.
> 
> 
> 
> Really, it will help to be boringly, redundantly precise with every reference, to leave no room for misunderstanding which actor is being referenced.
> 
> d/
> 
> -- 
> Dave Crocker
> [email-masked]
> 408.329.0791
> 
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: Dave Crocker <[email-masked]>
Date: Wed, 9 Dec 2020 10:09:00 -0800

On 12/9/2020 9:52 AM, tjw ietf wrote:
> Obviously the domain owner has no 'authority' over those using the 
> domain without authorization.  For this latter set of folk, the most 
> the domain owner can do is provide information to receivers of 
> unauthorized use.

It might be worth a bit of thinking about what, exactly, DMARC can 
reasonably do and how it should be summarized, for popular consumption:

    *Alignment - *DMARC defines a basis for authenticating use of the
    domain name in the rfc5322.From addr-spec.  (But nothing else in
    that header field or elsewhere in the message, neither header nor body.

    *Severity of unauthorized use - *DMARC provides a means of
    indicating to receivers how serious the domain owner considers
    unauthorized use of that domain name to be.

    *Reporting -* DMARC defines a mechanism for reporting DMARC-related
    activity by a receiver

I've tried to state each of these precisely and accurately, in terms of 
real-world pragmatics.

Comments?

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 10 Dec 2020 16:46:08 -0800

On Wed, Dec 9, 2020 at 10:09 AM Dave Crocker <[email-masked]> wrote:

> *Alignment - *DMARC defines a basis for authenticating use of the domain
> name in the rfc5322.From addr-spec.  (But nothing else in that header field
> or elsewhere in the message, neither header nor body.
>
> *Severity of unauthorized use - *DMARC provides a means of indicating to
> receivers how serious the domain owner considers unauthorized use of that
> domain name to be.
>
These seem like a good starting point, but I'd have to quibble with
the "*unauthorized
use*"  situation. This situation devolves into use-as-imagined vs.
use-as-really-used when one considers various intermediary scenarios. Does
a domain owner really have the prerogative to define recipient behaviour as
"unauthorized"?

--Kurt

---

From: Dave Crocker <[email-masked]>
Date: Thu, 10 Dec 2020 17:00:13 -0800

On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote:
> but I'd have to quibble with the "*unauthorized use*"  situation.

please do quibble. or more.

I intended the text to prime the pump, and don't have any expectation is 
is already perfect.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Dave Crocker <[email-masked]>
Date: Thu, 10 Dec 2020 17:03:20 -0800

On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote:
> to quibble with the "*unauthorized use*"  situation. This situation 
> devolves into use-as-imagined vs. use-as-really-used when one 
> considers various intermediary scenarios.

(to respond to the content...)

So, the driving issue is that it's characterizing problematic usage; use 
that did not achieve a DMARC pass.

And, yeah, that doesn't mean the use was unauthorized, given the other 
possible explanations for failure.

So, without suggesting a label, I'd describe this factor as "how serious 
is a failure to get a DMARC pass"?  If that's the right semantic, what's 
a reasonable label to use?  If it's not the right semantic, what is?

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 10 Dec 2020 18:01:21 -0800

On Thu, Dec 10, 2020 at 5:03 PM Dave Crocker <[email-masked]> wrote:

> devolves into use-as-imagined vs. use-as-really-used when one considers
> various intermediary scenarios.
>
> is a failure to get a DMARC pass"?  If that's the right semantic, what's a
> reasonable label to use?  If it's not the right semantic, what is?
>
I think that is much closer to the right semantic but highlights a problem
that the mail coming from a particular domain probably doesn't rate a
single broad-brush characterization of seriousness.

--Kurt

---

From: Michael Thomas <[email-masked]>
Date: Thu, 10 Dec 2020 18:25:11 -0800

On 12/10/20 6:01 PM, Kurt Andersen (b) wrote:
> On Thu, Dec 10, 2020 at 5:03 PM Dave Crocker <[email-masked] 
>>     to quibble with the "*unauthorized use*"  situation. This
>>     situation devolves into use-as-imagined vs. use-as-really-used
>>     when one considers various intermediary scenarios.
>
>     So, the driving issue is that it's characterizing problematic
>     usage; use that did not achieve a DMARC pass.
>
>     And, yeah, that doesn't mean the use was unauthorized, given the
>     other possible explanations for failure.
>
>     So, without suggesting a label, I'd describe this factor as "how
>     serious is a failure to get a DMARC pass"?  If that's the right
>     semantic, what's a reasonable label to use?  If it's not the right
>     semantic, what is?
>
> I think that is much closer to the right semantic but highlights a 
> problem that the mail coming from a particular domain probably doesn't 
> rate a single broad-brush characterization of seriousness.
>
I think this all should be driven by "what are you asking me to do?". 
p=quarantine is asking for a specific thing, but it doesn't seem to mean 
literally what it's asking for. it seems to mean "i'm not comfortable 
with this except in certain situations that i can't enumerate with any 
accuracy". maybe p=quarantine is my "only if you trust the intermediary" 
state I was talking about the other day.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Thu, 10 Dec 2020 18:26:00 -0800

> rate a single broad-brush characterization of seriousness. 

I've assumed the none, quarantine, reject choices are meant to indicate 
just how certain the domain owner is that the mail is problematic.

Perhaps:

     none: not certain at all

     quarantine: I believe I've got control of all my sending, but am 
not 100% positive

     reject: I have control of all my sending; if it doesn't pass DMARC, 
it's use of the domain is bogus.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Dave Crocker <[email-masked]>
Date: Thu, 10 Dec 2020 18:28:27 -0800

On 12/10/2020 6:25 PM, Michael Thomas wrote:
> I think this all should be driven by "what are you asking me to do?"

The domain owner has no business asking the receiver to do anything.  
The receiver has no relationship with the domain owner.

However, the receiver might like to hear the domain owner's opinion 
about usage of the domain when DMARC fails.  But that's different from 
attempting to give direction to the receiver (who demonstrably will 
ignore that direction and make their own decision.)

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Thu, 10 Dec 2020 18:32:48 -0800

> ignore that direction and make their own decision.)
Semantic nit picking at best. If the receiver doesn't care about the 
sender's opinion, they don't need to implement DMARC. Manifestly they do 
have a stake in what the sender's opinion is if they deploy DMARC. The 
only question is whether DMARC captures those opinions correctly.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Thu, 10 Dec 2020 18:44:19 -0800

On 12/10/2020 6:32 PM, Michael Thomas wrote:
> Semantic nit picking at best.

Because semantics do not matter in a specification?

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Thu, 10 Dec 2020 18:53:06 -0800

> Because semantics do not matter in a specification?
It's ok, I guess but I wouldn't want to make a career of nit picking. 
It's a lot more useful to get intent across of what the actual intent is 
rather than trying to express what is ultimately a code point for a 
filter that doesn't care about the ascii string.

Mike

---

From: Hector Santos <[email-masked]>
Date: Fri, 11 Dec 2020 11:10:54 -0500

On 12/10/2020 9:26 PM, Dave Crocker wrote:
>> problem that the mail coming from a particular domain probably
>> doesn't rate a single broad-brush characterization of seriousness.
>
> I've assumed the none, quarantine, reject choices are meant to
> indicate just how certain the domain owner is that the mail is
> problematic.
>
> Perhaps:
>+
>      none: not certain at all
>
>      reject: I have control of all my sending; if it doesn't pass
> DMARC, it's use of the domain is bogus.

When it comes to keeping focus with the purpose of SPF and DKIM-POLICY 
protocols and its implementation out of the box, default behavior:

1) The main purpose is Receiver Abuse Control.

2) Special attention to Port 25 Unsolicited Anonymous Senders and 
Message Authors.

3) For authenticated, authorized, white listed clients, SPF and DKIM 
do not apply, mail is always accepted.

Hard policies with SPF and DKIM-POLICY are honored aggressively. 
Softer policies are processed, classified and passed through to next 
filters, if any remaining, i.e. GreyListing.

* SPF -ALL, REJECT - Receiver rejects at MAIL FROM state with a 550 
response.

* ADSP DKIM=DISCARDABLE, Receiver rejects at SMTP DATA state with a 
negative 550 DATA response.

* DMARC p=reject, Receiver rejects at SMTP DATA state with a negative 
550 DATA response.

* DMARC p=quarantine, Receiver accepts at SMTP. Mail is moved outside 
targeted users' main inbox mail stream, i.e. can not be picked up by 
user's POP3 or normal mail pickup process. The user has to login in 
online to see the mail in another non-inbox folder, i.e. spam box.

Thats it.  No reporting. Period.

The domain should be grateful their public mail policy instructions is 
being honored for strict operations at compliant receivers. I hope 
their compliant receivers are also honoring our strict public mail 
policies as well to help protect fraudulent usage. I really do not 
need a report for the expected action when fraudulent mail is detected.

Overall, the receiver is doing the domain a favor by helping them 
protect their domain reputation from possible fraudulent usage of 
their domains, and at the same time, it is helping its own system and 
the target hosted user from potential abuse as well -- a win win 
situation.

For List-related situations, the receiver follows the 2006 DSAP 
recommendations:

https://tools.ietf.org/html/draft-santos-dkim-dsap-00

1) If a new subscribing domain has a restrictive public mail policy 
with ADSP and/or DMARC, the subscription is denied.

2) Incoming messages are checked for mailing list destinations. If the 
submitter's domain have restrictive public mail policies with ADSP or 
DMARC, the submission is rejected with a 550.

With these two simple peripheral filters, there was no need to modify 
the legacy list server source code for Rewriting or anything else 
related to the "in-direct" mail problem.

The DMARCbis codification/changes I am looking for are:

1) Improvements in the DNS lookup algorithm, optional additional 
lookups should be provided or referenced.

2) Recognition and support for ATPS to cover 3rd party authorization.

and other fine tunning, clarifications, for example, in another 
thread, it was stated:

"When you switch to p=quarantine pct=0, no one should apply quarantine 
(so it's equivalent to p=none),"

I thought the "pct=" was related to when reporting should be applied. 
I apparently read it wrong.  This needs to be code reviewed and 
corrected on our end, if needed.  We are not doing reporting at this 
time.  Not the main focus.  That can come later as an augmented 
feature, in fact, we might consider it as a paid service to be sending 
thousands report out to domains.

Keep it simple folks.  Be safe and have a great weekend.

Thanks

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

---

From: Dotzero <[email-masked]>
Date: Fri, 11 Dec 2020 11:19:38 -0500

On Fri, Dec 11, 2020 at 11:11 AM Hector Santos <hsantos=
[email-masked]> wrote:

> We are not doing reporting at this

That's good community spirit. I doubt many would be willing to pay you for
your reports.

Michael Hammer

---

From: Hector Santos <[email-masked]>
Date: Fri, 11 Dec 2020 11:30:04 -0500

> * SPF -ALL, REJECT - Receiver rejects at MAIL FROM state with a 550

Correction:

* SPF -ALL, REJECT - Receiver rejects at RCPT TO state with a 550
response.  SPF is only tested once a valid (existing) RCPT TO is provided.

This was the very first major optimization done with SPF back in 
2003/2004 when it was first changed from MAIL FROM to RCPT TO.   It 
resulted in a DNS lookup overhead savings of 60% because at the time, 
60% of the RCPT TO were "unknown, not locally hosted" addresses.

This mode of operation is on-par with the SMTP RFC5321 Section 3.3 
recommendation:

    3.3 Mail Transactions

    .....

    Despite the apparent scope of this requirement, there are
    circumstances in which the acceptability of the reverse-path may
    not be determined until one or more forward-paths (in RCPT
    commands) can be examined.  In those cases, the server MAY
    reasonably accept the reverse-path (with a 250 reply) and then
    report problems after the forward-paths are received and
    examined.  Normally, failures produce 550 or 553 replies.

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 11 Dec 2020 08:32:34 -0800

> it's use of the domain is bogus.

But the problem case in our off-topic rabbit trail meanderings is that
people who "have control of all their sending" still don't necessarily send
mail of consistent seriousness nor do they have any control of the paths by
which that mail takes to get to the ultimate recipient. There is a
conflation of "control of emission" with "control of path".

--Kurt

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Dec 2020 09:07:26 -0800

On 12/11/2020 8:32 AM, Kurt Andersen (b) wrote:
> people who "have control of all their sending" still don't necessarily 
> send mail of consistent seriousness nor do they have any control of 
> the paths by which that mail takes to get to the ultimate recipient. 
> There is a conflation of "control of emission" with "control of path".

A specification providing a choice of labels/settings needs to have a 
shared understanding of what those labels mean.

It seems pretty clear that DMARC's p= hasn't had that, to date. There is 
no consistency to the criteria used to set the label and, I suspect, 
little consistency to how a receiver's filtering engine uses it.

We need to settle on text that resonates with a consistent 
interpretation, by both domain owners and email receivers.

I've offered an approach that might permit reaching that community -- 
not just IETF -- rough consensus.

At this point we need to get suggested revisions for improvement. For 
now, I don't have better text to suggest.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Laura Atkins <[email-masked]>
Date: Fri, 11 Dec 2020 17:21:17 +0000

> On 11 Dec 2020, at 17:07, Dave Crocker <[email-masked]> wrote:
> 
>> But the problem case in our off-topic rabbit trail meanderings is that people who "have control of all their sending" still don't necessarily send mail of consistent seriousness nor do they have any control of the paths by which that mail takes to get to the ultimate recipient. There is a conflation of "control of emission" with "control of path".
> 
> A specification providing a choice of labels/settings needs to have a shared understanding of what those labels mean.  
> 
> It seems pretty clear that DMARC's p= hasn't had that, to date.  There is no consistency to the criteria used to set the label and, I suspect, little consistency to how a receiver's filtering engine uses it.
> 
> We need to settle on text that resonates with a consistent interpretation, by both domain owners and email receivers.
> 
> I've offered an approach that might permit reaching that community -- not just IETF -- rough consensus.  
> 
> At this point we need to get suggested revisions for improvement. For now, I don't have better text to suggest.
> 

There’s probably better phrasing than ‘DMARC compliant’ here, but here’s my stab at describing the processes. note, this is very close to the language I use with clients.

p=none: mail sent by authorized users of this domain may or may not be aligned in a DMARC compliant way.

p=quarantine: mail sent by authorized users of this domain should be aligned in a DMARC compliant way. Mail that is unaligned may or may not be legitimate messages from this organization.

p=reject: all mail sent from this domain should be aligned in a DMARC compliant way. Mail that is unaligned is not authorized by the domain owner and may be discarded or rejected by the recipient. 

laura 

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

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741		

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

---

From: "John Levine" <[email-masked]>
Date: 11 Dec 2020 12:37:22 -0500

In article <[email-masked]> you write:
>p=quarantine: mail sent by authorized users of this domain should be aligned in a DMARC compliant
>way. Mail that is unaligned may or may not be legitimate messages from this organization.

So far so good.

>p=reject: all mail sent from this domain should be aligned in a DMARC compliant way. Mail that is
>unaligned is not authorized by the domain owner and may be discarded or rejected by the recipient. 

Naah.

p=reject: all mail sent from this domain should be aligned in a DMARC
compliant way. We believe that unaligned mail is from unauthorized
senders so we ask receivers to reject it, even though that might mean
some of our authorized senders' mail is rejected too.

R's,
John

PS: I had more or less this same discussion leading to ADSP discardable.

---

From: Hector Santos <[email-masked]>
Date: Fri, 11 Dec 2020 21:14:06 -0500

On 12/11/2020 11:19 AM, Dotzero wrote:>
>
> On Fri, Dec 11, 2020 at 11:11 AM Hector Santos
>
>>  We are not doing reporting at this time.  Not the main focus.
>>  That can come later as an augmented feature, in fact, we might
>>  consider it as a paid service to be sending thousands report out
>>  to domains.
>
> That's good community spirit.

eh, thanks?

> I doubt many would be willing to pay you for your reports.

Customers are already paying for the total platform (not open source, 
not free, its expensive commercial hosting software). It comes without 
any DMARC reporting except with the description to add DMARC report 
tags to collect the reports and instructions to redirect the 
notifications to specific admin-only mail areas. No Doubt, this is an 
easy added-value feature when we are ready to offer the ad-hoc 
reporting capability added to their existing Wildcat! Ad-hoc Reporting 
tools (an paid for add-on).

How do you benefit from DMARC? What is your rejection (or protect 
domain action) average? Do you allow subscriptions to your mailing 
list services or you do rewriting?

-- Hector Santos,

---

From: Dave Crocker <[email-masked]>
Date: Sat, 12 Dec 2020 10:42:25 -0800

On 12/11/2020 9:37 AM, John Levine wrote:
> aligned is not authorized by the domain owner and may be discarded or rejected by the recipient.
> Naah.
>

As soon as this specification text, here, contains language about how 
this information is to be used, should be used, or could be used, it 
crosses over into creating confusion about expectations of receiver 
handling.

It encourages misguided language such as the receiver 'overriding' 
sender policy.  The sender has no policies about receiver behavior, 
because there is no relationship between them. Using milder language 
here doesn't help, because readers typically do not read like legal or 
technical scholars.

DMARC provides information, not direction.

The spec already contains misguided perspective by talking about 
'policy' records and, even worse, "policy enforcement considerations".

If the document must contain language about receiver choices in message 
disposition, move it to an overtly non-normative discussion section that 
legitimately covers a wide range of things that receivers do or don't do 
(cast as things they might or might not do.)  And make sure none of the 
language hints at sender 'policy', overrides, or the like.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: "John R Levine" <[email-masked]>
Date: 12 Dec 2020 13:51:54 -0500

On Sat, 12 Dec 2020, Dave Crocker wrote:
> As soon as this specification text, here, contains language about how this 
> information is to be used, should be used, or could be used, it crosses over 
> into creating confusion about expectations of receiver handling.

I agree with you, which is why I said "believe" and "request".

If we're going to have any description of p=none at all it needs to 
emphasize the point that it's telling you that they consider the messages 
unusually unimportant.  This appears to be at odds with what some DMARC 
users believe.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Michael Thomas <[email-masked]>
Date: Sat, 12 Dec 2020 10:57:47 -0800

> crosses over into creating confusion about expectations of receiver 

As a developer for 40 years, I can safely say that reject or discardable 
or whatever it was in ssp are all abundantly clear and that nobody 
writing a filter would make the error that you keep insisting that we 
would. The only thing all of this hand wringing has done is waste time 
and added to the length of time it takes to get specs out the door.

Quarantine however -- which is why I started this thread -- is not clear 
at all. Why are we still talking about "reject"?

Mike

---

From: Douglas Foster <[email-masked]>
Date: Sun, 13 Dec 2020 16:44:55 -0500

Based on this discussion, it seems evident that p=reject should include
language about in-transit modifications which are outside the control of
the source domain, and consequently outside the ability of DMARC to guide
recipients.    Extending from that, I thought it would be helpful to
specify some shared assumptions between sender and evaluator to make the
interpretation of the settings less subjective.   I call this the "Minimum
expected implementation at pct=100".

p=none
Minimum expected implementation at pct=100:
All first-party direct messages (RFC5321.MailFrom domain = RFC5322.From
domain) are verifiable using SPF, but may not have a DKIM signature.
Third-party direct messages ( RFC5321.MailFrom domain = RFC5322.From domain
) may or may not have DKIM signatures.
Consequently, indirect messages are often not verifiable using DMARC.

p=quarantine
Minimum expected implementation at pct=100:
All first-party direct messages (RFC5321.MailFrom domain = RFC5322.From
domain) are verifiable using SPF, but may not have a DKIM signature.
Third-party direct messages ( RFC5321.MailFrom domain = RFC5322.From domain
) are verifiable using DKIM signatures.
Consequently, indirect messages may or may not be verifiable, depending
whether the forwarded message included a signature.

p=reject
Minimum expected implementation at pct=100:
All first-party direct messages (RFC5321.MailFrom domain matches
RFC5322.From domain) are verifiable using SPF and DKIM.
Third-party direct messages ( RFC5321.MailFrom domain does not match
RFC5322.From domain ) are verifiable using DKIM signatures.
Indirect messages which are not modified in transit are verifiable using
DKIM signatures.
Indirect messages which are modified in transit are outside the scope of
DMARC and must be evaluated by other criteria available to the recipient
system.

Having defined the policies/categories in these terms, the logical next
step would be a best practices document which discusses how an evaluator
might distinguish between direct messages, indirect unmodified messages,
and indirect modified messages.   ARC obviously plays a role in making
these distinctions easier to determine and less error-prone.

Doug Foster

---

From: Dotzero <[email-masked]>
Date: Sun, 13 Dec 2020 17:41:03 -0500

On Sun, Dec 13, 2020 at 4:45 PM Douglas Foster <
[email-masked]> wrote:

> recipients.

And the buzzer goes off. Sources and modifications outside the control of
the domain in the RFC 5322 From is exactly what DMARC is addressing. That
is exactly the guidance that is being provided by a domain publishing a
DMARC record.

>
> Extending from that, I thought it would be helpful to specify some shared
> assumptions between sender and evaluator to make the interpretation of the
> settings less subjective.   I call this the "Minimum expected
> implementation at pct=100".
>

"Shared assumptions" is a poor assumption in writing a technical standard
for interoperability.

<snippage>

> these distinctions easier to determine and less error-prone.

"Shared assumptions" are not definitions, they are hopes. Again, not a good
basis for a technical standard.

Michael Hammer

---

From: Laura Atkins <[email-masked]>
Date: Mon, 14 Dec 2020 10:05:09 +0000

> On 13 Dec 2020, at 21:44, Douglas Foster <[email-masked]> wrote:
> 
> Based on this discussion, it seems evident that p=reject should include language about in-transit modifications which are outside the control of the source domain, and consequently outside the ability of DMARC to guide recipients.    Extending from that, I thought it would be helpful to specify some shared assumptions between sender and evaluator to make the interpretation of the settings less subjective.   I call this the "Minimum expected implementation at pct=100".

What about messages which do not have SPF verification but do have DKIM verification? A significant number of email platforms use their own domains in the 5321.from address but have the customer sign with DKIM. In many cases, DKIM signing is actually free, whereas making the SPF align is a paid service. 

> All first-party direct messages (RFC5321.MailFrom domain = RFC5322.From domain) are verifiable using SPF, but may not have a DKIM signature.
> Third-party direct messages ( RFC5321.MailFrom domain = RFC5322.From domain ) may or may not have DKIM signatures.

> All first-party direct messages (RFC5321.MailFrom domain = RFC5322.From domain) are verifiable using SPF, but may not have a DKIM signature.
> Third-party direct messages ( RFC5321.MailFrom domain = RFC5322.From domain ) are verifiable using DKIM signatures.
> Consequently, indirect messages may or may not be verifiable, depending whether the forwarded message included a signature.
> 
> p=reject
> All first-party direct messages (RFC5321.MailFrom domain matches RFC5322.From domain) are verifiable using SPF and DKIM.
> Third-party direct messages ( RFC5321.MailFrom domain does not match RFC5322.From domain ) are verifiable using DKIM signatures.
> Indirect messages which are not modified in transit are verifiable using DKIM signatures.
> Indirect messages which are modified in transit are outside the scope of DMARC and must be evaluated by other criteria available to the recipient system.
> 
> Having defined the policies/categories in these terms, the logical next step would be a best practices document which discusses how an evaluator might distinguish between direct messages, indirect unmodified messages, and indirect modified messages.   ARC obviously plays a role in making these distinctions easier to determine and less error-prone.
> 
> Doug Foster
>  
> 
> On Sat, Dec 12, 2020 at 1:42 PM Dave Crocker <[email-masked] <mailto:[email-masked]>> wrote:
> > In article <[email-masked] <mailto:[email-masked]>> you write:
> [email-masked] <mailto:[email-masked]>
> 408.329.0791
> 
> [email-masked] <mailto:[email-masked]>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dmarc <https://www.ietf.org/mailman/listinfo/dmarc>

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741

---

From: Douglas Foster <[email-masked]>
Date: Mon, 14 Dec 2020 10:01:47 -0500

> is exactly the guidance that is being provided by a domain publishing a

Do you mean that DMARC p=reject intends to block mailing lists that do
content alterations, so there is not a mailing list problem at all?

> "Shared assumptions" is a poor assumption in writing a technical standard

Then change the language to SHOULD and make it a requirement.   Here is the
point:

Sender policy is intended to help the evaluator divide incoming messages
into three groups:
- verifiably sent by the From domain
- uncertain
- verifiably NOT sent by the From domain (spoofed)

The evaluator has two results to work from:   Verified or Not Verified.
 Sender policy provides guidance for splitting the unverified messages
between "uncertain" and "spoofed" by providing information about which
messages SHOULD be verifiable.     This is inherently a communication
protocol and it has not been well defined, which is why the question has
been raised, "What does p=quarantine actually mean?"   It is a derivative
of the earlier Chair question, "what does it  mean to implement DMARC?"

One could argue that anything other than "p=reject pct=100" is a non-policy
which provides no useful guidance, equivalent to the SPF token ?ALL.   But
then we have the mailing list problem, so even at "p=reject pct=100" we
have a problem with false positives (messages actually sent by the source
domain but not verifiable because of in-transit changes.)   So maybe DMARC
has no ability to distinguish between spoofed and unverifiable messages.

What seems useful is to define the capabilties and the limitations of
DMARC, then define a signalling protocol so that the sender correctly
signals which messages are DMARC-protected and the evaluator understands
that signal in a manner which can be applied to an incoming message.    I
do not see that we have such a protocol at present.   Rather, the evaluator
is left with a lot of guesswork,and that means that the source domain owner
is left with a lot of guesswork about how the recipients will make
their guesses.

DF

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Dec 2020 07:10:36 -0800

> I agree with you, which is why I said "believe" and "request".

Except that that runs contrary to my point, rather than being compatible 
with it.

Any an all discussion of receiver /use/ of DMARC needs to be moved to a 
separate section and it needs to refrain from any linguistic form that 
characterizes that use as being in response to domain owner desires.

> emphasize the point that it's telling you that they consider the 
> messages unusually unimportant.  This appears to be at odds with what 
> some DMARC users believe.

It isn't about the 'importance' of the messages.  It is about the domain 
owner's view of the implication of the success or failure of DMARC 
validation.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Douglas Foster <[email-masked]>
Date: Mon, 14 Dec 2020 10:11:48 -0500

I called that a third-party message, since the RFC5321.MailFrom domain is
different from the RFC5322.From domain.

I am open to revisions of how the boundaries should be defined, but as I
said in my reply just now to Michael Hammer, we need to define those
boundaries in a way that both sender and receiver understand.  This is the
full problem description:

We have these three types of senders:
- first-party senders
- third-party senders
- spoofers

We have these four verification states at initial transmission:
- none
- spf only
- dkim only
- spf and dkim

We have these 9 routing scenarios:
- direct (1)
- indirect (8)
    with and without SMTP rewrite
    with and without FROM rewrite
    with and without content modifications

Upon receipt, we have these verification states:
- Not verified
- SPF only
- DKIM only
- SPF and DKIM

For messages that do not verify, the evaluator uses sender policy (none,
quarantine, reject) to categorize the message as either "verifiably
spoofed" or "uncertain".   What is the algorithm for doing so?

DF

On Mon, Dec 14, 2020 at 5:05 AM Laura Atkins <[email-masked]>
wrote:

>
>
> On 13 Dec 2020, at 21:44, Douglas Foster <
> What about messages which do not have SPF verification but do have DKIM
> verification? A significant number of email platforms use their own domains
> in the 5321.from address but have the customer sign with DKIM. In many
> cases, DKIM signing is actually free, whereas making the SPF align is a
> paid service.
>
> p=none
> Third-party direct messages ( RFC5321.MailFrom domain = RFC5322.From
> domain ) may or may not have DKIM signatures.
> Third-party direct messages ( RFC5321.MailFrom domain = RFC5322.From
> domain ) are verifiable using DKIM signatures.

---

From: Laura Atkins <[email-masked]>
Date: Mon, 14 Dec 2020 15:31:41 +0000

> On 14 Dec 2020, at 15:10, Dave Crocker <[email-masked]> wrote:
> 
>>> As soon as this specification text, here, contains language about how this information is to be used, should be used, or could be used, it crosses over into creating confusion about expectations of receiver handling.
>> 
> Except that that runs contrary to my point, rather than being compatible with it.
> 
> Any an all discussion of receiver /use/ of DMARC needs to be moved to a separate section and it needs to refrain from any linguistic form that characterizes
> that use as being in response to domain owner desires.

‘As a matter of policy we treat all unaligned mail as unauthorized use of our domain.’ 

I am agnostic about moving the ‘what to do’ section. I think it makes sense to keep the sender definitions and the ways receivers can interpret those declarations close together. 

>> If we're going to have any description of p=none at all it needs to emphasize the point that it's telling you that they consider the messages unusually unimportant.  This appears to be at odds with what some DMARC users believe.
> 
> It isn't about the 'importance' of the messages.  It is about the domain owner's view of the implication of the success or failure of DMARC validation.

The current p=reject is that the domain owner’s view is that the mail is unauthorized. And, according to discussion here on the IETF list, we are to presume that every domain owner knows exactly what they are doing and that every company understands the implications of a p=reject policy statement. 

laura 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741

---

From: Laura Atkins <[email-masked]>
Date: Mon, 14 Dec 2020 15:36:40 +0000

> On 14 Dec 2020, at 15:11, Douglas Foster <[email-masked]> wrote:
> 
> I called that a third-party message, since the RFC5321.MailFrom domain is different from the RFC5322.From domain.

No, you didn’t.

Third-party direct messages ( RFC5321.MailFrom domain = RFC5322.From domain )

I think ‘first party’ and ’third-party’ are problematic definitions in any case and I’m not sure I understand what your goal is here. Who are you considering ‘party’?

laura

> I am open to revisions of how the boundaries should be defined, but as I said in my reply just now to Michael Hammer, we need to define those boundaries in a way that both sender and receiver understand.  This is the full problem description:
> 

> For messages that do not verify, the evaluator uses sender policy (none, quarantine, reject) to categorize the message as either "verifiably spoofed" or "uncertain".   What is the algorithm for doing so?
> 
> DF
> 
> 
> On Mon, Dec 14, 2020 at 5:05 AM Laura Atkins <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 13 Dec 2020, at 21:44, Douglas Foster <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> [email-masked] <mailto:[email-masked]>
> (650) 437-0741		
> 
> Email Delivery Blog: https://wordtothewise.com/blog <https://wordtothewise.com/blog>	
> 
> 
> 
> 
> 
> 
> 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Dec 2020 08:12:23 -0800

On 12/12/2020 10:57 AM, Michael Thomas wrote:
> As a developer for 40 years, I can safely say that reject or 
> discardable or whatever it was in ssp are all abundantly clear and 
> that nobody writing a filter would make the error that you keep 
> insisting that we would.

An appeal to authority?  In this group?  Really?

So that means that my citing 50 years of writing this kind of networking 
standard and seeing exactly the kinds of misinterpretation I'm 
expressing concern about carries more sway than your own experience 
(which I suspect is a lot less than 40 years of writing specifications 
for the public Internet, as to writing them for more constrained 
environments.)

And the above is mostly meant to serve as a demonstration of just how 
inappropriate an appeal to authority is, here.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Dec 2020 09:01:41 -0800

On 12/14/2020 7:31 AM, Laura Atkins wrote:
> I am agnostic about moving the ‘what to do’ section. I think it makes 
> sense to keep the sender definitions and the ways receivers can 
> interpret those declarations close together. 

I'm pressing for clear separation because we've got an existing problem 
-- and DMARC isn't even close to the first case of this -- where people 
over-interpret the meaning of non-normative information.

So, I think that 'close together', as in 'in the same document', is fine 
and even good.  I think that  as in 'in the same paragraph' or even 'in 
the same section' is not.

d/

---

From: Michael Thomas <[email-masked]>
Date: Mon, 14 Dec 2020 10:00:36 -0800

On 12/14/20 8:12 AM, Dave Crocker wrote:
> So that means that my citing 50 years of writing this kind of 
> networking standard and seeing exactly the kinds of misinterpretation 
> I'm expressing concern about carries more sway than your own 
> experience (which I suspect is a lot less than 40 years of writing 
> specifications for the public Internet, as to writing them for more 
> constrained environments.)
>

Yes. I and developers like me are the target audience, not you. When we 
tell you it's not a problem, you should listen to us rather than badger 
us and tell us you know better. You have wasted years litigating a 
non-problem, and continue to litigate conversational speech as if it 
were some gigantic problem that will never be solved unless the world 
over uses some never quite precise enough language. p=reject is 
completely clear what its meaning and intent are. This is a waste of 
time, and a major symptom of why IETF is considered sclerotic and to be 
avoided if possible.

I started this thread about p=quarantine, not p=reject as the subject 
makes abundantly clear. If you want to relitigate p=reject, kindly 
create your own thread so I can more easily ignore it, and the chairs 
can rule as out of scope because there is no ticket.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Dec 2020 10:09:10 -0800

On 12/14/2020 10:00 AM, Michael Thomas wrote:
> When we tell you it's not a problem,

Except that the telling was by you.  Alone.

And you've yet to respond to the observable fact that receivers have 
been ignoring the directive language.

Or that many folk misunderstand the semantics of DKIM, thinking it means 
that message authorship is validated.

Or...

d/

---

From: Michael Thomas <[email-masked]>
Date: Mon, 14 Dec 2020 10:27:29 -0800

On 12/14/20 10:09 AM, Dave Crocker wrote:
> Or that many folk misunderstand the semantics of DKIM, thinking it 
> means that message authorship is validated.
>

I'll ignore the whataboutism, but point out that you have never produced 
one piece of evidence where the language of p=reject or any of the other 
previous labels has caused software design decisions to change for the 
worst. I don't even know what would qualify as a mistake. So yes, I'll 
take my direct experience of writing code over your indirect innuendo 
any day.

Mike

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 14 Dec 2020 15:02:10 -0500

All

Can we please stop with the non constructive discussions here?

tim

---

From: Michael Thomas <[email-masked]>
Date: Mon, 14 Dec 2020 12:07:04 -0800

> Can we please stop with the non constructive discussions here?

It would be helpful to just rule anything about the semantics of 
p=reject as out of scope. It is what hijacked my original question for 
which I haven't gotten an answer.

Mike

---

From: Douglas Foster <[email-masked]>
Date: Mon, 14 Dec 2020 22:26:03 -0500

Sorry about the confusion caused by my typing failures.
What I meant:
First party - From address aligns with SMTP address.  Can be validated with
SPF or DKIM.
Third party - From address and SMTP address are in different domains.  Can
be validated with DKIM only.
I am open to suggestions for better nomenclature.

But what I am trying to figure out is under what circumstances a DMARC
policy can be considered actionable.   Do I conclude that "p=quarantine"
means "domain is still collecting data, so results are unpredictable"?   Or
do I conclude that it means "Domain is fully deployed and failure to
validate is a highly suspicious event?"

Take the case of a SMTP-aligned message which does not have a DKIM
signature.   If it is received directly, it is DMARC compliant.   If it is
received indirectly, it is a presumed spoof.    It cannot be both valid and
spoofed.   Whether the message gets forwarded is not under the sender's
control.   If I receive it directly it is presumed valid, but does it
signal that the domain is still struggling to implement DMARC, so their
policy should be ignored on future messages?   Or if I receive it
indirectly, should I try to reverse engineer whether it was SPF-aligned
before it was forwarded?
Since all messages need to be DKIM-signed to survive a possible forward,
should SPF even be part of the DMARC criteria?

I am simply wondering if a DMARC policy has enough reliable information to
be of any value, at least for any setting other than p=reject pct=100.
This is intertwined with the ambiguity about what the sender means for any
policy other than p=reject pct=100.   My opening post was an attempt to
define milestones that should be associated with specific settings.   But
maybe the only certainty is that the domain is collecting data and
consequently spoof-prevention must be based on evidence other than the
DMARC policy.

DF

On Mon, Dec 14, 2020 at 10:36 AM Laura Atkins <[email-masked]>
wrote:

>
>
> On 14 Dec 2020, at 15:11, Douglas Foster <
> domain )
> I think ‘first party’ and ’third-party’ are problematic definitions in any
> case and I’m not sure I understand what your goal is here. Who are you
> considering ‘party’?
>
> laura
>

---

From: Michael Thomas <[email-masked]>
Date: Mon, 14 Dec 2020 19:36:26 -0800

On 12/14/20 7:26 PM, Douglas Foster wrote:
> policy can be considered actionable.  Do I conclude that 
> "p=quarantine" means "domain is still collecting data, so results are 
> unpredictable"?   Or do I conclude that it means "Domain is fully 
> deployed and failure to validate is a highly suspicious event?"

Yeah, that's why I question whether there is something actionable and 
whether this is so much wishful thinking. Somebody did say that they 
took action on it (gmail?), but i'm not sure whether that is a good 
thing or a bad thing. For mailing lists, that would seemingly be a bad 
thing, but if you're of the mind that mailing lists are a security bug 
and not a feature that might be contradictory.

Mike

---

From: Dotzero <[email-masked]>
Date: Tue, 15 Dec 2020 01:06:49 -0500

On Mon, Dec 14, 2020 at 10:26 PM Douglas Foster <
[email-masked]> wrote:

> First party - From address aligns with SMTP address.  Can be validated
> with SPF or DKIM.

You are way overthinking this.

> spoofed.

Rather than using the word "spoofed", think of it as simply "failed to
validate" if it was forwarded. Done.

>  Whether the message gets forwarded is not under the sender's control.
>  If I receive it directly it is presumed valid, but does it signal that the
> domain is still struggling to implement DMARC, so their policy should be
> ignored on future messages?   Or if I receive it indirectly, should I try
> to reverse engineer whether it was SPF-aligned before it was forwarded?
>

You appear to be venturing into an area that involves tea leaves and
crystal balls - way beyond anything a technical standard can address. An
organization publishing a p=quarantine record is making a request that
messages purporting to be from their domain be quarantined if they fail to
validate. It doesn't matter whether it was sent direct or was handled by an
intermediary. Even a certain (very small) percentage of emails sent
directly can fail for various reasons. Why is it so difficult to take
things at face value? If, as a validating receiver you have data that you
believe justifies exercising local policy then you have a choice to make.
It really is that simple.

> should SPF even be part of the DMARC criteria?

Yes, SPF should be a part of DMARC because even with direct mail there can
be problems with DKIM signing/signatures for various reasons. The
combination of SPF and DKIM signing provides a small but useful increase in
the percentage of mail that validates. This statement is based on my
experience of having been responsible for systems sending several billions
of emails with a p=reject policy.

> consequently spoof-prevention must be based on evidence other than the

Again, "spoofing" is a convenient but inaccurate descriptor.  DMARC is a
tool intended to prevent direct domain abuse based on the RFC 5322 From
email address, nothing more and nothing less. Even if an email message
validates for DMARC, it could be a homoglyph or cousin domain email address
in the RFC 5322 field. Attempting to overlay the meaning of a published
policy with other semantics or trying to guess the underlying intentions is
a perilous path for a standards body. Other tools and techniques can and
should be applied to messages by Receivers in order to protect their users.

Michael Hammer

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 15 Dec 2020 10:50:10 +0100

On Tue 15/Dec/2020 04:26:03 +0100 Douglas Foster wrote:
> First party - From address aligns with SMTP address.  Can be validated with SPF 
> or DKIM.
> Third party - From address and SMTP address are in different domains.  Can be 
> validated with DKIM only.

I'm neutral about the nomenclature.  However, the definitions lack something.

First party is clear.

Third party is not:

For a nit, albeit unusual, one can use a different bounce address, for any 
convenience reason.  If SPF helo is aligned it is still a first party message.

There are other considerations that indicate a the presence and the quality of 
a third party, such as multiple DKIM signatures, and a Sender: field.

Then there are dumb forwarders, who neither sign nor modify messages, nor even 
the bounce addresses.  Second parties?  Hm... external aliases?  Artifacts of 
email address portability?

> But what I am trying to figure out is under what circumstances a DMARC policy 
> can be considered actionable.   Do I conclude that "p=quarantine" means "domain 
> is still collecting data, so results are unpredictable"?   Or do I conclude 
> that it means "Domain is fully deployed and failure to validate is a highly 
> suspicious event?"

I think quarantine is not necessarily an intermediate step.  It is adequate for 
human mail, where one is not equipped to resend in case of reject.  It doesn't 
cover first/third party differences.  I wish there was an intermediate policy, 
call it p=mlm-validate, that directs a third party to reject if not 
authenticated, while final recipients can accept it as if p=none.

Best
Ale
--

---

From: Todd Herr <[email-masked]>
Date: Tue, 15 Dec 2020 11:01:12 -0500

> and not a feature that might be contradictory.
I'm not sure there's anything actionable about DMARC's policy values.

For receivers, attempts at manually tracking which RFC5322.From domains
appear in mail that's authenticated or not with SPF and/or DKIM are ones
that are bound to fail due to scaling issues. DMARC provides a solution to
this problem, in that if a domain owner publishes a DMARC policy, the
receiver now has some information that the owner of the RFC5322.From domain
may have an expectation that mail with that domain in the RFC5322.From
domain might be authenticated in some fashion, using SPF and/or DKIM.
The receiver can use that data point, and the data points collected from
DMARC validation checks for that message, as part of the sum total of data
it uses to decide its handling of that message. If there is a published
DMARC policy for the RFC5322.From domain, and the receiver so chooses, the
receiver can also use the p= value in that policy as another data point
contributing to the message handling decision, but the receiver is not
compelled or required to do so (nor is the receiver compelled or required
to even perform DMARC validation checks, or send aggregate and/or failure
reports, or even check for the existence of a DMARC policy record for the
RFC5322.From domain).

For domain owners that publish DMARC policies, the best case is that the
owner is announcing to the internet at large that

   - It is on a journey to ensure that if it's domain (or a sub-domain
   thereof) is the RFC5322.From domain in a message, then such a message will
   pass SPF and/or DKIM authentication checks, and
   - It is interested in seeing data from receivers about what kind of
   traffic the receivers are seeing where the domain is used in the
   RFC5322.From address, perhaps as a way of increasing the rate at which
   those authentication checks are passing, and
   - It is providing to DMARC validators some information, in the form of
   the p= value, that expresses its own level of confidence in how
   well-implemented its email authentication practices are, with such
   confidence levels probably roughly approximating:
      - none - Not at all confident, just starting the process, we know or
      at least think that some of our mail streams aren't authenticating
      - quarantine - We think we've got it all locked down, but even a very
      small risk of bouncing a big campaign is very scary to us,
and/or we don't
      fully trust SPF and DKIM to pass validation checks 100% of the time when
      they should, and it's better for us and our customer service staff if the
      mail we originate at least gets delivered to the recipients'
spam folders,
      regardless of the risk of our domain being spoofed.
      - reject - We've got everything locked down, we're confident in our
      choices, and if you, Mr. Receiver, accept messages that fail DMARC
      validation checks and your mailbox holders fall victim to a scam
because of
      it, it's your fault, not ours. Alternatively, 'reject' could also mean
      'this domain should never appear as the domain in the
RFC5322.From header',
      but with the same messaging about whose fault it is if messages are
      accepted and lead to a bad outcome.

In the worst case, the domain owner is just checking a box because they
think that "publishing a DMARC policy" means "my mail will make it to the
inbox".

Obviously indirect mail flows, such as mailing lists and forwarding,
complicate matters greatly here, as the handling by the intermediary
host(s) can and will lead to a higher percentage of authentication
failures. The community has attempted to mitigate this problem;
RFC5322.From header rewriting, RFC5321.From header rewriting (e.g., SRS),
and ARC are among the attempts put forth so far, but none have been deemed
The Solution(tm) yet. In my opinion, ARC has promise, because if a message
reaches me as a receiver or even intermediary and fails the authentication
checks I perform, ARC header sets in the message can tell me whether or not
such checks passed at previous hops *if I trust the entities that inserted
those ARC header sets*. In an earlier thread, I floated an idea about ARC
sealer reputation, but it didn't draw much response, so I'll float it here
again in the hopes that it does.

The idea is, I believe, simple in concept but complex in execution, and
perhaps extraordinarily so, and it requires that a mail handler have a
system in place to track reputation, however it defines reputation. We'll
let "X" represent an authenticated identity (i.e., a domain that passes an
authentication check) and "Y" represent the ARC Sealer identity; my idea
would work something like this:

   - The receiver has in its reputation system already historical data
   about direct mail flows where X was an authenticated identity, establishing
   X's reputation with the receiver
   - ARC header sets record the identities used in authentication checks at
   a given hop, and the purported results of those checks
   - For messages arriving with ARC header sets sealed by Y, with X as an
   authenticated identity in that header set:
      - If such messages earn a reputation for X that is consistent with
      that earned by X's direct mail flow, then Y builds a reputation as a
      trustworthy sealer. It doesn't matter whether X's reputation is good or
      bad, only that mail seen through the indirect flow has a
reputation that is
      consistent with mail seen through direct flow.
      - If such messages earn a reputation for X that is inconsistent with
      that earned by X's direct mail flow, then Y might build a reputation as a
      non-trustworthy sealer.

Now, there are a number of what-ifs here with the latter scenario, chief
among them "What if X's mail has a better reputation with an indirect flow
than it does with a direct flow?" and I haven't worked those out yet.
However, the larger point for me is that if X's mail is functionally the
same, reputationally, regardless of whether it arrives by direct or
indirect mail flow, then that is evidence that the ARC sealer (Y) can be
trusted. Of course X is just one data point in Y's reputation; all
authenticated identities that Y records in ARC header sets would play into
Y's reputation over time, and yeah, it's complicated.

Anyway, I've wandered far afield from your initial query, and though I
attempted to address it, I apologize in advance for my loquaciousness.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [email-masked]
*p:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Douglas Foster <[email-masked]>
Date: Wed, 16 Dec 2020 07:21:55 -0500

Thank you Todd.   I found this very helpful because it sets appropriately
low expectations but also describes a framework that I can envision
integrating into my filtering process.

Some version of these concepts need to be worked into the bis or BCP
document, so that product developers do not continue to implement SPF and
DMARC as on-off switches without integration to a local policy system which
implements the local reputation database.

Your comments about ARC do a better job of articulating its use case than I
have read anywhere else.   I have some ideas for elaborating them, but I
will save them for later, to avoid being reminded that forwarding is off
topic.

Doug Foster

---

From: Michael Thomas <[email-masked]>
Date: Fri, 18 Dec 2020 13:54:54 -0800

> I'm not sure there's anything actionable about DMARC's policy values.

you mean p=quarantine, or p=* in general?

> RFC5322.From header rewriting, RFC5321.From header rewriting (e.g., 
> SRS), and ARC are among the attempts put forth so far, but none have 
> been deemed The Solution(tm) yet. In my opinion, ARC has promise, 
> because if a message reaches me as a receiver or even intermediary and 
> fails the authentication checks I perform, ARC header sets in the 
> message can tell me whether or not such checks passed at previous hops 
> *if I trust the entities that inserted those ARC header sets*. In an 
> earlier thread, I floated an idea about ARC sealer reputation, but it 
> didn't draw much response, so I'll float it here again in the hopes 
> that it does.
>
We've always been able to check the reputation of lists that resign the 
message. The reputation is the previously (un)solved problem.

Mike

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 19 Dec 2020 11:24:44 +0100

On Fri 18/Dec/2020 22:54:54 +0100 Michael Thomas wrote:
>> In my opinion, ARC has promise, because if a message reaches me as a receiver 
>> or even intermediary and fails the authentication checks I perform, ARC 
>> header sets in the message can tell me whether or not such checks passed at 
>> previous hops *if I trust the entities that inserted those ARC header sets*. 
>> In an earlier thread, I floated an idea about ARC sealer reputation, but it 
>> didn't draw much response, so I'll float it here again in the hopes that it 
>> does.
>>

Yesterday 34 new domains —domains I never heard of before— sent 35 messages to 
my MX.  I count identifiers.  Some of them are subdomains of known domains, so 
they might inherit their parent's reputation.  Several others, however, are new 
organizational domains.  I'm just looking at the first 8, and none of them 
looks like a throw-away, freshly registered domain.

Now my tiny MX stores 115,225 domains total.  And I have no idea how I could 
add a trust-ARC-seals boolean field to each domain record.

Except for a few gigantic mailbox providers, I'd say the reputation problem is 
not quite solved.

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 19 Dec 2020 14:49:54 -0500

>add a trust-ARC-seals boolean field to each domain record.

You wouldn't.  Only a small fraction of those domains send enough forwarded
mail to be worth worrying about.  We know we need some sort of shared list
of plausible forwarders but I would be amazed if it were anything like 115K
domains.

R's,
John

---

From: Dotzero <[email-masked]>
Date: Sat, 19 Dec 2020 15:50:34 -0500

> of plausible forwarders but I would be amazed if it were anything like 115K

So the need for a shared list has been expressed a number of times. The
real question is who steps up to provide such shared lists.

Michael Hammer

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 20 Dec 2020 12:44:03 +0100

On Sat 19/Dec/2020 21:50:34 +0100 Dotzero wrote:
>>> Now my tiny MX stores 115,225 domains total.  And I have no idea how I
>>> could add a trust-ARC-seals boolean field to each domain record. >>
>> You wouldn't.  Only a small fraction of those domains send enough
>> forwarded mail to be worth worrying about.  We know we need some sort of
>> shared list of plausible forwarders but I would be amazed if it were
>> anything like 115K domains. >
> So the need for a shared list has been expressed a number of times. The real
> question is who steps up to provide such shared lists.

Dnswl.org counts about 25K domains.

Best
Ale
--

---

From: Todd Herr <[email-masked]>
Date: Sun, 20 Dec 2020 12:10:03 -0500

> you mean p=quarantine, or p=* in general?

Depending on the level of sophistication of a receiving email system, a
given email message can have dozens of signals (or data points) associated
with it, of which the relevant DMARC policy record, if it exists, is one.
Those signals can all be actionable, individually or collectively, or
ignored entirely, in that receiving system's decision to accept or reject
the message, and if it accepts it, the decision of where to place that
message.

If an applicable DMARC policy record exists for the RFC5322.From domain in
a message, the receiver can:

   - Perform the necessary authentication checks for DMARC validation, and
   use those validation results and the p= value as the sole or primary
   determining factor in how to handle the message, strictly applying the p=
   value in cases where it's not 'none' and validation checks fail
   - Perform the necessary authentication checks for DMARC validation, and
   use those validation results and the p= value as the sole or primary
   determining factor in how to handle the message, loosely applying the p=
   value in cases where it's not 'none' and validation checks fail (e.g.,
   placing the message in the spam folder even if p=reject is specified in the
   policy record)
   - Perform the necessary authentication checks for DMARC validation, and
   use those validation results and the p= value as one data point in a larger
   data set in how to handle the message
   - Ignore the DMARC policy record entirely

> Lists are a specific instance of the more general case of indirect mail
flows.

Any intermediate host can ARC seal and ARC-sign (a term I use as distinct
from re-sign) a message, an act that is meant to capture the results of
authentication checks done when it reached the intermediary. Whether or not
the receiver trusts those results (especially those results that claim that
authentication checks passed at the intermediary) when the message reaches
the receiver depends on the intermediary's reputation for being a truthful
sealer and signer, meaning whether or not it has established a history of
capturing authentication results that are true and accurate.

Since the receiver typically can't perform the same checks under the same
conditions that existed when the intermediary performed them (if it could,
we wouldn't need something like ARC) then the receiver has to decide if the
message is consistent with messages it's previously seen through direct
mail flows using that same authenticated identity that was captured by the
intermediary in the ARC header set.

If the indirect mail flow looks like the direct mail flow, then the sealer
is showing evidence that it can be trusted, and so the indirect mail flow
can receive the same treatment by the receiver that it would give to the
direct mail flow associated with the authenticated identity.

If the indirect mail flow looks different than the direct mail flow, then
the receiver can either decide to not trust the sealer and so treat the
indirect mail flow as unauthenticated, or perhaps it can dig into matters
further to see why the difference exists. A mailing list, for example, that
has subscribers whose domain is a consumer mailbox provider might just show
an indirect mail flow for that domain to the receiver that has a
substantially better overall reputation than the direct mail flow for that
domain to the receiver; rather than letting this difference impact the
level of trust in its sealing reputation that a receiver would assign to
the list, it may very well have to put in an override to its system for
tracking sealer trust.

--

---

From: "John R Levine" <[email-masked]>
Date: 20 Dec 2020 13:13:51 -0500

> Dnswl.org counts about 25K domains.

I suppose one might try them but I expect most of them are not sending 
forwarded mail.

I've finally gotten around to doing ARC checks in my SMTP daemon so I can 
see who's adding ARC seals.

Regards,

---

From: Douglas Foster <[email-masked]>
Date: Sun, 20 Dec 2020 15:53:19 -0500

Like any security problem, we need to minimize false positives (desired
mail being blocked) and false negatives (unwanted or malicious mail being
allowed).  ARC will hopefully address the false positives, but the false
negative issue remains.   The situation does not seem hopeless, but
the topic does appear to be underdeveloped.   Here are some observations:

SPF PASS means the message was received directly from the stated domain,
but it does not indicate whether or not the stated domain was the
originator, since the SMTP address may have been rewritten.   Similarly,
SPF FAIL indicates that the message was not received directly from the
stated domain, but it cannot distinguish between a message that originated
from an unauthorized source and a message that originated from an
authorized source but was then forwarded without SMTP rewrite.    The FAIL
could also be the result of a DNS configuration error, such as a domain
that changed hosting services without changing their SPF policy record.
The issues with failed DKIM signatures and From rewrite are similar.

A forwarded message may have:
- no address rewrite causing SPF FAIL but no masking of the
originator address,
- transparent address rewrite using SRS or ARC, or
- non-transparent replacement of prior SMTP and/or From addresses, without
SRS or ARC clues being included (as this list).

Consequently, the only reliable way to detect an untrusted source behind a
forwarder is to evaluate the entire message header chain.

Blacklisting
---------------
For purposes of filtering unwanted messages, verifiable header data is not
required.   (If someone wants to spoof an untrusted sender, I am happy to
consider that spoofer untrusted also.)   The Received chain can be checked
for IP addresses and DNS names with negative reputation.   Similarly, any
Received-SPF, Authentication-Results, ARC-Authenticated-Results,
Authenticated-As or similar headers can be checked for email domain names
with negative reputation.   All of this can and should be done regardless
of the SPF and DMARC status, because SPF and DMARC are designed around
direct mail flows, and SPF and DMARC pass can be achieved by pretending to
be a direct mail flow.

An additional test is to count the number of organizations that handled the
message along the delivery path.    First, consolidate out the
Received headers with private IPs or loopback IPs, then (probably) drop any
messages transferred over LMTP, and any transfers where the ReverseDNS and
HELO domains are unchanged in the handoff.   What should be left is a small
number of entries where the FROM information indicates the IP and hostnames
of the sending organization and the HELO name should be an MX of the
receiving organization.   (SPF checks and Forward-confirmed DNS checks can
then be performed on this data.)

For direct messages, I assume that the maximum number of organization
boundaries should be three:
- Cloud-based SMTP submitting client to mailstore organization,
- mailstore organization to cloud-based outbound filtering service,
- then outbound filtering service to destination domain.
Additionally, the cloud-based outbound filtering services are relatively
few and well known, which should simplify determining whether an
intermediate organization is a filtering service or a forwarding service.

It seems axiomatic that a forwarder will have an unreliable reputation with
recipients.   If the forwarder blocks a message, the recipient system will
not directly know that it was blocked, whether the blocked message was
wanted or unwanted.   But if the forwarder allows a message that the
recipient does not want, the forwarder takes a hit on its reputation.   An
automated forwarding service has an incentive to avoid false positives, so
it is almost certain to have a spam filtering policy which is weaker than
the final recipient system.    Rather than blaming the forwarding service
for unwanted messages getting through, the evaluator should look at the
entire received chain.

Whitelisting
---------------
It is much riskier to perform whitelisting based on the header data,
because one must allow for the possibility that a nation-state attacker
will construct a convincing but fraudulent header chain, if they perceive
that doing so will succeed.   But I cannot imagine whitelisting a message
from a random forwarder based on header data alone.  I would only do that
if the forwarding service, message originator, and forwarding path were
well understood from external sources.   In that case, a message from a
well-identified forwarding service with a sufficiently-identified message
originator might be a candidate for whitelisting.   But those situations
seem likely to be rare.

Conclusion
---------------
The overall conclusion is that if a message's only negative indicator is an
authentication failure, the best practice would be to send it to
administrative quarantine for local policies to be tailored to the
situation.   It seems foolish to block a message if sender authentication
failure is the only problem, unless domain abuse is actually confirmed
during the quarantine review.   It seems even more foolish to filter only
on the  identities provided by the submitting node, without evaluating the
entire header structure.

The unfortunate part of all this is that I suspect very few commercial
products evaluate the entire header.  Does anyone have data on this
question?

Where full scans are not implemented now, switching to a full scan will
significantly increase the processing overhead per message, which will
impact throughput.

Doug Foster

On Sun, Dec 20, 2020 at 12:10 PM Todd Herr <todd.herr=
[email-masked]> wrote:

>    - Perform the necessary authentication checks for DMARC validation,
>    and use those validation results and the p= value as the sole or primary
>    - Perform the necessary authentication checks for DMARC validation,
>    and use those validation results and the p= value as the sole or primary
>    - Perform the necessary authentication checks for DMARC validation,
>    and use those validation results and the p= value as one data point in a
>    larger data set in how to handle the message

---

From: Benny Pedersen <[email-masked]>
Date: Sun, 20 Dec 2020 23:01:17 +0100

> I suppose one might try them but I expect most of them are not sending

only sending to maillists here that breaks dkim and do not add arc 
before breaking dkim, world of 2020 cant be better :=)

> I've finally gotten around to doing ARC checks in my SMTP daemon so I
> can see who's adding ARC seals.

hopefully maillists stops dkim signing, its the incorrect place to solve 
breaking dkim

now that nearly all maillists i am on have showed what not to do, its 
hopefully solved soon

---

From: Michael Thomas <[email-masked]>
Date: Sun, 20 Dec 2020 14:07:31 -0800

On 12/20/20 2:01 PM, Benny Pedersen wrote:
>
> hopefully maillists stops dkim signing, its the incorrect place to 
> solve breaking dkim

Sorry, ARC is warmed over DKIM, and an experiment. DKIM is a full 
internet standard and expressly intended for lists, etc to resign if 
they broke the original DKIM signature. We have always had the ability 
to do reputation checks regardless of ARC. I'm not sure when this wg 
lost sight of that.

Mike

---

From: Benny Pedersen <[email-masked]>
Date: Mon, 21 Dec 2020 01:52:11 +0100

> to do reputation checks regardless of ARC. I'm not sure when this wg

only original senders should dkim sign, rest should only arc sign, i 
dont have to agre on anyhing other then that, if maillists dkim sign 
thay try to steel the original dkim private key without succes, and 
there is possible a solotion to dmarc adsp handling this break

seeing eitf do 3 dkim sign just to be sure it does not work

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 21 Dec 2020 18:27:04 +0100

On Mon 21/Dec/2020 01:52:11 +0100 Benny Pedersen wrote:
> only original senders should dkim sign, rest should only arc sign, i dont have 
> to agre on anyhing other then that, if maillists dkim sign thay try to steel 
> the original dkim private key without succes, and there is possible a solotion 
> to dmarc adsp handling this break
> 

For the message I'm replying to, I got:

Authentication-Results: wmail.tana.it;
   spf=pass smtp.mailfrom=ietf.org;
   dkim=pass reason="Original-From: transformed" (whitelisted) header.d=junc.eu;
   dkim=pass (whitelisted) header.d=ietf.org
     header.b=GUNfiCpP;
   dkim=fail (signature verification failed, whitelisted) header.d=ietf.org
     header.b=IIMQxhd+

Two out of three is not bad, is it?  If IETF only did ARC seals, I'd probably 
verified no signature at all —since I don't run ARC checks.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 21 Dec 2020 18:47:30 +0100

On Sun 20/Dec/2020 18:10:03 +0100 Todd Herr wrote:
> 
> Lists are a specific instance of the more general case of indirect mail flows.

How many kinds of indirect mail flows do rewrite From:?

Specific methods might prove more effective than general ones.

> [...]
> conditions that existed when the intermediary performed them (if it could, we 
> wouldn't need something like ARC) then the receiver has to decide if the 
> message is consistent with messages it's previously seen through direct mail 
> flows using that same authenticated identity that was captured by the 

Doesn't that assume some kind of omniscience at the receiver's?  Consistency 
with previous messages by the same source is not straightforward.  Using the 
same selector?  Signing more or less the same set of header fields?  Choice of 
vocabulary?  HTML vs. plain text style (e.g. line length)?  A.I.?

Best
Ale
--

---

From: Benny Pedersen <[email-masked]>
Date: Tue, 22 Dec 2020 03:37:52 +0100

> Two out of three is not bad, is it?  If IETF only did ARC seals, I'd
> probably verified no signature at all —since I don't run ARC checks.

metacpan Mail::DKIM gives dkim invalid if just one dkim is invalid, so 
spamassassin says aswell dkim invalid

what software used above to show this results ?

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 22 Dec 2020 10:38:05 +0100

> spamassassin says aswell dkim invalid

I don't think that's a reasonable choice.  A DKIM informative note exemplifies 
this very case:

       INFORMATIVE NOTE: The rationale of this requirement is to permit
       messages that have invalid signatures but also a valid signature
       to work.  For example, a mailing list exploder might opt to leave
       the original submitter signature in place even though the exploder
       knows that it is modifying the message in some way that will break
       that signature, and the exploder inserts its own signature.  In
       this case, the message should succeed even in the presence of the
       known-broken signature.
                          https://tools.ietf.org/html/rfc6376#section-6.1

> what software used above to show this results ?

zdkimfilter

Best
Ale
--

---

From: Todd Herr <[email-masked]>
Date: Tue, 22 Dec 2020 10:41:43 -0500

> Specific methods might prove more effective than general ones.
Sender Rewriting Scheme (SRS) exists for the rewriting of the RFC5321.From
address, and is sometimes used in mail that is forwarded by rule, say from @
alum.institution.edu to @consumerMailboxProvider.com

The larger point, though, is that mail that automatically passes through
one or more intermediary hosts on its way to its final destination can fail
authentication checks at the final destination due to the impact of changes
on the message, either in path, or content, or both, as it traverses that
journey. It seems to me that we can either work to find a way to ensure
that such failures don't happen, or we can work to find a reliable and
trustworthy way to record authentication results along the way so that the
failures can be mitigated and not result in failed delivery of wanted mail.

> mail
Not omniscience, no, but certainly a method of tracking an authenticated
identity's reputation, and consistency of reputation is what I'm speaking
of. Allow me to try again to get across the idea that I'm so far failing to
make clear.

I'm not currently working for a mailbox provider, but I have in the past,
and so I will role play as one here.

As a mailbox provider, I have a system for authenticating the identity or
identities associated with messages that come directly to me.

These authenticated identities can include some or all of:

   - The DKIM signing domain(s)
   - The DKIM signing domain(s) and selector(s)
   - The RFC5322.From domain (authenticated using DMARC)
   - The RFC5321.From domain (SPF)
   - The IP address of the client that passed the message to me
   - The domain associated with the PTR record of that IP address
   - Others as I deem useful

For each of these authenticated identities, I can and will track how my
users/customers/mailbox holders engage with the mail they receive, thus
over time establishing in my system a reputation to associate with each
authenticated identity. If, for example, mail that is DKIM signed using
selector S and domain D is mail that my users demonstrate through their
actions (opening it, clicking on links in it, etc.) is wanted mail, then
that authenticated identity (S._domainkey.D) will be associated with a good
reputation (however I define "good") in my system. Lather, rinse, and
repeat for other authenticated identities associated with the message, and
allow that both good and bad reputations can be earned.

Now here comes a message that is DKIM-signed by D with selector S, and it
fails DKIM validation when I do my checks. However, in scanning the
message, I see that there is an ARC header set, one that was signed and
sealed by A, and in that ARC header set is an ARC-Authentication-Results
header that says that the message passed DKIM validation with signing
domain D and selector S when A did its check.

My conundrum here is "Do I trust A's claim that the message was correctly
DKIM signed by domain D with selector S?"

The answer to that question will depend on how my users treat the message
and others like it, assuming that I accept it and deliver it. If my users
treat such messages in a manner that's consistent with how they treat
direct mail flow that is DKIM-signed by D with selector S, then A's
reputation as an ARC-sealer/signer will be positive, because A will
establish with me a history of being a source of ARC-sealed/signed mail
with ARC header sets that can be believed. On the other hand, if my users
consistently treat such messages differently than they do direct mail flow
that is DKIM-signed by D with selector s, then A's reputation as an
ARC-sealer/signer will be negatively impacted with me, because I will not
have evidence in hand that this is a path for mail with an authenticated
identity of S._domainkey.D to take.

The point here is that ARC (or any system designed to capture intermediate
authentication results) can only succeed if the downstream recipients of
the message trust the information that the intermediary host(s) record in
the message. What I'm describing above is one way to determine if that
information can be trusted, one that I'm trying to design to scale beyond
"Let me just whitelist these X hosts as reliable ARC sealer/signers."

--

---

From: Michael Thomas <[email-masked]>
Date: Tue, 22 Dec 2020 08:05:41 -0800

On 12/22/20 7:41 AM, Todd Herr wrote:
>
> My conundrum here is "Do I trust A's claim that the message was 
> correctly DKIM signed by domain D with selector S?"
>
which is why ARC brings nothing new to the table. it's not that it was 
correctly signed by the originator, it's whether i trust the mangler at 
all. if i do, then i implicitly trust that they handled the dkim 
verification too. it would be a lot more productive to work on that 
trust problem than hoping a renamed dkim signature is going to somehow 
change that.

Mike

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 22 Dec 2020 19:46:29 +0100

On Tue 22/Dec/2020 16:41:43 +0100 Todd Herr wrote:
>>> flows. >>
> address, and is sometimes used in mail that is forwarded by rule, say from
> @alum.institution.edu to @consumerMailboxProvider.com

VERP as done by MLMs is more specific (and better thought) than generic SRS.  I 
don't have numbers but off the top of my head I'd reckon MLMs cover a major 
part of RFC5321.From rewriters.  If you additionally select by RFC5322.From 
rewriting, I'd guess you're left with exactly MLMs.

> It seems to me that we can either work to find a way to ensure that
> [forwarding] failures don't happen, or we can work to find a reliable and 

Actually, people seem to be doing both.  Avoiding gratuitous autoconversions, 
anti-virus results as footers, and the like, have become a must for most modern 
MTA software.  And there are several mailing lists which operate that way as 
well.  OTOH, modifications are sometimes unavoidable and we still need to cope.

>>> Since the receiver typically can't perform the same checks under the
>>> same conditions that existed when the intermediary performed them (if it
>>> could, we wouldn't need something like ARC) then the receiver has to
>>> decide if the message is consistent with messages it's previously seen
>>> through direct mail flows using that same authenticated identity that
>>> was captured by the intermediary in the ARC header set. >>
>> Doesn't that assume some kind of omniscience at the receiver's? 
>> Consistency with previous messages by the same source is not
>> straightforward.  Using the same selector?  Signing more or less the same
>> set of header fields? Choice of vocabulary?  HTML vs. plain text style
>> (e.g. line length)?  A.I.? >

Except for PTR records, that's the data I collect to send out aggregate reports.

> allow that both good and bad reputations can be earned.

That's a delicate job.  For one point, 20161025._domainkey.gmail.com is not the 
kind of identifier you want to associate with users' liking, as it is shared 
among so many messages with diverging characteristics.  For another point, 
there are domains that change selector very often (taugh.com changes it on 
every message), so it can identify too narrow a message set.

Characterizing by author (a.k.a. RFC5322.From) probably works better.  An 
author authenticated by her submission server (a.k.a. author's domain) looks 
like a good identifier.  You still have to sort out authors having multiple 
email address and using them interchangeably.

However, as forwarding of modified messages settles on From: rewriting, 
recovering that identifier becomes fuzzy.  ARC does not cover that bit.  If we 
want to reliably use the author as an identifier, we need those forwarders who 
rewrite the From: header field —let's call'em MLMs— to adopt a standard way to 
convey the original value.  In my mlm-transform draft, I propose 
Original-From:.  IETF uses X-Original-From:.  Mailman uses Reply-To: or Cc:.

> identity of S._domainkey.D to take.

Here you're pairing a method which is fuzzy in nature with one, digital 
signatures, designed to be strictly binary.  You need a very large user base to 
achieve meaningful results.  Most medium/ small mailbox provider, think company 
servers to family MXes, will not even want to spy on users to determine their 
liking.

> "Let me just whitelist these X hosts as reliable ARC sealer/signers."

Overall, your plan confirms that ARC better suits global mailbox providers.

Best
Ale
--