Jeremy Kister <[EMAIL PROTECTED]> wrote:
On 3/3/2006 10:28 AM, Michael Krieger wrote:I'm not saying that you shouldn't do that. All I'm saying is that the RFC states that you should not intentionally kill the SMTP connection unless
> An SMTP server MUST NOT intentionally close the connection except:
> - After receiving a QUIT command and responding with a 221 reply.
> - After detecting the need to shut down the SMTP service and returning a 421 response code. This response code can be issued after the server receives any command or, if necessary, asynchronously from command receipt (on the assumption that the client will receive it after the next command is issued).
Not to turn this into a RFC contest on the wrong mailing list, but we
must be interpreting that differently --
my qmail-1.03.isp.patch will close a connection after a defined number
of errors. I claim RFC 2821 #3.9 compatibility, because before closing
the connection, I send a 400 error. I have the 'need' to close the
connection, because I no longer want to hear from this abuser, and he is
automatically entered into tcp.smtp.cdb for rejection.
1. the client sends a quit and you ack it with a 221.
2. the SMTP __service__ needs to shut down.
Note that the second one is not you wanting to shut down the connection, but rather the service restarting for example.
Now what you choose to do is up to you. In practice, the remote mailer in real-world situations will assume a disconnection beyond both of your control and try again in a wee bit, so it's deemed okay by some. That doesn't make it right by the standard, but then again, these are 'Requests For Comments' as a way to set an agreed upon standard. You can religiously follow them or veer from them, but it's safe to assume that they represent what most people are doing with their systems and how it's "supposed" to work.
So is there a reason not to do it? Yes the RFC suggests that this shouldn't happen if you can help it and have another way to do it. Is there a reason to do it? You cite bandwidth and CPU usage, as well as generally hostile Internet behaviour. So throw a coin and see what is more important to you.
I'd argue that you may find it more beneficial to add a qmail-smtpd.c code hack to keep a count of rcpt commands and issue a 5xx reply when there's a good number, placing this code before chkuser so that it eats up next to no CPU usage. In terms of bandwidth, it's probably minimal. There are already patches for tarpitting and having a max rcpts, so it should be easy to modify to increment on failed rcpts and avoid the overhead of a vpopmail lookup, favouring a simple if failed > 10, err_pissoff(). That'll reuduce any CPU overhead and the bandwidth will be minimal.
Then of course block for future connections if you wish (but I'd argue again that odds are it's some automated hacked Spam bot on an innocent system that picked up your domain randomly or from a list and will never come back after a few minutes anyway.) We've tried keeping blacklists for a while, but they tend to block real people too, who we will never see the attack from again. Temporary blocks are okay, but in most cases, you'll never see the abusive system again.
So anyway- RFC says one thing, but you do as you wish. That's always the case on the Internet.
-M
