[nSLUG] Whither to bounce unknown recipient address?
nslug at fop.ns.ca
Fri Aug 31 09:15:51 ADT 2007
On Thu, 30 Aug 2007, D G Teed wrote:
> I'm not 100% that this reject + bounce from the other relay
> will prevent back scatter.
If you reject at SMTP time, there is no bounce, only reject. If your
backup MX accepts the mail, you have taken responsibility for the mail, so
the target should be to refuse as much mail as possible from the outside
world regardless of which MX it hits.
> If my spam bot is on eastlink cable, and I sendmail out, providing
> hotmail.com or gmail.com as my from address, smtp relay on eastlink
> sends back a bounce rejection to my hotmail or gmail address after being
> told the recipient party SMTP rejected due to non-existent recipient.
> All it does is shift the source of the back scatter by one SMTP relay.
Very, very few spam bots are sending through ISP's mail relays. I run an
MX based antispam filtering service at work, and the vast majority of spam
comes directly from dynamically assigned IP addresses. The way the filter
works is to set up a special hostname as the primary MX for the client's
domain, so all their mail comes to our boxes, is filtered, and is then
forwarded on to the client's mail server through a rule on the MXen. The
flow that mail goes through looks something like this:
HELO is checked for correctness; anything that is not a FQDN is rejected
with an explanation. Anyone that doesn't say HELO is rejected. Anyone that
tries pipelining is rejected. Anyone that tries a known bad hostname
(speedtouch.lan, negative numbers, known virus constructed hostnames, etc)
is rejected. Anyone that gives a HELO of my server's hostname or the
domain it is delivering to is rejected. Anyone that is coming from the
~250 known dynamic domains is rejected (wanadoo, blueyonder, rima-tde,
telecomitalia, etc) is rejected with a message to use their ISP's mail
Sender: MAIL FROM
Sender verify is done to make sure it's a valid address, if not it's
rejected - after all if we can't do a sender verify if there's a problem
we can't report it back so the message will seem to drop into a black hole
if we don't.
Sender: RCPT TO
Recipient verify to make sure that the recipient is valid so we don't have
a ton of bouncebacks. Greylisting is done here also.
Message is read in and then RBL type checks are done and X-headers added
if found. Message is run through SpamAssassin with Bayesian filtering
enabled. Messages are not rejected because of RBL/SpamAssassin, it is
left to the user to set up their MUA to decide how harshly they want to
treat spam. Most users don't even bother, since most spam is already
filtered out anyway at this point, but SA will at least capture any spam
that's sent to mailing lists and similar that will look like real mail.
If the message makes it this far, it's accepted and delivered. If delivery
fails, at least there's a tested valid address to bounce it to, and we can
be reasonably sure it's probably not spam.
This approach is running across 4 relatively low-end machines (nothing
faster than a 2 gig P4, and the slowest is a PIII 667), each one
processing around 2-3000 messages a day, accepting around 500-1000
messages a day. Load average on these boxes very rarely gets over around
0.5, we have very few bouncebacks (I think about 4 or 5 messages a week
manage to work their way through to being a bounceback - I have a
suspicion there may be a few spam domains with short-lived dummy
mailservers for sender verify fooling), and our customers are pretty happy
with performance - one comment I heard was "now the mail is filtered I'm
getting mail from a whole bunch of mailing lists I'd forgotten I'd
I think the key to running this is to reject as much mail as possible as
early as possible with the lowest CPU usage possible. HELO checks for
validity followed by HELO checks for dynamic addresses (using simple
regexes) is what really did the trick. All the high CPU usage stuff
(SpamAssassin being the worst offender) is left till as late in the
session as possible.
More information about the nSLUG