I just did some tracing of the file activity involved in the sending of the message to which I referred in my post above.
The message is apparently sent in fairly large blocks by the mail client. These blocks are redirected to Avast which files them to a temporary
file. Attachments increase in size when they are encoded so that filing took
8 seconds.
Then for 151 seconds Avast was reading the file in 4k chunks and then, I assume sending each 4k chunk on to the network (and perhaps waiting for an acknowledgement).
On reading in the same message back in the network delivers in fairly large chunks which are passed to Avast and filed. Avast then reads the file and scans it in 4K chunks before it is passed to the mail client. since that is internal to the machine it is much faster than outbound and took only 5 seconds for the same message just sent out.
It looks to me as though the Avast folks should look to making the transmission of the scanned message much more like the transmission from the mail client, ie much fewer and larger blocks.
Since this message can be read and scanned in 5 seconds Avast can do a much better job of making the transmission time a closer approximation of that which can be done by the client when Avast is not involved.
Upon further reflection - does using an SMTP port number that is NOT 25 mean that no scanning is done on the outbound file regardless of the box being checked?
Harvey, I was trying to read the thread but it’s too long for me now… I start late…
Well, if you use any other port than the default ones, you should set them into the ‘Redirect’ tab of the Internet Mail provider settings (or MS Outlook plugin). Can you follow me? Do you need help in other specific point?
in the redirect ports tab, if port 25 is specified and the Internet Mail Provider is active then the outbound mail traffic is still intercepted by Avast. Whether that traffic is then scanned is determined by the “scan outbound mail” checkbox in the SMTP case.
This is true for all the intercept ports in Internet Mail Provider. Should one wish to have the provider active and “opt out” of having a particular class of traffic intercepted (for example NNTP) then it is necessary to ensure the the real port used is not specified to Avast.
At present, I believe that you have identified a real performance flaw in the SMTP scanning of Avast. I shall be interested to hear the response from the Avast team.
In the great scheme of things though, having my email take a bit longer to be scanned outbound I can live with. Especially at the price point I pay for Avast which is, I believe, a great product.
I am not a bigot on these products. If you check the e-mail forum of AVG you will find a “sticky” under my userid. I did test it a while back and I got my e-mail to be scanned.
I honestly believe that the email scanning is easier in Avast. On one thing I regret I cannot defer, the support in this forum and the direct participation and assistance of the Avast development team cannot be matched by AVG.
The purpose of the AVG support forums is the same as those of Avast and I have made a contribution there.
However, if you have never visited then I’m sure your faith is well justified, despite the fact that participation in the AVG forums by the developers is very rare.
your comment is somewhat disengenuous if you read the thread. He wanted to conduct a test with Avast not intercepting the traffic, I told him how to do this and I made it very clear that this was a method of not intercepting SMTP traffic.
Perhaps you can come back and advise us of the team’s finding on the basic point of this thread … that this user has identified a performance flaw in the way Avast transmits the SMTP traffic after scanning the data.
Will you also confirm (truth in advertising) that selecting the “do not scan outgoing messages” does not stop Avast from intercepting the traffic on the port specified or defaulted in SMTP in the Redirects tab?
Sorry, perhaps I did not understood it correctly. I though this is being offered a solution to speed the whole process not as a diagnostic measure.
Anyway, unchecking the checkbox “Scan outbound mail” on SMTP tab has exactly the same effect - it does stop avast from intercepting the traffic on the particular port completely. Slightly different behavior is in WebShield, when with unchecked “Enable Web Scanning” checkbox it still redirects the traffic and may do the page blocking if configured.
one can think that hgratt is not entirely aware of the fact, that turning outbond scanning on or off with the changed redirected port makes no real difference since it is (for all practical considerations) turned OFF completely.
you are the professional and I but the humble user and, honestly, it saddens me to disagree with you here.
However , I just clicked off the “scan outgoing mail” and I monitored the file activity in the the temporary Avast folder.
Avast created exactly the same temporary file and read exactly the same temporary file as when I had “scan outgoing mail” selected for exactly the same message as I reported earlier in this thread.
Now please tell me again that it does not intercept the traffic.
Alan,
the redirected port is unregistered when the outbound scanning is turned off. The service remains running but it stops to listen on that specific TCP port on localhost (12025 in this case). You can verify this but running netstat -a or TCPView.
Perhaps a concession is in order that we may both be correct in a way.
I have just conducted the test again.
When I click off the “scan outgoing mail” then port 12025 ceases to be listening.
It does not remove the intercept on port 25.
If I then terminate and start (again) the Internet Mail Provider then following the restart there is no intercept on port 25 and the temporary files associated with intercepted mail are not created.
I will happily agree that de-selecting the “scan outbound mail” option will stop intercepting the SMTP stream (ok - I admit I do think it should be with the proviso “but stop and restart the provider” to be sure).
However, I do hope that the team will give serious attention to the points raised on the efficiency of the onward transmission of the scanned SMTP stream.
with respect and thanks to Lukas and all other participants,
Alan
who will now (try to) leave this one up to the Avast team.
I made some tests on our connection, sending 5,6MB mail with PDF attachment.
Avast disabled: 4 s
Avast enabled: 7 s
It is no doubtly a slowdown, but the times are so small I don’t this this is a percentual slowdown of 75%. However Vojtech is aware of this thread, perhaps he’ll be able to detect some performance issues in the code.
On contrary. If there is a performance problem, it would appear on high speed networks more loudly. On dial-up even poorly written server is capable of serving data at 5kb/s, however serving at 100 Mbps is a completely different story.
O.K, I did some more testing using a stop watch to verify the speeds that NetPerSec was reporting. NetPerSec IS reporting the correct speeds - transmitted file size was about 2.2 MB.
Based on input from this thread, I have compared 3 scenarios (all standard ports are enabled):
Avast uninstalled - I pretty much get my full upload speeds (90-92KBS), 24 seconds
Avast installed, outbound scanning on - about 40KBS, 59 seconds
Avast installed, outbound scanning off - about 81-83KBS, 27 seconds
FWIW, NAV always gave me the 90-92KBS speeds after it scanned any attached files.
So again, as indicated in this thread, is this a significant performance problem and if so, how long does it typically take to get something like this fixed?
