ietf-smtp
[Top] [All Lists]

Re: Proposal: Using Conservative EHLO Response Parser Behaviour For Tarpitting

2007-06-18 13:30:34

Hi SM,

On 18 Jun 2007 at 8:50, SM <sm(_at_)resistor(_dot_)net> said:

At 18:27 17-06-2007, Sabahattin Gucukoglu wrote:
My idea is to replace greylisting with a connection-delaying technique
that will make the SMTP client wait until we're certain it is genuine.  We
differ from Greylisting only in how we determine that an SMTP client is
genuine; greylisting uses the fact that the client will come back, and
we'll use the fact that the client knows what continuation lines are and
that it must stay silent while we send periodic lines in the HELO/EHLO
response for a given time.  This isn't unlike teergrubing, except that we
don't need dedicated hosts for this technique and we slow the connection
down as soon as it's possible rather than while mail is being delivered.
We must not allow the client to pipeline any commands before EHLO or HELO,
and we must not allow the client to initiate a MAIL transaction until
issuing EHLO or HELO and completing the challenge either (unless, at the
server's discretion, the client has already "Proven" itself).  A client
that waits ("Proves itself") for a specified duration in minutes (five,
say), during which it is receiving five-secondly (for instance) "Stay on
the line" notices, shall eventually be allowed to see service extension

Some clients won't wait that long.  They will close the connection 
and may retry again.  There is no guarantee that the delivery retry 
will be from the same host.  The connection oriented approach suffers from
the same problems as what you listed for the transaction-oriented approach
to greylisting.

It would indeed, if it is true that (sensibly-minded) clients choose to 
abort a long-running transaction.  That might be a security advantage to 
avoid a DoS; I'd certainly recommend people set an upper limit on 
lingering connections that aren't actually taking mail, just in case some 
hostile person (or an evil admin) deploys a tarpit that never gives up.  
However, once again, this isn't what I've actually observed in a 
standalone tarpit taking mail from both Postfix and Sendmail forwarders as 
well as the big bad Internet; they have seemingly gone on for hours, 
possibly even days, waiting for the continuation lines which have 
presumably just been logged and then discarded.  But yes, if the 
connection is closed then the whole point of this idea is wasted.  If it 
happens often enough in non-robust mailers (some of which don't quite 
manage to adhere to the itty-bitty aspects of the standard) then this 
trick is only for the zealots.

Cheers,
Sabahattin

-- 
Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: feedme(_at_)yamta(_dot_)org
Phone: +44 20 88008915
Mobile: +44 7986 053399