[ietf-dkim] Re: SSP vs. reputation

[Hector Santos]

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
> 
>