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 alun@texis.com 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.
