The A-R header field is intended to be used within the recipient's
sphere of trust. If someone is concerned that the sphere may be leaky,
I say that they should fix the leak.
Part of the beauty of A-R is its simplicity. I have found it easy to
set up filters in my MUA to color-code messages that are authenticated,
and I like that. A secret that is shared between the adders of A-R
header fields and all the clients isn't very secret at all, so someone
will want a digital signature, and then you need to think about key
management and so forth. This is a very slippery slope.
-Jim
Murray S. Kucherawy wrote:
This came up both at the last IETF and at this one, so I thought it
worth opening up here once before I submit the draft to the area
director.
Should the normative text in the draft specify that this header SHOULD
be signed?
The point comes from someone who operates in an environment in which
he doesn't necessarily want to trust that the border MTAs are properly
removing forged A-R headers. This would mean there needs to be a
shared or distributed secret between the border MTAs where the header
is added and the clients where the header will be used. It also means
I'd either have to reference a header signing/verifying mechanism or
define one.
Some of the risk of this is mitigated by the AUTHRES ESMTP extension
draft, but the time to implement there is going to be longer than the
support for this header.
The hallway track at the last IETF and since was that the current
draft's Section 8.1 (especially the last paragraph) provide sufficient
discussion of this issue. I might change "posted" to "posted or shared".
What are the list's opinions?
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html