i cannot see why it's not possible to start with a "partial"
implementation that does not return the message body (does it explicity
forbid to have a implementation defined lenght limit of zero ?)
the rest of problems seem easy to fix
> On Wed, 24 Jul 2013, David Saez wrote:
>> El 24/07/2013 10:37, Michael Deutschmann escribió:
>>> 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:
>> maybe a good start point would be to ommit the original message body
>> entirely
> That would not be an implementation of RFC 3461 (the DSN ESMTP
> extension), since the extension provides a way for the sender to demand
> that the recipient commit to including the full content of the message
> when bouncing.
>
> RFC 3461 doesn't actually go out and say "MUST", but it does say the only
> exception should be an implementation defined length limit.
>
> It's a little better as an implementation of RFC 3462 alone, (the MIME
> format for all DSNs including bounces), but even that document says the
> default should be to return full content.
>
>
> By the way, reading RFC 3461 I see *another* bug in the Exim DSN patch.
> The RFC specifies that the sender's preference for full content or merely
> headers is only applied to failed deliveries -- for other DSNs (eg:
> successful delivery) only headers are ever to be sent.
>
> But the DSN patch sends full headers on success DSNs unless explicitly
> asked not to. And, as I noted earlier, the patch does not change the
> format of failure DSNs at all.
>
> ---- Michael Deutschmann <michael@???>
>
>
