----- Original Message -----
From: "wayne" <wayne(_at_)schlitt(_dot_)net>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Thursday, December 30, 2004 12:07 AM
Subject: Re: [spf-discuss] Re: draft-schlitt-spf-02 now available and
submitted to the IETF
In <20041230043515(_dot_)GA14642(_at_)alatheia(_dot_)elm(_dot_)net> Alex van
den Bogaerdt
<alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net> writes:
On Wed, Dec 29, 2004 at 09:21:15PM -0600, wayne wrote:
One of the editing changes I made was to try and carefully go through
the draft and make sure every reference to "host" or "host name" was
really talking about host and not domains. And, similarly, all
references to "domain" or "domain name" are not talking about hosts.
So, this is something that I know I have been confused about before,
and I *thought* I had it figured out. If the wording in the SPF draft
is not right, please let me know.
I think you got it right. The confusion seems to be that host
names supposedly need not be fully qualified domain names.
At least for SMTP this assumption is not valid.
In an earlier post, I mentioned that HELO and MAIL FROM domains are
often not fully qualified and John Martin pointed out that RFC2821
says that they must be. (I haven't doubled checked, but I'm pretty
sure JAM is right.)
On a related note.....
You can't write a spec under this premise.
You must state the new host requirements and allow these requirements to be
"updates" to the RFC 2821 if there is descrepancies. IOW, it is up to you
to clear it up. Then in your specs, you add to the top:
UPDATES: RFC 2821
This is how other RFCs do it. For example RFC 2821 updates RFC 1123 hosting
requirements:
Network Working Group J. Klensin, Editor
Request for Comments: 2821 AT&T Laboratories
Obsoletes: 821, 974, 1869 April 2001
Updates: 1123 <----------!!!!!
What you are doing is defining SPF hosting requirements that developers need
to work on. They will decide what the realities are and work from there.
But your specs can't be "relaxed" otherwise you defeat the purpose in my
view.
So what this means is:
SPF ready SMTP clients (senders) MUST use FQDN client domain names
(HELO/EHLO)
SPF receivers will expect BOTH in its consideration for analysis.
The key to the SPF specification is for it to add "enforcement"
specifications to the SMTP process. That is whats lacking in RFC 2821. It
does not have much to point UPWARD too.
By your specs adding "Updates 2821" now developers will have some
"ammunition" both technically and legally to apply stronger SMTP compliancy.
Essentially that is what Message Submission RFC 2476 does. It enforces ESMTP
AUTH via PORT 587 for what is otherwise optional via PORT 25. Your SPF
specs adds some level of enforcement to SMTP.
With this in place, current and future MUA authors will have a strong
guideline with no descrepancy in using a FQDN or a proper domain literal.
In fact, the can use the extended HELO format with the string description:
For dynamic IP MUA:
EHLO [x.x.x.x] Outlook User version 1.20
or whatever.
Of course, for backward compatibility, the SMTP receiver will need to handle
old and new situations, but that isn't a SPF issue really. If any, it would
that if a FQDN is used, it adds strength to the receiver protocol.
Now, what would be really sweet is a Migration DEADLINE <g>
SPF Receivers expect FQDN operations on all senders 360 days from the
date of initial recording.
This will clearly distill the gas from the tar!
But.....<g>
Happy Holidays,
---
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office