Re: [EXIM] Exim 1.82 and RFC2317

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Peter Radcliffe
Date:  
À: exim-users
Nouveaux-sujets: [EXIM] several messages
Sujet: Re: [EXIM] Exim 1.82 and RFC2317
Bruno Vuillemin <Bruno.Vuillemin@???> probably said:
> Here's a summary of the mail I received
>
> -------------
> The machine is question, netra.rega-sense.ch, is at a company I'm working
> for. Since the machine isn't on a full class C network, the reverse lookup
> is not configured as usually, but according to RFC 2317 ("Classless
> IN-ADDR.ARPA delegation").
> --------
> (He works also in the university of Fribourg and shows that
> name resolution is ok from a Sun workstation situated within
> the University)
> --------
> $ nslookup 195.141.72.66
> Server: siuftesun02.unifr.ch
> Address: 134.21.1.31
>
>   Name:    netra.rega-sense.ch
>   Address:  195.141.72.66
>   Aliases:  66.72.141.195.in-addr.arpa

>
> Given that we're running this setup for more than half a year now and
> that we never ran into any problems of this kind, it is hard for me to
> believe that something is not properly configured at our site. Your site
> is the only one we are having this kind of problems with. ;(
>
> Is is possible that your mail server software is outdated and does not
> properly support RFC 2317? This RFC is quite new, it dates from March
> 1998.


RFC 2317 ("Classless IN-ADDR.ARPA delegation") defines a reasonable
hack for working around delgating reverse DNS of part of a larger than
traditional class C.

exim is just calling the machine's resolver to get reverse DNS (and doesn't
need to in all cases).

The problem with RFC 2317 is that its a hack. Some older resolvers just
plain break. Most Sun resolvers (Solaris and SunOS with bind named hacked
into libc are known good) are ok, but older versions of Linux, *BSD and
others are not, to my knowledge.
I can't get onto any of my more modern FreeBSD boxes to check those right
now, but NetBSD 1.3.2 is ok. FreeBSD 2.1.6 or so was broken (they are now
on 2.2.7).

What OS is the box running exim using ? What reolver libraries is it
using ?

A work around for this is to remove all * entries in the sender_*reject
entries or add "+allow_unknown" to the list.
from section 7.15 of the spec:

] In some situations this may be too harsh, so if an entry in a host
] list is the string '+allow_unknown', and a gethostbyaddr() lookup for
] any subsequent item in the list fails, the opposite action to the
] default happens. That is, for an 'accept' list the host is deemed to
] be in the list, and for a 'reject' list it is deemed not to be in the list.

P.

-- 
pir               pir@???      pir@???      pir@???



--
*** Exim information can be found at http://www.exim.org/ ***