Milter-greylist

On 2013-08-12 05:20, manu@... wrote:
> Jim Klimov <jimklimov@... <mailto:jimklimov%40cos.ru>> wrote:
>
>  > I wonder if it makes sense to test "spf self" with 127.0.0.1 for
>  > example, in case neither {if_addr} nor "localaddr" are set, instead
>  > of bailing out completely? After all, we are checking that the SPF
>  > is so loose it allows unexpected addresses?..
>
> The spammer may use a domain that passes 127.0.0.1. It is less easy to
> prepare a domain that will mathc the MX of all the target recipient.

But isn't the point of the "spf self" test to detect that a spammer
owns or abuses a domain whose SPF record allows too much - such as
our server's address or loopback net, or "+all" completely - so that
we would not trust a "pass" result from this domain?

BTW, how is it supposed to work, given that currently there are no
"if" or "goto" structures in milter-greylist config language? :)
Should some "and-or-xor" evaluate both results in one rule?

The more I think about it, the less I am certain of my understanding.
It seems that now the SPF checks should be near the end of config,
just before the "greylist default" line - and after all our explicit
white and black lists, or custom-length greylists like those I posted
based on regex matching of "dialup-like hostnames"; so that we blacklist
"fail"ures, greylist-long "softfail" and "spf self" hits, whitelist
"pass"es and default the others?

Is there a way to permit "spf pass" EXCEPT "spf self" hits early
in the rules, and have those "spf self" hits fall through and be
subjected to all the other tests like regex - not plain greylisted?

On a side note, the libspf2 headers quote the SPF standard that the
mailers "SHOULD" add a header about processed SPF - verdict and
details (more details at http://www.openspf.org/SPF_Received_Header).

I've tried "addheader" on an spf rule, but milter-greylist crashed
for some reason when this line was in the config; the header text
was rather short (shouldn't exceed 2048 bytes by a long shot),
though it had some format strings; I did not debug any further.

On another note, I'd like to log the remote host's IP, HELO, DNS PTR
and FROM/RCPT addresses into X-Greylist headers of each processed
message. Is it possible to add via config - without hacking into
the "report all" source code?

As I've asked earlier - are there any ways to unconditionally inject
SMTP responses (like "msg") and/or headers without dependency on a
particular ACL rule hit and its msg/addheader parameters?

Thanks,
//Jim