Hi,
> I'm wondering if there is a way of indirecting the bounce generation so
> that a script or filter could be used to assemble the bounce. Maybe if
> the bounces were produced by a specifically named autoreply transport,
> then the transport could be overridden in the config to make a custom
> bouncer by say using a pipe transport. Is there a reasonably easy way
> this can be generalised to give people the hooks (or enough rope to
> hang themselves)?
I spent yesterdays last 2 hours with a glass of wine, RFC 1894 and
the Exim sources. The required & optional fields in RFC 1894
really are a bit more information than a classical bounce
message delivers.
You could pass this information by environment variables.
However, *one* reason to implement MIME-bounces would be to
fulfill RFC 1894 and give mailing lists or MUAs a chance to
automatically deal with error messages. This requires rather
strict compliance in the delivery-status part (part 2).
Part 1 (the "human" part in plain ASCII) is already customizable
by an external file.
Part 3 is the orginal message or a part of it (or nothing), and
there is not that much to customize about this.
Therefore I guess the actual decision is just if to generate
MIME-bounces or not, and how part 1 should look like.
Part 1 in MIME-bounces and the classical bounce should IMHO
not differ too much, apart from suppressing the "This is a copy
of the message..."-trailer.
Greetings,
Georg
--
*** Exim information can be found at
http://www.exim.org/ ***
