[Mimedefang] spamtrap on secondary MX
Aleksandar Milivojevic
amilivojevic at pbl.ca
Wed Nov 24 11:13:53 EST 2004
-ray wrote:
> I read an article in SysAdmin that talked about setting up a spamtrap on a
> secondary or tertiary MX box. The box would look like a good MTA, answers
> helo and 'mail from', but on 'rcpt to' always returns "451 Try again
> later". The idea being spammers prefer secondary MX's, but will never try
> again. A legit host that happens to connect will of course try again
> later (hopefully to primary MX). The author claims this reduced spam
> intake by 10%.
>
> Anyone done anything similar? Any thoughts? Seems like a simple way to
> catch a lot of spam...
10% doesn't sound like lot of spam. Dedicating entire machine just for
this seems more like waste of resources. Plus you risk some brainded
MTA always reattempting connection to secondary MX, and thus never
delivering otherwise legitimate email.
Refinement of the above idea is gray listing. You keep database of
sender/recipient pairs and tempfail them for 5 minutes (or you simply
accept second retrasmission, whenever it happens). Than you start
accepting them. If remote side hasn't attempted retransmission in five
days, you remove the entry from database after it is 5 days old (that is
for how long the remote side will usually keep retrying anyhow). If
remote side did (accepted) retransmission, you keep entry in database
for some period of time (couple of hours, up to one day) after last
successfull mail exchange between sender and recipient (this will ensure
that if two persons are exchaning several emails during short period of
time, only the first email will be delayed). Of course, you would
bypass gray-listing for outgoing mail (no point in delaying your local
site's email). Unlike previous idea, this can be implemented on all MXs.
I'm not particualry fond of gray-listing either. The amount of spam it
blocks isn't worth the delay in legitimate email exchange between two
individuals. Your spam problems don't need to be identical to mine, so
it might work better for you.
There are cuople of filters floating around that implement gray-listing.
Theoretically, it should be possible to implement it directly in
mimedefang-filter, but don't know anybody that did that. Basically what
you would do is create filter_recipient function, and place some code
that creates and maintains database (Berkely DB files, for example).
You'd keep in there sender/recipient pair, and timestampt with flag
telling if timestamp is time of initial (tempfailed) transmission or if
timestamp is time of last accepted email exchange. Depending on this
you either accept or tempfail. From filter_sender you can check for too
old entries, and purge them (filter_recipient is called once for each
recipient, so it might be more efficient to purge entries in
filter_sender or fiter_end that are called once per email).
Gray listing can be implemented using remote side's IP address instead
of sender/recipient pair, or by using only sender's email address
(probably not as efficient). Implementing it using IPs isn't good idea.
Remote side might have farm of mail servers operating on shared mail
queue (I'm not aware of any such existing configuration, but that
doesn't mean it does not exist somewhere out there), so theoretically
each retransmission attempt might come from different IP address.
--
Aleksandar Milivojevic <amilivojevic at pbl.ca> Pollard Banknote Limited
Systems Administrator 1499 Buffalo Place
Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7
More information about the MIMEDefang
mailing list