[Mimedefang] spamtrap on secondary MX

[Aleksandar Milivojevic]

-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