IETF Logo Mail Archive

Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03

"Murray S. Kucherawy" <msk@cloudmark.com> Thu, 16 February 2012 23:41 UTC

Return-Path: <msk@cloudmark.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC29321E8047 for <apps-discuss@ietfa.amsl.com>; Thu, 16 Feb 2012 15:41:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.594
X-Spam-Level:
X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e71oLwTnGQbH for <apps-discuss@ietfa.amsl.com>; Thu, 16 Feb 2012 15:41:12 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1A24F21E8040 for <apps-discuss@ietf.org>; Thu, 16 Feb 2012 15:41:12 -0800 (PST)
Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 16 Feb 2012 15:41:11 -0800
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 16 Feb 2012 15:41:11 -0800
From: "Murray S. Kucherawy" <msk@cloudmark.com>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Date: Thu, 16 Feb 2012 15:41:09 -0800
Thread-Topic: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03
Thread-Index: AcztA3e+C8IzKa38S6egzcROziHnyAAAIE2A
Message-ID: <F5833273385BB34F99288B3648C4F06F19C9A7DDD4@EXCH-C2.corp.cloudmark.com>
References: <6.2.5.6.2.20120215194417.098a0438@elandnews.com> <4F3D0EE5.9060008@dcrocker.net> <6.2.5.6.2.20120216143635.09cc8660@resistor.net>
In-Reply-To: <6.2.5.6.2.20120216143635.09cc8660@resistor.net>
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
Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Feb 2012 23:41:13 -0000

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of SM
> Sent: Thursday, February 16, 2012 3:33 PM
> To: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03
> 
> >What about saying 421 for sites that want to kill the connection
> >immediately, and 450 otherwise?
> 
>  From RFC 5321:
> 
>    "450  Requested mail action not taken: mailbox unavailable (e.g.,
>     mailbox busy or temporarily blocked for policy reasons)"
> 
> The 450 code is listed for RCPT and end of data indicator.  Greylisting
> fits "policy reason".  I'll suggest using 450 to keep this separate
> from non-policy conditions.  That code does not fit it for connection
> establishment as the SMTP server kills the connection.  There would
> have to be some text for the 421 exception.  I have a strong preference
> for not encouraging the 421 (debugging comment) as it is hard to tell
> whether there is a problem or if this is policy stuff.

So we agree that if one doesn't go for 421, then 450 is appropriate.  But a server could say either one without any comment text and be equally un-useful to the client.

That is, if a client does 421 and dumps the connection, versus doing 450 but keeping the connection open (but probably unable to do anything), I don't see the benefit of the latter for either party.  Are you presuming that the 421 comment will be generic while a 450 might be descriptive?

> >I think a specific use of a TS to implement a technique falls within
> >the definition of an AS.
> 
> An Applicability Statement is about setting or adapting requirement
> levels for a specific use.  I don't think that providing degraded
> service qualifies for it.

The definition of AS from RFC2026 is:

   An Applicability Statement specifies how, and under what
   circumstances, one or more TSs may be applied to support a particular
   Internet capability.

I would say abuse mitigation qualifies as a "capability".

-MSK

v2.23.0 | Report a Bug | By Email