Lloyd Zusman writes:
But what about these two cases, both of which refer to the case where all three variables are set to "all", and where there is a courierfilter that is controlled by /var/spool/courier/filters. 1. a message comes in for which SPF fails, and there are no maildrop
If all three variable are set to "all", SPF checking never fails, since all possible SPF results are deemed acceptable.
whitelisting rules, and the message therefore gets sent to
a courierfilter
2. a message comes in for which SPF fails, and there ARE matching
maildrop whitelisting rules which then cause the courierfilter step
to be bypassed (because it's controlled by
/var/spool/courier/filters).
In case 1, it's clear that the message will be (or at least _should_
be) sent on to the courierfilter.
But what about case 2? The message won't be sent to the courierfilter,
so is there then a possibility that the SPF fail will cause a 517
message to be returned to the sender, after all?
No. Either SPF checking accepts the message or rejects it. One or the other. If an SPF check results in an unacceptable status code, the message gets rejected by a 417 or 517 code (depending on the setting of BOFHSPFHARDERROR).
If an SPF check results in an acceptable status code, the message passes SPF checking, and normal processing continues, which may or may not involve courierfilters, depending on other factors. SPF is now completely out of the picture, and no longer has any bearing on the eventual outcome (except for the presence of a few additional headers that record the results of the SPF check).
Once SPF checking is complete, subsequent processing is no different than what would've happened if SPF checking wasn't enabled at all.
pgpOnKoN4nmOx.pgp
Description: PGP signature
