Re: [exim] Sending To A Forged Address

gascione wrote:

> All of our mail is filtered by inbound MX servers running Exim4.x and is sent
> from our primary servers to outbound servers running Exim. This is all done
> to help us perform as many checks we can on inbound and outbound mail.
>
> We have been having a problem with some of our clients autoresponders
> resonding to forged email addresses that are real email addresses. The real
> problem comes in when one of those forged email addresses happens to be a
> SPAM trap for SPAMCOP. We end up getting listed for 20 hours.
>
> Anyway to stop inbound or outbound forged email addresses. Loaded question I
> know but we were pretty sure we were using every ACL we could possibly use.
> I suspect the only way to stop it is at the source by not letting a forged
> address into our primary mail server.
>
> GA

Might not be autoresponders alone....

Key here is that while preventing autoresponders should be OK on the secondaries
(only), you need to *also* make sure you don't have non-connect-time
rejection/bounces to forged addresses from any of your hosts.

If forgeries are getting in at all, then you aren't quite using all the
available tools to prevent them.

Downside is that some of those tools will give apparent false-positives, perhaps
'bigtime'.

Ex:

- strictly requiring forward/reverse hostname/IP match will block a lot of
'outbound only' servers that *could* have at least an 'A' record created - but
have not had. We do it anyway, 'coz it kills nearly all 'zombies', then
whitelist when we must (fewer than a half-dozen, normally).

- requiring HELO to be a hostname that resolves to the/an IP belonging to the
sending organization would be nice, but block far too many genuine
organizations. We do that, but only for the top 10-15 ISP's, as they do try to
keep things consistent, if not matched. We also blacklist about 200-500
worst-offenders by HELO name, as some zombie software will repeat that even
while migrating across thousands of IP's. Lots of samples in archives here.

- blocking on black/brown lists renewed from dynamic IP RBL's helps.
There is no such animal as a 'legitimate' mail server on dynamic IP, but that is
probably not where the spamtraps are, either. Might need to whitelist 2 or 3 only.

- require verify = sender has been a disappointment. As with 'ident' callouts,
there are too many major players for whom it breaks down becasue of
inbound/outbound server pool DNS & HELO laziness - and too few where it works.

Some ISP may even locally BL frequent inquirers on the basis of too many
connections opened then abandoned w/o traffic, as it can look suspicious.
(try it - do your *own* servers even respond corectly to an attempted sender
verification?)

If it is any consolation, Spamcop won't much hurt your credibility with our
servers - you experience with their flakiness is not unique. We haven't quite
given up checking them altogether, but do look at their hits with one eye
shut...the log_message line a hit produces reflects the name of a famous
military anti-hero:

log_message = Brownlisted in General Leif Ukdup $dnslist_domain

;-)

Bill