Radu Hociung wrote:
[I'm reading p* / p.* / o.* where you say o*]
None of the o* modifiers have any effect at all on SPF
results.
Strange, but I understood your later argument about sharing the
available TXT space. You're not trying to reinvent something
like SRV or NAPTR using SPF-TXT records, or are you ?
DK is not really a good example
Okay, let's drop it, we can also bury it formally with op=nodk,
that variant could make sense, in theory.
this example, let's say that the domain owner publishes an
odk=yes extension.
Anything with "yes" or "no" is a candidate for op= and all its
restrictions, simply because "odk=yes oyx=no" needs 14 char.s,
where "op=dk.noyx" needs only 10 char.s.
See also chapter 2 ("motivation").in the op-drafts -04 or -05.
perhaps only it's existence.
Tricky, it can also exist without op=dk, and that's again the
general problem of _all_ modifiers in v=spf1 introduced after
v=spf1. Same problem for spf2.0/pra and all its variations.
It's okay for a yx (not DK) where op=yx is required right from
the start. If op=yx is _required_ the domain owner must add
it to his sender policy, or he can't use yx (whatever that is).
You could limit this requirement to "if and only if you have a
v=spf1 sender policy it MUST announce op=yx". With this trick
yx could be also used independent of v=spf1.
But if you say "yx MAY be announced as op=yx" it doesn't work.
Any MAY is implicitly "maybe not", and if the absence of op=yx
means nothing, then its presence is a waste of characters.
So op=dk doesn't fly unless the DK-spec adds a corresponding
MUST and "we" fire the still unofficial op-I-D (= SPF Council
wants it, anything else for a proper I-D would take me a few
minutes, I'd know how to fix its obsolete RfC 2234 reference.)
FAIL on their check of the MAIL-FROM. The SPF checker passes
the spf_also_found["dk"]="yes" to the MTA. In order to
decide whether to reject after the SPF fail, or to give it
one more chance using DK, it may use any other information it
has available.
That's "modifying SPF results" in my terminology. So you'd use
op=dk in a way like op=trusted, to bypass SPF in certain cases.
That makes sense - limited, because I wouldn't want to look
"into" the DATA, but reject with 5xx right after the MAIL FROM.
How the various spam fighting methods are combined is the MTA
vendor's problem.
Sure. Some like Hector won't look into the DATA, it's against
their religion (shared by me in this case), others can delay
their decision after they've seen the final "dot" of SMTP DATA.
Let's assume that SPF3 operates on the message headers.
Forgetting my religion for the moment... ;-)
Let's also assume that SPF3 is designed to be a 1-query
protocol
Yes, the strange B64 or whatever it was proposed by David here.
they have to share the 400-bytes available in the TXT space
between the two SPF records.
Horrible. They better stay as far as possible away from TXT
or the future SPF RR, but okay, it's only an assumption.
the domain owner will double the number of queries received
from the installed base of SPF checkers.
Not really. Your assumption is actually very similar to the
situation today for v=spf1 and spf2.0/pra, e.g. ebay.com. You
already "have" both policies after one q=spf query, or at most
two queries if you need a secod q=txt. For "have" read: both
records are in your DNS cache, in the worst case.
There's no need to add an op=spf2 (oops, I can't use a dot) to
the v=spf1 record, or an op=spf1 to the spf2.0/pra record, you
get them both with a single q=spf (or a second q=txt) query.
1. Publish the 300 byte SPF1 record at the top domain, and
add ospf3=_s3
2. Publish the 300 byte SPF3 record at _s3.domain.com
That's a new idea, now you introduce a prefix for v=spf3 RRs.
It's also out of scope for an op=spf3, unless the v=spf3 spec.
always uses the same prefix _s3 for its records.
If you want an arbitrary prefix you could use p3=_s3.%{d} - but
an arbitrary prefix based on hints in a v=spf1 policy, that's a
major headache. There are also the known wildcard problems.
I am assuming that an MTA vendor would use an SPF3
implementation that are also supports SPF1
At this point I'm not more sure how many assumptions you have -
let's say "one too much". If good old v=spf1 can somehow help
to bootstrap v=spf3 it's fine, but I don't see it yet.
IMHO v=spf3 is better off if it does its own thing, whatever it
is, and falls back to v=spf1 only if there is no v=spf3 policy.
Like spf2.0/mfrom could fall back to v=spf1. It certainly does
not need any modifier for this purpose.
if Sender ID had been successful and if it used the top level
TXT record
It's far too early to judge the success of Sender-ID, or to say
that spf2.0/mfrom etc. are a dead end. At the moment v=spf1 is
the only spec. that might fly, but v=spf1 is at least 9 months
older than any spf2.0 policy.
the o* function would have to be built into Sender ID as well
You're talking about spf2.0, and there's no such thing as an
"o* function", neither in v=spf1 nor spf2.0. It's apparently
remotely related to op=, but I don't know any implementation
of this idea, the author would press me to send it to the IETF.
Which I can't, as stated in the op= spec. only the SPF Council
can release it. Unless we'd declare the Council to be defunct.
<http://purl.net/xyzzy/home/test/> + draft-hallambaker etc.
Interesting. I see also why it did not work.
Actually you don't see it, I've fixed the offending non-ASCII
manually in my copy. No idea why Phil never did this and sent
the fixed text again to the IETF. Okay, the silence of ASRG
wasn't very encouraging. And I'm also somewhat lost with this
text, all I remember is "so you can do bitfields with XML". ;-)
if "op" has been in use already
AFAIK only here as a concept for yes / no aggregations, and as
a tombstone for some ideas (pra, trusted, helo, nohelo, etc.),
ready to be resurrected when necessary.
the syntax makes it clear what is a mechanism and what is a
method.
s/method/modifier/ Yes, the syntax is clear, either "=" or
no "=" after the name, the latter must be a mechanism, it may
use a ":". But for stupid users I'd avoid any a= or mx= like
hell, there are enough "free" characters / names.
I would not use the "." as it provides no value other than a
little bit of readability.
Just an idea found in Phil's draft, how you could get your own
"modifier namespace". IMHO better than trying to squat all
names starting with a given charater, or even all o* minus op.
Using dots has the advantage that even a completely broken SPF
should know how to split something at dots. The original op=
idea was "comma separated", I've intentionally replaced this by
"dot separated" later.
the dot will take space each time a new extension is needed.
True. OTOH claiming that all x* are reserved for "whatever" is
very ambiguous, I'd probably not support it. It's not the way
to create a proper namespace. x-* is much more familiar, and
x.* is the way proposed by Phil for this purpose.
the shortest possible extension would be 5 characters, (e.g.
"<SP>or=1")
If this "1" is again a case of "yes" you only need the "r" in
an op=r or op=r.foo.nobar. If it's something else, e.g. if an
or=2 or or=0 make sense, it's of course out of scope for op=,
Unless you could twist it into r0, r1, r2. op=r0 etc. could
work. But I can't recommend op= in this case, it's too ugly.
an SPF1 implementation should pass any other TXT records
found at the top level to the MTA.
It's in the DNS cache after a q=txt, isn't that good enough ?
Transfering that information in memory is faster than if
SPF3 needs to do a DNS query, even if the query goes to a
cache on the local network
Okay, if you want to implement the future v=spf3 in this way
just do it. My ideas of mixing CSV with v=spf1 were also not
exactly straight forward... ;-)
This behaviour does not need to be specified in the SPF
specification,
Full ACK, seconded, consensus, so ordered. Maybe you should
really look into the op= text, sometimes I almost think that
you try to reinvent it. Bye, Frank