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

"Murray S. Kucherawy" <msk@cloudmark.com> Fri, 17 February 2012 06:32 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 8821721F8734 for <apps-discuss@ietfa.amsl.com>; Thu, 16 Feb 2012 22:32:19 -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 8bbJZsoPeDxP for <apps-discuss@ietfa.amsl.com>; Thu, 16 Feb 2012 22:32:19 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0C78C21F8732 for <apps-discuss@ietf.org>; Thu, 16 Feb 2012 22:32:18 -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 22:32:18 -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 22:32:18 -0800
From: "Murray S. Kucherawy" <msk@cloudmark.com>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Date: Thu, 16 Feb 2012 22:32:17 -0800
Thread-Topic: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03
Thread-Index: AcztLXUQWsxG/6S8TDC74LT5IWd1awACbOQw
Message-ID: <F5833273385BB34F99288B3648C4F06F19C9A7DDDD@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> <F5833273385BB34F99288B3648C4F06F19C9A7DDD4@EXCH-C2.corp.cloudmark.com> <6.2.5.6.2.20120216201037.0901f720@resistor.net>
In-Reply-To: <6.2.5.6.2.20120216201037.0901f720@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: Fri, 17 Feb 2012 06:32:19 -0000

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of SM
> Sent: Thursday, February 16, 2012 8:34 PM
> To: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03
> 
> >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?
> 
> If the SMTP server sends a 421, it would force the connection to close.
> The usual implementations usually provide some text with the 450.  The
> 421 comment I have seen was generic.
> 
> I'll presume that a 421 means "service unavailable" as described in RFC
> 5321.  BTW, 421 is sometimes used for load shedding.

I don't think we can make the presumption that the text accompanying 421 will be more or less descriptive than the text accompanying 450.  The implementation will decide in either case.  Proscribing use of 421 by itself won't compel implementers to make the 450 text more helpful.

So the question comes down to whether or not the implementer wants to dump the connection or let it linger.  There's also the common argument that if you've decided to greylist a client because it might be a spammer, you probably don't want to be helpful to it at all anyway.

I'll try to come up with some text that walks the line between the two perspectives.

> >    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".
> 
> Local policy in SMTP provides leeway.  It can be used for abuse
> mitigation.  In my opnion, that's not an Internet capability.

Since the work of greylisting involves an altered but still interoperable interaction between clients and servers, I believe it does qualify.

Do others want to weigh in on this?

-MSK