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

[Tony Hansen]

ooh, ooh, I know, I know (think Horschack or Screech, depending on your
generation)

The A-R header can be signed using dkim.

Only half a :-) here.

	Tony Hansen
	tony at att.com

Jim Fenton wrote:
> 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