Peter M. Goldstein wrote:
Sure those are nice add-ons of other forms of fast-fail, but I'm just focused on the issue of whether to accept the overly pipelined SMTP session.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.
I guess. I mean you've already got most of this logged (IP, etc.). TheYes, I agree it is spam and am not offering other use cases to consider. My preference is to allow James to accept this so an admin can do as they choose. This allows James to be a honey-pot for spam... they can invoice or better detect other spam or log the way they want to using mailets to determine it.
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
Out of the box it just flags this as spam. I don't think this category of spam isn't going to cost you significantly enough to have to outright block it.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.
Because I might want to know. It could raise the likelyhood that this was a piece of spam. There'd be nothing to "manage"... we add a header to the incoming mime message, and that's it. If you look at these messages, there are about 15 informational headers like this, including spam and antivirus ratings. Just another thing to know.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.
The difference is keeping open connections that are consuming memory you can't GC. Your trivial example does not require the server to keep anything extra.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).
Um no, I was very specific and accurate in my list of buffers. There is a BufferedInputStream of a fixed length (1024 bytes), there is a BufferedReader of a fixed length (512 chars), and there is a InputStreamReader of an uncontrolled length... which is where in fact the data is sitting in my tests. And sure, I suppose there might be TCP buffering, but I was just focusing on the buffers in James we've created.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?
If you want, this ugly uncontrolled buffer is explained in the javadoc... the InputStreamReader authorizes itself to read ahead for encoding efficiency, and you can't control or manage this length. Once more, this buffering is done in an internal sun class, so I can't even look at the source to see how it's done (I would assume it's capped at maybe 1kb, but usually you can look at the bundled classes to see how they function).
I don't mean to be sounding some big alarm bells that this is mega-diasterous. But the aggressive-pipelining will tie-up a couple kb of memory per connection that your case doesn't.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.
--
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
