Frank,
The point is that in a new level of DKIM/SSP operations, these things
would be a natural part of the "checking" Frank.
It may not jive with some aspects of the current relaxed nature of
internet email, but that is why we have such a high rate of fraud too,
the unverified relaxed nature of x821/x822 allows for such a high rate
of exploitation.
Also, no one ever said that SSP or even DKIM is for everyone. Some
people simply will not be able to use it, and that includes legacy
Mailing List systems.
So SSP/DKIM is really only going to be useful for those who WANT it and
do not expect to be using their domains in ways they promote breaking
their own policies.
It will not make sense for me to add DKIM=STRICT for santronics.com and
then go to some greeting card service and use my santronics.com address
for their services. It doesn't make sense.
But I will use a DKIM=STRICT with the intention of stopping others from
forging my domains at this legacy ESP systems which is such a BIG
problem today across the board.
The fact is, I will venture very strongly millions of people and
companies with their own domains will begin using STRONG policies if
given the change to do so and will not sweat a tear if it breaks Frank's
way of doing mail or any other ESP mail system or the bad guy forging or
facsimile of such exploitation is high - TODAY.
But again, if a domain sees that as a problem then he doesn't have to
use a SSP strong policy.
Thats been debated over and over and over again. and its no different
than any other security related augmented technology that removes or
affects the current exploitable relaxed way of doing things.
That includes Reputation Services which you have just shown would be an
exploit as well by resending mail A.K.A replaying mail unchanged.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Frank Ellermann wrote:
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html