Hector Santos wrote:
Oh I see, you are "redirecting" the original mail to someone
else as if it was "new."
Whatever results in a From: you, Resent-From: me, as mentioned
I don't use / like / have this feature, but it's in (2)822(upd).
You are not using the FORWARDING features of the MUA.
If you mean a MIME Content-Type: message/rfc822 containing your
mail - it's still your old unsigned mail in conflict with your
new "strict signing" policy. In this hypothetical example I'm
just using 2822upd and MIME as designed, I and my MUA have no
idea what DKIM and SSP are, and you plus SSP try to change the
rules "forgetting" that old unsigned mails from you exist.
So far for "voluntary" and "SSP" :-|
even though you are a GOOD GUY, if we allow this loophole,
the bad guy will exploit it.
I see your point, but as this "breaks" various aspects of the
"e-mail architecture" as we know it, I want to watch it when
it hits the IAB (no "1F" from me, Resent-* fans might differ.)
Your MUA should tell ya
My MUA is stupid, I downgraded it from "mozilla 3" to MS OE :-(
If SSP has ambitions what "resending" MUAs are supposed to do
I missed that chapter in the draft.
Something has to give and this one is perfectly acceptable to
me because it helps secured my domains as I intended it to be
secured with a DKIM=STRICT.
The d*mned old From addresses are not more "your domain" when I
find them in an 2006 mbox file, in a sense that's now "my mail".
Bad style if I "resend" mail from you to third parties without
your permission, sure. But if it was an old mail sent to the
folks invited to discuss SMTP HEAD, and one of them asks me to
"resend" it there's no netiquette issue, only the potential SSP
problem. Okay, the person could "whitelist" Resent-From: me to
bypass your SSP strict rule, yet another undocumented effect.
You are forcing SSP on folks NOT volunteering to participate -
not nice, putting it mildly, maybe it should be "experimental".
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html