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

Alessandro Vesely <> Tue, 07 April 2020 08:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CAAA83A192B for <>; Tue, 7 Apr 2020 01:47:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1152-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YUHCHeQ_rC8r for <>; Tue, 7 Apr 2020 01:47:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 99AC93A18C1 for <>; Tue, 7 Apr 2020 01:47:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=delta; t=1586249274; bh=/zG9ksMY263dRgRI+6gOFqZatlnfthv05svqDB4WGPw=; l=2594; h=To:References:From:Date:In-Reply-To; b=BgRyV455OWWczhJZLL09p5a/j9a9YFKBCkR5AtvlviZqDfacw7Pk7q/NLPBvdoddA 0TvUoGKDXgMq+SinevKXb63KF/rYVce8wKyn86mC48nawqjdAUpDCCoHmI9dYgl6K9 hRmJlWm4oz23QXvKKjrtECxvXGmSkkC4NPzExtLyeeN25esNnFjPVzhTuRwdD
Authentication-Results:; auth=pass (details omitted)
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by with ESMTPSA id 00000000005DC02A.000000005E8C3E3A.000037D2; Tue, 07 Apr 2020 10:47:54 +0200
References: <> <> <> <> <>
From: Alessandro Vesely <>
Message-ID: <>
Date: Tue, 7 Apr 2020 10:47:54 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Apr 2020 08:47:59 -0000

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 and, 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 address, bearing
>> a faked Authentication-Results by  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
traffic to your mailbox, directly from server.  Now
you'd want to trust A-Rs even when they arrive through
 The only easy way that I see to accomplish that is to instruct to
whitelist's A-R; if admins trust, 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.