John L wrote:
That's why I've been saying over and over and over that an AR message
is only credible if it arrived via a good path. Tying the header name
to the account is one way to do that BUT NOT THE ONLY WAY, and in
setups more complicated than your end user sitting at the end of a VPN
to HQ, often not even a feasible way.
Show me a UI that has any notion of path and you'll find me sympathetic
to your view. Right now I know of none.
To remedy that situation you have to leave a gaping security hole for
all others.
Sigh. Only if everyone involved are complete idiots. We seem to have
dealt adequately with the problem of forged received headers. Why do
you insist that the same people who can do that can't deal with forged
AR headers?
Humans manage this ok. Computers less so. Why is that? Because in
practice we do see reordered headers and all manner of other "variants"
from the standard. If this is of not meant to be useful in some
automated fashion we don't even need to bother with ABNF.
Because it can do harm if done wrong. Providing a false sense of
security is not helpful.
I guess I hold people in less contempt than you do.
No, I suppose hold erroneous logic in contempt. So tell me this: how do
you imagine a UI being configured with trust parameters?
Eliot
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html