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