Serge, > 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.
Ok, I find this far more acceptable than the alternative of processing the message. > > 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. > > Yes, 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. I've got no problem making this configurable. Not too hard to do. Two additional parameters (max command line length, max # of bad commands) for the SMTP server. > > 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? > > 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... > - 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. I guess. I mean you've already got most of this logged (IP, etc.). The Bayesian point is reasonable, as is the invoice issue. But there seems to be a piece of circular logic here. We still don't have a single solitary example of a valid client manifesting this behavior, much less a widely used one. Certainly no general incompatibilities have been reported. The only assertion is that this is behavior manifested by some spammers. So why do we need to determine whether the message is spam? It seems that In this case just fail it immediately. Certainly seems like a more desirable solution that wasting bandwidth, processing power, disk space, etc. on reading in a message that we're assuming a priori to be spam. > 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. Uh...why? Again, there isn't a single documented client that demonstrates this behavior. What's the motivation for adding this? Simply amounts to one more piece of state that we'd have to manage internally. > This is why I think it's a DoS opportunity. > 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. Again, I still don't get it. Keeping the connection open for a long time is no big trick (see trivial example below, comments in previous email). The buffer to which you're referring is presumably the underlying TCP/IP socket buffer, since there is no buffer growth in the Java code. The only buffer in the Java code is the one in BufferedInputStream, which is of a constant size as long as the connection is open. And as I said above, keeping the connection open is no big trick. But even the TCP/IP buffer is size limited. So what buffer is necessarily going to be cleaned up in this case? > 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. > > 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. I can write a 10 line program that does this. And it has nothing to do with this issue. A client that loops and sleeps between RSET calls will tie up threads just as effectively as a theoretical "all at once" buffer send. Very low bandwidth, no it slips under the radar. Run 50 clients and the server is unresponsive. As I said, this is a fundamental problem with SMTP. Not much you can do about it at this level. > 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. As I said, I just don't see how either of those solutions would immunize you from a simple ten line looping RSET program. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
