ietf-dkim
[Top] [All Lists]

[ietf-dkim] Resend-cruft (was: ISSUE: Better definition of"DKIM signing complete" required)

2006-11-26 15:29:19
Hector Santos wrote:

The issue is Alice with an "I sign everything" SSP.  Bob resends her
mail, he has no clue what SSP and DKIM are, his MUA also doesn't know
it, and maybe his ISP removed Alice's signature at the MDA (proposed
by Doug as naive anti-replay strategy some months ago).

Would the next hop check Alice's SSP (ignoring Bob's Resend-* header
fields) and reject Bob's mail, if Alice's signature didn't survive
the resending ?  Or if her signature is too old.
 
Do MUAa resend, forward messages with original headers included?   Are
we talking about an MUA or a MTA (router)?

We're talking about the Resend-* header fields as specified in STD 11,
RFC 2822, and RFC 4406 7.3.  I can't believe that I quote Sender-ID :-(
 
Am I missing something here?

No idea, same situation as 30 months ago:  I never got a Resend-* mail,
I never sent one, and as far as I'm concerned this mechanism should be
deprecated in favour of a proper MIME message/rfc822 (or a similar EAI
message/utf8smtp, if that's how EAI eventually solves its MIME issue).

Even clarifying 4409 8.1 (it doesn't discuss Resend-Sender) is a royal
PITA, one SHOULD too much, and it's back at PS instead of going forward
from DS to STD.  IMO we need 4409 at STD more urgent than Resend-cruft.

Who on earth needs more or less than one address in a Resend-From, 
justifying to use a Resend-Sender ?

Frank


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>