I feel very strongly that this shouldn't be accepted. What follows is my
reply to Serge's 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