From: Derek J. Balling
Date: 2007-02-06 13:29:56 -0500
Subject: Re: Per user settings
More information..: http://www.milter.info/#Support
> One really *BIG* problem with this is that an SMTP client can not send
> to multiple clients at a time. Thus if you have an email inbound to a
> server destined to 10 different recipients with a multi megabyte
> attachment, it will have to be transfered to the server for each
> recipient. This is drastically different than a SMTP client being able
> to list all the recipients in one envelope and transfer the message one
> time. If you say N recipients with a size of S, the total transfer will
> be at least N*S verses the possible S+<small amount of overhead>. I
> think the draw backs of this are self explanatory for all parties involved.
I think it depends a great deal on your environment. Many places limit
the size of inbound attachments anyway (to prevent denial-of-service
attacks where someone just starts e-mailing you ISO images to fill your
temp-space, queue-space, or spool-space). If you're in an environment
where "large attachments to a number of discrete addresses" is an issue,
then certainly it's not ideal. However, it's worth pointing out that if
you want per-user DATA-stage filtering you don't have any other *real*
options, because the SMTP spec simply doesn't account for mix-n-match
responses after the fact (unless you want to get into the business of
crafting and queuing DSNs to possibly forged envelope-senders).
> If you are wanting individual recipient settings, I'd suggest that you
> run Milter-Sender on the main inbound server so that you have a verified
> sending email address to successfully bounce things to.
I've pointed out my objections to milter-sender (and, to be fair to
Anthony, any type of callback scheme) in the past. I think it's a
shameful waste of resources, and will lead to an escalation in spammers
simply joe-jobbing real addresses to get around the problem.
Before I implement any anti-spam solution, I always ask myself, "If I
was a spammer, and this solution was prevalent, how would I work around
it?" ... and the answer for callbacks is simple: Use valid addresses.
Now, certainly they could use their OWN valid addresses, but that's an
inefficient use of their scarce resources. It's much more cost-effective
for a spammer to use SOMEONE ELSE's valid address. So
"email@example.com" appears to e-mail you, you validate the address,
and lo and behold, it's not really from firstname.lastname@example.org.
To me, that particular anti-spammer/spammer escalation simply makes mail
LESS useful. Long-term it doesn't solve the e-mail problem, but it
*will* increase blow-back, meaning a net *increase* in net abuse, not a
Copyright 2009, 2012 by SnertSoft. All rights reserved.