[Mimedefang] Comments on mimedefang.plL
David F. Skoll
dfs at roaringpenguin.com
Wed May 29 08:43:17 EDT 2002
On Tue, 28 May 2002, Clayton, Nik [IT] wrote:
> My main concern is the additional disk accesses that are required.
I've thought about it and I agree that the file-based interface as it
stands is inefficient. I can make a case for two files from the C
glue to Perl, and up to two going back. I think I will make these
changes:
>From C to Perl, we will write only two files:
- INPUTMSG which is the mail message
- COMMANDS which is a list of commands something like this:
S<sender at domain.com> # Set sender
R<recip1 at here.com> # Recipient
R<recip2 at here.com> # Another recipient
HFrom: <sender at domain.com> # A header
! # Flag - suspicious chars in hdr
... etc
All the info will be in one file. The commands are one-character long
for ease of parsing; I think the disk access saved will more than make up
for increased CPU time.
>From the Perl glue back to the C, we will have RESULTS, which will
again be a list of commands:
D<recip1 at here.com> # Delete recipient
N<joe at there.com> # New recipient
CX-Spam-Score: 5 # Change header
AX-Scanned-On: myhost.com # Add header
B551 5.7.1. Forbidden # Example: Bounce message
T451 4.7.1. Looks like spam # Example: Tempfail message
X # Example: Discard message
R # Example: Replace message mody
F # Filter finished successfully - must
# be present as last command.
If the "R" command is given (replace message body), then the NEWBODY file
will be used as it is now.
This should help the disk access. Also note that newer versions of
MIMEDefang support different directories for spool and quarantine, so
you can keep the spool directory in RAM and the quarantine directory
on disk.
The rest of the changes you suggested are fairly major, and I'm about
to have a deficit of spare time -- we're expecting our third child in
about four weeks, and I will probably go silent for a while after
that. :-)
Regards,
David.
More information about the MIMEDefang
mailing list