Re: [exim] How to not reply to bad mail

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: W B Hacker
Dátum:  
Címzett: exim users
Tárgy: Re: [exim] How to not reply to bad mail
Rick Duval wrote:
> I now have a lookup that accepts emails only for addresses that are in
> the database.
>
> accept   condition = ${lookup mysql{SELECT count(*) from addresses \
>                       WHERE active AND domain='${quote_mysql:$domain}'  \
>                       AND local_part='${quote_mysql:$local_part}'}}

>
> deny
>
> It works great but I don't want to contribute to backscatter by
> sending denial messages back to the sender everytime an address is
> rejected.


So long as you are doing the 'deny' in acl_smtp_rcpt, you are NOT
sending backscatter.

Instead, an 'in-session' handshake tells the currently-connected sending
machine, in near-real-time.

> Right now it sends out and email like:
>
> SMTP error from remote mail server after RCPT TO:<bob@???>:
>     host duvals.ca [74.51.38.171]: 550 5.1.1 <bob@???>:
>     Recipient address rejected: User unknown in virtual alias table

>


That is not an e-mail message. It is a log entry reflecting what the
sender was given in 'real time'.

The *sending server* may raise a DSN message to their client. Which is
harmless, as that is an entity known-to-them, and properly logged-in
when they sent.

Or so it should be....

In reality, most of these non-existent addresses come from spambots.
It does no harm to give them a proper denial message, so long as it is
during the connection, not later.

IF, OTOH, they have failed an rDNS / forward/reverse lookup, have
HELO'ed with other-than a FQDN, are in a dynamic-IP or other RBL...etc

You might impose a 30 second delay. Then hand them a 'defer' instead of
a deny.

Most won't wait. They'll drop off the teat at 13 to 18 seconds so they
can go hammer a more willing victim.

Done in acl_smtp_connect, HELO, and mail_from ---- BEFORE you have had
to do the recpt-to SQL DB lookup, it reduces lookup workload on the server.

> Can I turn that off and just not have it reply at all?
>


One can, but it is neither necessary nor (ordinarily) desireable, as it
'blinds' your logs to possible edge cases wherein you may need to
whitelist the odd idiot who thinks the price of a Linux or *BSD CD makes
hime into a mail service w/o need of fixed-IP, MX and PTR RR.

Just try to insure that any and all rejection is done in acl's, NONE in
router/transport sets.

Your own user community's 'outbound' traffic that might get the odd
'undeliverable after X days' is the exception - you KNOW who they are...

HTH,

Bill