Re: [Exim] Rejecting due to reverse DNS lookup failture

Top Pagina
Delete this message
Reply to this message
Auteur: Chris Bayliss
Datum:  
Aan: Terry Edhouse
CC: exim-users
Onderwerp: Re: [Exim] Rejecting due to reverse DNS lookup failture
>     At the moment we refuse to accept mail from hosts where a reverse DNS
> lookup fails to supply a hostname for the calling IP address, or if the
> returned name gives a different IP address when it is looked-up (or the
> lookup fails).
>
>     My question is - how common is this practice amongst members of the
> list, and how do you deal with the users who give you grief because mail
> to them is not getting through?

>


We tried this for some time (before we ran exim) and found that whilst it
was very good at stopping spam that it caused too many problems. In the
end we had to make exceptions and maintaining the exception list became too
much work and we abandoned this when we installed exim. Our main reason
was spam reduction. We now use RSS, RBL and DUL which were not practical
options with the previous software.

The big problem with sender exception lists is that users perceive that the
fault is yours, because you've changed something and email now works for them.

The list of servers was quite interesting. There were various noticeable
areas which had a lot. These included Latin America, India, France and
UK companies (mainly small but as far as I can remember there were one
or two bigger ones like Nestle UK). The fact that there were large groups
like this affected some departments a lot particularly if they had a lot
of key contacts in these areas. Some complaints were in languages that
I didn't understand which did hamper comunication.

A lot of small companies caught out complained that they were at the
mercy of their service provider for DNS services and could not fix the
problem themselves. Others complained that the email was coming
through their firewall which wasn't registered for reverse lookup for
security reasons. These did seem to be pretty lame excuses, but got in the
way of

Chris Bayliss
Information Services
The University of Birmingham