Strange problems caused by strange formatted mails

Today I had quite a strange problem with downloading mail and the question is if Avast pro behaved correctly (due to the strangeness of the mail) or behaved in an erroneous way due a situation not previewed by design.

Various clients of mine began this morning to tell me that they could not download new mails anymore. They all have Avast pro and the same ISP (different virtual mailboxes of the same domain). The clients used were also of different types (Eudora and Outlook Express) and other virtual mailboxes of the same domain were instead perfectly working and downloading mail as usual.

By checking the accounts with the use of an http client it was possible to see and interact with the new mails, but it was not possible to download them using the cited mail clients. They could send mail as usual, but not dl from the pop server.

Eudora gave a quite strange error: quit error when checking mail (Dominant, Shutting down POP connection, QUIT Error reading from network Cause: Connection closed by foreign CODE 0). There were 14 messages to download but the connection stopped immediately after trying to download them.

Reinstalling Eudora with fresh new and correct parameters didn’t change the situation.
So I tried creating the same account on an Outlook Express client, the result was the same but the error code gave some more elements to investigate:
Your server has unexpectedly terminated the connection. Possible causes for this include server problems, network problems, or a long period of inactivity. Account. account name, Server: ‘server name’, Protocol: POP3, Server Response: ‘+OK’, Port: 110, Secure(SSL): No, Error Number: 0x800ccc0f

Searching on MS knowledge base I found the article 815314, and I could exclude that the problem depended on the firewall or the antivirus (because they are the same for different virtual mailboxes of the same ISP: some are functioning, the others not).

I contacted the ISP support, they made me trying downloading while logging and concluded, quite easily indeed, that from the server side all was normal (because they saw the negotiation between client and server and the server responded correctly that I could start downloading).
They made me try another experiment: a Telnet connection to the virtual pop. The ISP support concluded (erroneously, as we will see) that, as long I could login and browse the mail by telnet interface everything was OK (it is obviously wrong from a logic point of view, because I can also simply browse the mail by http interface, but I still cannot DOWNLOAD those mails by a mail client).

Don’t knowing what to do else, at one point I completely disabled Avast Pro and the mail client began to download the mail without problems (both Eudora and Outlook). I enabled Avast once again, sent some test mails to the virtual account not functioning before and the mail client still dled without any problem.

But looking at the dled mails i noticed that some of them had a very strange aspect: no header, no subject, no of nothing, completely EMPTY mails. By connecting again with Telnet interface i could list them and they had dimension… 0 bytes!!! Of course they were not visible using http interface.

When speaking with the ISP support I first asked them if they had some problems with the virtual mailboxes, and they answered that there was a problem in the last days so that a server generated some EMPTY mails, but that the problem was over now.
The problem was over, but the effects NOT!

By carefully reading the cited MS article 815314, and excluding all obviously wrong explanations, the only one plausible is number 8:
Delete suspicious messages from your mailbox
If there is a damaged message in your mailbox, you can resolve this by doing one of the following: • Contact your ISP and ask them to delete any suspicious e-mail.

So, as I had several other virtual accounts to unlock, I now tried my (and MS’s) theory. I Left Avast pro running, connected to the virtual pop by Telnet interface, list and delete the mails with size of 0 bytes, logged out, then launch a mail client (at pleasure) and… the mails were again dling with no problems!
Of course I had some big problems in finding the 0 bytes mails with an account (ahem, the one of the Boss…!) that listed more than 1000 mails! (I had to dl and install a Telnet specialized emulation SW, as the XP 2K Telnet interface sucks).

Finally, it’s clear I had a heavy quarrel with the ISP support personnel, as they easily concluded that the problem was mine and I had to solve it myself (fortunately I’m used to this approach since 1980 at least), but the question remain open:

What happens when Avast Pro checks incoming mails and finds some 0 bytes messages? It seems it stops the connection between client and server, instead of passing some sort of comprehensible error message to both sides. Is this correct and done by design?

Thanks very much

Roberto Balzan

Any of the Avast Designers and/or Moderator could gently give me an answer? Because I’m obviously quite dubious on future use of Avast Pro, otherwise.

Thanks

Roberto Balzan

I am convinced by personal experience and contributions in this forum from avast team members that there is no difference in the processing of email messages by the Internet Mail provider between the avast Home and Pro versions. (We can discuss my view of this outside this thread if you care to).

It might be well to use the services of avast to log a much finer level of activity on the message connection to try to identify further the details of this problem. Would you care to do so?

I am convinced by personal experience and contributions in this forum from avast team members that there is no difference in the processing of email messages by the Internet Mail provider between the avast Home and Pro versions. (We can discuss my view of this outside this thread if you care to).

I was implicitly comparing Avast pro to other commercial virus scanners, and their behavior in cases like this (as a matter of fact the ISP personnel asked me “What virus scanner are you using”), not to the free version of Avast: as I have to choose a professional virus scanner for my clients, I try to minimize the problems that the virus scanner can cause to my clients (and so to me).

It might be well to use the services of avast to log a much finer level of activity on the message connection to try to identify further the details of this problem. Would you care to do so?

As far as I know the problem is definitely solved (aka: I deleted via telnet all the ‘null’ mails from my clients accounts). I think I haven’t got the means to simulate the problem once again (as far as I know), while I think that this should be matter of investigation for the Avast team of designers/testers, and they also should have the wright means to emulate the described events.
Of course they could decide as well that the problem doesn’t deserve to be investigated anymore, considered how much rare it is.

Roberto Balzan

I am sorry I did not make myself clearer.

I was highlighting that there is no difference in the mail scanning by avast versions because were the problem you reported more common we would most likely have seen it reported by avast home version users too.

Some of the folks I support (who have avast scanning their mails) have reported receiving empty emails periodically and I have seen them too but without any problems of having them scanned by avast. However, an empty email may not be usually be reported by other servers as length 0 (which it should not) so I agree with your view that this is something for the avast team to look at.

I have also seen empty emails, most notable I see them in MailWasher Pro my anti-spam and I have this scan my email at server level (it only downloads a limited number of lines to determine spam) and this I have ignored by the email scanner (editing the avast4.ini file), so there is no interference/interaction with avast’s scanners, but I still get a few empty emails every so often.

I do not want to appear too partisan here but I believe that the the OP’s ISP was more at fault than avast.

I do not want to let avast off the hook … it appears that a 0/null message length (however improper under the POP3 protocol) should be handled by avast - if it is not already. At the same time the ISP should have cleaned up the known error condition and made sure it did not report invalid message lengths of 0/null from the server to the client. As the OP has already suggested this a rather rare circumstance.

As for the Original Poster, as a supporter of other avast users I too want a product that will not inconvenience my users. I believe the OP has a more compelling case since this is a professional environment while my support to my users is pro bono. If fault there be in this case with avast I suggest it is a rare condition and that the avast Professional product continues to be an excellent choice.

I do not want to appear too partisan here but I believe that the the OP's ISP was more at fault than avast.

Got it perfectly! I completely agree.

As a matter of fact I explained to my client the incident (and its quite long duration, nearly six hours) by saying that:
a) The ISP acted quite incorrectly not deleting all the 0 lenght spurious email, after having created them
b) I want to file a formal and documented complain against the ISP and the way they acted (highly unprofessionally, at last brutally telling me that “it was a problem of mine”), but first
c) I want to be sure that even in the most absurd situation (the check of a 0 lenght mail) our antivirus choice was not co-responsible in generating the problem.

Roberto Balzan