Author Topic: Avast 4.6.652 Email Problem  (Read 42239 times)

0 Members and 1 Guest are viewing this topic.

hgratt

  • Guest
Re: Avast 4.6.652 Email Problem
« Reply #45 on: May 17, 2005, 10:19:49 PM »
Hgratt, have you performed the test with ZoneAlarm completely disabled? (right click on the icon and choose exit)
Thanks.
L.



Yes, several times. The results are the same.

Harvey

Offline alanrf

  • Avast Evangelist
  • Massive Poster
  • ***
  • Posts: 3870
  • Just an avast user
Re: Avast 4.6.652 Email Problem
« Reply #46 on: May 17, 2005, 10:42:42 PM »
I just conducted my tests again this time with ZoneAlarm turned off.

I confirm Harvey's findings.  My are the same as I reported yesterday.

Just one extra test I conducted.

I paused the Internet Mail Provider.  It is my understanding that pausing the provider still intercepts the mail but does not scan it.  So it is just receiving the mail from the client and then retransmitting it to the network.

Result: the delay was exactly the same as when the provider is scanning.






sded

  • Guest
Re: Avast 4.6.652 Email Problem
« Reply #47 on: May 17, 2005, 11:36:34 PM »
Another data point.  Since I encrypt all email (SSL/TLS) and normally scan with avast! anyway, using Stunnel for the encryption/decryption, compared uploading messages with/without avast!, but still using TLS.  Setup is 384kbps DSL uplink, XP with SP2, Thunderbird mail client, Sygate PF.  Total message size as received was 5.3MB, including a .kap (map) attachment.  With avast!/Stunnel took 176 sec (30KB/sec) to upload; without avast!, using TLS in TB, took 150sec (35KB/sec).  Max achievable link would be about 40KB/sec without encryption.  So even with encryption, I am not seeing the scanning overhead of the others.      Renamed the .kap to an .exe, and it took 195 seconds, including waiting for a warning message from avast that it was a suspicious file extension.  Tried again with a real .exe about the right size, actually ran slightly faster (more efficient scanning of known types?).  So what does all this mean?   Seems like there is nothing inherent in the flow through avast! that causes huge time discrepancies, at least with XP.    Results are entirely satisfactory and about as expected.  Message takes a lot longer oubound than inbound, but this is normal because the link is assymetric in speed.  Unable to repeat other results; do not see an avast! problem in this area.  Zone Alarm an issue? (vs Sygate).  Use of W98 and issue?  Faster uplink an issue?  (93kBps or 750kbps is much faster than most).  Something else to chew on.

Offline alanrf

  • Avast Evangelist
  • Massive Poster
  • ***
  • Posts: 3870
  • Just an avast user
Re: Avast 4.6.652 Email Problem
« Reply #48 on: May 18, 2005, 12:08:32 AM »
sded,

interesting observations. 

Both Harvey and I are on Win XP Pro SP2.  Both of us use ZoneAlarm as the firewall.  Both of us have reported here that the results are unchanged when ZoneAlarm is deactivated.

I, like you, use Thunderbird and, like you, I have a 384Kbps upload speed but I am using the same cable service provider as Harvey even though he has a much faster uplink.

 We both experience a slowdown when the outgoing mail is interecepted (whether it is actually scanned or not in my testing).  It does seem that Harvey, with his much faster uplink, encounters a greater degree of slowdown than I do. 

So, Win98 is not an issue, nor is the Firewall. 

Unfortunately I do not have an account similar to yours that I can test mimicking your encrypted configuration as an apples to apples test. 

hgratt

  • Guest
Re: Avast 4.6.652 Email Problem
« Reply #49 on: May 18, 2005, 12:24:47 AM »
Another data point.  Since I encrypt all email (SSL/TLS) and normally scan with avast! anyway, using Stunnel for the encryption/decryption, compared uploading messages with/without avast!, but still using TLS.  Setup is 384kbps DSL uplink, XP with SP2, Thunderbird mail client, Sygate PF.  Total message size as received was 5.3MB, including a .kap (map) attachment.  With avast!/Stunnel took 176 sec (30KB/sec) to upload; without avast!, using TLS in TB, took 150sec (35KB/sec).  Max achievable link would be about 40KB/sec without encryption.  So even with encryption, I am not seeing the scanning overhead of the others.      Renamed the .kap to an .exe, and it took 195 seconds, including waiting for a warning message from avast that it was a suspicious file extension.  Tried again with a real .exe about the right size, actually ran slightly faster (more efficient scanning of known types?).  So what does all this mean?   Seems like there is nothing inherent in the flow through avast! that causes huge time discrepancies, at least with XP.    Results are entirely satisfactory and about as expected.  Message takes a lot longer oubound than inbound, but this is normal because the link is assymetric in speed.  Unable to repeat other results; do not see an avast! problem in this area.  Zone Alarm an issue? (vs Sygate).  Use of W98 and issue?  Faster uplink an issue?  (93kBps or 750kbps is much faster than most).  Something else to chew on.

My upload speed is 768Kbits/sec or about 96KBS. When I have scanning turned on, my upload speed averages around 35 to 40KBS which is just about equal to your max upload speed. It may be that you don't see the effect since your scanning transfer speed is around the maximum upload speed that your ISP allows.

On the other hand, since I should see about 90-92KBS, I do see the effect.

Harvey
« Last Edit: May 18, 2005, 04:20:00 AM by hgratt »

sded

  • Guest
Re: Avast 4.6.652 Email Problem
« Reply #50 on: May 18, 2005, 12:32:53 AM »
Mine is definitely scanned, I see it in avast!  And get messages saying .exe attachments are suspicious.  Zone Alarm is still a concern because of all of the avast! incompatibilities earlier-and because it is hard to kill.  The encryption is actually inline with the scanning-TB to avast! unencrypted, scanned there, then encrypted in Stunnel and sent to the smtp server.  Both TB and avast! are unaware of the encrypted link, and even with the additional overhead all works fine.  Are either of you using OE?  It has a very nice logging capability under tools/options/maintenance that will log all the server commands and perhaps provide some insight.  Log will be at documents and settings/yourname/local settings/application data/identities/{garbage}/microsoft/outlook express/smtp.log with all the time stamped server traffic.

hgratt

  • Guest
Re: Avast 4.6.652 Email Problem
« Reply #51 on: May 18, 2005, 05:03:48 AM »
Some more data points. I've now noticed that as time goes by with my browser open and Avast running, my upload speeds drop back down to low values even though scanning is disabled.

Also, if I send large files via Comcast webmail, I get full upload speed - around 92-94 KBS!

I can only conclude that email sending is, in general, broken in Avast 4.6. 

I will soon be able to get fiber optic cable with 2 mps upload speeds - I sure hope I don't have to go back to NAV in order to make use of the upload speed!

Harvey

Offline alanrf

  • Avast Evangelist
  • Massive Poster
  • ***
  • Posts: 3870
  • Just an avast user
Re: Avast 4.6.652 Email Problem
« Reply #52 on: May 18, 2005, 06:56:44 AM »
Harvey,

The figures posted by sded indicate that he does not encounter the problem though I wish he would do us both the favor of assuming we are capable of disabling a firewall. 

The timings posted by Lukas earlier today (while they may have a huge upload capacity - given the numbers posted) indicate that even for them there is a very clear deterioration in the sending capacity with Avast intercepting outgoing mail.  This is in line with the information we have supplied to Avast.

My experience with Avast has been that a problem is often not encountered by all users, the Avast team seem to accept that and work on the problem.  I do not, for a moment, believe that the Avast team is discounting this issue and I think it only fair to allow them time pursue their investigations.

As you know from your own experience not all anti-virus solutions are as easy to implement as Avast.   I have confidence that you will not need to return to NAV.

Alan