Actually, I've had a blinding insight, which (hopefully) brings this thread to a
conclusion.
If all SPF rejections take place during the SMTP process, and all explanation
messages are carried in 5** responses then, if only 'good guys' are involved,
the sending MTA (i.e. the one receiving the 5** explanation) will be under the
same administrative control as the domain which published the explanation.
(SPF recommended that Redirects stay within a single administration, and
Explanations do not propogate outwards with Includes, so the 'same admin'
assumption applies even under these conditions).
So, in deciding what to put in the explanation TXT the administration can write
whatever it wishes.
Providing allowance is made for the application of the macro-expansion applied
by the rejecting MTA (the one which applied the SPF test), the text is otherwise
unaffected and ignored by that remote MTA.
Therefore the sending administration could decide to implement either of the two
internationalization schemes I proposed.
One could use any of the available encodings-in-ASCII to represent any
international character sequence in any encoding, or one could use PLAN B and
have an auto-expanded URL.
All one needs is an MTA that understands the convention adopted and applies it
when composing the error message to be sent back to the original sender.
If a 'bad guy' sender gets given the strangely-encoded explanation it may not
mean anything to him, but that doesn't really matter, does it?
The encoding/semantics of the explanation is entirely private to the sending
administration, so no standardisation is required, so none of it needs to be
mentioned in the SPF draft.
It's just an opportunity for an enterprising MTA supplier to offer this as a
'added value' feature.
Any flaws in this logic?
Chris