This is a discussion on Re: Spam filtering non-features within the mailing.postfix.users forums, part of the Mail Servers and Related category; Noel Jones: > At 01:50 PM 5/6/2005, Victor Duchovni wrote: > >On Fri, May 06, 2005 ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
Noel Jones:
> At 01:50 PM 5/6/2005, Victor Duchovni wrote: > >On Fri, May 06, 2005 at 02:20:42PM -0400, Wietse Venema wrote: > > > This would be an argument to keep the name check_ptr_access > > > and to make clear that it is the dumbest possible lookup > > > routine that doesn't even follow CNAMEs. > > > >Yes. The requirement is I think to handle unmodified PTR data from DNS > >essentially as-is (modulo syntax issues below). > > seems to me most userland tools will follow the CNAME unless you explicitly > tell them not to. > I think CNAMEs should be resolved, if that fails, then "unknown". Good point. The Postfix DNS client follows CNAMEs too, and will report failure when the target of the CNAME is not found. Turning off CNAME expansion would involve a new option. If we are to follow CNAMEs and sanitize the result, then we might just as well use getnameinfo(), for consistency with the hostname as used in logging and access control. Wietse > This is already what is logged by postfix with the "connect from" or if it > can't be verified, in a warning: message, so the cannonicalized name will > be the one "naturally" used by someone examining their log. > > So I would argue for following the CNAME if there is one, and also suggest > that we already know the client PTR as it was reported when the client > connected. > > Converting REJECT into DEFER on DNS lookup failure would be a great > improvement. > > -- > Noel Jones > > > |