Kolus Maximiliano wrote:
>
> Instead of sending a FIN, the connection closed using RST (i
> believe it's because the originating process died), for some reason
> exchange couldnt see it and continued to send packets until his buffer
> was emptied, then he ignored the 451 and showed the 499 (aka
> connection reset by peer). Before getting flamed, i know that it's
> exchange's fault to ignore the 451, but, shouldnt the connection be
> closed by FIN instead of RST?
I get this a lot with the microsoft SMTP service (comes with IIS)
talking to qmail. If a website is using CDONTS, it's a particular
problem - if a connection is dropped, the SMTP service will re-try
without any delay and won't back off.
Generally, it's not too bad - adding the IP number to your
tcp.smtp file for a while will stop the connections. If the connections
are from a server on the same LAN, it can take out qmail. I've had
something like 100 connections a second from a single server on the
same LAN to one qmail server.
(As an aside - if you don't log your smtp connections, and you
get hit hard, all you will see is a whole load of defunct processes.
This could well be what Travis Johnson was experiencing.)
Now - I can understand why DJB sends a 451 error and drops the
connection. Stopping broken MTAs from sending crap out is the right
thing to do ... but the implementation is just a tad off the mark.
I'm 100% behind Microsoft being wrong with this one - but that
doesn't mean the qmail implementation has to make life difficult for
both the sending and receiving servers/admin.
RFC821 says that "The receiver should not close the transmission
channel until it receives and replies to a QUIT command (even if there
was an error)". smtpupd says it must not, but adds "After detecting the
need to shutdown the SMTP service and returning a 421 response code."
But that isn't the case here either.
Both the existing and draft specs forbid what qmail is doing.
Sure, the smtp update forbids what Microsoft is doing too, I'm not
suggesting otherwise - but just because Microsoft is bad, doesn't mean
qmail should be, too. (Or at least this will be the case when the
smtpupd is published.)
A "fix" which I have been considering is, instead of sending a
451 followed by a reset, is to sleep for 5 seconds, send the 451,
sleep for another 5 seconds and then reset the connection.
At the very worst, this will reduce the connections to one per 5
seconds. At the best, it'll look like a valid SMTP conversation to the
remote MTA and might actually give it a chance to parse the response
and include the message in the bounce - instead of the usual "reset by
peer" junk.
I hope this helps,
Richard
P.S. Posting in HTML won't do you any favours on this list.
