On Thu, 2004-12-30 at 16:29, wayne wrote:
I presume you are referring to the
draft-kucherawy-sender-auth-header-00.txt I-D.
[...]
If this header was already in
widespread use, it might be productive to use it, but since it is only
an I-D, I don't think we want to tie SPF to it.
I understand the logic of not wanting to tie SPF to a header that
doesn't quite fit for the specific case of SPF, but I would go further
and say that SPF shouldn't be tied to a header that only fits for the
current, unscoped SPF.
So I would suggest changing:
It is RECOMMENDED that SMTP receivers record the result of SPF
processing in the message headers. If an SMTP receiver chooses to
do so, it MUST use the "Received-SPF" header defined here.
to:
It is RECOMMENDED that SMTP receivers record the result of SPF
processing in a "Received-SPF" message header. If an SMTP receiver
chooses to do so, it MUST use the "Received-SPF" header format defined
here.
(Or something similar)
This way, once there is a mature Authentication-Results header, (or
something like it that works well and is widely used, even if it's an
xml monstrosity), that works with multiple tests, shows test-paths and
such, and MUA's can read it's generic format even for new tests that the
MUA writer didn't know about..
Then people can write or package spf libraries and while still claiming
to be meeting the spf spec, without needing the default settings of the
library to be to write what would at that point be superfluous
Received-SPF lines.
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com