On Apr 3, 2005, 3:26 PM, John Glube wrote:
* Are the authors prepared to make the proposed change to
the final sentence in section 2.4?
The sentence in issue presently reads:
"Checking other identities against SPF records is NOT
RECOMMENDED because there are cases that are known to give
incorrect results."
The IESG suggested this sentence read:
"Checking other identities against SPF records is not
defined in this document."
My sense of the spirit behind this objection is that the IETF wants to
maintain neutrality between the competing methods. Clearly that can't be
done for every item in a spec on SPF, but I think it can for this
item. What if we added words like:
"""
A sender must flag an identity in one of the existing email commands, or it
may add a new one. To flag an identity, put the string *ID* after the
declared name.
HELO my-company.com *ID*
MAIL FROM: bob(_at_)sales(_dot_)my-company(_dot_)com
To use an identity different than one in either command, add ID=<identity>
after either of the commands.
HELO mailserver.my-company.com ID=my-company.com
It is important that the sender's ID be explicitly declared, not just
assumed from existing information. Not only will this remove the current
uncertainty as to which ID the sender intends to use, but false information
here is evidence of lying, not just a forgivable error in passing on
existing information (a long-standing tradition on the Internet). This
will greatly reduce the administrative burden in deciding whether to trust
a sender.
Most reputable Public Mail Servers will chose their top domain name as
their ID, but it can be any name under DNS control. This could be a domain
set up specifically to authorize mail servers, or it could be some other
organization's ID. The latter should be allowed but discouraged, since any
miscommunication over the use of someone else's ID could result in
authentication failures, suspicion of forgery, and loss of reputation by
the owner of the ID.
"""
This puts a burden on the receiver to do the best it can with whatever
choice the sender makes, but this is better than the current confusion,
where the receiver cannot even know what choice the sender is assuming.
It will also respond in a very positive way to one IETF concern, without
sacrificing anything essential in SPF.
--
Dave
************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *