Radu Hociung wrote:
[DK modifier]
Actually it would mean "My DK information is at ...",
or "My PSG information is at ...".
Okay, then that's no simple opt-in option, maybe it's a proper
modifier like redirect= or exp=, e.g. dk=. And what's the
exact meaning after I found whatever-it-is at the given domain
in conjunction with SPF ?
How does this dk= modifier "modify" SPF results, if at all ?
The call to the spf_check function would return the SPF
result as per SPF rules, and also any "other" information it
may find:
Among these results could be PASS, SOFTFAIL, and FAIL, what's
the role of DK in these cases ? It's clearer for UNKNOWN, then
the dk= simply means "maybe use DK or forget it".
For instance, if an SPF record specifies
spf_also_found["reputation"]=blah.com, the receiving MTA
should probably ignore it, as it's the recipient's choice of
which reputation services to check, not the sender's.
Phil and Meng intended to publish an I-D in this direction,
draft-hallambaker-accreditation-00.txt, but that never worked,
it didn't pass the I-D nitpicking. For an unofficial copy see
<http://purl.net/xyzzy/home/test/> + draft-hallambaker etc.
I would prefer that all o* modifier namespace be set aside
op= is older, pick another character. In Phil's scheme it's
accredit= plus accredit.substuff= IIRC. You could in theory
reserve some= plus all some.thing= for arbitrary values of
"some" (like "p") and arbitrary sub-modifiers "thing" (as in
"p.whatever=").
It's not exactly necessary to invent a general rule for this
concept now, you could simply say that you need "p" (or "o"),
and all possible modifier names p.whatever= (or o.whatever=).
For obvious reasons you'd better stay away from exp, redirect,
accredit, op, match_subdomains, default, etc., and you'd also
avoid the names of mechanisms like "a". I've forgotten some
of the proposed names for positional modifiers, one was "not=".
From a system perspective, all these details matter
Fine, but a say op=pgp is still useless, and a modifier like
pgp=domain.of.keyserver is also a PITA, if it's irrelevant for
the purposes of SPF. We also don't need a homepage= or ssn=,
we have the hard limit of UDP for q=spf and q=txt DNS replies.
some of the extensions don't make sense, and the record
publisher should know not to waste TXT record bytes by
including them.
Yes, and an op=dk or a dk=domain or a p.dk=whatever should be
analyzed very carefully. The obvious problem as stated in the
op-paper, the absence of a modifier (excl. exp= and redirect=)
means nothing. The presence of a modifier can be also ignored,
old implementations don't know it, and new implementations are
still free to ignore it.
So it should be very useful in the remaining cases, and so far
I don't see what a p.dk=whatever does for a receiver. If the
receiver wishes to support DK it's still forced to test DK in
the way offered by DK, because the absence of a p.dk= has no
meaning.
A useful modifier could be a hypothetical op=nodk, if it stands
for "don't waste your time with DK queries, I don't use it".
Bye, Frank