[nSLUG] Whither to bounce unknown recipient address?
D G Teed
donald.teed at gmail.com
Thu Aug 30 15:14:32 ADT 2007
Thanks for the tips. We've got amavisd+SA , RBL+,
clamav, reject from reverse DNS failure and
many more configurations to defeat spammers.
SPF and DKIM are on my to do list.
However, the change I was considering would be a
significant change as it would mean someone sending
in email with a typo of the user address gets no response,
as if it had delivered.
That in particular is why I'm wondering how common it is,
particularly for a company or organization MX. Normally
email goes somewhere, even for quarantined virus/spam.
Doesn't this keep the email RFC compliant with some standard?
e.g. see discussion of http://www.eweek.com/article2/0,1895,2175935,00.asp
I won't get into lots of numbers, but on one MX, in a sample day
there were 155,000 bounces from DNS lookup failure,
and 36,000 bounces from recipient address failure.
One can see this and wonder about the back scatter potential.
Another option would be to control all bounces so that it only sends
minimal information, not a copy of the entire message. This
would provide the bounce notification but defeat the purpose
of spam via back scatter via all rejection methods.
I'm still digging into postfix docs to see how that is tweaked...
On 8/30/07, Ian Campbell <ian at slu.ms> wrote:
> On Thu, Aug 30, 2007 at 01:16:15PM -0300, D G Teed wrote:
> > I read the postfix backscatter readme today.
> > http://www.postfix.org/BACKSCATTER_README.html
> > Up until now it seemed like a good idea to always bounce
> > undeliverable email, so people can realize their typos.
> > But this seems to be a spammer technique to deliver
> > via forged from addresses.
> > I'll have to convince people setting
> > unknown_local_recipient_reject_code = 550
> > in postfix is a good idea.
> > How many of you use this (or similar) in your MX server?
> I do.
> The bigger problem is spam/virus scanning. With Postfix, you get the
> option of before-queue or after-queue content filtering. Before-queue
> lets you bounce spam/virus emails properly (... hopefully WITHOUT the
> virus, man I hate those virus gateways that bounce with
> attachments...) during the SMTP transaction. That only works for
> relatively low-traffic sites though, otherwise you get a pretty
> significant bottleneck.
> After-queue filtering is better from a reliability perspective, except
> that it means you can't bounce the emails, since there's no good way
> to send a bounce... which leaves you with dropping it silently or
> quarantining it.
> As Dop pointed out, it's easier to do as much filtering as you can up
> front, bonus points if it's 'cheap' filtering. Sender verification is
> a good start. Checking SPF/DKIM is a good idea too.
> Depending on how comfortable you are with it, RBLs and RFC strictness
> are also a good idea. Personally, I don't really trust most RBLs, but
> they're right enough that I want to use them... so anything that gets
> a hit in an RBL I greylist.
> I do other simple checks as well. I reject anyone pretending to be my
> server. I reject servers that send broken HELO/EHLOs, domains it
> doesn't know about, domains that don't exist.
> I run body checks that block emails with executable attachments. I
> greylist anything that looks like a dynamic ip (four or more .s or -s
> in the hostname, or anything that matches an ugly, ugly regex) or
> anything that doesn't resolve.
> Anything that makes it through that goes to regular filtering.
> ... and it seems to work pretty well so far.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> -----END PGP SIGNATURE-----
> nSLUG mailing list
> nSLUG at nslug.ns.ca
More information about the nSLUG