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

"Chris Lewis" <clewis@nortel.com> Mon, 08 February 2010 18:36 UTC

Return-Path: <CLEWIS@nortel.com>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id C8B5A3A723A for <asrg@core3.amsl.com>; Mon, 8 Feb 2010 10:36:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.53
X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id cmjlikhsCvNA for <asrg@core3.amsl.com>; Mon, 8 Feb 2010 10:36:18 -0800 (PST)
Received: from zcars04e.nortel.com (zcars04e.nortel.com []) by core3.amsl.com (Postfix) with ESMTP id AA1D73A71DD for <asrg@irtf.org>; Mon, 8 Feb 2010 10:36:17 -0800 (PST)
Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com []) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id o18IbGq00241 for <asrg@irtf.org>; Mon, 8 Feb 2010 18:37:16 GMT
Received: from zrtphx5h0.corp.nortel.com ([]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Feb 2010 13:37:15 -0500
Received: from [] ( by zrtphx5h0.corp.nortel.com ( with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 8 Feb 2010 13:37:15 -0500
Message-ID: <4B7059C9.2060102@nortel.com>
Date: Mon, 8 Feb 2010 13:36:57 -0500
From: "Chris Lewis" <clewis@nortel.com>
Organization: Nortel
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090812 Lightning/0.9 Thunderbird/ Mnenhy/
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <20100208153359.56374.qmail@simone.iecc.com> <20100208164237.389722425C@panix5.panix.com> <4B704FFC.8040306@tana.it>
In-Reply-To: <4B704FFC.8040306@tana.it>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Feb 2010 18:37:15.0923 (UTC) FILETIME=[BCA69630:01CAA8ED]
Subject: [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: Mon, 08 Feb 2010 18:36:18 -0000

Alessandro Vesely wrote:

> That's the risk we run when _mis_directing ARs. It can be minimized by 
> choosing a header that MTAs are aware of and actively zap unless 
> trusted, just like the A-R field of rfc 5451. Possible alternatives 
> may be to
> 1. use 5451's authserv-id,
> 2. create an A-R's extension, or
> 3. create a brand new header field.

I've been glancing at RFC5451, and beginning to realize that 
"destination discovery" by out-of-band methods will make the MUA's job 
quite confusing in the case of multiple MDAs.  How better to direct it 
to the right place if the MDA (or incoming border MTA) can specifically 
identify where the reports should go, in-band?

[Yes, I think I've flip-flopped again :-(]

Could we not do this by extending 5451 semantics to have a "where to 
complain to" cause?

I note that 5451 specifically talks about/permits stripping of upstream 
Authentication-Results:, both where the MTA figures it's being spoofed, 
or simply all upstream at gateways or others as policy dictates.

MUAs could merely take the most recent AR headers that have the 
appropriate complain-to fields.  Exposure is limited to MUAs that will 
do this on MTA/MDAs that haven't done anything about AR headers and 
doesn't insert one of their own.