Re: Unfortunate interaction between EZMLM and MessageLabs virus scanning

From: Alun Jones (alunat_private)
Date: Thu May 09 2002 - 06:13:51 PDT

  • Next message: Vanja Hrustic: "Re: Nearly undocumented NT security feature - the solution to executable attachments?"

    At 11:17 AM 5/7/2002, Ben Laurie wrote:
    >The widely used mailing list manager, EZMLM
    >(http://cr.yp.to/ezmlm.html), when sending mails for moderation, sets a
    >reply-to address which, if responded to, will cause the mail to be
    >accepted for distribution.
    >
    >MessageLabs (http://www.messagelabs.com/) offer an email virus scanning
    >service which, unfortunately, sends virus alerts to, amongst others, the
    >reply-to address.
    
    This is definitely a very troubling interaction between two 
    programs.  Without further information, of course, it's difficult to state 
    where the problem needs to be fixed.  Neither program is unique in the 
    behaviour stated, and a general solution should almost certainly be suggested.
    
    >I have heard that some people within MessageLabs think that they should
    >argue about the RFCs rather than fix this problem, so MessageLabs
    >customers might care to inform them directly of their own opinions.
    
    I'm not privvy to MessageLabs' internal wrangling, so I'm not sure to what 
    extent I'd support, or decry, "arguing about the RFCs", but there is an 
    important point to note here, that the problem should really be fixed where 
    the problem exists, not worked around by one company, so that another 
    company might fall afoul of the same problem.
    
    Virus scanners that reject email _should_ warn someone.  No doubt about 
    that.  Virus scanners do occasionally flag things as viruses even when they 
    are not.
    
    [You may skip this brief description of why this is important to me, should 
    you wish - pick it back up at the next bracketed comment]
    
    As part of my job, I send out attachments containing zip-compressed and 
    encrypted software.  Occasionally, I will get a response back that "a virus 
    has been detected".  The "virus" that is detected is usually described as 
    "encrypted executable".
    
    Sure, it's not beyond the bounds of social engineering to have a user open 
    the attached zip file, extract the files, enter a password, and run the 
    executable, so it's not entirely impossible that a virus might travel in 
    such a way, but it does seem unlikely.  In my case, I've only ever seen 
    this on non-infected executables.
    
    [You can start reading here again.]
    
    The problem comes when the virus scanner notifies neither the targeted 
    recipient nor the sender.  Often, the virus scanner notifies a 'postmaster' 
    or some similar role account unconnected with the file delivery 
    itself.  Since they're unconnected, they have no reason to hurry to check 
    the veracity of the virus report, particularly if there's news of viruses 
    being distributed at the time, and they trust the virus checker 
    implicitly.  If the checker says it's a virus, then it's a virus - they are 
    often completely unaware that their virus checker could flag something as a 
    virus when it is not.
    
    So, any time from a week to a month later, I get an angry call from a 
    customer who says he's seen his credit card bill has a charge from me, yet 
    he never received his software.  "What?"  I ask, since I've sent his 
    software and received no bounces [maybe email isn't supposed to be 
    reliable, but I've experienced either successful delivery, bounces, or 
    unreported drops due to virus checkers and the like].  We then go through 
    the same old dance of me trying to convince him that yes, I've sent the 
    software, and yes, his email server said it accepted it, so he needs to 
    contact his network administrators and find out why it was not delivered.
    
    So I've established one argument for why the virus checker should, in most 
    cases, be responding to the Reply-To.  In what cases shouldn't it?  A 
    posting on this topic appeared in the RISKS digest issue 22.06, and noted 
    another hazard of a mailing list manager that accepts any reply from the 
    moderator as cause to accept a posting for the mailing list: the "Out of 
    Office" autoreplies.  [Ben Laurie also posts in that RISKS column, but 
    incorrectly notes that "vacation(1) sends to the From address" - one copy 
    of 'man vacation(1)' that I find says "Note that if the incoming message 
    contains a ``Reply-To:'' message header, vacation will send its reply 
    message to the address listed there instead of to the address from the 
    ``From'' line." - all "Unix"s are _not_ the same.]
    
    So what does "vacation", the old Unix standard for "Out of Office" do in 
    order not to get into trouble with automated loops?  Here's a quote from 
    the man-page:
    
        Once the message has been collected, vacation will send an
        automatic reply to the sender of the incoming mail message
        provided that all of the following are true:
        1. userid (or an alias supplied using the -a option) is part
           of either the ``To:'' or ``Cc:'' headers of the mail.
        2. No automatic reply has been sent to the sender within the
           configured interval days. (See the -i and -r flags above.)
        3. The sender of the incoming message is not ``???-REQUEST'',
           ``Postmaster'', ``UUCP'', ``MAILER'', or ``MAILER-DAEMON''
           (where case doesn't matter).
        4. No ``Precedence: bulk'' or ``Precedence: junk'' line is
           included in headers of the incoming mail message.
    
    It would seem that the appropriate solution, then, is for the virus scanner 
    to follow at least item 4 above, and for the mailing list manager to ensure 
    that it adds the "Precedence: bulk" header to the mail meant for approval 
    _before_ sending it to the moderator.
    
    That's just my first thought on the issue, of course, so it's possible that 
    there's wiser heads who need to prevail on this.  Other obvious ideas for 
    resolving the problem include:
    1. Make the mailing list manager not accept just _any_ response as being 
    acceptable; require some form of human input (may be dismissed by the 
    program's author as "too difficult for the moderator")
    2. Require that the mailing list manager ignore all moderation approval 
    except from a particular address (and then make sure that the virus scanner 
    doesn't send its DSN from that address), rather than accepting an email to 
    the appropriate Reply-To address.
    3. Ensure that every virus that is flagged be checked for veracity by a 
    human being, and information be forwarded within a couple of hours to 
    either the recipient or the sender (or both).  Oh yeah, I can really see 
    that happening :-)
    
    However, I remain unconvinced that virus scanners _not_ replying to the 
    Reply-to address is truly a fix, if this was what Ben was suggesting.
    
    >"There is no limit to what a man can do or how far he can go if he
    >doesn't mind who gets the credit." - Robert Woodruff
    
    Of course, we have no way of knowing if Mr Woodruff was the originator of 
    that quote :-)
    
    Alun.
    ~~~~
    
    --
    Texas Imperial Software   | Try WFTPD, the Windows FTP Server. Find us at
    1602 Harvest Moon Place   | http://www.wftpd.com or email alunat_private
    Cedar Park TX 78613-1419  | VISA/MC accepted.  NT-based sites, be sure to
    Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for NT.
    



    This archive was generated by hypermail 2b30 : Fri May 10 2002 - 19:31:23 PDT