[exim] Using DEFER instead of DENY or DROP for spam

Top Page
Delete this message
Reply to this message
Author: Nikademus
Date:  
To: exim-users
Subject: [exim] Using DEFER instead of DENY or DROP for spam
I had some thought about doing this kind of thing.

Some explanation of my idea:
If you have a message you know for sure it's spam, let's consider doing
a comparison between doing DEFER and DENY/DROP

DENY/DROP:
- If it's a spambot/virus, the error code is of no real importance.
- If it's an openrelay, the message won't be resent and will be cleaned
out of the openrelay queue.

DEFER:
- If it's a spambot/virus, the error code is still of no real
importance. The spambot may or may not retry, but it's independent from
the error code, just as formerly.
- If it's an openrelay, the message will (at least should) be resent
later.

From this point, DENY may seem the best technique as you won't get spam
back in the case of openrelay.
However, if many mail server admins do a defer on known spam messages,
queues will grow on openrelays as they have to resend mails instead of
flushing the denied mail from the queue. So, this will slow down spam
propagation from this particular openrelay.

Of course, like teergrubing, this is mostly a benefit to others, but the
idea is to raise the costs of sending spam.