On Dec 8, 2006, at 4:22 PM, Hector Santos wrote:
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!
What element is ratified? What benefit is established when
recipients may not understand what is signed, and who actually sent
the message? Do you care this blocking scheme fails to ensure
recipient protections? This should not be just a check mark on a
feature list.
Is receiving non-ASCII email-addresses protected by this effort?
Unrelated to the basic QUESTION of DOMAIN protection via SSP.
Rather than just establishing restrictions, policy can also establish
associations and permit a "recognized" email-address 'X' to be used
in conjunction with signing-domain 'Y' to generate an annotated
message. Annotation can be a gold-star or placement into a folder or
specialized mailbox handled by _either_ the MDA or the MUA.
Recognition criteria can be established by the account's address-book
or a DAC list.
Are look-alike and cousin-domains prevented?
Doesn't APPLY!
What is the goal then?
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.
When a message is signed by a mailing-list, this establishes their
signatures integrity. Annotation can make it clear the header used,
and that the originator is known (and trusted). When annotation
added by the MUA or MDA _is_ the protective mechanism, use of a
mailing-list is never a problem and nothing is broken. A mailing-
list only becomes a problem when subjected to a highly flawed
blocking scheme unable to provide adequate protection anyway.
Should they setup different domain names, or use a sub-domain?
Maybe, if that is what they want.
This then increases recipient's confusion about what is being checked
with a blocking scheme.
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.
This is about protecting recipients from being spoofed. This is not
about making sure a message jumps through a set of hoops.
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.
It is hard to understand your goals. What constitutes "pretty good"
when recipients can still be spoofed?
Simple schemes remain where your customers continue to be spoofed.
Not with a DKIM/SSP framework. Phished? sure. not SPOOFED.
Huh?
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!
Bad actors would only need to provide the appearance of being from
the trusted domain. This is easily done with the proper HTML format
and images. It is also common to see display-names that make it
appear the email-address is being displayed, when it is not. The
visual tricks are vast.
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.
Not really. Annotation offers a clear indication about which dogs
are known safe. Your scheme lets in any dog and offers no clue which
are safe. Don't expect Johnny to look at the dog's tattoo under
their lip.
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.
This approach can be applied at _both_ the MDA and MUA. Message
annotation has a realistic chance of offering real protection. A
blocking scheme does not!
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.
DNS transactions required to discover whether policy is within any
domain level for any message, signed or not, is not trivial
overhead. In addition, there will be support calls dealing with
messages lost by various services. There will be issues created when
the use of EAI extensions is prevented. There is information leaked
to bad actors regarding the level of acceptance achieved at the MTA.
There are still problems related to white-listing and the properly
handling of DSNs not improved by a blocking strategy. Comparisons
between blocking and annotation are rather stark in terms of costs
and benefits.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
