Re: SPF and SenderID - for your comments Chuck

This is the relevant extract from the note suggested by David Kessens:

https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1599&filename=draft-schlitt-spf-classic


" I would have much preferred a solution that would be an extension to SMTP
that simply checks back with one of the official MTA machines as listed
in the
'mx' records for the domain whether the sending machine can be accepted,
or just one simple DNS record with the name of the machine which is capable
of doing the verification. The
resulting protocol would be much simpler as all the configuration of the
MTA doesn't need standarization as this information would not need to be
published since it is not needed by any other than the 'mx' domain.

 From an operational perspective, the DNS solution also has issues since
the DNS administrator is not necessarily the same as the mail
administrator. "

------

Taking these points in turn -

Unfortunately a domain does not have to have an MX record for it to be
used for e-mail. If an A record exists, this is sufficient. Should the
IETF/IESG choose to rectify that situation, the world of e-mail would
already become an easier place to work in.

SPF does have the ability to use a simple DNS record entry which can
include the relevant detailed record from another zonefile, perhaps the
zonefile of a subdomain. This would probably be the method of choice for
large users of SPF, since it eliminates the necessity of maintaining a
lot of records in each individual domain's zonefile.

Operationally, any specialist DNS administrator will be able to
accomodate his Mail administrator counter-part by allowing access to
add, edit or remove the relevant DNS records required by SPF.


Kind regards,

John Pinkerton








Ted Hardie wrote:
> 
> At 5:15 AM +0200 6/16/05, Frank Ellermann wrote:
> 
>> Arnt Gulbrandsen wrote:
>>
>>>  Does that IESG member happen to think that SPF suffers from
>>>  poor workmanship?
>>
>>
>> That person changed [yes] to [discuss] after he found out that
>> his removal of one critical "NOT RECOMMENDED" against the PRA-
>> abuse doesn't fly with the SPF community.  That person did not
>> propose to remove the offending "SHOULD abuse v=spf1" from PRA.
>>
>>                            Bye, Frank
> 
> 
> All changes to the state of document are noted in a public ID tracker.
> The URL for the tracker details for the SPF document is:
> 
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12662&rfc_flag=0 
> 
> 
> A sponsoring AD always has a ballot position of YES when they bring
> a document to the IESG.  Sponsoring ADs often put in what are called
> "placeholder DISCUSS" comments when there are issues raised outside
> of the IESG (since those would otherwise not be tracked).  Those
> should have explanatory text.  In this case,the explanatory text is:
> 
> "Further discussion on the intended status and relationship to
> MARID working group needed."
> 
> This was entered to track the fact that the IESG needed to discuss 
> Wayne's comments
> on the disconnect between his intentions as author and the original 
> draft solicited
> after MARID closed (draft-lentczner).  This discussion has continued 
> through Wayne's
> request that the spf draft be considered for Proposed Standard, rather 
> than Experimental.
> It also encompasses the problems raised by forwarding both documents; these
> were raised both within and outside the IESG, and the IESG had discussed 
> them
> at great length.
> 
> As was documented on the IETF list response to Wayne, there was no 
> support for
> at this time for publishing the spf draft as a Proposed Standard (to be 
> clear:  the
> IESG was asked this question at a telechat, and no AD thought it was 
> appropriate).
> The IESG is currently considering moving forward on the basis of an IESG 
> note
> suggested by David Kessens.  Once the IESG agrees that the document set
> is ready, the sponsoring AD position will go back to YES.  For those who 
> find
> navigating the tracker hard (and it can be non-intuitive), here's the text:
> 
>> The following documents  (draft-schlitt-spf-classic, 
>> draft-katz-submitter,
>> draft-lyon-senderid-core, draft-lyon-senderid-pra) are published 
>> simultaneously
>> as Experimental RFCs, although there is no general technical
>> consensus and efforts to reconcile the two approaches
>> have failed.  As such these documents have not received full IETF review
>> and are published "AS-IS" to document the different approaches as
>> they were considered in the MARID working group.
>>
>> The IESG takes no position about which approach is to be preferred and
>> cautions the reader that there are serious open issues for each approach
>> and concerns about using them in tandem. The IESG
>> believes that documenting the different approaches does less harm
>> than not documenting them.
>>
>> The community is invited to observe the success or failure of the
>> two approaches during the two years following publication, in
>> order that a community consensus can be reached in the future.
> 
> 
> The document names would be replaced by RFC numbers by the RFC Editor.
> All other instructions to the RFC Editor (that is, all the text trying 
> to reconcile
> the two) has been removed.
> There has been a lot of discussion of this draft, and this short summary 
> no doubt
> misses some points, but I hope it clarifies the current state at least 
> somewhat.
>             regards,
>                 Ted Hardie
> 
> 
> 
>