Re: [ietf-smtp] SMTP server reply extensions

[John C Klensin <[e-mail]>]

--On Wednesday, April 8, 2020 15:31 +0100 Jeremy Harris
<[e-mail]> wrote:

> On 08/04/2020 15:00, Timo Sirainen wrote:
>> 1. IMAP-like login referrals (RFC 2221)
>> 
>> This RFC isn't really used nowadays, but I'm now thinking of
>> using referrals internally in Dovecot clusters. Dovecot
>> backend could send a referral and Dovecot proxy would
>> reconnect to that referral instead. But the same thing is
>> needed also for LMTP, which means that it would have to be
>> sent in a RCPT TO reply since the redirection can be
>> different for different users. Perhaps something like:
>> 
>> RCPT TO:<[e-mail]>
>> 250 2.1.5 OK
>> RCPT TO:<[e-mail]>
>> 450 4.4.4 [REFERRAL smtp://backend2/] Redirected
>> RCPT TO:<[e-mail]>
>> 450 4.4.4 [REFERRAL smtp://backend3/] Redirected
> 
> Perhaps this?
> 
> RFC 4321 Section 4.2.3
>   551  User not local; please try <forward-path>

Jeremy, 

Thanks although I assume "4321" is a typo and your meant "5321".

The more general issue is that there has been a long-standing
principle of the SMTP design that, unless situation-specific
information is actually needed (and that use of 551 is one of
the exceptions), the codes contain most or the information and
are what is important, not the text.  That is important because
it avoids the SMTP-sender having to do natural language
processing and because it largely eliminates the need to worry
about internationalization (and hence translation) of the text
strings.  Of course the "act on the first digit only" rule is
intended to put even less burden on the SMTP-sender as well as
providing robustness against the SMTP-receiver using codes that
the SMTP-receiver has not been upgraded to understand
specifically. 

I've read through Timo's note a few times with the above as
context and I'm not sure I see the fit between what I think he
is proposing and SMTP.

First, a 4yz code implies that the sender should requeue the
message and try again later.  It is not an intermediate
processing indication of some variety with the implication that
the server is retaining responsibility for getting the message
delivered.   SMTP, by design (and long before me) does not have
such intermediate processing indications in reply codes;
inventing one or a series of them (1yz, perhaps?) would be a
rather major change to the standard and would probably break
SMTP-senders who have assumed there are only codes starting in
2, 3, 4, or 5 since the publication of RFC 821 in 1982.

Second, if the above is ignored, it would seem to me that the
right way to do at least part of this would be to use extended
status codes based on RFC 3463 and the registry established by
RFC 5428.

Finally, the information shown in that example looks a lot more
like trace information to me than like anything appropriate to a
reply code.  Normally, track information ends up on the hands of
someone on the far side of the SMTP-receiver.  But I can see no
reason (other than creating an opportunity for noise, blowback,
and spam if not done carefully) why one could not build a
Delivery Status Notification containing that type of trace
material and send it to the message originator or the
SMTP-sender.  No change to SMTP required.

Timo, if Jeremy's comment and that explanation do not answer
your question/ proposal, could you explain a bit more?

thanks,
   john