Subject: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers

From: Damian Lukowski <[email-masked]>
Date: Fri, 3 Apr 2020 18:09:44 +0200

RFC8601 sec 5 states:

> any MTA conforming to
> this specification MUST delete any discovered instance of this header
> field that claims, by virtue of its authentication service
> identifier, to have been added within its trust boundary but that did
> not come directly from another trusted MTA.

In my opinion, a header that does not conform to the specified
authres-header-field in the RFC, is not an Authentication-Results
header, has no authentication service identifier, and as such cannot
claim anything in the context of the RFC. So suppose there is a mail
system with an UTF-8-non-ASCII authserv-id. When creating its own A-R
headers, it puts the authserv-id into quotes, because it cannot use it
without them, as discussed in the separate thread.

What should the system do with an A-R header of an inbound message that
incorporates the system's authentication service identifier without
using quotes, but that otherwise would be syntactically correct?

Again in my opinion, the system needs to keep the header, but what is
the RFCs intention?

---

From: Brandon Long <[email-masked]>
Date: Fri, 3 Apr 2020 12:59:31 -0700

I can see there being an issue here if the inbound smtp server that would
normally remove existing AuthRes headers for its admd before adding its own
uses a different algorithm than any downstream systems used.

In particular, theoretically the inbound smtp server may use software from
a different source than the spam system or the clients which consume this
header.

In practice, I don't know how common it is for clients to consume this
header.

Also, any mis-handling should be treated as a bug.

The system should remove the quotes when comparing, and should also do any
decoding to get the admds into the same format.

Brandon

On Fri, Apr 3, 2020 at 9:10 AM Damian Lukowski <[email-masked]> wrote:

> authres-header-field in the RFC, is not an Authentication-Results header,
> has no authentication service identifier, and as such cannot claim anything
> in the context of the RFC. So suppose there is a mail system with an
> UTF-8-non-ASCII authserv-id. When creating its own A-R headers, it puts the
> authserv-id into quotes, because it cannot use it without them, as
> discussed in the separate thread.
>
> incorporates the system's authentication service identifier without using
> quotes, but that otherwise would be syntactically correct?
>
> Again in my opinion, the system needs to keep the header, but what is the
> RFCs intention?
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: "John Levine" <[email-masked]>
Date: 3 Apr 2020 16:05:26 -0400

In article <[email-masked]> you write:
>claim anything in the context of the RFC. ...

Honestly, it doesn't matter.  The only A-R headers you can trust are
the ones that your own system added, and the point of that text is
that you should delete ones that look like yours but that you didn't
add.

We leave other people's A-R headers in case they might be useful to
do forensics, and we have a slightly different version of them in
ARC chains which again are only trustworthy if you know who added
the ARC seals.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 3 Apr 2020 16:09:37 -0400

>In practice, I don't know how common it is for clients to consume this

They have to if they're adding ARC seals on the way out.  Other than
that I don't have much idea either.  On my system my mailing list software
looks at it them to decide how much DMARC hackery to do but again I don't
know how common that is.

Since the point of the text is that you can only trust your own A-R
headers, presumably the code that adds them and that consumes them are
at least partly under the same management so I'd think they could agree
on their quoting practices.

R's,
John

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 3 Apr 2020 13:18:52 -0700

On Fri, Apr 3, 2020 at 1:09 PM John Levine <[email-masked]> wrote:

> In article <
> [email-masked]> you
> write:
> They have to if they're adding ARC seals on the way out.
>

Only if the ADMD's particular implementation to pass through the
information from incoming perimeter system to outgoing perimeter system
happens to utilize the A-R header(s) for the purpose of conveying that
information.

--Kurt

---

From: "John R Levine" <[email-masked]>
Date: 3 Apr 2020 16:30:09 -0400

> happens to utilize the A-R header(s) for the purpose of conveying that

It would seem pretty perverse to create an AAR header with exactly the 
same info as the AR header by ignoring the AR header.  But whatever.

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

---

From: Damian Lukowski <[email-masked]>
Date: Fri, 3 Apr 2020 22:42:23 +0200

> The system should remove the quotes when comparing, and should also do
> any decoding to get the admds into the same format.

My question's intent was not particularly about the quotes and UTF-8, I
just chose it, because the syntactically invalid version looks more
legit than the syntactically valid one. Assume some plain-ASCII
examples. A mail system with own authservid of domain.tld receives mail
with:

> Authentication-Results: domain.tld; spf=pass smtp.mailfrom=[email-masked]

Needs to be removed? Clearly yes.

> Authentication-Results: otherdomain.tld; spf=pass smtp.mailfrom=[email-masked]

Needs to be removed? Clearly no.

> Authentication-Results: {garbage}

Needs to be removed? I say no.

> Authentication-Results: domain.tld, spf=pass smtp.mailfrom=[email-masked]

Needs to be removed? I say no.

> Authentication-Results: domain.tld; {garbage}

Needs to be removed? I say no.

> Authentication-Results: "domain.tld"; {garbage}

Needs to be removed? I say no.

> Authentication-Results: "domain.tld"; spf=pass smtp.mailfrom=[email-masked]

Needs to be removed? Yes.

---

From: Damian Lukowski <[email-masked]>
Date: Fri, 3 Apr 2020 22:53:57 +0200

> that you should delete ones that look like yours but that you didn't

How can a MUST not matter? My personal interest in this area is what
needs to be done according to the specification, which unfortunately
uses a metaphoric verb for the condition of the MUST.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 6 Apr 2020 17:55:06 +0200

> Needs to be removed? Clearly yes.

Yes, and log it.

> Needs to be removed? Clearly no.

Rename the header field to Old-Authentication-Results anyway.

> Needs to be removed? I say no.

Rename the header field to Old-Authentication-Results anyway.

> Needs to be removed? I say no.

Yes, and log it.

> Needs to be removed? I say no.

Yes, and log it.

> Needs to be removed? Yes.

Both cases are renamed to Old-Authentication-Results anyway.  The part that
would log it, however, doesn't recognize the quotes (I'm going to fix it now)
and intermittently removes the header.

Note that some tools, e.g. Thunderbird DKIM-Verifier[*] can be configured to
either "Read Authentication-Results header" or not.  Hence is makes sense to
rename all on entry.

Note2: even if a tool accepted a list of trusted authserv-id's, consider a MUA
simultaneously accessing two mailboxes, at example.com and example.org, say.
Of course you would configure the tool to trust both of their authserv-id
(which is already beyond what an average user is willing to configure).  Then,
a malicious party can send you a message at your @example.com address, bearing
a faked Authentication-Results by example.org.  Should the tool trust it?

jm2c
Ale
-- 

[*]
https://www.reddit.com/r/Thunderbird/comments/5nheej/is_it_possible_to_make_thunderbird_display_the/
(The "Edit 2" is bogus, but the previous edit describes the point well.)

---

From: Damian Lukowski <[email-masked]>
Date: Tue, 7 Apr 2020 09:09:01 +0200

>> Needs to be removed? I say no.

Please notice the comma instead of the semicolon, it wasn't a typo.
Would you still remove it?

>> Needs to be removed? I say no.

Interesting, you suggest to parse "lazily", i.e. as soon as a token
looks like an authserv-id, treat it as such.

> and intermittently removes the header.

I wanted to object that the RFC does not allow to tamper with "innocent"
headers, but it actually does not forbid it. That said, I could even
remove previous A-R headers altogether and be RFC compliant, so a lazy
evaluation parser can be compliant as well.

Thanks.

> a faked Authentication-Results by example.org.  Should the tool trust it?

Wouldn't a trust-list per mailbox solve the issue, instead of a global
trust-list?

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 7 Apr 2020 10:47:54 +0200

> Would you still remove it?

If I can lazily (or sloppily) identify it as an authserv-id, so can do other
tools too.

> evaluation parser can be compliant as well.

IMHO that's the simplest approach.  By renaming (otherwise obscuring) instead
of deleting you still leave room for debugging and forensics.

> Wouldn't a trust-list per mailbox solve the issue, instead of a global

Per-mailbox lists might seem to do it.  However, consider, in the above
scenario, making the decision to forward some or all of your @example.org
traffic to your example.com mailbox, directly from example.org server.  Now
you'd want to trust example.org A-Rs even when they arrive through example.com.
 The only easy way that I see to accomplish that is to instruct example.com to
whitelist example.org's A-R; if example.com admins trust example.org, that is:

   For simplicity and maximum security, a border MTA could remove all
   instances of this header field on mail crossing into its trust
   boundary.  However, this may conflict with the desire to access
   authentication results performed by trusted external service
   providers.  [...]  A more robust border
   MTA could allow a specific list of authenticating MTAs whose
   information is to be admitted, removing the header field originating
   from all others.
                         https://tools.ietf.org/html/rfc8601#section-5

Best
Ale
--