Scott Kitterman wrote:
The interesting thing, I think, about DKIM is that it should
work in circumstances that SPF may not (forwarding comes to
mind)
The other case is non-SMTP message/rf822 transport. AFAIK
that's a complete enumeration of all cases where DKIM could
work and SPF "won't" (for the "forwarding issue" that's of
course subject to some semantical interpretations, as far
as I'm concerned it's 1123 5.3.6(a) that's "FUBAR by design",
not SPF... ;-)
an option in an SPF record that promised a DKIM signature
for valid messages might be a good enough reason to go to
DATA on an SPF fail.
Wait a moment, you can't weaken PASS or FAIL with a modifier.
Omigod, that's apparently a fudamental issue, it's always true,
new modifiers can _never_ modify PASS to less-than-PASS or FAIL
to less-than-FAIL.
"As soon as you really need this you would also need a new
SPF-version - same problem as 'new mechanism'" - is this really
correct ? If yes I'd add it to the op-draft. Actually _that_
could be also something for the RfC (AUTH48 or any new attempt
to publish SPF as PS).
Back to your idea: You are however free to modify NEUTRAL (and
with some Caveats SOFTFAIL) towards PASS or FAIL or "please
consider DKIM or PRA or S/MIME" etc. And you're free to split
PASS into some idea of HARDPASS vs. SOFTPASS with a modifier,
(like op=auth).
Bye, Frank
-------
Sender Policy Framework: http://spf.pobox.com/
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