Style wechseln: ?

Für diese Funktion muß JavaScript aktiviert sein.

wechseln zur deutschen VersionX-Mozilla-Status(2) explained :: Mozilla-Features :: Mozilla vs Antivirus :: Mozilla-Links :: Mozilla-Applications


sending corrupt messages
lacking encryption
retrieving hangs
retrieving hangs 2
deleted messages
can't log in
Conclusion

Following spam viruses are arguably the biggest e-mail plague and are top when seen from the aspect of dangerousness. So protection against viruses is quite important and users are busy installing tools against this menace.
Unfortunately these tools aren't the great redeemers but also fairly often the cause of problems. In the last time calls for help cumulate in the Usenet and Bugzilla because of problems in getting and sending messages or because of deleted inboxen. The bad thing about that is, that mainly Mozilla/Thunderbird is being blamed for the trouble.

Of course, also Mozilla/Thunderbird has and makes its problems (either because of an own bug or due to a non standards-compliant mailserver). But this page is about problems in combination with an installed antivirus software.

Until now I spotted five groups of problems, five have a entry in Bugzilla. Here are the numbers (dupes aren't listed): Bug 235589, Bug 235401, Bug 224900, Bug 220225 and Bug 259840.

1. sending corrupt messages

Effect one is caused by Panda Antivirus for example. According the first bug report, a fix is available for the scanner, but prior versions or other applications might still lead to the same symptoms.

For any reason a null byte (0x00) is being inserted at the end of an outgoing mail. That's not allowed by the specification and servers or clients can choke on it. Anything can happen, from the refusal through your ISP's mail server to accept the mail to an error message of the receiving mail client.

2. lacking encryption

Problem two is triggered e.g. by Norton Antivirus and can lead to various effects. So it's e.g. impossible to establish an encrypted connection to the SMTP server if the STARTTLS command is used.

That can produce an error message saying that Mozilla couldn't connect to the server. Or a connection is made, but the server denies any further command with the notification that you should log in first, because Mozilla couldn't log in. Or accepting the mail is refused with “relaying denied” (again because not logged in).

In any case the cause is, that the anti virus software sees threatened its mission, that is to protect the world from viruses from your computer. Looking in encrypted connections and scan them isn't possible, hence it prevents establishing an encrypted connection!

The steps are: The connection is established unencrypted first and the server advertiseses it's ability to handle the STARTTLS command. The client now sends this command and after a positive response from the server they switch to an encrypted link.
One variety is, that the AV software simply deletes the line with “STARTTLS” from the list of the servers abilities. A second variety is to fake a server error in response to the clients STARTTLS command. The effect is the same: it's not possible to establish a TLS connection. The AV software retains control, but the user is left out in the cold.

3. retrieving hangs

The third problem is being caused by corrupt incoming mails in combination with McAfee VirusScan. The corrupt mails (mostly Spam) contain null bytes (see above), shortly before the message end in the majority of cases.

While Mozilla is immune against this since a few months, McAfees VS isn't able to cope with these bytes. The result is, the scanner hangs at the null byte and doesn't hand over the rest of the mail (with the bytes necessary to detect the end of the message) to the client. So the client waits “forever” for more data and appears to hang.

4. retrieving hangs 2

The fourth problem is caused by a corrupt mail in combination with Norton Antivirus. These corrupt mails don't have CRLF (0x0d0a) as line terminators but only a LF (0x0a). This isn't allowed according to RFC 2821.

Mozilla isn't bothered by this too, but NAV seems to get confused so much that nothing of the message comes through. After the initial response “+OK Now here's the mail” nothing followes. Again with the effect that the client waits “forever” for more data and appears to hang.

5. deleted messages

The fifth problem are disappeared mailboxes. That can be traced back to the fact that Mozilla (like the most other e-mail clients) stores mails in the mbox format, i.e. all mails in one file. Has the virus scanner been configured to scan files for viruses and to delete infected ones, it happens once in a while that the whole mail file gets deleted. And that's it.

The problem is increased by the fact that Mozilla doesn't remove a mail from the file when it gets deleted, but sets a corresponding flag (see X-Mozilla-Status explained). Thus the viruses in attachments are kept on disk too (until the mailbox is being compacted). Although they're inactive and totally harmless, the virus scanner does its job.

6. can't log in

This problem is caused by a bad behaviour (won't call it bug) of Norton Antivirus (at least it's only known from this app) in connection with a buggy mail server.

The specs for POP3 and SMTP allow one answer per command. But some servers send two (or more), e.g.
-ERR invalid user or password
-ERR unsupported SASL authentication method
or
421 out of memory (#4.3.0)
535 auth failure
Since Bug 234421 we've a workaround in Mozilla and Thunderbird. This just clears our receive buffer before sending the next command, so the second error message won't be handled as answer to that command.

This works for all servers that are fast enough to send the second response before we're ready to issue the next command. And at this point NAV comes into play. It sits between the network socket and Mozilla/TB. And it only delivers one line at a time instead all available data as it would be the situation without NAV. So the code that clears the buffer doesn't help because the second answers isn't in the buffer at this time.

I don't call this NAV behaviour “bug” since it doesn't violate any spec. Also it's no problem itself but in conjunction with a bad server (another example is IMail mail server before version 8.14, Bug 258077) it is. BTW, AFAIK no other AV software does this and IMHO no application should change the communication if it doesn't for a real reason (e.g. attack from outside or virus detected in the data stream).

Conclusion

Since the user of an antivirus software doesn't expect the data stream getting modified by their guardian, they put all the blame on the mail client. But now you know it better and you should investigate in all directions.
Shut down the antivirus complete and totally—not simply disable it or set it to inactive. That's because scanning of outgoing messages stays active although it has been “deactivated” e.g in Norton-AV.

If the problem still occurs after this step, it's maybe really the clients fault. If not, it likely was the scanner and you should put further investigations in what option causes the trouble.

[arrow up] hoch

last modified 2009-10-23
© Christian Eyrich
main page | webmaster