wayne wrote:
I may even add a change history from
draft-mengwong-spf-0[01]
This could be a good idea, but don't say something like this:
x "Include_subdomains=yes zone cut" added,
x+1 "Include_subdomais=yes" removed
x+4 "zone cut" removed
a change history from those and the previous dozen drafts.
It's not for "me". I can sing this stuff for the past year.
It's for the IESG, and only if you really want it for some
of the more dubious points in Andy's "spf-considerations".
I wouldn't recommend holding your breath waiting for this
though. :-/
I held my breath when I clicked on https://datatracker etc.
by "Bruce" do you mean "Bruce Lilly"
Yes, this Bruce. He's a killer with many formal aspects of
the standards process. And if he says that something in any
syntax is odd he was almost always right. He got me to read
a lot of RfCs.
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 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 ?
"whatever the DNS gurus say is fine, as long as I can go
on using TXT RRs."
Yes, I know that that's your position. Unlike you I hope that
the SPF RR could fly in some years. And be useful in the case
of "overloaded TXT" problems.
many anti-spam programs send many DNS lookup queries off
all at once, and wait for various responses to come back.
For example, SpamAssassin will do a bunch of DNSBL queries,
ACK, but not exactly the same as our -q=spf plus -q=txt
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.
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.
Bye, Frank