On Fri, Mar 29, 2013 at 09:04:57AM -0400, Wietse Venema wrote:
> 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).
[ FWIW my original Y splitter parsed ORCPT from DSN "RCPT TO" commands ]
> 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
Multipart/related is required to designate a top-level type for
the primary part, and may then use Content-ID linkage (e.g. <cid:....>
URIs):
Content-Type: multipart/related; type = message/rfc822;
boundary = unique-boundary-string
here it is not clear whether the envelope or the message is the
primary payload, and which is the "related", so I would just
go with multipart/mixed. That way MUAs will display two parts,
rather than just the "root" part.
https://tools.ietf.org/html/rfc2387
> --unique-boundary-string
> Content-Description: Message envelope
> Content-Type: text/plain
I think it is a fine idea (I would have used that in the Y-splitter
were it not for legacy compatibility issues) to use
https://tools.ietf.org/html/rfc3464
as the envelope encoding format, and to even tag the MIME type as
such:
Content-Type: message/delivery-status
> 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--
