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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html