Re: [ietf-smtp] SMTP server reply extensions

[Timo Sirainen <[e-mail]>]

On 8. Apr 2020, at 20.04, John C Klensin <[e-mail]> wrote:
> 
> --On Wednesday, April 8, 2020 15:31 +0100 Jeremy Harris
> <[e-mail] <mailto:[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>

This looks like it could work for the first use case. Although I'm still wondering a bit whether to use the deprecated source routes:

551  User not local; please try <@backend2:[e-mail]>

Or if it should just rewrite the address in some way to contain the backend name as the domain (or local-part):

551  User not local; please try <""@backend2>
551  User not local; please try <[e-mail]>

There are still the other two issues though.

> 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.

The 4yz codes were used only for the first use case, which I think can be solved with the 551 result. And I suppose if I still wanted to do it in another way, 5yz code would have been more appropriate since that's what 551 is also doing.

> 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.

I think you means some other RFC than 5428? Seems unrelated.

Anyway, the extended status codes couldn't at least fully be used for the other two examples I had, since it's not possible to give two different status codes in a single reply. But I suppose since the 2nd example is just internal communication data then maybe it could be just hacked in some way. I was just hoping for a something that could be used in a generic way to add any kind of key-value metadata pairs to replies, but it's beginning to sound like there's no nice SMTP-way of doing that.

> 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.

I think you're still talking about the first example? The reply code was meant from LMTP backend server to the LMTP proxy server in front of it, so the proxy would instead deliver the mail to a different backend's LMTP server (user was just moved from backend1 to backend2). Sending DSN to the LMTP proxy that would match it to that specific ongoing LMTP session would get pretty complicated to implement.