Milter-greylist

On Mon, Aug 05, 2013 at 03:14:21AM +0200, Jim Klimov wrote:
> Hello all,
> 
>    I am trying to make milter-greylist work with Sun/Oracle Messaging
> Server (part of Oracle unified Communications Suite now), and there
> is a problem which I've touched on recently - its partial milter-API
> implementation. While extending and porting some rulesets from our
> Sendmail-based relays, I found that the "domain" keyword only has
> the bracketed IP-quad as the submitter host's name, like "[1.2.3.4]".
> 
>    Since milter-greylist does use DNS a lot anyway (RBL, SPF, etc.)
> I wonder if it is possible to add a re-request into DNS for such
> botched remote client names? Perhaps there is already a keyword to
> enable such behavior?
> 
>    Also, are there any configuration patterns to enable DNS-based
> tests that the remote host's HELO/EHLO name matches the textual
> name in the DNS PTR entry for its IP address, and that this name
> from DNS PTR resolves back to this IP address (or includes it
> among multiple values) - i.e. what I believe Sendmail does when
> estimating address "forgery"?

Sendmial provides macro client_resolve, I use it like that:

sm_macro "maybe_forged" "{client_resolve}" "FORGED"
racl greylist sm_macro "maybe_forged" delay 1h autowhite 3d


>    I tried to print in milter-greylist's "msg" clause the values
> of "sendmail macros" listed in different articles and blogs, and
> found that if_addr, client_name, client_ptr are not defined; the
> helo is defined to whatever the remote host wrote about itself,
> client_addr is defined to the IP address (no brackets), and I did
> not find a macro which would contain the domain name (%d in milter
> greylist formatting), which is the IP in brackets.

The real problem has it root in how Solaris (back into acient days)
handles IP to hostname mapping: Even a valid mapping from ip to hostname
exists, if the hostname does not exist or does not map back to the
originated IP the name is not taken! Gave me headache in all the
IP translation stuff for years ...
Solaris calls this kind of double-reverse check "security" (other call
it paranoid, e.g. TCP wrappers package). ;)

I didn't find a way to circumvent this behavior (in Solaris,
except with something like a dynamic library hook or similar).

Johann