Ben Bucksch wrote:
> Yes, with 2 exceptions:
>
> *�I�don't�mind�deleting�the�attachment,�if�(and�only�if)�the�user
> explicitly�requested�it.
> That�would�be�bug�2920�and�different�from�what�you�suggest�(never
> store�attachments�together�with�the�rest�of�the�mail).
Had you asked me a week ago, we would have been in 100% agreement. Bug
116443 now has 2 major AV apps trashing the InBox on both Mozilla and NS
4.7x due to their attempting to clean out an attachment that is still part
of the mail. At this point none of us know how many other AV apps do the
same thing.
I should also clarify one point. Automatically detaching an attachment
from the E-Mail and linking to it's location on the hard drive isn't quite
the same as deleting attachments as they come in.
> *�Separating�attachments�from�the�rest�of�the�mails�doesn't
> necessarilyl�solve�the�AV�problem.
> As�stated�on�the�bug,�many�AV�software�packages�just�scan�for
> significant�bytes,�and�these�might�already�be�the�subject�or�body
> or�other�structure�(e.g.�attachment�filename)�of�the�email�(e.g.
> "Want�to�see�pictures�of�...?",�"filename=foobar.wav.exe").�In
> other�words,�you�might�still�end�up�with�all�your�mails�deleted
> and�only�the�attachments�(maybe�even�incl.�the�virus)�surviving.
I don't believe this to be true. The user I had reported in 116443 had a
bunch of viruses in his archived mail. These were only discovered when I
converted this user on over to Eudora. During the conversion process
attachments were stripped from the E-Mail and stored to the hard drive,
thus triggering an event for the AV software to start taking notice. It
didn't care about the attachments prior to an attempt to save to disk.
The order of how Eudora handles new E-Mail is critical to not conflicting
with AV software. The new mail appears to be processed prior to actually
being stored on the hard drive. The message body is written to it's InBox,
then the attachment is written to an attach folder. At no point is the
body and an attachment within the same file on the hard drive.
How well does this work? Since converting over to Eudora this user has
received at least 5 Sircam infected mails. The AV software properly
removed each attachment, and left the message body intact immediately after
downloading the infected mail. Sircam certainly has signature text in it,
so this should be a fair example. At no time did the AV app target the
text within the body as you would suggest happens.
It would be interesting to find out if an app that handles attachments like
Eudora has suffered data loss due to AV software. I find that scenario
highly unlikely, but I am easily swayed by evidence to the contrary.
> IMO, if the AV software brutally deletes all mails, that's their
> unexcusable fault and we can't do much about it, esp. if it means such
> drastic changes.
I fully realize what I'm suggesting is a drastic change, and I don't do so
lightly. Watching a user's InBox and 2 other folders get wiped clean twice
in less than a week prompted me to bring this up in the first place.
Unless I can be certain of a specific AV app working with Mozilla properly
I can't advocate it's use. We know of two major apps that have difficulty,
but we don't know if others have similar problems. What's worse, is that
we don't know of any AV apps that are definitely not going to cause data
loss. Do we?
> I am much more worried about bug 109249.
Agreed. It is also very related to what actually triggers the AV software
to take action against a user's InBox.
In the case of BadTrans HTML triggers a save dialog box to pop up in order
to attempt to get the user to put that file on their hard drive. The
attempt to save triggers the AV software to take notice. At this moment in
time the only place the file exists is embedded in the message, stored in
the mailbox being viewed. The AV app attempts to circumvent this by
removing the offending file, being the InBox itself.
One quick, simple, and necessary anyway approach to correct this would be
to stop Mozilla from executing ANYTHING from within E-Mail. No pop up
iframe html tags, no javascript, no Java, no anything that isn't related to
simply displaying a message. Reading E-Mail should be a 100% passive
experience.
This still leaves the door open to possible AV software going after the
wrong thing though. For this I only see the following options...
1. Notify at least e-Secure and Norton and get them to correct their bugs.
a) Make sure that every user out there is running an updated versions
with these bug fixes.
2. Identify which AV apps will work with Mozilla properly and notify users
who these vendors are.
3. Change how Mozilla presents attachments to all AV apps.
None of the above are attractive options. I'd love to see others added to
this list. What I hope I never have to see again is a user's InBox wiped
out by software I recommended.
Later on,
--
"Outside of a dog, a book is man's best friend. Inside of a dog, it's too
dark to read."
- Groucho Marx
