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

[Eric Allman]

I'm inclined to agree with the consensus.  There may be situations 
where you verify a signature and then pass the message through an 
untrusted environment, in which case you might want to re-sign and 
re-verify the message, but I suspect they will be rare.  Consider 
that this would effectively double the crypto overhead on verifiers, 
and it really looks like making this a SHOULD is an expensive 
solution to what will be for most people a non-problem.  I would say 
that it should be at most a MAY.

eric


--On December 3, 2007 10:00:45 AM -0800 "Murray S. Kucherawy" 
<msk at sendmail.com> 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