Murray S. Kucherawy wrote:
Tony Hansen wrote:
[...]
Works for me.
good
The other value definitions are different, but need to recognize that
not all authentication methods require policies. I'd suggest this
rewording:
softfail
The authentication method requires a policy to be accessed, but
the policy does not require authentication of all messages from
that domain, and the message failed the authentication tests
How about:
The authentication method has either an explicit (i.e. published
by the sending domain) or implicit policy, but the policy being
used doesn't require successful authentication of all messages
from that domain, and the message failed the authentication tests.
works for me :-)
neutral
The authentication method requires a policy to be accessed, but
the sending domain does not publish any sender authentication
policy.
What if the method doesn't require a policy be accessed?
Actually in light of that question, maybe we don't need "neutral" at
all. For methods that have a policy, the verification attempt will
produce one of the other results. For those that don't have some
queryable policy, "neutral" never happens.
Well, I've seen people who want to be able to say "X doesn't say
anything positive or negative for this message". That's the purpose of
neutral.
A related question is what value should be put in the headerspec for
failure situations? The identity has not been verified, so there's no
value to be put into the headerspec.
temperror
[...]
Works for me.
permerror
[...]
Works for me.
Tony Hansen
tony(_at_)att(_dot_)com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html