Julian Mehnle wrote:
These are heuristics, which means they get tweaked when needed to get
legitimate mail delivered. They are never complete or "correct" by
definition. I already second guess him and assume that he meant "ip4"
when "ipv4" is used. I haven't had the need to translate a:<numeric_ip>
to ip4 - but it is feasible - and in fact I just added it to CVS. In
the code, the pattern is to check for a common mistake, call note_error
to record an official PermError result with a diagnostic tailored to the
mistake, then correct the mistake and continue processing to compute the
"guessed" result. For instance, the a -> ip4 code I just added looks
Stuart D. Gathman wrote:
Fair enough, but how likely is it that the postmaster has checked the SPF
record for /non-basic/ correctness if he hasn't checked it for /basic/
correctness? Are you going to second-guess him on "ipv4:220.127.116.11" and
In no way does "lax" mode transmute a permerror into a pass. The only
thing "lax" mode heuristics do is change the local policy as to
whether to accept a message with SPF permerror. I add my own
"X-Guessed-SPF" header to record the result of the heuristics.
"a:18.104.22.168" issues as well? </devils-advocate>
if m == 'a' and RE_IP4.match(arg):
x = self.note_error('Use the ip4 mechanism for ip4
m = 'ip4'
Even when 'lax' mode (accept messages with permerror when a "corrected"
policy yields pass) is not active, the tailored diagnostics for the
PermError are a win.
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com