"Roger Moser" replied:
<snip>
With SPF the rejection happens before the DATA phase and therefore
no bounce message will be created by the receiving MTA.
<snip>
How should the receiving MTA encode this message in a "55x"
SMTP reply? Should it reply following?
558 =?UTF-8?B?471644F734A715BD563E85DC8....?=
Ah! Now I also understand what William Leibzon was getting at.
I'm talking anout the MARID drafts, not juist SPF Classic.
With the MARID tests there can be two times-of-failure, depending on the tests
applied.
Some tests can only fail after the message has been received in the DATA phase
and analysed, so a bounce will be generated. My 'mental model' of the rejection
explanation message was that it would be incorporated into the body of this
bounce.
But of course you rightly point out that other tests (SPF-Classic) can fail at
SMTP time. For these failures, the only communication mechanism available is the
free-format part of the 55x rejection. You (and William?) are suggesting that
the RFC2047 encoding mechanism could perhaps be be used to pass the
UTF-8 -encoded explanation back to the sending MTA.
AFAIK, there is no existing RFC which provides for the use of this MIME-related
encoding in SMTP responses (I've checked RFC 2821, please say someone if I'm
wrong on this).
Soooo, this looks like a big problem for my suggestion.
For completeness, let me list the logical options I can think of (but I'm
beginning to think my proposal has hit the end of the road).
Option 1:
If the test failure occurs at SMTP time _and_ an explanation text has been
provided, send a separate bounce message containing that explanation, as well as
the SMTP 55x rejection.
I don't like this because
(1a) The nice thing about the SPF-Classic tests is that the load on the
receiving MTA when rejecting a 'bad' message (at SMTP time) is minimal. Option 1
puts the MTA load up again (for those cases in which the domain has published an
explanation).
(1b) The user may get two rejection messages from a single mail submission -
confusing.
Option 2:
Extend the definition of SMTP to require the support of RFC2047 encoding in the
responses.
Theoretically this could be done. By publishing an SPF record a domain declares
that it is SPF-conformant. If we were to include mandatory support for
RFC2047-style encoding in the SPF core, we could, in theory, guarantee
interoperability.
However, I think this is 'using a sledgehammer to crack a nut'. To my mind it's
too radical a change, would need yet another ietf-draft in an area outside of
the expertise of MARID and would slow down the whole SPF adoption process.
So, I think I've concluded that I should drop this proposal.
Anyone think I should keep going?
Chris