Subject: RE: So here it is one year later...

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 31 Jan 2005 08:50:38 -0800

The main point of the Web page seems to be that Domain Keys/IIM does the
whole thing much better.

Like we did not know that already, the point of SPF/Sender-Id is that it
will be a while yet before we have a merged spec for Domain-Keys/IIM we are
still in trial stages. It makes a lot of sense to go forward with the low
hanging fruit authentication that SPF provides.

SPF now includes the HELO check so CSV is utterly redundant, it is an
unhelpful contribution to the debate at this point. The promoters of CSV
have not been working to win friends and influence people. 'nuff said.

For DK to work we need a policy layer, that will almost certainly be linked
to the deployed SPF/Sender-ID standard.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David Woodhouse
> Sent: Monday, January 31, 2005 9:35 AM
> To: [email-masked]
> Cc: Douglas Otis; Frank Ellermann; [email-masked]
> Subject: Re: So here it is one year later...
> 
> 
> 
> On Mon, 2005-01-31 at 08:40 +0100, [email-masked] wrote:
> > The forwarding problem is known and information is on spf.pobox.com 
> > (which still is the primary source for information about spf). It's 
> > not like it is 'the big secret of spf' that there is a forwarding 
> > issue. I suppose people read this site before publishing, 
> so they must 
> > know about the forwarding problem. However, people still 
> publish. I'm 
> > not going to guess at the motivations of these people, i'm not a 
> > pyschologist. Fact is that despite the forwarding issue, people do 
> > publish.
> 
> The forwarding problem isn't exactly shouted from the 
> rooftops on the SPF site, and people rarely actually think 
> things through for themselves, unfortunately. If you point 
> those _same_ people at something like 
> http://david.woodhou.se/why-not-spf.html they > often seem to 
> change their mind again and stop publishing records, in my experience.
> 
> -- 
> dwmw2
>

---

From: wayne <[email-masked]>
Date: Mon, 31 Jan 2005 12:38:03 -0600

In <[email-masked]> "Hallam-Baker, Phillip" <[email-masked]> writes:

> Like we did not know that already, [...]

Actually, that is something I don't know.

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.)

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.)

CSV breaks very little, but no one really seems to care.  Despite
having *FAR* more publicity in the 9(?) months since it was first
announced, far fewer people are using its HELO checking than were
using SPF's HELO checking in the first 6 months since it was
announced.  Of course, the real growth of SPF didn't happen until
after 6 months since it took that long to get a slushy spec done.

I really like the ideas behind the crypto systems, but they have a
bunch of technical problems with them that haven't been figured out
yet.  Considering that the technical problems with both crypto systems
and IP systems have been pretty obvious since the spring of 2003, I'm
not sure that good solutions will be found for either type of system.
It was based on my analysis of the various technical problems will all
systems that I decided that IP based solutions would have the most
potential and therefore I started helping out with SPF.  18 months
later, it still looks like I made the right choice.

So, please, before you go claiming that DK/IIM is "better", provide
some data to back up that claim.

-wayne

---

From: Jim Fenton <[email-masked]>
Date: Mon, 31 Jan 2005 12:18:53 -0800

>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.

>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

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 31 Jan 2005 16:37:18 -0500

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