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

Alessandro Vesely <vesely@tana.it> Mon, 06 April 2020 15:55 UTC

Return-Path: <vesely@tana.it>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402803A0B49 for <dmarc@ietfa.amsl.com>; Mon, 6 Apr 2020 08:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUbZtyIIaHf8 for <dmarc@ietfa.amsl.com>; Mon, 6 Apr 2020 08:55:17 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 341F73A0B22 for <dmarc@ietf.org>; Mon, 6 Apr 2020 08:55:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1586188506; bh=wgUEq4Hb3+3EPtSmABe+PzotnI5GCoXPSuC9Ws+JDN4=; l=2473; h=To:References:From:Date:In-Reply-To; b=DDHpSmtNlEup8VlrcSzlPDCufZTHbJvnp9sgov2lOklPjZRV7KnZOr7qdsjsAftth duk16J1ROTcHI+WQ6aAls034xZ7XIwpVWIqLH0M0WPwuTGkJFluQmwzWqLTITcpnGF mKMIod4NsD0HgJzdhwkjN3eILQmaYukm00She+YXIDe3hf1xoRwmZwqkOuKyX
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC056.000000005E8B50DA.00000BA8; Mon, 06 Apr 2020 17:55:06 +0200
To: dmarc@ietf.org
References: <e2bd3117-2217-1206-0c0c-f06a35d49dca@arcsin.de> <CABa8R6sbHLfkzHD4gaPBxQbgNy57J1eLXt2sPyAfaTYAY3tG-Q@mail.gmail.com> <0fbab9d5-d00e-42ff-3059-8cb269ff1591@arcsin.de>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <7084d678-ce11-fa3f-8b59-67e46da841f7@tana.it>
Date: Mon, 06 Apr 2020 17:55:06 +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: <0fbab9d5-d00e-42ff-3059-8cb269ff1591@arcsin.de>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/fybtPjDE2jOEAOCMArS7KUEWHOg>
Subject: Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Apr 2020 15:55:20 -0000

On Fri 03/Apr/2020 22:42:23 +0200 Damian Lukowski wrote:
>> 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:


My system, my rules:


>> Authentication-Results: domain.tld; spf=pass smtp.mailfrom=x@y.z
> 
> Needs to be removed? Clearly yes.


Yes, and log it.


>> Authentication-Results: otherdomain.tld; spf=pass smtp.mailfrom=x@y.z
> 
> Needs to be removed? Clearly no.


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


>> Authentication-Results: {garbage}
> 
> Needs to be removed? I say no.


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


>> Authentication-Results: domain.tld, spf=pass smtp.mailfrom=x@y.z
> 
> Needs to be removed? I say no.


Yes, and log it.


>> Authentication-Results: domain.tld; {garbage}
> 
> Needs to be removed? I say no.


Yes, and log it.


>> Authentication-Results: "domain.tld"; {garbage}
> 
> Needs to be removed? I say no.
> 
>> Authentication-Results: "domain.tld"; spf=pass smtp.mailfrom=x@y.z
> 
> 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.)