Frank,
Thanks for taking the time to reply.
I'm trying to analyse all the responses.
Am I right that one of your objections is to the "Explanation" feature of the
current spec per se (regardless of my attempts to internationalize it); that
you think its a waste of time and bandwidth?
Regarding the specific choice of UTF-8 and the encoding, I was hoping to avoid
opening this up as a whole debate in itself. If one is going to do something
like I have proposed, there has to be just one encoding used - mandated by
specification (as there are no facilities in the DNS TXT record to indicate the
use of more than one encoding).
The IETF "Policy on Character Sets and Languages" RFC2277, when talking about
text strings, states that "Protocols MUST be able to use the UTF-8 charset". Is
this sufficient authority for my proposal?
I would refer those still concerned about the choice of UTF-8, and about the %HH
encoding, to the extensive debates which have taken place elsewhere
(public-iri(_at_)w3(_dot_)org ) concerning the decisions on IRI encoding and to
the
excellent Character Model produced by the W3C http://www.w3.org/TR/charmod/
Regarding the decision on which human language to use, whoever has to write the
SPF rejection explanation has to pick a single language to use. The people who
matter are not the 'illegals', it is those legitimate senders whose messages are
being rejected by SPF and who need to be told why this has happened.
These are the friends and aquantances of the would-be recipient, she wants to
help them understand what has happened and what they should do to be able to get
through to her.
It's my belief that the recipient is the only person who can decide which
language is the appropriate one to use for the explanation sent to her
'legitimate' senders. Restricting the character set to US-ASCII effectively
restricts the language choice to English - a minority language when assessed
globally.
Chris
----- Original Message -----
From: "Frank Ellermann" <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Sunday, July 25, 2004 10:19 PM
Subject: [spf-discuss] Re: Support for Internationalized Explanations
Chris Haynes wrote:
draft-ietf-marid-spf-3-protocol-00.txt
"SPF 3" ? Do you mean draft-ietf-marid-protocol-00.txt ?
See also <http://purl.net/xyzzy/-ietf/MARID>.
section 5.2 " exp: Explanation"
IMHO recipients are not interested in these explanations, they
want either PASS or FAIL, allowing for "ERROR" and "DONTKNOW".
And recipients are not interested to display an explanation of
the sender policy to the sender. If senders don't understand
their policy then they also won't understand their own "exp=".
Like SOFTFAIL this concept is a waste of time and bandwidth.
"allows the publishing domain to communicate further
information via the SMTP receiver to legitimate senders
in the form of a short message or URL."
More flexible than a 5xx SMTP error message, which also use
the "language" i-default (with charset us-ascii).
This communication takes place by putting the explanation
string into a rejection message.
Like "no such user here" (SMTP error messsages) resp. URLs of
blocklists incl. the relevant IP.
it is the 'legitimate senders' who are intended to read this
message, i.e. they are frequently humans who were intending
to communicate with the recipient, and who probably share
with the intended recipient his/her preferred language of
communication.
Impossible to determine at the time of SMTP / SPF checks. All
you have at this moment are some IPs and domains. And because
it's about a FAIL we're wasting time and bandwidth to "explain"
SPF to a trojaned Spamcast zombie.
It think it is now widely accepted across the IETF and W3C
that all new specifications etc. should provide support for
all languages
Not necessarily, that's why there is a "language" i-default for
cases without any base for I18N.
I therefore conclude that it should be possible to create and
transmit the explanation message using a wide range of
International characters.
This conclusion is IMHO wrong. I've seen bounces, where the
remote system used a German explaation for SMTP errors, because
my address ends with .de - that's ridiculous. In my case it's
still better than a Korean or Russian error message, but the
sender of a "de"-bounce didn't know this, it was a wild guess.
So we need a way of representing international characters
using a sequence of DNS-compatible US-ASCII characters
No, we don't need this. We only need to construct URLs, and
then let browsers and servers handle I18N using HTTP / XHTML.
We don't need I18N in a SMTP dialogue.
We choose the UTF-8 encoding
JFTR: my software doesn't support UTF-8. Please make sure to
check the browser and its version in your I18N why.html pages.
The name "Dürst" has a u-umlaut in it. The u-umlaut is
represented in UTF-8 by the two octets C3 and B3.
Probably you could also combine u with diaeresis (UTF-8 CC 88).
"D%C3%BCrst".
Or maybe "Du%CC%88rst", if you don't specify the normalization.
It's a completely unnecessary can of worms. You could also use
and allow =?iso-8859-1?Q?D=FDrst?= (RfC 2047, IIRC)
All SPF response messages MUST use MIME
I've never seen SMTP error messages using MIME, is this some
kind of ad hoc invention ? Or are you talking about bounces ?
The one and only purpose of classic SPF is to avoid bounces.
Bye, Frank
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Send us money! http://spf.pobox.com/donations.html
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com