Hi vlad!
> Unfortunately, using this policy as argument is impossible, me simply
> will forced to replace exim with another mta. so, i just redirect
> spammers to other mta by firewall.
Switching to another MTA would surely slow the spammer down, at least
for a while. :) On the other hand, if "policy" is not a suitable
argument, you should come up with as many "technical" arguments as
possible, even if they are not completely true. I would consider
doing some or all of the following:
- Reject connections from spammers by a temporary error message:
421 Too much load; please try again later.
This *is* a valid Exim error, you just have to make it appear more
often than usual, e.g., by limiting the server to one SMTP
connection at a time.
- Delay the initial SMTP banner by some reasonable amount of time:
10-60 seconds before the banner is returned is not unusual,
remember that the server is under heavy load delivering all that
spam, has to do ident lookups, host verification, etc.
- Prevent the spammer from forging his return address:
That way he'll get all the bounces from undeliverable spam, which
places an even higher load on your mail server -> less resources to
send out spam. If the spammer forges his return address, deny his
MAIL FROM or RCPT TO commands (unauthorized access).
- Limit SMTP connections to one or very few transactions:
The spammer will be forced to reconnect for every message he sends.
- Limit RCPT per message to a few:
10 RCPTs is usually enough even for legitimate mail, unless you are
running a mailing list server. Any additional RCPTs must be
rejected by a temporary error to prevent bounces.
- Delay RCPTs by a reasonable amount of time (see delay SMTP banner):
Again, 10-60 seconds is not unusual, increasing the time for every
subsequent RCPT.
- Queue all messages from the spammer:
This places a high load on the storage subsystem, which may
eventually run out of space.
- Limit queue_run_max and remote_max_parallel:
This will slow down the rate your mail server sends out the spam to
the victims, and will cause the queue to grow even faster.
None of the above will have any significant impact on legitimate mail,
but will severely impact any spammer, without actually denying him
service, especially when you are able to transparently redirect him
via a firewall.
The following options may not be appropriate, because they sometimes
affect legitimate mail and may be prohibited by local laws:
- Perform pedantic syntax checking on spam mails, and reject any that
do not completely conform to RFCs:
This may be counterproductive, because some scanners rely on
syntactic errors in messages to filter out spam. Then again, you
can
- Modify spam messages in subtle ways so that they can more easily be
identified as spam:
Add a lot of spaces in the Subject: header (preferably at the end),
add some X- headers stating that this message is spam or that
otherwise enable a scanner to identify your messages, add bogus
Sender: headers that contain unqualified addresses (Exim may not
allow you to do that), etc.
Andy
--
Andreas J Mueller email: <andy@???>
