In <87ll5qq9zd(_dot_)fsf(_at_)deneb(_dot_)enyo(_dot_)de> Florian Weimer
<fw(_at_)deneb(_dot_)enyo(_dot_)de> writes:
I'm implementing the syntax part of draft-schlitt-spf-classic-01[1]
and noted that no charset is defined for the explanation string.
Section 3.1.1. "DNS Resource Record Types" specifies that SPF records
use US-ASCII. It doesn't say anything about the explain strings, so
I'll update it.
There's also no kind of language handshake. These days, this is
unacceptable for a message which should be presented to end users.
I'll echo what Chris told you, and add a few more details.
Like Chris, my immediate reaction when Meng first proposed the exp=
feature is that we had to support i18n.
Unfortunately, RFC2821 section 2.4 "General Syntax Principles and
Transaction Model" specifies that all SMTP commands and response use
ASCII, and since the explanation string is intended to be sent as an
SMTP response, we are pretty much stuck with ASCII.
Any sort of language handshake would have to be done in the SMTP
session, and that is something that SPF can't change. Some new SMTP
working group would have to be started to modifiy RFC2821.
By the way, the "third party" part is duplicated in these two
paragraphs:
Software evaluating check_host() can use this string to communicate
information from the publishing domain in the form of a short message
or URL. Software should make it clear that the explanation string
comes from a third party. For example, it can prepend the macro
string "%{o} explains: " to the explanation.
Implementations MAY limit the length of the resulting explanation
string to allow for other protocol constraints and/or reasonable
processing limits. The SPF client SHOULD make it clear when an
explanation string is coming from a third party, such as shown in
Section 2.5.4.
Thanks, I'll also fix that also. ;-)
[1] Mainly to be able to provide reverse SPF lookup, and to put the
"700,000 domains use SPF" claim into perspective. My efforts
should not be viewed as any kind of endorsement of SPF.
I have a list of 738703 domains that had SPF records as of March 3rd.
I'm going to try and start another survey of SPF records soon, but I'm
trying to get an update list of all .com, .org and .net domains (and
any other list I can). The list I have is about a year old now.
-wayne