anomy-list

Re: A philosophical question: To rewrite or not to rewrite

From: Robert de Bath (robert$@mayday.cix.co.uk)
Date: Mon 05 Aug 2002 - 08:21:18 UTC

  • Next message: Rick Johnson: "Re: uvscan with anmomy"

    On Sun, 4 Aug 2002, Bjarni R. Einarsson wrote:

    > On 2002-08-04, 11:56:37 (+0100), Robert de Bath wrote:

    > > Firstly;
    > > I think this is a _very_ good idea, if Anomy isn't intrested in the
    > > contents of an attachment it shouldn't encode/decode it. Then it would
    > > even be able to pass messages with unknown content types like the 'x-yenc'
    > > or 'x-base251' that may appear soon.
    >
    > You're assuming (incorrectly) that the headers properly reflect what
    > the contents of an attachment are. Then what happens if someone
    > figures out a way to get Outlook to execute a binary disguisesed as
    > a image/jpeg .jpg attachment? Some common viruses do exactly that.

    > > It may even allow me to up the maximum size of message that I allow
    > > Anomy to check.
    >
    > I place no limits on this myself - I spent alot of time getting
    > Anomy's memory/disk usage as independant of message size as
    > possible so I wouldn't have to, and this work is the root of the
    > problems you're discussing above.

    I've noticed Anomy's use of disk and memory and I'm impressed by it,
    it even seems to take less memory than 'SETI'.

    However, the disk isn't really a problem for me, the mail load is such
    that an extra tempoary file shouldn't really be an issue; Still, I'm
    not keen to find out the hard way. :-)

    The real reason that I limit the messages I feed to Anomy is probably
    because it's written in Perl and if I feed it a huge message (eg: 30Mb) it
    takes many minutes of CPU time to say "I'm happy, you can forward this".
    Far, far longer than a "cat >tmp.file ; cat tmp.file" which takes seconds
    at most.

    The messages in question contain a single attachment with a known local
    extension ".fbk" on the filename and is passed based on just that so in
    this case Anomy, in theroy, doesn't need to decode+encode the attachment.

    Unfortunatly these 'fbk' files also look like text files to Outlook
    and MSIE (the first 100k or so _is_ a DOS text file) so they have the
    corrupted encoding problem too.

    Both of these problems should be solvable for me by 'simply' making Anomy
    pass 'boring' attachments without touching them at all. No decode+encode
    means no 'corruption' and a much lower CPU usage.

    BTW: I'm using maildrop to do the filtering. I just checked and yes it
         does have the tempoary file issue too, but if I replace Anomy with
         "cat" the BIG messages are fast.

    PS: I've not looked at Anomy's code, I'm not a Perl programmer, I don't
        like Perl's "Pathologically Eclectic" language design.

    -- 
    Rob.                          (Robert de Bath <robert$ @ debath.co.uk>)
                                           <http://www.cix.co.uk/~mayday>
    



    hosted by molar.is