"Ernesto Baschny" responded:
On 27 Jul 2004 at 11:28, Chris Haynes wrote:
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.
What if a "good sender" (i.e. an user of your domain) is traveling and
sends an email through a foreign provider's SMTP-Server, which you don't
allow in your SPF-policy. This is the case you want to catch with
your "explanation message", isn't it?
The foreign provider's SMTP-Server will possibly generate the bounce that
is send back to your user in your original domain with the error message.
You will have no easy access anymore to the original 5xx response, since
it will be embedded inside the MTA's bouce message.
Or not?
Let's see I've understood your scenario (and SPF-Classic) correctly:
Your traveller connects to a foreign provider's SMTP server (e.g. by using a
dial-up connection) and asks it to send a message for her. We have to assume
that the foreign provider is prepared to do this for an 'unknown' client (unwise
though that may be; your traveller could be a spammer).
That foreign-MTA accepts the message from the client, stores it and then offers
the message to the destination-MTA. The destination MTA consults the
foreign-MTA domain's SPF record (not the traveller's home-domain's record) and,
for some reason, decides there is a problem with the message.
The destination MTA gets the foreign-provider's explanation from its DNS TXT
record, macro-expands it (inserting the details of the problem where requested
by the macro-chars) and returns the expanded explanation to the foreign-MTA in
the 5** rejection.
It is now the job of the foreign-MTA to create the bounce message. It knows the
conventions used in its own domain's explanations, so it can do whatever is the
local policy there - convert the string from the SMTP rejection from UTF-8 into
Unicode characters, look up URLs, etc. It then puts the (possibly-amended)
explanation into the bounce message and sends it back to the traveller.
The point is that what the explanation says, what language it is written etc. is
entirely up to the foreign-MTA. It's their marketing policy which will decide
this. Likewise, how much of it is composed when the DNS TXT message is written,
and how much of it is done at rejection-time by the bounce-message-composer in
the sending MTA is up to them.
If the foreign provider caters entirely for, say. Nepalese customers, thy may
decide to send the explanation only in Nepalese. If they know they are
supporting international travellers using internet cafes, they could use five or
ten languages.
I think the only logical alternative to accepting that service providers can
choose whatever language(s) they wish to communicate with their customers would
be to mandate that all error mesages should be in English encoded in 7-bit ASCII
...
But even in this case, no standardization is needed if you stick to 7bit
ASCII, since this is really just something that the original sender will
have to read.
... which is perhaps what you are implying here?
Let me just declare my assertion again, 'cause this is where I'm not 100% sure I
fully understand SPF and I welcome contributions like yours.
My assertion is that (for SPF-classic applied as recommended) the MTA which
receives an explanation in an SMTP 5** rejection message is always under the
same administrative control as the domain which published that explanation.
Is this a correct assertion?
Does it hold for _all_ the SPF-related tests being considered by MARID?
Chris