On Sun, 3 Oct 2004, Mark Lentczner wrote:
Friends -
Here is a list of questions about what should be included in my
upcoming SPF v1 draft. Remember, the goal is to write up what is
generally agreed, deployed and implemented as SPF v1.
1) HELO domain checking clause
------------------------------
The last SPF draft (draft-mengwong-spf-01) includes language that
allows mail receivers to lookup SPF records for the HELO/EHLO domain
and test for a non-Fail result. This is a separate test, performed
even in the normal case of a non-null MAIL FROM. Note: the language
doesn't specify what to use for a sender-mailbox during such a test, so
it is incomplete at present.
I don't know how recently this language was added. Do any
implementation of SPF do this? Do people consider this part of SPF
Classic, or is this an add-in from the Unified SPF work?
I think this belongs better into Unified SPF work and should not be in SPF
Classic draft. For me and others SPF Classic is associated with protecting
Return-Path and while doing EHLO check on postmaster(_at_)EHLO-name is ok when
Return-Path is empty, anything beyond that seems not appropriate to include
into SPF Classic specification. And I actually have not seen any SPF Classic
implementation that does EHLO check, but maybe I'm seriously wrong.
But we can and should certainly work on creating draft for HELO check for
Unified SPF work.
2) The Received-SPF Header
--------------------------
The SPF drafts have always had a section on the Received-SPF header. I
am presuming that this should be in the draft. Does itm, as it appears
in draft-mengwong-spf-01, reflect any implementation?
Do include Received-SPF information in the draft in the way its actually
used. But if possible say Received-SPF is OPTIONAL and SPF verifiying
agents MAY use other special authentication results headers to report
information about success of failure of SPF verification.
3) New DNS RR Type
------------------
While this language never appeared in any SPF draft, it has been
discussed since very early on. The form of the language that made it
into the Sender ID protocol draft would not affect any deployed SPF
domain or any implementation. Essentially, it simply endorses and
hopes you will use a the new RR type (once it is assigned by the IANA).
I recognize that this language clearly does not reflect the deployed or
implemented state of SPF. However, it seems to me to be part of the
common "we were going to do that when we got to draft status"
understanding. Do people agree? Or should I remove it?
I'm conflicted here like you are. While I recognize that new RR is not
used by SPF currently and that SPF Classic draft is to document currently
deployed base, I also recognize that SPF need this RR ASAP and that
promoting this draft into EXPERIMENTAL RFC is a way to do it.
I do have strong personal opinion about stealing somebody elses record
type is wrong and that SPF community should not promote such activities
for long term future...
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net