Avast WEBforum
Consumer Products => Avast Free Antivirus / Premium Security (legacy Pro Antivirus, Internet Security, Premier) => Topic started by: Alexzorg on November 03, 2010, 06:17:49 PM
-
Good day. I have spent 6 hours (!) to find out what happening.
The problem: I use "The Bat!" mail program with pop3 protocol mail delivery. Sisnce 27 or 28-th, October, 2010 the mail delivery had been stoped for server pop.i.ua. After long correspondence with http://i.ua Support Team it became obvious that the problem is in Mail Shield module of Avast Antivirus.
when Mail Shield is active then after executing command "telnet pop.i.ua 110" the -ERR message is received:
[00:06:20] C: Connected to pop.i.ua, port 110
[00:06:20] S: -ERR
[00:06:21] C: Connected to pop.i.ua, port 110
[00:06:22] S: -ERR
[00:07:30] C: Connected to pop.i.ua, port 110
[00:07:30] S: -ERR
after shutting this shields down, the normal "+OK POP3 server ready <839277231.1288804305@web01.mi6.kiev.ua>" message is received. I have these dumped IP packets, if it is needed.
I am absolutely sure that this behaviout is because of some database update (or program update). Quite similar OPO3 server "ua.fm" is OK, the problem IS only with "pop.i.ua". Please, make a fix for this!
-
Do these accounts use/require SSL/TLS secure connections for POP3 ?
If so does the account settings in the Bat show they should use SSL/TLS ?
If so then you would need to uncheck that option in the Bat settings.
If not then check the Mail Shield, Expert Settings, SSL Accounts and check the Encryption column for that account and ensure that it is set to None.
-
The main question: did you install a program update on that day?
The Mail Shield doesn't contain any such functionality (blocking a server), and it doesn't take anything from the database updates (except for non-redirected IPs, but that didn't change for more than a month).
When you write "after shutting this shields down", do you mean you stopped the Mail Shield only, or did you stop all the real-time shields?
-
When i use context menu Rightmouse click on avast icon, then avast! shields control -> Disable for 1 hour the problem still was, thats why i spent not 5 minutes , but maybe 6 hours of tracing this down. Then I use Administrative tools in Windows XP SP3 and manually stop the Avast service, after this pop3 server works properly.
Then I open avast user interface and individually stopped mail shield. Sucsess! then enabled shield but uncheck "scan inbound messages". Pop3 server works. Then go to expert, add pop.i.ua , the same seting that are for working server ua.fm and still error. but telnet now writes another message:
----------------------------
telnet pop.i.ua 110
--------------------------------------------------------------------------------------
+OK avast! POP3 proxy ready. 20:33
q
-ERR
Connection to host lost.
-----------------------------------------------------------------------------------------
i pressed "q" - that command exits telnet session.
for ua.fm this looks different:
telnet ua.fm 110
-----------------------------------------------
+OK POP3 server ready <1405899064.1288809364@st07.mi6.kiev.ua> 20:36
q
+OK bye-bye
Connection to host lost.
-----------------------------------------------------
-
Another thing about this...
I did the full backup of drive C: (every cluster) at 15.09.2010 Until 28.10.2010 everything was ok with mail delivery. Then the problem starts. Yesterday I restore entire C: drive from that image (15.09.2010). But the problem was! Avast did automatic update. How can this be explained? No hardware changes was performed since 15.09.2010. All system files, their configuration , everything was returned to the state at 15.09.2010, the only thing that changes was avast update. Thats why I think that problem is because of some update. Because it is automatic it is difficult to trace this changes.
-
Do these accounts use/require SSL/TLS secure connections for POP3 ?
No
If so does the account settings in the Bat show they should use SSL/TLS ?
the settings in the Bat are OK, I tested the connection without Bat additionally with the same result: "-ERR"
If so then you would need to uncheck that option in the Bat settings.
If not then check the Mail Shield, Expert Settings, SSL Accounts and check the Encryption column for that account and ensure that it is set to None.
every combination was tryed. here is another "reference" server ua.fm from the same mail team, the same settings but different domain name. in the case of pop.i.ua is error, and in the case of ua.fm everything is ok with the same settings. Mail support team said that no firewall or filer is from their side, and they even fing logs of my connection from the server side:
02.11 19:21:04 [W] 0xb7362230 +OK POP3 server ready <993810615.1288718464@web01.mi6.kiev.ua>
02.11 19:21:04 [W] 0xb7362230 CAPA
02.11 19:21:04 [W] 0xb7362230 +OK
02.11 19:21:04 [E] 0xb7362230 Cannot read cmd
02.11 19:21:04 [E] 0xb7362230 CAPA
02.11 19:21:04 [E] Recive bad status
-
Hopefully Igor can get back to this as it is beyond my knowledge as an avast user like yourself.
I don't know if there is a behind the scenes email server provided by pop.i.ua that is redirected to server ua.fm. I have seen this in the forums where people have reported that there was another account/domain name in the Mail Shield SSL Accounts section and it transpires that they actually provide the email service for the other account.
-
yes, maybe this problem is quite complicated, i think this needs the developer level of knowledge about how the packets flow inside Avast. Was there a program update 27-28 of october that could affect this? I thought that pop.i.ua was in blacklist, but if no, then maybe this is some sort of program bug.
here is the packet flow (screens):
-
second packet. Here You can see the welcome message from pop server. But it is NOT delivered to application. Analyzing server side packets, client answers to server with CAPA command (http://www.faqs.org/rfcs/rfc2449.html):
Discussion:
An -ERR response indicates the capability command is not
implemented and the client will have to probe for
-
third
-
forth: this is response to CAPA command with list of capabilities. OK, but tlnet pop.i.ua MUST NOT send CAPA command!
so, for some reason,being the third point in the packet flow Avast sends CAPA command without permission of application.
-
last
-
No program updates for a while (build 5.0.677) as they are working on version 5.1, the only thing that has been happening regular basis are the virus signatures and engine updates and what Igor mentioned in his post.
-
What are these engine updates? Can they affect this?
-
The engines are the scanning processes I believe, but I don't believe they would have that effect. Or I would have thought that this would show across all accounts and we would also see occurrences of the problem in the forums and that hasn't been the case so far.
-
Alexzorg--
I have just opened another thread addressing the same problem with my POP3 server being blocked my the avast! Mail Shield. My server only began to experience the block yesterday afternoon. Let's hope they start to believe they have a real problem.
-
Unfortunetely i am not professional hacker or debugger or net programmer, so i cannot do more then i did trying to sink into this problem, but i DO believe that this is the program bug with Avast. I'll try to investigate this in another locations, why does this affected only my computer? I am using Agnitum Outpost as firewall. there are a lot of possible influences on this...
-
Unfortunetely i am not professional hacker or debugger or net programmer...
Well, before I retired I was a professional software developer with some 35 years experience chasing program bugs. I am satisfied that I definitely eliminated everything other than avast! Mail Shield as being the cause of blocking on my POP3 server.
-
Oh! my respect!
i think that without source code it is too hard to track the problem...
-
Hello,
the mail scanner in the current version may rarely have problems with some firewalls. It will be solved in the next update and I can also provide the fixed ashMaiSv.dll file.
Sorry for the trouble.