ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] SMTP server reply extensions

2020-04-10 07:56:34
On 10. Apr 2020, at 3.34, Valdis Klētnieks 
<Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu> wrote:

On Wed, 08 Apr 2020 17:00:27 +0300, Timo Sirainen said:

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:

And then in backend2:
RCPT TO:<user2(_at_)example2(_dot_)com> MAILDATA 
/nfs/mail/user1(_at_)example(_dot_)com/INBOX/Maildir/file1

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

Maybe I need more caffeine, but I'm pretty convinced you'll have a hard time
getting identical mails, unless the front-end -> back-end mail fails to add
a Received: line. There's no way the Received: line for front->backend1 will
be identical to the Received: line for front->backend2.

True, I didn't remember that LMTP also normally adds a Received: header. But I 
don't think it's really necessary to add them, and if this feature is 
implemented then we could just require turning them off in backends. It's just 
an internal implementation detail how the mails are delivered after MTA has 
accepted them. I know some of our customers already have disabled the Received 
headers because they don't want any of the internal server names visible in the 
mails. All the tracing information exists in the log files anyway.

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp