Re: Dropping connection instead of returning 400

On 03/03/05 15:26 -0800, christopher@baus.net wrote:
> > Christopher,
> >
> >  It seems like such a trivial measure that I don't think breaking the
> > spec is worth it. You seem to be concerned about the information
> returned... well just return less. Don't 'break the spec' for
> > something so trivial.
> Doing this in accordance to the spec in a pipeline is a bit more
> complicated.  I am working on a blog entry that explains some of the
> issues of proxying pipelines.  The primarily problem is determining the
> number of requests you'll send to server before receiving a reply. 
> Information needs to be buffered and queued in the proxy which is a
> potential area for overrun failures.  This is not required by straight
> through proxies like stunnel.  I'm going to implement this since everybody
> is so keen on this, but I'm going to continue make dropping connection
> optional.
>
> I talked this issue over with a friend of mine that works at an anti spam
> company, and they do exactly what I am proposing.  If they determine the
> message is spam they drop connection immediately regardless of the SMTP
> spec.  Also I see this as a similar to rejecting TCP/IP packets (ie

And if they are doing this based on the content of the message and the
sender is a legitimate MTA, the MTA will keep retrying for five days.
(You don't sane bandwidth by doing something like this, which is the
typical reason given).

It would have been easier for them to send a 5xx error after the final .

Breaking protocols for the wrong reason is bad. Breaking them silently
is worse.

Devdas Bhagat