|
RE: Email Forwarder's Protocol ( EFP )
2005-02-23 09:04:28
At 12:12 AM 2/23/2005 -0500, Stuart Gathman wrote:
On Tue, 22 Feb 2005, David MacQuigg wrote:
> Bouncing the way they always have is no good, because return paths can be
> forged, Received-SPF headers can be forged, anything can be forged except
Return path is not forged when sender publishes (a non-trivial) SPF
record and receiver checks it. That is the point of SPF.
If senders don't publish a useful SPF and get bounces from forged
return paths, that should motivate them to publish.
OK, I'm motivated. :>) The problem is the bounces coming from folks who
are not participating in SPF. My SPF record doesn't stop them from sending
me a bounce. A universally-understood authentication system would end most
of that "backscatter".
> the IP address of the immediately previous forwarder. By bouncing only to
> that address, we don't need to depend on the headers.
You're reinventing the SRS wheel.
You're also reinventing the SPF wheel. You do you know precisely which
IP adresses actually belong to the previous forwarder? Call them on
the phone? What about when the list changes?
I'm hoping to avoid re-inventing anything. It seems like we have all the
technology and algorithms we need to solve this technically simple
problem. It should have been solved a year ago. The problem is we need a
way to convey the results of IP-authentication between systems that may not
use the same protocol. We can't be calling on the phone to find out what
it means when they say "verified".
Should we just dig in and insist that everyone use Received-SPF
headers? Are you happy with current progress? What can we do to get the
ball rolling again? Where should we put our efforts? I have written an
article for Wikipedia. I started another for IEEE. My initial efforts
were at raising public awareness. Now I see a roadblock with this fight
between different protocols. Maybe I should drop this effort at finding a
common standard and focus on the articles instead. The discussion in this
group has been a little discouraging.
> stalled. When Microsoft comes out with SenderID, no doubt there will be
> efforts to stall it. Either method will work, but neither will work if
SenderID attempts to authenticate header From and competes with
DomainKeys. Different animals. We need those other layers also,
but that is not what SPF is addressing. SPF is the consensus of 3 or 4
preceding MAIL FROM validation systems (more history at spf.pobox.com
and other sites). There are no serious contenders with SPF for
MAIL FROM validation except proposed extensions (unified SPF, SPF2 which
include separate HELO scope among other things) which are generally
compatible, and SES (where the sender signs MAIL FROM) which is
also compatible and complementary.
I see some overlap, and some significant differences in these
methods. Except for DomainKeys, which does not rely on IP-authentication
at all, there are some common parameters ( protocol name, IP address,
domain name, and result ) which could be put in a standard header that
favors no one protocol. That header could allow for additional keyword
parameters specific to each protocol. There need not be any agreement on
these protocol-specific parameters. As long as the common parameters are
easily read, we have an avenue to better public acceptance of email
authentication. Its a social-engineering problem, not a technical
one. The public must have confidence that authentication will work, not
just between participants that share the same protocol, but across the
entire internet.
SPF works just fine, and will continue to be useful for those who
publish/check it regardless of whether it ever becomes universal.
If we don't get beyond this, we won't realize the full potential of email
authentication. I believe that potential is not just a small reduction in
spam, but a knockout punch. For this to happen, we need much more
universal acceptance of authentication.
[snip]
If people would just think of SPF as an automated IP list publishing
framework for email senders instead of all this FUD about SPAM and
disrupting email.
I agree that there is too much FUD and unfounded criticism of opponents'
methods. The focus on helping with the spam problem is important
however. If spam were not a problem, do you think this mailing list would
even exist? We've tried Bayesian filters. We've passed federal
laws. Nothing has stopped the relentless growth of spam. Now we have a
new technique. This is the first thing I've seen that really has the
potential to stop spam, not by itself, but as a key enabling technology.
-- Dave
************************************************************* *
* David MacQuigg, PhD * email: dmq(_at_)gain(_dot_)com * *
* IC Design Engineer * phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* * 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. * Tucson, Arizona 85710 *
************************************************************* *
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
|
|