Re: [exim] Backscatter

トップ ページ
このメッセージを削除
このメッセージに返信
著者: W B Hacker
日付:  
To: exim-users
題目: Re: [exim] Backscatter
Ted Cooper wrote:
> On 05/06/10 00:52, Grant Peel wrote:
>> Hi all,
>>
>> I am looking to ensure the configuration below will not send backscatter and
>> will not accept NDRs from any server other than iteself (locally generated
>> only).
> [snip]
>
> This doesn't address your your question of not sending backscatter, but
> rather attempting not to accepting it when it looks the same as a callout.
>


There is never just 'one correct answer' - but simple steps can be the most
effective:

IF you insure you always indicate a rejection 'in session', and never send a
possibly mis-directed NDR/DSN to an off-box server... (which could be a major
contributor to getting back a bounce). See 'errors_to'

AND trust that other well-managed servers will do the same more often than not..

AND go ahead and accept incoming DSN/NDR..

BUT..

- only if they are from servers with legitimate credentials, not forgeries
(pass rDNS, AND NOT RBL'ed)

- and obey 'the rules' (one recipient/addressee ONLY). See recipients_count

THEN divert all such to a sysadmin for a manual review, onpassing only if
appropriate...

One may find fewer than one per MONTH that has to be so onpassed.

Seriously.

Why so?

- Nearly all bogus DSN/NDR WILL have originated on a forged source nailed by the
initial barriers as early as CONNECT. No further workload but a log entry.

- Such of the many otherwise-proper servers that remain unable to give YOU an
in-session rejection .... simply deliver the message so often that their DSN/NDR
load on YOU doesn't amount to much.

IOW - unless your user-community have a boatload of dodgy correspondents,
mal-configured greylisters, and/or you have a poorly-controlled MLM or
web-script running, it just need not be a problem.

> Your use of ips.backscatterer.org in the RCPT acl will mean that if you
> ever send even a single email any of Marc Perkel's mail servers, he'll
> instantly add you to his blacklist and report you for spamming to your
> ISP; all because of a rejected sender callout.
>
> So useful.
>


I'm no fan of Marc's ways of 'tasting' or playing with spam to inflate stats
instead of simply blocking it - but he is by no means alone in raising the bar
to unwanted sender callouts.

No need to blacklist. No need to greylist. Just insist on valid credentials and
limit all comers to ONE simultaneous connection per source IP if you are feeling
hard done by, two if feeling generous.

> I say this 3 days after this happened for the SECOND time when sending
> to a different person to last time. Again it was just an email from
> friend to friend. I have asked my ISP to ignore all "spam notifications"
> from Marc in the future.


Curious as to which ISP would have paid any attention to his 'service' in the
first place?

>
> I'm thinking of either using the backscatterer list as a blacklist for
> outgoing mail so I never send to someone listed in it, or moving my
> check from rcpt to pre-data. The later would be conceding defeat to the
> turkeys so I'm not too keen on it.


I agree their goals.

But I don't see any need to use them as a blacklist.

Local rules will either block or 'sanitize' (as above) the same folks they list
*when misbehaving* ELSE NOT, hide fewer 'false positives'. All w/o need of
calling a Remote BL or being concerned if it is available, responding rapidly,
or accurate.

Chronic offenders you can LBL more cheaply.

Usual disclaimers: 'BFBI' and 'Works for me'

YMMV,

Bill