Peter M. Goldstein wrote:
<rant-on-spammers>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.
I will testify to God that spammers do not care a lick about bandwidth. And they don't care about whether a server is an open relay. I don't know if it's just because I'm a mail server author or what, but our corporate mail server gets 100-150 failed relay messages a day. For a while I blocked an IP address or whole subnet, and 2 days later it's some different idiot sending the spam. The cost to them to send 500 messages to test for open relay is as expensive to them as 1 message.
And consider that it is cheaper for them to just do out.print() the whole message stream than to use some interactive message processing... easier to do, less CPU, less delay getting that message out. Everything a spammer drolls over. Bandwidth is the cheap part... a T1 could send about 50 messages per second at about 4kb in size, or over 4,000,000 messages per day. That's without the routers doing any network-level compression of this text emails. Anyway, so they do this sometimes.
And they don't spend much time trying to improve their hit ratio... the more email addresses they send to, the more impressive it sounds... it's like trying to convince a lawyer to get something done quicker... they get paid by the hour!
</rant-on-spammers>
Yes, that is a nice way to do it... you can call inReader().ready(), and if true, tell them to go away with a 5xx.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 parsingYes, the fast-fail might be nice. I would prefer though if we could leave this decision in the hands of the admin rather than us.
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.
If you can receive and process the message, then you can determine if it's spam or not (based on relay rules, Bayesian filter, whatever). If it is spam, there are a wide range of options for you...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?
- You can log who was spamming you in case you want to brag to people about how stupid spammers are, or more seriously report on the # of attempts spam.
- You can generate an email to the ISP saying someone from this IP address at these times sent 300 pieces of spam to you (which gives them enough information to close that account)
- You can get the IP address blacklisted on one of the various lists.
- Assuming you determined it was spam from a relaying rule, you can add it to your Bayesian filter to learn more patterns of spam.
- If you're in certain states or countries, you can send the spammer an invoice for sending you spam.
- You can charge certain customers more money for extra spam blocking tools.
Anyway, just some thoughts... so I plan to implement, some I don't.
We could also add a header to the message stating whether this message violated SMTP by having data in the stream already when we received DATA.
This is why I think it's a DoS opportunity.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.
a) the connection is kept open for a long time... it gives the attacker a chance to load up multiple connections.
b) the buffer can't be disposed while the connection is open... if you fast-failed or accepted the message, you could take those bytes, stick them where you want (maybe /dev/null), and then recycle that memory.
Well, sure, I'll grant you can overload someone's bandwidth with anything, and SMTP makes it pretty easy... heck you can PING someone to death.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.
But right now you can write a 100-line program, which won't take much of any bandwidth (making it harder to spot the DoS), but will stop a James server from accepting any more incoming SMTP connections, either because it exhausts memory or exhausts the number of threads/handlers. This is why I raised this as potential DoS vulnerability.
If you had fast-fail or accepted the message, you would have to significantly increase the effort (be it connections or bandwidth) to bring that James server down.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
