----- Original Message -----
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
To: "John P Baker" <jbaker314(_at_)earthlink(_dot_)net>; "IETF-SMTP"
<ietf-smtp(_at_)imc(_dot_)org>
Sent: Saturday, April 16, 2005 11:03 PM
Subject: Re: Anti-Spoofing Technology
Is there any extension to the SMTP protocol which, for a client
connection
to an SMTP server, would require that all messages originating from
that
client specify a return address known by the server to be associated
with
that client?
Why is the rfc2821.mailfrom address of particular address, rather than any
of
the other identification information, such as rfc2821.helo, rfc2822.from
or
rfc2822.sender?
I think he ask about SMTP and return address. not POST SMTP or 2822. The
client domain machine is too far gone to be useable for anything today. So
CSV is out of the picture all together.
The return path is the closest then we have today to anything that can be
considered to be technically required to be "correct." This is written
into the documents.
+80% of the time it is not and since most systems do not check, hence the
spoof problem. From a SMTP standpoint, the return path will have a great
technical value at the SMTP process to make sure , at a minimum, that it is
"verifiable."
Everything else (2822) is gravy.
I really hope this doesn't go into a useless debate about what is right or
wrong or SPF vs. CSV or some other machine. He asked about SMTP and the
return address and today, there are some practical "anti-spoofing" SMTP
based protocols in place today that do attempt to address the return path
validity. They exist in practice because they do offer some level of
protection.
----
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
http://www.winserver.com/wcsap (Wildcat! Sender Authentication Protocol)
http://www.winserver.com/spamstats (WcSAP Anti-Spam Stats)