spf-discuss
[Top] [All Lists]

RE: I hate to interrupt all this for something practical, but.... we need a concise, easy-to-follow set of SPF instructions in file format - anyone able to help?

2004-10-31 21:03:21
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Meng 
Weng Wong
Sent: Wednesday, October 27, 2004 6:18 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] I hate to interrupt all this for something
practical, but.... we need a concise, easy-to-follow set of SPF
instructions in file format - anyone able to help?


On Wed, Oct 27, 2004 at 04:54:32PM -0400, guy wrote:
|
| The "a:SMTP.ISP.net" tells the world to trust SMTP.ISP.net (since the
| default is "+").  But this is not correct.  Everyone that has
access to the
| SMTP server can forge your email address.

While this may be true today, it is such a vast improvement
over the current state of things that most people are
comfortable doing it anyway.

Besides, many ISPs are moving toward a stricter set of rules
with SMTP AUTH: i fully expect that two years from now,
cross-customer forgery will not be allowed by the majority
of responsible, progressive ISPs.

but moving the customer base in that direction is unusually
challenging because we're going back and changing the
general culture of expectations that have been built up
around email, and that's harder than start out with a new
set of expectations altogether.

I suspect two years is optimistic unless those of us working on sender
authentication make a point of making this a major issue.  Moving to SMTP
AUTH for those already doing it is one set of headaches.  Moving to restrict
mail identities is a whole additional set of problems.

How are MTA service providers supposed to validate the authority of their
customers to use mail identities foreign to their service?  I don't believe
that there is a good proposal on the table for this.  Does anyone know of
one?

Although not directly a part of SPF (I agree 100% with the previous thread
that MSA authorization issues are outside the scope of SPF), getting these
kind of restrictions deployed is a key piece of the infrastructure that
needs to be in place for SPF to be fully useful in a shared MTA environment.

Scott Kitterman


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