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

"Murray S. Kucherawy" <msk@cloudmark.com> Thu, 06 January 2011 18:34 UTC

Return-Path: <msk@cloudmark.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 E1D973A6F3D; Thu, 6 Jan 2011 10:34:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.048
X-Spam-Level:
X-Spam-Status: No, score=-104.048 tagged_above=-999 required=5 tests=[AWL=-0.449, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 I0G1cPlYwsAm; Thu, 6 Jan 2011 10:34:31 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id EAAF73A6F36; Thu, 6 Jan 2011 10:34:31 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 6 Jan 2011 10:36:38 -0800
From: "Murray S. Kucherawy" <msk@cloudmark.com>
To: David McGrew <mcgrew@cisco.com>, "draft-kucherawy-authres-vbr@tools.ietf.org" <draft-kucherawy-authres-vbr@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>
Date: Thu, 6 Jan 2011 10:36:37 -0800
Thread-Topic: SECDIR review of draft-kucherawy-authres-vbr
Thread-Index: AcutupEeVcqrZszkSzOCa5gOzXSQewAFUteg
Message-ID: <F5833273385BB34F99288B3648C4F06F1341E73CFC@EXCH-C2.corp.cloudmark.com>
References: <07F215F7-78DF-4B09-AF28-F75FF15FD9CD@cisco.com>
In-Reply-To: <07F215F7-78DF-4B09-AF28-F75FF15FD9CD@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 06 Jan 2011 12:22:36 -0800
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: Thu, 06 Jan 2011 18:34:33 -0000

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.

-MSK