Author Topic: Mac beta and mail shield  (Read 6505 times)

0 Members and 1 Guest are viewing this topic.

Offline sylvie75012

  • Newbie
  • *
  • Posts: 1
Mac beta and mail shield
« on: November 27, 2011, 11:20:57 AM »
Hello,

I was forced to desactivate Mac Avast's mail shield because it was preventing me from receiving my mail (Mac mail software). I could send mails, but no longer received.

Offline tumic

  • Moderator
  • Advanced Poster
  • *
  • Posts: 724
Re: Mac beta and mail shield
« Reply #1 on: November 28, 2011, 11:53:50 AM »
Hello,
We need a little bit more information to help you or eventually fix something. At least we need to know:
  • What version of avast! do you have?
  • What error do you get from your mail client?
  • Do you use POP3 or IMAP?
  • Are there any interesting messages in the system log (/var/log/system.log)
  • What mailserver are you connecting to?

Offline Fargo

  • Newbie
  • *
  • Posts: 1
Re: Mac beta and mail shield
« Reply #2 on: November 28, 2011, 08:36:13 PM »
Same problem with "Mail" program: incomming emails are blocked without any messages. We use POP3 account.
Avast35600 Beta

Offline tumic

  • Moderator
  • Advanced Poster
  • *
  • Posts: 724
Re: Mac beta and mail shield
« Reply #3 on: November 29, 2011, 10:56:16 AM »
Same problem with "Mail" program: incomming emails are blocked without any messages. We use POP3 account.
Avast35600 Beta

  • Are there any interesting messages in the system log (/var/log/system.log)
  • What mailserver are you connecting to?



Offline bakasan39

  • Newbie
  • *
  • Posts: 1
Re: Mac beta and mail shield
« Reply #4 on: December 02, 2011, 01:15:00 AM »
Same issue here..can only use Apple Mail if I deactivate Avast Mail Protection. Most unfortunate..as I have come to trust Avast.

Offline mfortin

  • Newbie
  • *
  • Posts: 1
Re: Mac beta and mail shield
« Reply #5 on: December 04, 2011, 02:36:11 AM »
Hello,
I have the same problem using Avast 35600 Beta.
I have 3 mail account.  I am using Mail from Mac.  Two of my account are working just fine but not the 3rd one.
The mail service that is not working is using a POP server (globetotter.net).
I do not know how to look at the system log (/var/log/system.log) but if I deactivate the mail shield, then all the 3 account are working fine.
Regards

Offline SamEdge

  • Newbie
  • *
  • Posts: 4
Re: Mac beta and mail shield
« Reply #6 on: December 04, 2011, 05:46:23 AM »
Having similar problems, again with Mac Mail on Snow Leopard (10.6.8) with the latest beta (35600b).

I have a number of email accounts and some are working fine whilst others are timing out when attempting to connect to POP/IMAP.

The following are working fine:-
imap.gmx.com - configured as SSL in avast, now unencrypted 143 in Mail
imap.gmail.com - configured as SSL in avast, now unencrypted 143 in Mail
imap.mail.ovi.com - configured as SSL in avast, now unencrypted 143 in Mail
pop3.live.com - configured as SSL in avast, now unencrypted 110 in Mail
pop3.tiscali-business.co.uk - configured as SSL in avast, now unencrypted 110 in Mail
pop.orangehome.co.uk - unencrypted 110

The following are timing out in Mail:-
pop3.o2.co.uk - unencrypted 110
imap.tiscali.co.uk - unencrypted 143

I don't know what the avast algorithm is for checking whether to use SSL, STARTTLS, unencrypted is but it is taking far too long. The problem may be that for the two POP/IMAP hosts that are failing, attempting to connect to TCP ports 993 or 995 (with avast disabled) does not immediately fail with a TCP RST or ICMP port-unreachable response from the server so the local TCP stack sits there for ages until the timeout before reporting back to the client's connect() call. I suspect that because the avast 'transparent proxy' mail shield is sitting there waiting in this case, having already opened the connection to the Mail client, Mail times out waiting for the POP/IMAP initial protocol 'hello' lines.

What is needed is the same feature as is available on the Windows avast mail shield whereby you can manually tell avast NOT to try to attempt SSL connection to port 993/995 for a given POP/IMAP host.

(By the way, the UI for this on the Mac version is much nicer. I like the way I can put in my POP/IMAP server FQDN and avast creates labelled entries for all the IP addresses to which it resolves. This is much clearer than the Windows UI. I hope though that it re-queries the DNS for the FQDN given the TTL from the DNS server so that the entries remain valid.)

Offline tumic

  • Moderator
  • Advanced Poster
  • *
  • Posts: 724
Re: Mac beta and mail shield
« Reply #7 on: December 04, 2011, 02:15:09 PM »
I don't know what the avast algorithm is for checking whether to use SSL, STARTTLS, unencrypted is but it is taking far too long. The problem may be that for the two POP/IMAP hosts that are failing, attempting to connect to TCP ports 993 or 995 (with avast disabled) does not immediately fail with a TCP RST or ICMP port-unreachable response from the server so the local TCP stack sits there for ages until the timeout before reporting back to the client's connect() call. I suspect that because the avast 'transparent proxy' mail shield is sitting there waiting in this case, having already opened the connection to the Mail client, Mail times out waiting for the POP/IMAP initial protocol 'hello' lines.

Yes, it works exactly this way. And yes, there is currently a problem with servers that don't support imaps/pop3s and do drop connections to this ports instead of rejecting them. This will be fixed in the next beta refresh (in fact it is already fixed in our SVN ;-)). A timeout much shorter than the TCP timeout will be used to try a connection to the SSL variant of the service on not SSL-forced accounts. This way, the clients of such "bad behaving" servers will notice only a short lag when connecting, whereas clients of SSL enabled servers will still be redirected to the SSL variant of the service.

Offline SamEdge

  • Newbie
  • *
  • Posts: 4
Re: Mac beta and mail shield
« Reply #8 on: December 04, 2011, 04:22:22 PM »
Good to know a solution is in the works.

Would still like to see a more flexible manual configuration option. The problem with hard-coded timeouts is that they are always arbitrary and can, for example, make working (but slow or heavily loaded) servers seem to be failing when they're not. A per-host configurable timeout or per-host disable-SSL-checking option would solve this. In the UI for preference but in a registry setting or text config file would do for those edge cases.

Look forward to the next release.