+<BR><H2><A NAME="SEC223" HREF="FAQ.html#TOC223">15. MODIFYING MESSAGE BODIES
+
+</A></H2>
+<A NAME="SEC224" HREF="FAQ.html#TOC224">Q1501</A>: How can I add a disclaimer or an advertisement to a message?
+
+
+<P>
+A1501: There are a number of technical and potential legal problems that arise
+ in connection with message modification. Some of them are listed below.
+ If, despite these considerations, you still want to modify messages, you
+ can do so using Exim, but not directly in Exim itself. It is not the job
+ of an MTA to modify messages, something that requires understanding of
+ their content and format.
+
+</P>
+<P>
+ Exim provides a hook in the form of a "transport filter" that lets you
+ pass any outgoing message through a program or script of your choice. It
+ is the job of this script to make any changes to the message that you
+ require. By this means, you have full control over what changes are
+ made, and Exim does not need to know anything about message bodies.
+ However, using a transport filter requires additional resources, and may
+ slow down mail delivery.
+
+</P>
+<P>
+ You can use Exim's directors and routers to arrange for those messages
+ that you want to modify to be delivered via a transport filter. For
+ example, suppose you want to do this for messages from addresses in
+ your domain that are being delivered to a remote host. Place the
+ following router before the standard <B>lookuphost</B> router:
+
+</P>
+<PRE>
+ filter_remote:
+ driver = lookuphost
+ transport = remote_smtp_filter
+ condition = ${if eq {$sender_address_domain}{your.domain}{yes}{no}}</PRE>
+<P>
+ This routes the relevant addresses to a transport called
+ <TT>remote_smtp_filter</TT>. Other addresses fall through to the normal router,
+ and are routed to the standard <TT>remote_smtp</TT> transport. Another way to do
+ this would be to use a single router, with an expanded string for the
+ transport setting. The new transport is defined thus:
+
+</P>
+<PRE>
+ remote_smtp_filter:
+ driver = smtp
+ transport_filter = /your/filter/command</PRE>
+<P>
+ The entire message is passed to your filter command on its standard
+ input. It must write the modified version to the standard output, taking
+ care not to break the RFC 822 syntax. The command is run as the Exim
+ user, if one is defined; otherwise it is run as root.
+
+</P>
+<P>
+ There are a number of potential problems in doing this kind of
+ modification in an MTA. Many people believe that to attempt is it wrong,
+ because:
+
+</P>
+<P>
+ 1. It breaks digital signatures, which are becoming legally binding
+ in some countries (already in the UK, likely to be 1 October 2000 in
+ the USA).
+
+</P>
+<P>
+ 2. It is likely to break MIME encoding, that is, it is likely to wreck
+ attachments, unless great care is taken.
+
+</P>
+<P>
+ 3. It is illegal under German and Dutch law to change the body of
+ a mail message in transit. It might potentially be illegal in
+ the UK under European law. This consideration applies to ISPs and
+ other "common carriers". It would presumably not apply in a corporate
+ environment where modification was done only to messages originating
+ from the employees, before they left the company's network. It might
+ also not apply if the senders have explicitly given their consent
+ (e.g. agreed to have advertisements added to their incoming mail).
+
+</P>
+<P>
+ 4. Since the delivered message body was produced by the MTA (not the
+ originator, because it was modified), the MTA operator could
+ potentially be sued for any content. This again applies to "common
+ carrier" MTAs. It's interesting that adding a disclaimer of liability
+ could be making you liable for the message, but this case seems
+ more likely to involve adding advertisements than disclaimers. After
+ all, no postal service in the world opens all the mail it carries to
+ add disclaimers.
+
+</P>
+<P>
+ 5. Some mail clients (old versions of MS outlook) crash if the message
+ body of an incoming MIME message has been tampered with.
+
+</P>
+<P>
+ An alternative approach to the disclaimer problem would be to insist
+ that all relevant messages have the disclaimer appended by the MUA. The
+ MTA should refuse to accept any that do not. Again, however, the MTA
+ must understand the format of messages in order to do this. Simply
+ checking for appropriate wording at the end of the body is not good
+ enough. It would probably be necessary to run a Perl script from within
+ an Exim system filter in order to adopt this approach.
+
+</P>
+<A NAME="SEC225" HREF="FAQ.html#TOC225">Q1502</A>: How can I remove attachments from messages?
+
+
+<P>
+A1502: The answer to this is essentially the same as for
+ <A HREF="FAQ.html#SEC224">Q1501</A>.
+
+</P>
+<BR><H2><A NAME="SEC226" HREF="FAQ.html#TOC226">20. MILLENNIUM
git://git.exim.org / exim-website.git / commitdiff