Doug,
Not everyone will be able to produce a cross the board solution. Only the
"Microsofts" and the likes will have the capacity to address a consistent
solution across their applications. Although we are a small company with
one of the oldest and most complete total mail design frameworks in the
market, even I realize we can't do that. We can make it work for us in an
integrated fashion, but we can't dictate our TOTAL solution will be the
right TOTAL solution for everyone else. Its unrealistic and it would be
unrealistic for others here who might feel their total solution is right for
us as well.
But what is common with all of us, is the MTA or more specifically x822/x821
internet mail operations. Reading mail, while there is are standards on the
OFFLINE side with popular methods (POP3, IMAP), there are a multiple MAIL
ACCESS methods which you can't control, online, proprietary, API based,
gateways, etc.
For example, using us, we have the following mail access methods all
controlled using a single source backend system:
- Console mode (Dialup, Telnet)
- Browser (WebMail)
- Online GUI Navigator
- XML/SOAP API
- POP3 Email
- News
- Sysop Editor (GUI)
- Reports Manager
And a bunch of 3rd party mail readers. It would be a mistaken to believe
that x822 is the common format between all of them (for the internet
clients, yes) but not necessary the rest.
The buck really stops at the server side if we really want this to work. A
centralize source. Your nor my MUA needs should not stop the progress with
implementing DKIM-BASE/SSP solutions at the MTA.
In my opinion, if you have a MUA application in mind, you should concentrate
on how it will communicate with the server side. I would first concentrate
on reading any results that the MTA produces. If you intend to sign at the
MUA, then you need to make sure the MSA understands what you are doing too
because if you don't, you can find it overwritten, destroyed or even
removed.
Thanks my opinion.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Cc: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Saturday, September 09, 2006 6:19 PM
Subject: Re: [ietf-dkim] SSP = FAILURE DETECTION
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