Milter-greylist

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