On 8. Apr 2020, at 20.04, John C Klensin <john-ietf(_at_)jck(_dot_)com> wrote:
--On Wednesday, April 8, 2020 15:31 +0100 Jeremy Harris
<jgh(_at_)wizmail(_dot_)org <mailto:jgh(_at_)wizmail(_dot_)org>> 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:<user(_at_)example(_dot_)com>
250 2.1.5 OK
RCPT TO:<user2(_at_)example2(_dot_)com>
450 4.4.4 [REFERRAL smtp://backend2/] Redirected
RCPT TO:<user3(_at_)example3(_dot_)com>
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:user(_at_)exameple(_dot_)com>
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 <backend2(_at_)example(_dot_)com>
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.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp