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

[Ned Freed <[e-mail]>]

Sorry, I should have commented on the client rescheduling aspect of this
in my first response.

First of all, this is trivially easy for us to implement, at least in
principle. All we have to do is parse out the value from the response and then
make a single subroutine call. It really is just that easy with our queue
manager.

But as always, the devil is in the details. Obviously you can't fully trust the
value you get since there are obviously ways small (or large) values could be
used to enhance a service denial attack.

So there have to be allowed ranges for the values. But is that enough control?
I don't know if it is or not. In particular, should MT-PRIORITY be tied into
this, and if so, how should it be done? (Different allowed ranges for different
priorities is the obvious answer, and may be a reasonable starting point.)

And then there's the message versus host issue. We have the ability to either
reschedule this one message or reschedule all the messages headed to a
particular host. Which one makes sense depends on what sort of greylisting is
being done: Is it purely based on the sending host or is it based on some
characteristics of the specific message?  And before anyone says that you can
determine that by the phase at which the greylisting occurs, sorry, no you
can't. In my experience it's not at all uncommon for IP-level greylisting to
happen as late as RCPT TO phase, and I wouldn't be surprised if it can happen
at the end of data.

And if you get this one wrong use of this extension could easily increase
rather than decrease delivery times with greylisting schemes that penalize
overly aggressive retries at the sending host level.

The obvious way to address this is to add some enhanced status codes to say
whether or not the retry value is intended to apply to this one message or to
the sending host as a whole. But I have to wonder if people setting this up
would understand the distinction, and I also have to wonder if other queue
managers are capable of making use of it.

And finally, we have to take the least astonishment principle into account. For
whatever reason some sites obsess over the predictability of message retry
intervals: Any time they see what they regard as unusual behavior in this
regard, they get very excited and demand an analysis be done. Our support
people then have to waste time digging in to what invariably turns out to be
have a perfectly reasonable explanation: a queue backlog, an unresponsive
destination, bad configuration setting, etc. etc.

Unfortunately, given their obsession with delivery times such sites are likely
to be first in line to enable such functionality if it is available. The
possible consequences of this in terms of support time should be obvious.

The bottom line is that if this is standardized, given how easy this is for us
to support we'd probably implement it. But given the risks we might have to
make it a restricted option, which would substantially lessen the liklihood of
sites actually using it.

Finally, I missed the optional nature of the GREYLIST extension. I have to
say I'm not comfortable with assigning semantics to the content of a response
line absent a clear indication of what the contents of that line mean.

				Ned