On Thu, Mar 28, 2013 at 08:10:33PM -0400, Wietse Venema wrote:
> - A new queue file record (soft bounce) saying that Postfix must
> never bounce the message containing that record. This is a safety
> mechanism for when delivery to the archive server fails.
There should also be an "archive_sender" parameter that specifies
the envelope sender address of archive messages and defaults to
the empty string (null sender) (or perhaps "postmaster", if this
does not risk loops). This ensures that even if downstream systems
don't support DSN the archive message will never bounce or will
bounce to a suitable recipient, not the original sender.
> Example 2: archive SMTP transaction
> ===================================
>
> Here, Postfix delivers an archive copy of the message to the archive
> server (S=archive server; C=Postfix hub), preserving the original
> envelope sender and recipients in the archival copy's From: and To:
> headers together with a copy of the Date: and Subject: headers, and
> preserving the original message (headers and body) as a message/rfc822
> attachment.
>
> S: 220 mailhost.archive-domain ESMTP
> C: EHLO splitter.example.com
> S: 250-mailhost.archive-domain
> ...other ESMTP feature announcements...
> C: MAIL FROM:<original-sender@sender-domain>
This should I think be "MAIL FROM:<$archive_sender>"
> ...
> S: 354 End data with <CR><LF>.<CR><LF>
> C: From: <original-sender@sender-domain>
> To: <original-recipient1@recipient-domain1>,
> <recipient2@recipient-domain2>
> Date: ...same date as original message...
> Subject: ...same subject as original message...
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Type: Multipart/Mixed;
> boundary="unique-boundary-string"
The message envelope could be quite large, since a message
can have thousands of recipients after virtual(5) expansion.
Putting all envelope recipients in the "To:" header risks
running into header length limits that cause header truncation
or parsing problems.
Unlike Postfix, some software imposes limits on the total size
of the header, not just individual header records.
Therefore, the envelope should be presented a MIME body part.
If the above is not compelling, and there is no message body part
containing the envelope (which is carried above in headers) then
we don't need a multipart encapsulation of the inner message, just
set the outer content-type to message/rfc822.
> --unique-boundary-string
> Content-Type: message/rfc822
>
No need for a multipart/mixed with just a single part.
> ...
> Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
> eiusmod tempor incididunt ut labore et dolore magna aliqua.
>
> --unique-boundary-string--
Nor this final boundary string.
> .
> S: 250 Ok: queued as 97C84AC2947
> C: QUIT
> S: 221 2.0.0 Bye
--
Viktor.
