[mail-vet-discuss] SHOULD the header be signed?

[Jim Fenton]

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