In <427AF108(_dot_)3B39(_at_)xyzzy(_dot_)claranet(_dot_)de> Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> writes:
wayne wrote:
Feel free to propose the change to a vote on the council.
The Council deciding on the 2821 "MUST accept source routes" ?
I've just posted my old -01pre2 proposal about this statement
in reply to Julian, let's see what happens.
I don't think we can decide on 2821 issues.... I was referring to the
"should eliminate the reference to %-hacks", but feel free to submit
whatever you want. The council has, at various times, shown they can
vote pretty quickly. ;-)
I would be happy to just eliminate all references to the
SPF RR, but that ain't gonna happen.
I'd be happy to play with a s/TXT/SPF/g - but that's also not
possible. I'm unsure about any "SHOULD reject if different"
in practice. How would you implement this without useless
timeouts ?
"SHOULD" means that you are supposed to do it unless you have good,
technical reasons not to and that you have considered the issues. I
consider the timeout problem to be a good, technical reason to ignore
doing the comparison. Others may disagree.
Since the response for late DNSBL queries will still be
cached, maybe the next email from the same IP address will
benefit.
Also clear, but then you'd simply get -q=spf first. Or do
the DNS gurus expect something smarter, like copying the TXT
answer to "SPF" in your cache, if the latter got no reply ?
Or implement a separate "SPF-cache layer" between SPF on top
and DNS below it ? IIRC MarkL had this idea, and you still
mention something in this direction in your %{l} etc. caveat.
libspf2 has an "SPF" cache, but I'm not sure what you are referring to
here...
Wait a moment, that makes sense, doesn't it ? And it would
be not exactly straight forward for _different_ policies. I
still don't see this "SHOULD reject if different", but maybe
that's what it's about.
I'm pretty sure the reason it is marked as "SHOULD" is that some MS
software *can't* query for the SPF RR, and therefore *can't* do the
comparison. Only doing the comparison when both records are cached
(or return at the same time) seems reasonable, but I'm sure that's not
the reason.
-wayne