Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations

[Hector Santos <[e-mail]>]

On 2/4/2014 2:33 PM, John Levine wrote:
>> I don't think this is an argument for or against standardization, however. The
>> overarching goal of improving timely delivery of mail trumps the cost of
>> dealing with the obsessions some sites have. IMO this protocol needs to be
>> assessed almost entirely on the basis of whether or not it improves the
>> situation surrounding greylisting.
>
> In my experience, the amount of real mail that is delayed at all by a
> reasonable greylister is insignificant.

This spec only attempts to document the basic framework of greylisting 
based on [HARRIS] and also offers a method to minimize GLS 
(GreyListing Server) forced client mail delivery delays.

> Once you know that an IP has successfully retried, there's no point in
> further greylisting, so you add it to the greylist whitelist (pale
> grey list?)

It might be good if the growing amount GLS out there would permanently 
IP whitelist the sender from future unnecessary GL based delays. 
However, this is not generally the case. SMTPGREY includes a concept 
of an expiration period which was part the original 2003 [HARRIS] 
greylisting specification where most systems, if not all, were based 
on. So its more of a temporary whitelisting concept.

Your suggestion would be this make this a permanent whitelist.  I 
think this would be local level policy idea for GL implementators to 
offer to operators -- make it optional.  GL can help feed into these 
additional automated white listing intelligence.  Perhaps also couple 
it with a DKIM signature requirement before it can get pass a greylist 
requirement.  I think these considerations could be part of an 
appendix, but not the basic protocol.

I will venture that most systems that have implemented Greylisting has 
done so with plug and play fashion, using best establish values for 
blocking and expiring.   There is much experiences in these values and 
the values have worked out of the box. Operators don't usually adjust 
the defaults. But if they have, that would be something to learn about.

> This means that the only non-bot mail that gets
> greylisted is the first one or two from an IP that hasn't sent mail
> before, and that just isn't very many IPs or very much mail.  It's
> certainly not worth a new SMTP extension and extra state in mail
> servers.

None of this is a problem -- it is an optimization to minimize mail 
delivery delays that is increasingly caused my GL servers. With bulk 
transmissions, there are more IP congestion/load limits and following 
retry hints has helped remove some of the randomness in retry/bulk 
mail delivery delays.

Its not a problem because retry/bulk strategies are necessary w/o 
greylisting.  SMTPGREY addresses a certain portion of the temporary 
rejection spectrum that do cause mail delivery delays by design.   The 
mail will get out eventually, maybe after 3-5 wasted attempts over 
long extended mins, even hours.   SMTPGREY has proven to show to cut 
all waste to the bare minimum, which can be an extra retry at the 
lowest possible time offered by the server.

Keep in mind NULLMX proposal is not a problem and we about to take on 
this work as a standard.  In fact, if NULLMX, why not SMTPGREY while 
we are in a SMTP CHANGE mode mindset.

One suggest a successful MX lookup with PREFERENCE=0 as a means to 
remove a queued item from the outbound queue and immediately activate 
a bounce process.

The other suggest a RETRY HINT from the temporary rejection GL server 
as a way to override the next delivery attempt time with a shared 
client/server handshake time value.

Both are good ideas to do help improve with mail delivery and queuing 
strategies.

> I realize there are extreme greylisters that greylist everything on
> the theory that a mail server might be sharing its IP with a bot, or
> if they wait long enough the sender will show up on a blacklist, or
> something.  That's certainly not a basis to standardize anything.

This proposal attempts to not deal with the poor implementations of 
greylisting. It uses [HARRIS] as the original method most GL systems 
are based on to document the basic framework and its options 
available.  SMTPGREY deals with what exist in the market place - a 
higher degree of hitting HARRIS-like GL servers with temporary 
rejections and many of the different GL servers already provide a 
Retry Hint which client can leverage.


-- 
HLS

   [HARRIS]   Harris, E., "The Next Step in the Spam Control War:
               Greylisting", 2003, <http://projects.puremagic.com/
               greylisting/whitepaper.html>.