On Sep 9, 2006, at 12:23 PM, Hector Santos wrote:
I agree. A policy of any form will be unable to reliably block
phishing messages or identify what messages should be annotated in
isolation of other information. However, DKIM related information
can be applied beyond the MTA. Think outside the MTA box. : )
Doug, its hard to follow you, so if I am wrong, I apologize but I
think I think you need to stop saying DKIM-BASE or SSP can help
with anti-phishing. It can not and AFAIK no one on the either side
of the SSP camp believes that is the case.
There should be serious doubts regarding the entirety of _any_
domain's email as being trustworthy. There should be serious doubts
about blocking messages based upon policy as a means to prevent
spoofing. However...
Annotation selectivity can be achieved by recipients retaining
"specific" email-addresses found within the address-book, and by a
list of trusted-domains and "specific" local-part addresses. A
trusted-domain list that combines with "specific" local-part
addresses can be used safely in conjunction with an MTA or MUA
annotation scheme. Few domains will desire the entirety of their
email annotated as trustworthy, even when specific messages are
trustworthy. Solving this concern is where policy should play a
critical role in facilitating selective annotations. Annotations are
effective at improving open rates of valid messages and preventing
recipients from mistaking the source of illegitimate messages. This
is _not_ theory.
I believe you are promoting a MUA solution and you doing so from an
application standpoint when in fact the DKIM-BASE and SSP
discussions are pretty much focused on the MTA level (or server side).
There is no reason to focus upon only one aspect of how DKIM offers
protection. The use of trusted-domain list annotations can be
applied at either the MUA or the MTA. Annotations at the user agent
can be more uniform and offer a consistent user experience regardless
which MTA provided the message. When done at the user agent the
address-book is also readily available.
But then again, maybe this is part of the problem:
- MTA DKIM promoters (SMTP vendors, Admins)
- MUA DKIM promoters (MUA authors, plug-ins, DMA)
These are TWO conflictive solutions. Keep in mind we have both MTA
and MUA products so my technical engineering is purely based on
whats the most effective and feasible solution. Centralizing the
mail operation will no doubt provide the most benefits.
The best solution to combat phishing encompasses both the MTA and the
user message application. These are not in conflict unless someone
goes overboard on message blocking and disrupts email-delivery. The
best place for applying the DKIM signature appears to be at the MTA;
the best place to apply DKIM related annotation that associates a
retained and validated email-address is at the MUA. When annotations
are based upon the address-book, no external services are required
which you should find pleasing.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
