On 2013-08-11 12:38, manu@... wrote:
> >Can you please suggest an example of config which explicitly whitelists
> > passes and blacklists failures (where an spf rule is defined in dns, and
> > the sender is not among permitted addresses)?
>
> racl whitelist spf pass
> racl blacklist spf error
> racl blacklist spf fail
Thanks, in the absence of any documented examples I tried to quote the
statuses which gave syntax errors... vague indications in the mailing
list archives got me on track though; but thanks for your reply to
confirm my guesses :)
Then I dug into libspf* headers to decipher the numeric result codes
(since milter-greylist does log the return, but only as numeric value),
and it seems that every library has its own numbering :(
So, here is the ruleset I came up with, and in experiments it seems
reasonably working - in my tests.... is there anything glaringly wrong
in the snippet below, or would you say it is okay for production use?
# cat milter-greylist.conf-70-SPF
### See http://www.openspf.org/SPF_Record_Syntax for values
### See also http://vamsoft.com/support/tools/spf-policy-tester
### $Id: $
### Logged libspf result code numbers, according to "spf.h"
### enum SPF_RESULT:
### 0 SPF_PASS
### 1 SPF_NONE
### 2 SPF_S_FAIL
### 3 SPF_H_FAIL
### 4 SPF_ERROR
### 5 SPF_NEUTRAL
### 6 SPF_UNKNOWN
### 7 SPF_UNMECH
### Logged libspf2 result code numbers, according to "spf_response.h"
### enum SPF_result_enum:
### 0 SPF_RESULT_INVALID = 0 /**< We should never return this. */
### 1 SPF_RESULT_NEUTRAL
### 2 SPF_RESULT_PASS
### 3 SPF_RESULT_FAIL
### 4 SPF_RESULT_SOFTFAIL
### 5 SPF_RESULT_NONE
### 6 SPF_RESULT_TEMPERROR
### 7 SPF_RESULT_PERMERROR
######## Interpretations:
### PASS The SPF record designates the host to be allowed to send
### SOFTFAIL The SPF record has designated the host as NOT being
### allowed to send, but is "in transition" (accept & mark)
### FAIL The SPF record has designated the host as NOT being
### allowed to send (reject)
### NONE The domain does not have an SPF record or
### the SPF record does not evaluate to a result
### NEUTRAL The SPF record specifies explicitly that nothing can be
### said about validity (process as if no SPF record was
### published)
### ERROR A transient error has occured (like DNS timeout)
### UNKNOWN A permanent error has occured (eg. badly formatted SPF
### record)
### Possible values are pass, softfail, fail, unknown, error, none,
### and self. The first six values are plain SPF validation status.
### The self value is a special test that checks the server's local
### IP address against the sender's SPF record. If that test validates,
### odds are good that the sender SPF record is wide open, and this
### is a hint that SPF should not be trusted.
racl blacklist spf fail msg \
"SPF verification failure: sender host '%d'[%i] not among
explicitly allowed origin hosts for domain '%sf', and misses are
forbidden; REJECT"
racl greylist spf softfail delay 120m msg \
"SPF verification soft failure: sender host '%d'[%i] not among
explicitly allowed origin hosts for domain '%sf', but misses are
permitted; delay by %R"
racl greylist spf self delay 120m msg \
"SPF verification soft failure: sender domain SPF ruleset is so
permissive that our relay can impersonate it; delay by %R"
racl whitelist spf pass
### To debug
#racl greylist spf none delay 2m msg "SPF: none"
#racl greylist spf error delay 2m msg "SPF: error"
#racl greylist spf unknown delay 2m msg "SPF: unknown"
#racl greylist spf neutral delay 2m msg "SPF: neutral"
### Unknown/Neutral, Error and None fall through to other greylist rules
Now, for the last debug lines - it might be nice to have a "noop"
keyword which does not make a white/grey/black-list decision but
allows to output a message into logs or SMTP dialog, and goes on
to other processing to decide the ultimate *-listing result :)
Also, I have no idea yet if "SPF self" works for Messaging Server
without the if_addr macro... and that "localaddr" keyword is so
far only defined for Postfix at compile-time...
On a side note, I found that even though I've set lengthy timeouts
here, if the remote host tries to post FROM: another domain, chances
are that it will hit another greylisting rule with a much shorter
timeout and will overall be accepted faster. I guess this is where
the difference of delays for IP only vs IP-from-rcpt tuples shows :)
HTH,
//Jim Klimov