Serge, Now to respond to the technical points:
> Spammers will send email this way, and I'd rather not have their already > wasteful emails leave me with a bunch of open connections. I'd prefer > to close the connection and be done with the transaction. As is, my > mail server will receive all the TCP data, it sits in some odd buffer, > sit with an open connection until it times out, and then the data gets > dumped and I don't even get a chance to log and do whatever else to make > sure I can catch more spam in the future. I'm not sure I buy the first assertion, especially when I've never seen a spammer send mail that way. Spammers have to pay for bandwidth just like everybody else, and in general it's in their best interest to confirm that a server is an open relay before wasting their time and bandwidth sending arbitrary mail to be relayed through the server. But let us grant that some spammers do send email this way. IMO the logical way to handle this situation is to require more strict compliance from the clients, not less. This means that when a command is read off the wire, it would be useful to confirm that no additional data is pending. If it is, a 5xx is immediately returned informing the client that they've sent a malformed command. I've got no real objection to that, provided it doesn't break any of the standard clients. I'd also argue that there are a number of additional, command level parsing mechanisms that would be far more effective at dealing with this problem than the suggested alternative of accepting the message. For example, imposing line length limits. Or imposing limits on the number of malformed commands that are allowed before the connection is closed. Both of these would be "fail-fast" techniques that would save the James server bandwidth and minimize the number of open connections. They are also compatible with the RFC and don't encourage standard-violating clients. As far as reactive action, I'm not sure what you've got in mind. Let us imagine that, in fact, this data is all read in to the appropriate buffers and the commands are processed. It's going to be stuck on the spool and processed. Now you've seen it - it's in your spam repository or something. What're you going to do? I mean I guess you could globally block connections from the server that sent it, but if this is really a problem you've got the IP address of the server in either case. What does processing and storing the message get you? > Anyway, this also smells like a great DOS opportunity. Honestly, I don't see how this is any kind of DoS opportunity. At least not one above and beyond those provided by the protocol itself. Fundamentally, SMTP is not a particularly DoS resistant protocol. That's just how it is. If I want to kill an SMTP server, all I have to do is open up enough connections and send NOOPs, RSETs, or EHLOs over each of them, over and over and over again. Since endless loops of these commands are permitted by the SMTP protocol grammar, there's basically nothing to be done about that. The problem is even worse, since James doesn't have any of the data filtering mechanisms described above. So I can attach a base64 encoded version of my favorite MP3 and send it along as an argument to RSET. I'll get a 5xx, but it will tie up bandwidth and resources while James is processing. So James is vulnerable to DoS attacks, but that's basically because it's a mail server. We could harden it a bit (using some or all of the techniques I describe above) but I don't see how DoS is relevant to the issue under discussion. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
