Re: [secdir] SECDIR review of draft-kucherawy-authres-vbr

David McGrew <mcgrew@cisco.com> Fri, 07 January 2011 15:19 UTC

Return-Path: <mcgrew@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 048C63A67F4; Fri, 7 Jan 2011 07:19:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 xO7k8P926BRx; Fri, 7 Jan 2011 07:19:44 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 1C7223A67E9; Fri, 7 Jan 2011 07:19:44 -0800 (PST)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEALW+Jk2rRN+K/2dsb2JhbACkKHOjS5g4hUwEhGeGIoMe
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 07 Jan 2011 15:21:50 +0000
Received: from [10.32.254.210] ([10.32.254.210]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p07FLnkr022078; Fri, 7 Jan 2011 15:21:50 GMT
Message-Id: <53F0388A-4BFF-4474-B504-EE3C2DD3DB19@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: "Murray S. Kucherawy" <msk@cloudmark.com>
In-Reply-To: <F5833273385BB34F99288B3648C4F06F1341E73CFC@EXCH-C2.corp.cloudmark.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 7 Jan 2011 07:21:49 -0800
References: <07F215F7-78DF-4B09-AF28-F75FF15FD9CD@cisco.com> <F5833273385BB34F99288B3648C4F06F1341E73CFC@EXCH-C2.corp.cloudmark.com>
X-Mailer: Apple Mail (2.936)
Cc: "draft-kucherawy-authres-vbr@tools.ietf.org" <draft-kucherawy-authres-vbr@tools.ietf.org>, The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] SECDIR review of draft-kucherawy-authres-vbr
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jan 2011 15:19:45 -0000

Hi Murray,

On Jan 6, 2011, at 10:36 AM, Murray S. Kucherawy wrote:

> Hi David.  Thanks for your comments.
>
>> -----Original Message-----
>> From: David McGrew [mailto:mcgrew@cisco.com]
>> Sent: Thursday, January 06, 2011 7:58 AM
>> To: draft-kucherawy-authres-vbr@tools.ietf.org; secdir@ietf.org;  
>> The IESG
>> Subject: SECDIR review of draft-kucherawy-authres-vbr
>>
>> [...]
>>
>> Section 1.  It is not clear what problem is referred to in paragraph
>> two.
>
> The "problem" (though I agree it could be worded better) is that VBR  
> came along after Authentication-Results was published, and so  
> there's currently no standard way to convey VBR results in past a  
> border gateway.
>
>> Section 4.
>>
>> What behavior should a mail filter have upon receiving the result
>> codes defined in that section?   If the recommended behavior is
>> defined elsewhere (presumably [VBR]), then it should be referenced in
>> this section.
>
> Reactions to the information provided within an Authentication- 
> Results field is entirely up to the consumer(s) of that  
> information.  It's all a matter of local policy, and thus not  
> specified in either document.  RFC5451 and its extensions only  
> define the mechanism for transmitting that information inbound past  
> border gateways.
>
>> What behavior should a border mail gateway have upon receiving a VBR
>> response?   For instance, under what conditions (if any) should a
>> border mail gateway not forward an email on which VBR has returned
>> "fail"?   I would guess that this draft expects gateways to always
>> forward emails, and regards a mail filter as a logically separate
>> entity.  I suggest clarifying this point.
>
> Again, it's a matter of local policy.  A gateway detecting a VBR,  
> DKIM, SPF or any other failure is at liberty to reject or quarantine  
> the message, or allow it to pass after adding those results via the  
> mechanism of RFC5451 so that internal filters or MUAs can take  
> whatever action they deem necessary without repeating those  
> mechanisms themselves.
>
> Since this is just an extension to the existing mechanism, I'm not  
> sure it's useful to discuss it in this memo.  It would be better  
> discussed in an RFC5451bis since it applies to the mechanism itself  
> and not this extension.  That said, I'll add mention of this in an  
> -03 draft if that's the preference.

I'm surprised that it's not discussed in RFC5451, but given that fact  
I certainly agree that RFC5451bis would be the right place for it.

David

>
> -MSK
>