On Tue, 8 Jun 1999 09:39:59 +0100 (BST), you wrote:
>On Mon, 7 Jun 1999, Marc Haber wrote:
>> In <Pine.SOL.3.96.990604112959.8350H-100000@???>, you
>> say that "you can't really tamper with the message body in a system
>> filter". While it is clear now that exim can't do this at the moment,
>> are there reasons in the exim code that would make implementation
>> expensive?
>
>The existing file is open and locked to act at the "delivery lock" on
>the message. I don't see a safe way of updating it while this remains
>the case.
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.
Does a lock survive a rename or a hard link / unlink?
Since exim is doing all the work, I don't see a locking problem here.
However, I do have exactly no UNIX programming experience.
>You wouldn't want to write to it in place, in case there was a
>crash halfway through. (But as I said before, a simple truncation is
>less of a problem.)
Removing attachments will probably need to change some MIME headers as
well.
>OTOH, perhaps taking out a lock
>on the new file before renaming might be sufficient. I would have to
>check up on that.
I see, we both have been thinking the same way.
>> if $header_Content-Type: multipart/mixed then
>> if pipe_message "virus_scan()" <> 0 then
>> fail
>> endif
>> endif
>
>I see the attraction of that kind of approach. However, if it really is
>just a virus scan (no modification of the message) then running embedded
>Perl and using "exim -Mvb" to read the body is just a slight variation
>on your syntax, and you can do that already. It's the modification of
>the message that poses the problem.
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.
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.
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
--
*** Exim information can be found at
http://www.exim.org/ ***
