spf-discuss
[Top] [All Lists]

IESG and

2005-04-12 10:45:46
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        *
************************************************************ *


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