[Top] [All Lists]

[ietf-smtp] SMTP server reply extensions

2020-04-08 09:02:03

I've recently found several reasons to add some kind of extended response 
metadata to SMTP/LMTP's RCPT and DATA replies. Similar to IMAP's resp-codes. 
Since I'm not so familiar with SMTP protocol, I was thinking I'd ask here if 
anyone happens to know already existing solutions for this or has some 
recommendations? Maybe there is already some RFC solving a similar problem?

IMAP uses "[resp-code parameters]" strings, but this doesn't seem to be used 
with SMTP protocol. Another option is to invent new SMTP enhanced code numbers, 
but especially for private extensions it seems a bit dangerous since there 
could be numbering conflicts. Also I'm not sure if SMTP clients would become 
confused when they see codes they don't understand? Also another problem with 
these numeric codes is how to add multiple different replies, especially since 
multi-line replies can't have different enhanced codes. But perhaps a single 
new extensible enhanced code could be invented? Something like:

RCPT TO:<user(_at_)example(_dot_)com>
250-2.1.100 key1 metadata1
250-2.1.100 key2 metadata2
250 2.1.100 OK with some extra metadata
354 OK
250-2.0.100 key1 metadata1
250-2.0.100 key2 metadata2
250 2.0.100 <user(_at_)example(_dot_)com> Saved and returned some metadata

To maybe clarify things, below are the 3 use cases I have so far. The first two 
are likely to be completely internal to Dovecot and I'm not trying make them 

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

2. Single instance storage for deliveries between backends in a cluster

The idea is that if backends share a storage (NFS, object storage) and there 
are multiple recipients, the proxy could deliver mail first to backend1, get 
back some metadata and use that to deliver mail to backend2, which would use 
the metadata to store a copy of the original mail. So for example:

RCPT TO:<user(_at_)example(_dot_)com>
250 2.1.5 OK
354 OK
250 2.0.0 <user(_at_)example(_dot_)com> [MAILDATA 
/nfs/mail/user1(_at_)example(_dot_)com/INBOX/Maildir/file1] Saved

(In reality the path would likely be a base64 encoded blob)

And then in backend2:
RCPT TO:<user2(_at_)example2(_dot_)com> MAILDATA 

Now backend2 can create a hard link from user1(_at_)example(_dot_)com's mail to 
user2(_at_)example2(_dot_)com's INBOX, saving some disk space. (Obviously only 
if the mails would be identical.)

3. We published a "submission token" draft a while ago:

It's going to need a bunch of changes, but that draft is also trying to solve 
this metadata problem by inventing new enhanced status codes, e.g.:

     S: 250 2.1.13 <user(_at_)foo(_dot_)com> etLBdTj1iG NRaaVe83QN Saved

The client is expected to understand 2.1.13 and to parse the reply 

The 2 and 3 cases are also an example of when it would be necessary to combine 
these metadata to the same DATA reply.

ietf-smtp mailing list