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

From: SM <[email-masked]>
Date: Wed, 15 Feb 2012 21:30:14 -0800

Hi Murray,

Here are some comments on draft-ietf-appsawg-greylisting-03.  The 
title of the document is "An Applicability Statement for SMTP".  If 
we ignore that greylisting is a antispam technique that reuses one of 
the properties of SMTP, that might be appropriate.

In Section 1:

   'Preferred techniques for handling email abuse explicitly identify
    good actors and bad actors, giving each significantly differential
    service.  In some cases an actor does not have a known reputation;
    this can justify providing degraded service, until there is a basis
    for provider better service.  This latter approach known as
    "greylisting".'

The last sentence seems incomplete.  The above is one way to look at 
greylisting.  Another way would be to describe the SMTP angle which 
is to relying on SMTP retries to "reject" mail delivery on the first 
try if the SMTP client is not known to the SMTP server.  That is 
mentioned in Section 1.1.  I suggest having the Background Section first.

   'Greylisting exploits this by rejecting  mail from unfamiliar
    sources with a "soft fail" (4xx) [SMTP] error code'

"soft fail" is an euphemism of Section 4.2.1 of RFC 5321. 
:-)  maemuki ni kento sasete itadakimasu.

  'Another, less well-developed, application of greylisting is
   to delay mail from newly seen IP addresses on the theory that, if
   it's a spam source, then by the time it retries, it will appear in a
   list of sources to be filtered, and the mail will not be accepted.'

This is actually one of the first and well-developed application of 
greylisting (see 
http://projects.puremagic.com/greylisting/whitepaper.html ).  I 
recommend adding a reference to the paper as the author proposed the technique.

Section 2.l is titled "Connection-level greylisting".  This technique 
is used by a well-known provider.  It makes debugging difficult as 
421 is a forced shutdown when the SMTP service is unavailable.

Section 2.4 mentions "the return email address" for the tuple.  RFC 
5321 uses the term "reverse-path".  BTW, instead of "other 
recipients", you could use "recipients".

I don't know about the effects of "greylisting" in response to 
DATA.  In Section 2.5, the dot could be referred to as the end of 
mail data indicator.

In Section 3:

   "The most obvious benefit with any of the above techniques is that
    spamware does not retry, and is therefore less likely to succeed,
    absent a record of a previous delivery attempts."

Some "spamware" do retry nowadays.

In Section 4.2, I suggest using "SMTP client" instead of "client".

In Section 5:

   "To accommodate those senders that have clusters of outgoing mail
    servers, greylisting servers MAY track CIDR blocks of a size of
    its own choosing, such as /24, rather than the full IP address."

As a note, there are some odd cases where mail from the cluster may 
come from outside a /24 (IPv4).  I suggest mentioning that it's the 
full IPv4 address.

   " There is no specific recommendation as to the specific choice of 4yz
    code to be returned as a result of a greylisting delay."

I prefer a recommendation about the choice of code as this is a 
policy reason (see Section 4.2.2 and 4.3.2 of RFC 5321).

RFC 5598 should be a normative reference as it is mentioned in Section 1.2.2.

The draft is well-written.  It is ready for a Last Call.

Regards,
-sm

---

From: Tony Finch <[email-masked]>
Date: Thu, 16 Feb 2012 12:29:20 +0000

SM <[email-masked]> wrote:
> greylisting (see http://projects.puremagic.com/greylisting/whitepaper.html ).
> I recommend adding a reference to the paper as the author proposed the
> technique.

Perhaps the author of that paper proposed the name: the technique is at
least five years older. See for instance http://www.gnu.org/software/sauce/

  "Mail from previously-unknown sources is delayed to give them a chance
   to try a bait address or get their account cancelled."

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Faeroes, South-east Iceland: Westerly or northwesterly, backing southwesterly,
5 to 7, increasing gale 8 at times. Rough or very rough, occasionally high.
Squally wintry showers. Good, occasionally poor, becoming very poor at times.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 16 Feb 2012 06:12:53 -0800

On 2/15/2012 9:30 PM, SM wrote:
> The last sentence seems incomplete.

should be 'is known as'.

  The above is one way to look at greylisting.
> Another way would be to describe the SMTP angle which is to relying on SMTP
> retries to "reject" mail delivery on the first try if the SMTP client is not
> known to the SMTP server. That is mentioned in Section 1.1. I suggest having the
> Background Section first.

rejection is the goal that is most discussed, but note that this is also a way 
to slow down incoming mail selectively.

> "soft fail" is an euphemism of Section 4.2.1 of RFC 5321. :-) maemuki ni kento
> sasete itadakimasu.

Since the class of error codes is officially "Transient Negative Completion" I'm 
inclined to suggest having the text say "transient (soft) fail".

> This is actually one of the first and well-developed application of greylisting
> (see http://projects.puremagic.com/greylisting/whitepaper.html ). I recommend
> adding a reference to the paper as the author proposed the technique.

Since this is non-normative material, it's generally good to be especially 
inclusive.  Including both your and Tony's citation nicely establishes 
relatively long history for the mechanism.

> Section 2.l is titled "Connection-level greylisting". This technique is used by
> a well-known provider. It makes debugging difficult as 421 is a forced shutdown
> when the SMTP service is unavailable.
>
> Section 2.4 mentions "the return email address" for the tuple. RFC 5321 uses the
> term "reverse-path". BTW, instead of "other recipients", you could use
> "recipients".

hmm.  the email architecture document uses the term return address and that term 
matches the actual semantics of the address better than the RFC821 label that 
RFC5321 uses.  To add explicit linkage, I'll suggest "the return email address 
(rfc5321.MailFrom)"

> As a note, there are some odd cases where mail from the cluster may come from
> outside a /24 (IPv4). I suggest mentioning that it's the full IPv4 address.

Although it is unlikely that such topologically diverse 'clusters' will 
demonstrate the kind of hand-off for sending of mail, you are right that it is 
possible. So the text should just add "This heuristic will not work for clusters 
having machines on different networks."

> I prefer a recommendation about the choice of code as this is a policy reason
> (see Section 4.2.2 and 4.3.2 of RFC 5321).

DO you have a preference for which value should be recommended?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 16 Feb 2012 10:57:40 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
> Sent: Thursday, February 16, 2012 6:13 AM
> To: SM
> Cc: [email-masked]
> Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03
> 

Fixed.

> > Another way would be to describe the SMTP angle which is to relying on
> > SMTP retries to "reject" mail delivery on the first try if the SMTP
> > client is not known to the SMTP server. That is mentioned in Section
> > 1.1. I suggest having the Background Section first.
> 
> rejection is the goal that is most discussed, but note that this is
> also a way to slow down incoming mail selectively.

In line with Tony's suggestion, I've removed the text alleging that this goal of greylisting is "less well-developed".  In my experience, though, it's not "the" reason people deploy greylisting these days, hence that language.

I think I prefer the current section ordering.  The Introduction lays out the general subject area, and then the Background starts presenting the "how'd we get here?" material.

> inclined to suggest having the text say "transient (soft) fail".

Done.

> relatively long history for the mechanism.

Done.

> > when the SMTP service is unavailable.

How does that impede debugging?  A server that doesn't go the 421 route is not guaranteed to give you more information.

> RFC5321 uses.  To add explicit linkage, I'll suggest "the return email address

Done, and fixed "recipients".

> having machines on different networks."

Done.

> DO you have a preference for which value should be recommended?

My point there is actually to say there's no effective difference between 421 and any other 4yz in this context.  But that said, I'd be happy to discuss suggestions others might have.

What about saying 421 for sites that want to kill the connection immediately, and 450 otherwise?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 16 Feb 2012 11:15:02 -0800

Covering the stuff Dave didn't address...

> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Wednesday, February 15, 2012 9:30 PM
> To: [email-masked]
> Subject: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03
> 
> Here are some comments on draft-ietf-appsawg-greylisting-03.  The title
> of the document is "An Applicability Statement for SMTP".  If we ignore
> that greylisting is a antispam technique that reuses one of the
> properties of SMTP, that might be appropriate.

I think a specific use of a TS to implement a technique falls within the definition of an AS.

> Some "spamware" do retry nowadays.

I'll put "generally" before "does".

> In Section 4.2, I suggest using "SMTP client" instead of "client".

I'll change it in the title of the section, rather than making that substitution everywhere in the section.

> RFC 5598 should be a normative reference as it is mentioned in Section

OK, though I think it's a bit odd to make an Informative document into a normative reference.

> The draft is well-written.  It is ready for a Last Call.

Thanks!  Hopefully we get one more good round of feedback and then we can request WGLC in Paris.

Thanks for the review.

-MSK

---

From: SM <[email-masked]>
Date: Thu, 16 Feb 2012 15:32:38 -0800

Hello,

[replying to both Dave and Murray's messages]

At 06:12 16-02-2012, Dave CROCKER wrote:
>Since the class of error codes is officially "Transient Negative 
>Completion" I'm inclined to suggest having the text say "transient 
>(soft) fail".

I'm ok with that.

>Since this is non-normative material, it's generally good to be 
>especially inclusive.  Including both your and Tony's citation 
>nicely establishes relatively long history for the mechanism.

Thanks to Tony Finch for the reminder about sauce.

>hmm.  the email architecture document uses the term return address 
>and that term matches the actual semantics of the address better 
>than the RFC821 label that RFC5321 uses.  To add explicit linkage, 
>I'll suggest "the return email address (rfc5321.MailFrom)"

I forgot about that.

>Although it is unlikely that such topologically diverse 'clusters' 
>will demonstrate the kind of hand-off for sending of mail, you are 
>right that it is possible. So the text should just add "This 
>heuristic will not work for clusters having machines on different networks."

Ok.  I don't mind if Murray just goes for the /24 to keep matters simple.

>DO you have a preference for which value should be recommended?

I'll comment below.

At 10:57 16-02-2012, Murray S. Kucherawy wrote:
>I think I prefer the current section ordering.  The Introduction 
>lays out the general subject area, and then the Background starts 
>presenting the "how'd we get here?" material.

Ok.

>How does that impede debugging?  A server that doesn't go the 421 
>route is not guaranteed to give you more information.

See comment below.

>My point there is actually to say there's no effective difference 
>between 421 and any other 4yz in this context.  But that said, I'd 
>be happy to discuss suggestions others might have.
>

 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.

>I think a specific use of a TS to implement a technique falls within 

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.

>into a normative reference.

As it is already in the down-ref registry, there shouldn't be any 
process issue.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 16 Feb 2012 15:41:09 -0800

> Sent: Thursday, February 16, 2012 3:33 PM
> 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?

> 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

---

From: SM <[email-masked]>
Date: Thu, 16 Feb 2012 20:34:09 -0800

Hi Murray,
At 15:41 16-02-2012, Murray S. Kucherawy wrote:
>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.

Yes, to the "returns a 421 SMTP reply" in Section 2.1 as I do not see 
any other alternative.  For the rest, it would be 450.

>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 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.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 16 Feb 2012 22:32:17 -0800

> Sent: Thursday, February 16, 2012 8:34 PM
> >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.

> 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

---

From: "John Levine" <[email-masked]>
Date: 17 Feb 2012 20:26:33 -0000

>RFC 5321.  BTW, 421 is sometimes used for load shedding.

Quite possibly, but what would a client do differently?  Remember
that the client is software, it only looks at the code, not the
text.  My clients treat all 4xx the same, go away for a while,
until the aggregate while gets so long that it gives up.

R's,
John

---

From: SM <[email-masked]>
Date: Fri, 17 Feb 2012 13:21:52 -0800

Hi John,
>until the aggregate while gets so long that it gives up.

The SMTP client does not have to do anything differently as it on 
looks at the code.

Regards,
-sm

---

From: "John Levine" <[email-masked]>
Date: 18 Feb 2012 04:28:48 -0000

Looks pretty good.  A few minor points:

In section 3, I think that you should point out that a in a successful
greylister, all the regular correspondents will be whitelisted, so the
only mail that is delayed is mail from an IP that has never sent mail
before, or sent mail so long ago that it's fallen out of the
whitelist.  In mail systems I've used, the vast majority of mail comes
from places on the whitelist, so after a training period (which you
can fake by watching traffic before you turn on the greylister and
seed the whitelist with all the addresses you've seen) only a small
proportion of mail should be affected.

In section 3 and again in section 9.2, it refers to the size of the
database.  My total database is under 40,000 entries, including 92
IPv6 addresses.  I expect a larger system would have a larger
database, but it would be a pretty feeble server that would have
trouble with a table even ten times that size.  My manual whitelist
has 62 entries, mostly CIDR ranges, probably half of which are stale
but there's not much incentive to clean it out.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 17 Feb 2012 20:41:32 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Levine
> Sent: Friday, February 17, 2012 8:29 PM
> Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-04
> 
> before, or sent mail so long ago that it's fallen out of the whitelist.
> In mail systems I've used, the vast majority of mail comes from places
> on the whitelist, so after a training period (which you can fake by
> watching traffic before you turn on the greylister and seed the
> whitelist with all the addresses you've seen) only a small proportion
> of mail should be affected.

Sure, a description of the "steady state" would be a reasonable thing to add.

I'll schedule that for the next revision, probably late next week after MAAWG.

> IPv6 addresses.  I expect a larger system would have a larger database,
> but it would be a pretty feeble server that would have trouble with a
> table even ten times that size.  My manual whitelist has 62 entries,
> mostly CIDR ranges, probably half of which are stale but there's not
> much incentive to clean it out.

That's good news.  I wonder if we can get a couple of other greylisting sites to provide their database sizes too so we know for sure that this is fairly consistent.

Thanks,
-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 21 Feb 2012 11:02:56 -0800

> of mail should be affected.

I've added this paragraph to the bottom of Section 3:

   Presuming that known friendly senders will be manually configured as
   exceptions to the greylisting check, a steady state will eventually
   be reached wherein the only mail that is delayed is mail from an IP
   address that has never sent mail before.  Experience suggests that
   the, the vast majority of mail comes from places on such a developed
   exception list, so after a training period, only a small proportion
   of mail is actually affected.  The training period could be replaced
   by processing a history of email traffic and adding the IP addresses
   from which most traffic arrives to the exception list.

Does that cover it?

> much incentive to clean it out.

Added this to the end of 9.2, same question:

   In practice, this has not appeared as a serious concern, because any
   reasonable aging policy successfully moderates database growth.  It
   is nevertheless identified here as a consideration as there may be
   implementations in some environments where this is indeed an issue.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 21 Feb 2012 11:07:38 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Thursday, February 16, 2012 10:32 PM
> Since the work of greylisting involves an altered but still
> interoperable interaction between clients and servers, I believe it
> does qualify.
> 

I'd like to hear some other WG opinions on this.  This document started out as a BCP, but with some guidance from Pete and a re-read of RFC2026, cited above, I believe this qualifies as an Applicability Statement, so I changed its requested status accordingly.  (I should have pointed this out when I posted the revision; sorry about that.)  SM disagrees; his is the middle cited text there.

What's the group's consensus?

-MSK

---

From: "John Levine" <[email-masked]>
Date: 21 Feb 2012 19:52:34 -0000

>   exceptions to the greylisting check,

see below

> a steady state will eventually

The only sources that need to be configured manually are ones that
either don't retry in a way the greylister will recognize, or send so
rarely that they'll age out of the exception list.  Any normal sender
will enter the exception list the first time it retries, and never
leave.

>   implementations in some environments where this is indeed an issue.

Sure.  I suppose a greylister in an embedded device might have space constraints.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 21 Feb 2012 13:12:50 -0800

> From: John Levine [mailto:[email-masked]]
> Sent: Tuesday, February 21, 2012 11:53 AM
> Cc: Murray S. Kucherawy

Added to the end of 2.6:

   Likely candidates to be excepted from greylisting include those known
   not to retry according to a pattern that will be observed as
   legitimate, and those that send so rarely that they will age out of
   the database.  In both cases the excepted source is known not to be
   an abusive one by the site implementing greylisting.  Otherwise,
   typical non-abusive senders will enter the exception list on the
   first proper retry, and remain there permanently.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 21 Feb 2012 16:36:42 -0500

>
> This document started out as a BCP, but with some guidance from Pete and a
> re-read of RFC2026, cited above, I believe this qualifies as an
> Applicability Statement, so I changed its requested status accordingly.  (I
> should have pointed this out when I posted the revision; sorry about that.)
>  SM disagrees; his is the middle cited text there.
>

For the record, as incoming AD, I concur that this fits fine as an AS, and
that that target status works better for this document than BCP does.  It
describes how to apply SMTP to a particular use case.

That said, this is a working-group document, and at the first level its
target status has to reflect working-group consensus.  So please, weigh in.

Barry (as chair/AD)

---

From: Ned Freed <[email-masked]>
Date: Tue, 21 Feb 2012 23:34:15 -0800 (PST)

> I'd like to hear some other WG opinions on this.  This document started out
> as a BCP, but with some guidance from Pete and a re-read of RFC2026, cited
> above, I believe this qualifies as an Applicability Statement, so I changed its
> requested status accordingly.  (I should have pointed this out when I posted
> the revision; sorry about that.)  SM disagrees; his is the middle cited text
> there.

> What's the group's consensus?

AS seems like a good fit to me. It's not *the* applicability statment for SMTP
by any means, but then again I've never viewed AS-on-foo as having to cover
everything about protocol foo.

I'd like to see more documents about applicability of various protocols to
address various issues; this seems like a good step in that direction.

				Ned