On Wed, 24 Jul 2013, David Saez wrote:
> There is a DSN patch for Exim (RFC 3461 SMTP Service Extension for
> Delivery Status Notifications) at
> http://sourceforge.net/projects/eximdsn/ , it's a confirmation of
> delivery to the remote mta (not a user confirmation receipt) but may
> help ... i wonder why this feature was never added to Exim
DSN is a really heavyweight feature. I wouldn't expect most casual
contributors to get it right. And it's not hopeful that the latest
release of the patch was in early 2011 while Exim was last updated in late
2012.
I took a look at the patch (it at least applies with no rejects against
4.80.1) to see how it handled what I would consider a really hard part of
the problem - the format of the DSN messages themselves. Here, you have
to:
* detect invalid (8-bit) content in the message and avoid including the
full message if so. MIME stupidly forbids nested encoding, so if the
message to be bounced is not clean there's no way to legally include it
as a message/rfc822 attachment.
* choose a MIME multipart boundary that does not clash with the message.
* encode the enclosed headers if they aren't clean. Thankfully QP
CTE is allowed for the text/rfc822-headers format defined in RFC 3462.
The patch I see handles none of that. It just picks a random boundary
and *assumes* it won't clash, and *assumes* the message is clean.
Furthermore, it makes two other mistakes:
* When omitting the message body (which it only does on request of the
originator), it still uses the message/rfc822 content type instead of
text/rfc822-headers.
* While it implements RFC 3464 for the new success or relay-to-non-DSN
messages, it leaves Exim's old non-MIME format for delivery *failure*
notifications unchanged. DSN requires that failure messages follow the
3464 format too.
---- Michael Deutschmann <michael@???>
