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.)
- [dmarc-ietf] Spirit of RFC8601 section 5 for inva… Damian Lukowski
- Re: [dmarc-ietf] Spirit of RFC8601 section 5 for … Brandon Long
- Re: [dmarc-ietf] Spirit of RFC8601 section 5 for … John Levine
- Re: [dmarc-ietf] Spirit of RFC8601 section 5 for … John Levine
- Re: [dmarc-ietf] Spirit of RFC8601 section 5 for … Kurt Andersen (b)
- Re: [dmarc-ietf] Spirit of RFC8601 section 5 for … John R Levine
- Re: [dmarc-ietf] Spirit of RFC8601 section 5 for … Damian Lukowski
- Re: [dmarc-ietf] Spirit of RFC8601 section 5 for … Damian Lukowski
- Re: [dmarc-ietf] Spirit of RFC8601 section 5 for … Alessandro Vesely
- Re: [dmarc-ietf] Spirit of RFC8601 section 5 for … Damian Lukowski
- Re: [dmarc-ietf] Spirit of RFC8601 section 5 for … Alessandro Vesely