Re: [Asrg] RFC5451 Re: who gets the report, was We really don't need

Alessandro Vesely <vesely@tana.it> Wed, 10 February 2010 18:33 UTC

Return-Path: <vesely@tana.it>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 882823A7781 for <asrg@core3.amsl.com>; Wed, 10 Feb 2010 10:33:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.679
X-Spam-Level:
X-Spam-Status: No, score=-4.679 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUjtUfJ7ywxk for <asrg@core3.amsl.com>; Wed, 10 Feb 2010 10:33:53 -0800 (PST)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id B3C023A777F for <asrg@irtf.org>; Wed, 10 Feb 2010 10:33:53 -0800 (PST)
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 10 Feb 2010 19:35:03 +0100 id 00000000005DC035.000000004B72FC57.0000076A
Message-ID: <4B72FC56.5070508@tana.it>
Date: Wed, 10 Feb 2010 19:35:02 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: asrg@irtf.org
References: <20100208153359.56374.qmail@simone.iecc.com> <20100208164237.389722425C@panix5.panix.com> <4B704FFC.8040306@tana.it> <4B7059C9.2060102@nortel.com> <BB012BD379D7B046ABE1472D8093C61C01C3C452A4@EXCH-C2.corp.cloudmark.com> <4B7070AF.2050304@nortel.com> <2E34570FC4E61E0A7E857EBF@lewes.staff.uscs.susx.ac.uk> <4B717820.9090506@tana.it> <BB012BD379D7B046ABE1472D8093C61C01C3C454E2@EXCH-C2.corp.cloudmark.com> <4B7268F5.1040909@tana.it> <BB012BD379D7B046ABE1472D8093C61C01C3C455C6@EXCH-C2.corp.cloudmark.com>
In-Reply-To: <BB012BD379D7B046ABE1472D8093C61C01C3C455C6@EXCH-C2.corp.cloudmark.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] RFC5451 Re: who gets the report, was We really don't need
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Feb 2010 18:33:54 -0000

On 10/Feb/10 18:22, Murray S. Kucherawy wrote:
>>>>>   Could the MDA add a DKIM signature for the authentication results header?
>>>>
>>>>   Yes, it could. However, removal of the field on forwarding would then break the signature.
>>>
>>>  True, but you don't have to do that.
>>
>>  But retention is only allowed for trusted internal MTAs.
>
> More accurately, removal is required if the A-R header claims to be one of yours but it's not coming from an MTA you trust (e.g. one of your border MXes).
>
> An A-R header claiming to be from elsewhere doesn't have to be purged, so a signature covering it would continue to validate.  The MUA, however, is supposed to know to ignore those.

Thanks for the clarification! The last sentence in section 5 kept 
confusing me...