Wietse Venema:
> Viktor Dukhovni:
> [archive transaction]
> > > ...
> > > 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
>
> No, this would show the original recipients, not the expanded ones.
>
> However, the list could be long in case of "sendmail -t" submission.
> This means the header may show only a sub-set with the complete list
> in a MIME segment before the message/rfc822 with the original message.
On the other hand, with this draft Postfix could easily list both
the current and original recipients (unlike a design based on an
SMTP-level "Y" splitter, which the current draft descends from).
If we do that, then we should almost certainly reuse existing syntax
instead of rolling our own. That will hopefully allow Postfix to
track developments as that format evolves to support richer
address/domain syntax.
Content-Type: multipart/related;
boundary=unique-boundary-string
--unique-boundary-string
Content-Description: Message envelope
Content-Type: text/plain
Reporting-MTA: dns; mailhost.example.com
X-Postfix-Queue-ID: 84863BC0E5
Sender: rfc822; sender@sender-domain
Original-Sender: rfc822; sender@sender-domain
Arrival-Date: ...mail date format...
Final-Recipient: rfc822; final-recipient1@final-domain1
Original-Recipient: rfc822; original-recipient1@original-domain1
Final-Recipient: rfc822; final-recipient2@final-domain2
Original-Recipient: rfc822; original-recipient2@original-domain2
-unique-boundary-string
Content-Description: Message content
Content-Type: message/rfc822
...original message headers...
...original message body...
--unique-boundary-string--
Wietse
