Re: [EXIM] Remove attachments

Top Page
Delete this message
Reply to this message
Author: Philip Hazel
Date:  
To: Marc Haber
CC: exim-users
Subject: Re: [EXIM] Remove attachments
On Tue, 8 Jun 1999, Marc Haber wrote:

> How about this:
> - exim reads the spool file
> - exim feeds the spool file's content to the filter program
> - exim reads the filter's output back
> - exim writes that output to a different file (that is also locked)
> - exim deletes the old spool file
> - exim renames the new file to the old name.


That is the kind of thing I was referring to, but I need to investigate
and do experiments to see if it behaves as expected. I have made a note
on the Wish List.

The second last operation (delete old file) should *not* be done. You
want the file always to exist - a rename replaces one file with another
atomically. Deleting the old one first would leave a gap when there was
no file.

> Does a lock survive a rename or a hard link / unlink?


Locks apply to open files. If the file remains open, the lock should
remain. Messing around with the names that point to it should not affect
this.

> Removing attachments will probably need to change some MIME headers as
> well.


That would have to be done with "headers remove".

> Sure. The actual job I want to do at the moment would be the virus
> scan that would work with the Mvb approach. However, there are some
> operations being desireable (such as unzipping zips and reattaching
> the unzipped data to the same message or removing the attachments,
> decoding them, writing them to a directory on a file server and
> replacing the attachment in the message with a link to the decoded
> files) that will need access to the whole message (including full
> headers, I might regret to add). That would be beautifully doable with
> this filter approach.


I still feel this is getting overly-complicated. In particular, the
headers could not be modified in this way because Exim is holding them
in main memory during processing. I am much happier with a scheme that
does such involved message modifications entirely outside of Exim.

> Oh btw, the re-deliver approach mentioned in the FAQ will cause
> messages to need two queue runs to be actually delivered if
> queue_remote is set.


Not true. The system filter is run at the start of delivery, before it
looks at any addresses and decides whether they are remote or not.


-- 
Philip Hazel            University of Cambridge Computing Service,
ph10@???      Cambridge, England. Phone: +44 1223 334714.



--
*** Exim information can be found at http://www.exim.org/ ***