Ever since Melissaarrived in 1999 the delivery of Office-applications developed for others has been much more cumbersome. Every time I make a delivery there is a lot of trouble, often ending up with loss of confidence for me in the eyes of my customer. The situation is most vulnerable when acting with new customers, who are not located nearby, so a personal visit is not feasible, costing far too much. The first desperate changes made by Microsoft where probably too restrictive, and have since then been the markup for how to protect against macro-viruses. Since I have seen no reports on “succesful” macro-viruses since Melissa in that sense the countermeasures could be said to have worked well, to very high cost for all making valuable macros for others (ie. Office developers), having to pay the cost of in some cases totally confusing restrictions. In the list of “blocked files in Outlook” constructed by Microsoft it contains among others “.mdb”, this happens to be the default file type for the JET-engine (Access Databases) Why Access-macro are more harmful than macros in Excel (.xls, xlsm etc) or Word (.doc,.dot,.dotm etc) had never really been explained, and technically they are totally equivalent. By the way Melissa was a Word-macro! The main problem with macro-viruses are that they probably only work if they contain an autoexec-macro of any type. An mdb-file containing only table definitions, relations and data – could never ever do any harm!! If the file contains queries it could be constructed to do some smaller harm, but if it contains VBA-code it could of course be just as problematic as a Word- or Excel-macro.
The reason I prefer to send my applications as attachments to a mail is that most users feels much more comfortable with that compared to downloading over internet which is much more risky, and they are not as used to that as picking an attachment from a mail, where they trust they sender. In the downloading-process they get a lot of false warning-messages making them unsure if this really is as safe as I guarantee. So since many years I have had some tricks that worked well, even if my customers asks themselves, “why does he send so dangerous stuff”. I have renamed the file type to .xxx or anything seen by Outlook as not dangerous. Then someone found that people tricked Outlook so I had have to put the mdb-file into a zip-file before sending it. Since all these countermeasures are “secret” you never get a warning that a new problem has aroused due to some new smart feature from an anti-virus specialist.
Last week I went mad in the contact with a new French customer I have gotten by internet marketing. When I delivered my harmless mdb-file (only containing tables and definitions), today I always do the VBA-part of my solutions in Excel, since xlsm-files are “harmless”. None of my tricks worked anymore, they were using Notes, where someone has invented looking into the zip-file, and then examining not only on file type but also on content, so Notes found “the potential virus”, so the attached zip-file was removed without any warning. It all ended up with finding a new way of delivery, this time “Drop-box” finally managed to get the files to France from Sweden. Sooner or later I guess this loophole also will be filled, to enhance “security” in Windows. Ever heard of the story “The boy who cried wolf” – you don’t raise security by telling new lies about potential threats, instead security is lowered.
So I asked the question “Danger of mdb-files??” in the Access forum, and I was advised by many helping colleges on how to handle the situation… Everybody just accepting the rules of security that apply for the moment and the war fought against the anti-virus trust.
So now I try to raise the problem in another forum, which I hope is more correct. I would like to know why harmless mdb-files still are compared with exe etc. in the class of danger. Is there no possibility to mark them as harmless? When opened by JET it must be possible to examine if they are harmless or not. Am I right or am I wrong?
Rickard Olsson http:/www.ricol.se/en/
rixol