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

[Alessandro Vesely <[e-mail]>]

On Tue 07/Apr/2020 09:09:01 +0200 Damian Lukowski wrote:
>>>> Authentication-Results: domain.tld, spf=pass smtp.mailfrom=x@y.z
>>>
>>> Needs to be removed? I say no.
>> 
>> 
>> Yes, and log it.
> 
> Please notice the comma instead of the semicolon, it wasn't a typo.
> Would you still remove it?


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


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


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


>> 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?
> 
> Wouldn't a trust-list per mailbox solve the issue, instead of a global
> trust-list?


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