Re: [ietf-smtp] SMTP server reply extensions

[Timo Sirainen <[e-mail]>]

On 10. Apr 2020, at 3.34, Valdis Klētnieks <[e-mail]> 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:<[e-mail]> MAILDATA /nfs/mail/[e-mail]/INBOX/Maildir/file1
> 
>> Now backend2 can create a hard link from [e-mail]'s mail to
>> [e-mail]'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.