[nSLUG] Whither to bounce unknown recipient address?

Dop Ganger 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:

Sender: HELO
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 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.

Sender: DATA
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 
subscribed to".

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.

Cheers... Dop.

More information about the nSLUG mailing list