Re: So here it is one year later...

In order words, SPF and most so with CSV and DK/IIM presume across the board
compliance.

Thanks for confirming the obvious. The question is, which one is more
plausible in addressing the real industry concerns with minimum
intrafracture changes?

Personally, there are two form of mail integrity concepts:

One that remain outside of transports, and one that independently controlled
by SMTP with the possibility linkage of the two.

The point being is that SMTP (the transport system) should not depend on
SPF, CSV or DK/IIM clients.   You either do it across the board or you don't
because ultimately you have to deal with the questions of compatibility and
legacy issues.

In layman terms:

What if my SMTP mail server detects a non-DK/IIM ready message?

You need to answer that question otherwise what is the use of using DK/IIM
if a system still needs to work and be ready for non-DK/IIM messages?

Now of course, it might work well in an exclusive CISCO corporate/enterprise
settings, a big pat on the back, an exciting marketing and promotion largely
based on "hope"  I can imagine for your big customer base.  But this is not
a standard across the board.

In short, we need to get back to basic and address the real issue - SMTP
with Transport Negotiated security and to satisfy CANSPAM - Topic
identification.

Regardless of the EPV (Endpoint Validation) method used,  SMTP "3821" must
be remodeled as an advanced secured system with some level of backward
compatibility.    This will allow for the fastest endorsement and adoption.

As a side comment,  the failure of MARID was 100% due to the philosophical
conflicts between developers and administrators. I had seen it before when
the last original big public email network "FIDONET" faced the then new
internet migration technical design issues.  It is now all deja-vu with the
security issues of the internet.  Everyone has half-baked ideas. Everyone is
protecting their turfs especially with the old school people around here,
and not many, except for myself and a few others, are not pointing to the
obvious - Where is the IETF-SMTP input in all this?  Where is author of
2821?

In all honesty,  I could only hope that a SMTP, POP, IMAP vendor/developer's
working group get together to work out the a Generic/General specifications
for the new transport system - independent of any specific SPF, CSV, DK/IIM
proposals.   This will allow the new system to STILL work when new inventors
have new EVP methods.  We are doing it backwards based on some half washed
"semi-proprietary" ideas and we wonder there isn't censensus.

I'm out of here.....

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office


----- Original Message -----
From: "Jim Fenton" <fenton(_at_)cisco(_dot_)com>
To: "IETF MARID WG" <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Monday, January 31, 2005 3:18 PM
Subject: Re: So here it is one year later...


> wayne wrote:
>
> > Despite asking several times on the MASS mailing list, I have yet to
> > see any data on the false positive rates for DK, IIM, William's DK-IIM
> > merged system, CSV, or SES.  So far, all I've seen is people claiming
> > that their systems work better than SPF, with no data to back it up.
> > (Often, there is data to back up the claim that SPF has false
> > positives, but we *do* know that.)
> We are starting to get some data on false positives (signature breakage)
> for DK and IIM, but since the number of verifying domains at this point
> is very small, it would raise more questions than it would answer if we
> were to publish it.  Success rates depend a lot on what the originating
> and terminating domains' MTAs do with their messages, so having data
> from a couple of domains is far from representative.  It also depends on
> things like whether the signer, in the case of DK, uses the optional h=
> parameter to sign specific headers.
>
> > SPF breaks forwarding unless the sender uses SES, the forwarder uses
> > SRS, or the receiver uses a whitelist.
> >
> > DK breaks mailing lists, and from what I can tell from reading MASS,
> > the DK folks don't see that as a problem.  The other crypto systems at
> > least *try* to not break mailing lists, but it not at all clear how
> > well they do in practice.  (SES looks like it will do the best, but it
> > requires some sort of call-back to work.)
> The real answer is to have mailing lists re-sign their messages.  While
> IIM does try not to break mailing lists, and does in some cases, it's
> imperfect and intended primarily as a expedient until they do.
>
> If you'd like to discuss this more, let's move to the ietf-mailsig list.
>
> -Jim