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