Subject: [Asrg] Re: Wierd reverse DNS resolution might affect spam filters.

From: Douglas Campbell <[email-masked]>
Date: Sun, 25 Jun 2006 10:39:29 -0700

Claus Assman said:
> As it has been pointed out before, sendmail does the "reverse" check
> (for obvious reasons). You can access that information in your
> milter, see the sendmail documentation (doc/op/op.*):
>
>       ${client_name}
>            The host name of the SMTP client.   This  may  be
>            the  client's  bracketed IP address in the form
>            [nnn.nnn.nnn.nnn]    for    IPv4     and     
>            [IPv6:nnnn:...:nnnn] for IPv6 if the client's IP
>            address is not resolvable, or if it is resolvable
>            but  the  IP  address  of  the  resolved hostname
>            doesn't match the original IP  address.   Defined
>            in    the    SMTP    server   only.    See   also
>            ${client_resolve}.
>
>   
I see it's there. Then why does the milter interface xxfi_connect() 
provide the untrustworthy name? I would have expected it to provide just 
the bracketed ip address, given the description above. I draw your 
attention to this line in my milter log as described in my initial 
message in this chain. This entry describes faithfully in text what 
libmilter provided my milter in the 2nd and 3rd arguments (the 
"hostname" and IP address of the sending mailhandler). [the first 
argument is a unique per-milter identifier of the transaction, and the 
number 1 after the parameters indicates the number of outstanding 
connections to the milter]:

2006-06-23 08:15:09.589901-07:00 [mx] 
connect(821,localhost,[222.252.168.54]) 1

The text "localhost" was provided to my milter by libmilter. So 
libmilter is not providing me ${client_name} in xxfi_connect(), but 
something else. The "something else" is obviously a successful rDNS 
resolution, per the xxfi_connect() documentation, but not the bracketed 
IP address that sendmail claims it gives for ${client_name} if the rDNS 
resolution yielded false results.

That, coupled with sendmail not logging a word about "localhost" out of 
[222.252.168.54] failing any truth test, nearly guarantees that at least 
one clueless newbie programmer such as myself will make this sort of 
mistake.

However, given what Claus said, it seems that I will be able to get what 
I need out of sendmail/libmilter via smfi_getsymval() coupled with 
confMILTER_MACROS_CONNECT. DNS lookups are expensive, so I obviously 
want to minimize them; if sendmail has already done what I want and can 
give it to me, that's OK.

It's nice that libmilter has the hooks to get the truth information; I 
just question why the truthful information isn't provided in the first 
place by default (with untrue information provided on request via 
smfi_symval()), thus decreasing the chance that idiots like myself will 
make a mistake.

Cheers,
Doug

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Claus Assmann <[email-masked]>
Date: Sun, 25 Jun 2006 11:01:46 -0700

> provide the untrustworthy name? I would have expected it to provide just 

Good question. Someone else already filed a bug report, so this
will probably be changed in 8.14.

> something else. The "something else" is obviously a successful rDNS 

      ${client_ptr}
           The  result  of  the PTR lookup for the client IP
           address.    Note:   this   is   the    same    as
           ${client_name}  if  and only if ${client_resolve}
           is OK.