I'm not concerned about the former, either. I pretty much exclusively use softlimit to prevent the latter - DoS attacks.
The concern isn't about the NUMBER of concurrent connections - a resource starvation attack can be done with very few, even 1 single connection, depending on the configuration. Suppose a contrived SMTP session where, once in the DATA phase, the remote client sends 1 byte per second, every second, indefinitely, without terminating the DATA phase. What happens to all available system memory? Of course, your SMTP server implementation can handle this gracefully by spooling bytes out to disk as they're received into a temporary file and not holding them in memory. It can also limit the max number of bytes that a message can contain and close the session once that limit has been reached (c.f. qmail-smtpd's "databytes" setting, which by default is "0" or unlimited). Clearly, there's many ways to handle this kind of attack. But, can you think of every kind of attack possible, and implement things to handle them? I would argue: no. Cover many cases, especially obscure edge cases? Sure. But every single one? No. That's where softlimit wins. It guarantees that no single process can exceed the limits you impose. Does this mean that spamdyke, qmail-smtp, etc. needs to be protected by softlimit? Probably not. Most MX operators will never be attacked in this fashion since it's merely resource starvation and not a path to a remote security vulnerability. But, it's good to know what this softlimit tool CAN be used for - it's not solely for sandboxing a process that's misbehaving on its own, but being made to misbehave by a malicious user. On 6/9/11 12:26 PM, Eric Shubert wrote: > I'm not really concerned about the former. > > Will you care to elaborate on the latter? I would think that the -c > option (maxsmtpd) on tcpserver would mitigate that. -- Dossy Shiobara | "He realized the fastest way to change [email protected] | is to laugh at your own folly -- then you http://panoptic.com/ | can let go and quickly move on." (p. 70) * WordPress * jQuery * MySQL * Security * Business Continuity * _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
