On 2/7/2007 5:06 AM, Tony Finch wrote:
There is a question related to a security consideration: if you do
per-recipient content scanning instead of per-message content scanning
then it's much easier for an attacker to use up your CPU.
This is a valid concern. OTOH, systems that already perform per-user
scanning by limiting SMTP transfers to one recipient already have to deal
with the same relative load burden, so it's not entirely new.
In the general sense, I think it's an admin problem more than anything, in
that admins need to know how to manage their load. "If per-recipient
scanning breaks your mail, don't do per-recipient scanning" is the same
sort of sentiment as "if database driven web content breaks your web
server, don't do database driven web content"
As far as that goes, actually, people who are already doing after-dot
content scanning (either globally or one-recipient) already know that it
takes some planning and resource management to balance volume with load.
"hmm, should I buy another server, or eliminate some filters?" These are
admin decisions, and to that extent, this is really the wrong place to ask
if it is worth it, since it clearly is worth it to so many already.
Having said all that, MTA developers that expose this feature directly
will also have options that they can use to limit how much trouble their
users get into. EG, an MTA can limit certain types of scanning to global
filters (ie, only doing ~Bayes and string-matching filters in the
per-recipient loop and do everything else globally). MTAs can also adopt
certain kinds of attack-avoidance features, such as enforcing limited
RCPTs per connect. The extent to which an MTA developer my want to provide
this kind of hand-holding (or not) is out of scope naturally, but we
should ack that it's an option that exists for many of them.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/