On 8/11/2010 8:30 AM, ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
>> Completely agree for several reasons, including that the only senders
>> that take advantage of "as fast as you can process" scenarios are
>> spammers. If I take a second or two to accept a message from a legit
>> sender they neither know nor care. But to a spammer, the faster we
>> receive and delivery the more mail gets through before a content filter
>> or blocklist can update. We saw this happen when we migrated to our
>> current system 3 years ago. Spam was delivered at many hundreds of
>> times faster than mail from AOL, Hotmail and Gmail combined. Responding
>> as quickly as my system will allow with<CRLF>.<CRLF> helps no one I
>> want to help.
>
> You know, that's very nicely put. I'm going to use that last line the next
time
> this comes up.
Isn't this effectively a form of greylisting?
No. It would only be greylisting if the intent was to cause a temporary failure
and a later retry. That's not the case. Rather, the intent is to avoid
accepting more mail than you can deliver by slowing down the acceptance process
just a little, but staying well within the vast majority of timeouts
in actual operational use.
I've seen mixed results with greylisting, given that some legit senders have
SMTP clients that are, well, problematic. (Nearly lost a consulting gig because
the initial query note got mishandled from greylisting.)
Since we're not talking about greylisting this isn't really relevant, but FWIW
one of the effects of widespread use of greylisting has been to force certain
sorts of senders to clean up their acts. This may be one of the most
significant virtues of greylisting, actually.
In any event, to the extent it's good to add some delay, the question is how
much. The other question is why this is good for long-term -- since
specifications last for a decade or two -- and that bad actors won't simply
adapt as the behavior becomes institutionalized.
I see why you want to put a specific value in the specification, but this is
actually the reason it's a bad idea: These are the sorts of things that change.
Right now latencies are generally low and relay senders seem willing to wait
for a fair amount of time while submission senders aren't. But any or all of
this could shift. And a small shift in any direction could easily result in any
set of specific values becoming suboptimal.
What doesn't change - and cannot change without funamental changes to SMTP
itself - are the tradeoffs involved. That's why describing them is a good idea.
I'll also point out that this is just one example of a more general issue: This
specification and quite a few others have been written with the view that the
most, and in comes cases the only, important thing is for everyone to be as
good a network citixen as possible.
This may have been fine advice thirty years ago, but it isn't now. The Internet
can be a hostile place and protecting yourself is important. Nobody wins when
your mail server is so overrun with garbage to to point that legitimate email
is blocked.
Please note that I am not advocating the removal of the "good network citizen"
stuff. It's important to have that too, but for mostly historical reasons there
are too many places like this one where the advice is much too one sided.
Ned