Re: [exim] Backscatter & Sender callouts.

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Jonathan Knight
Dátum:  
Címzett: exim-users
Tárgy: Re: [exim] Backscatter & Sender callouts.

> We noticed that there are a few outside receiving servers that are
> rejecting email because our server is listed on backscatter dor org. As
> you can see from the config below, we also check this list.


backscatterer.org has a poor reputation and there are a number of
articles on the net that take a very dim view of their activities.

The ironic thing is that UCE Protect (who run the backscatterer) state
that the list should ONLY be used to block inbound mail from postmaster
or the error sender <>. It is not intended for a general purpose block.

Some sites try to use it as a general purpose block and that will cause
a lot of problems for them.


You can reduce the amount of backscatter that you generate by ensuring
that you do inbound recipient callout checks at your gateway to ensure
that you generate 5xx messages for unknown users at the gteway and not
on an internal server that requires your gateway to generate the NDR.
However Exim will always hit problems with the autoresponders part of
the exim filter and with over quota mailboxes.

A simple solution is to use multiple IP's for your outbound email. Make
sure that all messages from postmaster or <> are sent through one IP
address and everything else is sent through another. That way
backscatterer.org will only ever list your postmaster/<> server and so
your normal mail will not be affected.


My servers are frequently listed on backscatterer.org because we allow
our users 4 days to get below quota. During that time we generate
"delayed message" warnings back to the sender and if that sender is
forged then we can get caught by a backscatterer trap. I'm reluctant to
change our over quota policy and I think generating a warning to the
sender is only polite so I have to take the hit on getting listed. So
far I've had no complaints from our users about not getting email through.


jon.