[ietf-dkim] Blocking/Restritive-Policy vs Annotation/Associative-Policy

[Hector Santos]

Douglas Otis wrote:
> 
> On Dec 8, 2006, at 3:05 PM, Hector Santos wrote:
> 
>> Nope, once again, MUA are not required. I can do the above easily at 
>> the MDA.
> 
> Is viewing the display name protected by this effort?

N/A - MUA are not part of the process for this protocol ratification!

> Is receiving non-ASCII email-addresses protected by this effort?

Unrelated to the basic QUESTION of DOMAIN protection via SSP.

> Are look-alike and cousin-domains prevented?

Doesn't APPLY!

> What happens when a domain wishes to allow users use of a mailing-list?  

Then the domain asking for trouble because MAILING-LIST are know to 
break the integrity of the mail.

> Should they setup different domain names, or use a sub-domain?  

Maybe, if that is what they want.

 > How will increased domain names of the same entity better
 > allow a recipient to detect a spoof?

Doesn't apply. We are talking about 1 domain.  One transaction at a time.

> You can not offer "pretty good protection" at the MTA based upon policy 
> blocking.  

I sure can and if I didn't think so, I wouldn't be touching or even 
looking at DKIM/SSP.

> Simple schemes remain where your customers continue to be 
> spoofed.  

Not with a DKIM/SSP framework.  Phished? sure. not SPOOFED.  Plus
if a bad guy wanted to BREAK DKIM/SSP, all he has to do is AVOID using 
it and stay away from DKIM/SSP protected domains!

 > Annotation at the MUA can prevent these schemes,

This is like saying,

    "Mom, can I let the rabid dog in the house? He looks so cute!"

Mom is not going to let johnny get in trouble if she can help it. But 
just in case, she might give Johnny a rabbies shot.

> works with 
> non-ASCII email-addresses, prevents look-alike and cousin domains 
> exploits, and permits the use of mailing-lists without additional domain 
> names.

Out of scope!  You're stuck with this because you are looking for a MUA 
solution - unrealistic.

> Policy based blocking is not a desirable feature when it will likely 
> make the situation worse at substantial costs to resources.

But that premise is highly false. So what bother to continue?  Its 
friday! Thats why!

---
HLS