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" <[EMAIL PROTECTED]>
To: "Hector Santos" <[EMAIL PROTECTED]>
Cc: <ietf-dkim@mipassoc.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
