spf-discuss
[Top] [All Lists]

RE: The pretty name

2004-09-30 14:05:34
From: Hector Santos Sent: September 30, 2004 2:34 PM

|In any case, think "integrity" authentication.  The problem
|with "researchers" is that they don't want to use a use a
|callback mechanism to validate authenticate the mail. 
|Instead, they want to use a 3rd party. But in my view, the
|ideal solution is a callback concept that authenticates the
|transaction against the original domain submission site.

I have been following the recent messages you have sent on
this topic.

One big problem I have with SPF and the Sender-ID Framework
is that mailfrom and pra checking as presently conceived
break mail forwarding. 

Unfortunately, despite all of the effort neither the sender
rewriting scheme, nor a submitter scheme ultimately solves
the problem, meaning we are left with last hop
authentication. 

This is a problem. 

For what it is worth, to move SPF ahead, a couple of
comments:

* Having a record which allows receivers to plug into with
a variety of checks has merit.

* But today, I suggest the underlying need is to focus
on developing and perfecting a method of mail channel
authentication which does not break mail forwarding. 

* In the interim, solidifying what exists, which is mail
from checking using SPF records as an experimental
proposal, makes sense. Especially, if these records can be
used to support a method of mail channel authentication
which is low over head and offers end to end validation
without relying on SRS or Submitter.

* As to reliable message authentication, I agree PRA is not
a good approach. 

I appreciate the financial institutions want a solution and
they want it now. I also agree pushing something which is
conceptually flawed and requires breaking existing rules is
not the proper way forward. 

One may get buy-in from MS, along with the telephone
companies who have MS administer their consumer portals,
but I can't foresee any other large mail box provider
wanting to further damage email.

Apart from this, until MS clarifies its position viz the
scope of its patent claims (specifically confirming the
good faith representations made to MARID by its
representative prior to September 11, 2004) and modifies
its patent license so that it meets the Open Standard
Alliance model, then ... 

Of course, maybe the financial institutions don't care if
one corporation controls the keys to email and don't mind
paying significant fees for email delivery. I don't know.

Besides Yahoo! is offering a patent license for DomainKeys
which to my understanding is compatible with open software
licensing requirements.

I am not saying DomainKeys is the cat's meow. But Sendmail
and Yahoo! are working on testing and tweaking DomainKeys.
In the interim, there are other proposals and I believe the
IETF will charter a new working group called MASS to
specifically deal with message authentication using light
weight cryptographic techniques.

Bottom line? 

We need to really deal with the problem of breaking mail
forwarding, because at day's end, unfortunately it seems
neither SRS nor Submitter will fully solve the problem,
instead from the comments made by others will simply create
more overhead without adding significant benefit.

I suggest using EHELO/HELO checking is one part of the
solution. In my view this is the next "plug-in" one wants
to focus on. 

How to strengthen this is the question. Some folks want to
use 3rd party accreditation to check the domain. Others
don't like this because it introduces the "human" factor.
Hence, Hector's automated call back concept, which
"authenticates the transaction against the original domain
submission site." 

Either way, unless one focuses on methods which don't break
mail forwarding for mail channel authentication and are low
overhead, I suggest SPF will remain experimental.

John

John Glube
Toronto, Canada

For The Record, Will Microsoft Own Email?
http://www.learnsteps4profit.com/wme.html

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.767 / Virus Database: 514 - Release Date: 21/09/2004
 


<Prev in Thread] Current Thread [Next in Thread>