Virus scanner blocking/messing up traffic?

[MoreDakka]

Well I've got a CentOS box that I was doing some yum installs to today and when I tried I get some errors:

With the Virus Scanner enabled:


[root@testbox tmp]# yum install net-snmp php php-mysql php-snmp rrdtool apache
Loading "installonlyn" plugin
Setting up Install Process
Setting up repositories
Reading repository metadata in from local files
Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package php.i386 0:5.1.6-12.el5 set to be updated
---> Package php-snmp.i386 0:5.1.6-12.el5 set to be updated
---> Package php-mysql.i386 0:5.1.6-12.el5 set to be updated
---> Package net-snmp.i386 1:5.3.1-14.0.1.el5 set to be updated
--> Running transaction check
--> Processing Dependency: php-common = 5.1.6-12.el5 for package: php
--> Processing Dependency: php-common = 5.1.6-12.el5 for package: php-snmp
--> Processing Dependency: libnetsnmp.so.10 for package: php-snmp
--> Processing Dependency: libgmp.so.3 for package: php
--> Processing Dependency: libnetsnmpagent.so.10 for package: net-snmp
--> Processing Dependency: libsensors.so.3 for package: net-snmp
--> Processing Dependency: php-pdo for package: php-mysql
--> Processing Dependency: httpd-mmn = 20051115 for package: php
--> Processing Dependency: libnetsnmphelpers.so.10 for package: net-snmp
--> Processing Dependency: libnetsnmpmibs.so.10 for package: net-snmp
--> Processing Dependency: php-cli = 5.1.6-12.el5 for package: php
--> Processing Dependency: libnetsnmptrapd.so.10 for package: net-snmp
--> Processing Dependency: php-common = 5.1.6-12.el5 for package: php-mysql
--> Processing Dependency: libnetsnmp.so.10 for package: net-snmp
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for php-pdo to pack into transaction set.
php-pdo-5.1.6-12.el5.i386 100% |=========================| 17 kB 00:00
http://centos.secsup.org/5.0/updates/i386/RPMS/php-pdo-5.1.6-12.el5.i386.rpm: [Errno -1] Header is not complete.
Trying other mirror.
php-pdo-5.1.6-12.el5.i386 100% |=========================| 17 kB 00:00
http://centos.westmancom.com/5.0/updates/i386/RPMS/php-pdo-5.1.6-12.el5.i386.rpm: [Errno -1] Header is not complete.
Trying other mirror.
php-pdo-5.1.6-12.el5.i386 100% |=========================| 17 kB 00:00
http://mirrors.gigenet.com/centos/5.0/updates/i386/RPMS/php-pdo-5.1.6-12.el5.i386.rpm: [Errno -1] Header is not complete.
Trying other mirror.
php-pdo-5.1.6-12.el5.i386 100% |=========================| 17 kB 00:00
http://ftp.telus.net/pub/centos/5.0/updates/i386/RPMS/php-pdo-5.1.6-12.el5.i386.rpm: [Errno -1] Header is not complete.
Trying other mirror.
php-pdo-5.1.6-12.el5.i386 100% |=========================| 17 kB 00:00
http://centos.arcticnetwork.ca/5.0/updates/i386/RPMS/php-pdo-5.1.6-12.el5.i386.rpm: [Errno -1] Header is not complete.
Trying other mirror.
php-pdo-5.1.6-12.el5.i386 100% |=========================| 17 kB 00:00
http://mirrors.kernel.org/centos/5.0/updates/i386/RPMS/php-pdo-5.1.6-12.el5.i386.rpm: [Errno -1] Header is not complete.
Trying other mirror.
php-pdo-5.1.6-12.el5.i386 100% |=========================| 17 kB 00:00
http://mirror.stanford.edu/yum/pub/centos/5.0/updates/i386/RPMS/php-pdo-5.1.6-12.el5.i386.rpm: [Errno -1] Header is not complete.
Trying other mirror.
php-pdo-5.1.6-12.el5.i386 100% |=========================| 17 kB 00:00
http://centos.mirrors.tds.net/pub/linux/centos/5.0/updates/i386/RPMS/php-pdo-5.1.6-12.el5.i386.rpm: [Errno -1] Header is not complete.
Trying other mirror.
Error: failure: RPMS/php-pdo-5.1.6-12.el5.i386.rpm from updates: [Errno 256] No more mirrors to try.


When I shut the virus scanner down, everything goes through no problem:


[root@testbox tmp]# yum install net-snmp php php-mysql php-snmp rrdtool apache
Loading "installonlyn" plugin
Setting up Install Process
Setting up repositories
Reading repository metadata in from local files
Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package php.i386 0:5.1.6-12.el5 set to be updated
---> Package php-snmp.i386 0:5.1.6-12.el5 set to be updated
---> Package php-mysql.i386 0:5.1.6-12.el5 set to be updated
---> Package net-snmp.i386 1:5.3.1-14.0.1.el5 set to be updated
--> Running transaction check
--> Processing Dependency: php-common = 5.1.6-12.el5 for package: php
--> Processing Dependency: php-common = 5.1.6-12.el5 for package: php-snmp
--> Processing Dependency: libnetsnmp.so.10 for package: php-snmp
--> Processing Dependency: libgmp.so.3 for package: php
--> Processing Dependency: libnetsnmpagent.so.10 for package: net-snmp
--> Processing Dependency: libsensors.so.3 for package: net-snmp
--> Processing Dependency: php-pdo for package: php-mysql
--> Processing Dependency: httpd-mmn = 20051115 for package: php
--> Processing Dependency: libnetsnmphelpers.so.10 for package: net-snmp
--> Processing Dependency: libnetsnmpmibs.so.10 for package: net-snmp
--> Processing Dependency: php-cli = 5.1.6-12.el5 for package: php
--> Processing Dependency: libnetsnmptrapd.so.10 for package: net-snmp
--> Processing Dependency: php-common = 5.1.6-12.el5 for package: php-mysql
--> Processing Dependency: libnetsnmp.so.10 for package: net-snmp
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for php-pdo to pack into transaction set.
php-pdo-5.1.6-12.el5.i386 100% |=========================| 17 kB 00:00
---> Package php-pdo.i386 0:5.1.6-12.el5 set to be updated
---> Downloading header for php-common to pack into transaction set.
php-common-5.1.6-12.el5.i 100% |=========================| 19 kB 00:00
---> Package php-common.i386 0:5.1.6-12.el5 set to be updated
---> Downloading header for httpd to pack into transaction set.
httpd-2.2.3-7.el5.centos. 100% |=========================| 54 kB 00:00
---> Package httpd.i386 0:2.2.3-7.el5.centos set to be updated
---> Downloading header for php-cli to pack into transaction set.
php-cli-5.1.6-12.el5.i386 100% |=========================| 17 kB 00:00
---> Package php-cli.i386 0:5.1.6-12.el5 set to be updated
---> Downloading header for net-snmp-libs to pack into transaction set.
net-snmp-libs-5.3.1-14.0. 100% |=========================| 26 kB 00:00
---> Package net-snmp-libs.i386 1:5.3.1-14.0.1.el5 set to be updated
---> Downloading header for lm_sensors to pack into transaction set.
lm_sensors-2.10.0-3.1.i38 100% |=========================| 26 kB 00:00
---> Package lm_sensors.i386 0:2.10.0-3.1 set to be updated
---> Downloading header for gmp to pack into transaction set.
gmp-4.1.4-10.el5.i386.rpm 100% |=========================| 10 kB 00:00
---> Package gmp.i386 0:4.1.4-10.el5 set to be updated
--> Running transaction check
--> Processing Dependency: libapr-1.so.0 for package: httpd
--> Processing Dependency: libaprutil-1.so.0 for package: httpd
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for apr-util to pack into transaction set.
apr-util-1.2.7-6.i386.rpm 100% |=========================| 7.3 kB 00:00
---> Package apr-util.i386 0:1.2.7-6 set to be updated
---> Downloading header for apr to pack into transaction set.
apr-1.2.7-11.i386.rpm 100% |=========================| 10 kB 00:00
---> Package apr.i386 0:1.2.7-11 set to be updated
--> Running transaction check
--> Processing Dependency: libpq.so.4 for package: apr-util
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for postgresql-libs to pack into transaction set.
postgresql-libs-8.1.9-1.e 100% |=========================| 15 kB 00:00
---> Package postgresql-libs.i386 0:8.1.9-1.el5 set to be updated
--> Running transaction check

Dependencies Resolved

================================================== ===========================
Package Arch Version Repository Size
================================================== ===========================
Installing:
net-snmp i386 1:5.3.1-14.0.1.el5 updates 699 k
php i386 5.1.6-12.el5 updates 1.2 M
php-mysql i386 5.1.6-12.el5 updates 82 k
php-snmp i386 5.1.6-12.el5 updates 27 k
Installing for dependencies:
apr i386 1.2.7-11 base 122 k
apr-util i386 1.2.7-6 base 75 k
gmp i386 4.1.4-10.el5 base 664 k
httpd i386 2.2.3-7.el5.centos updates 1.1 M
lm_sensors i386 2.10.0-3.1 base 494 k
net-snmp-libs i386 1:5.3.1-14.0.1.el5 updates 1.1 M
php-cli i386 5.1.6-12.el5 updates 2.2 M
php-common i386 5.1.6-12.el5 updates 139 k
php-pdo i386 5.1.6-12.el5 updates 61 k
postgresql-libs i386 8.1.9-1.el5 updates 196 k

Transaction Summary
================================================== ===========================
Install 14 Package(s)
Update 0 Package(s)
Remove 0 Package(s)

Total download size: 8.2 M
Is this ok [y/N]:


So What could be the problem here. It's only when I have the virus scanner enabled does it mess up the yum connection. I'm not sure what to do. I can try different levels of scanning as well.

Thanks.

[MoreDakka]

Well it seems that it's the "disable FTP download resume" that messes that up. Not really sure why but it does. I'll just disable that and see anyone has any idea why.

Thanks.

[MoreDakka]

So I lied on that last statement. I just tried to do another update with yum, different files and it blocked traffic again. So I'm not sure what's going on. I had to disable the virus scanner to let the connection connect again.

[MarkF]

Hi, MoreDakka!

This isn't unusual. Astaro had the same problem for years, and it's due to improper handling of HTTP range headers by the "transparent" HTTP proxy. The workaround in Astaro was to explicitly bypass the HTTP proxy for Linux machines, but I don't see an obvious means to do that in untangle without removing the machines from firewall protection completely (i.e. assigning the machines to No Rack), unless you use the Professional version.

FYI!
MarkF

[MoreDakka]

Well doesn't that suck now. :-/ Oh well, "most" of the linux stuff is "safe" so it should be alright but it sucks that I can't have those boxes behind the virus scanner because of improper handling. Is this something that Untangle programers are looking to fix in future releases or it this one of those "live with it" type of situations? (I would help with the programming but I'm pretty sure the whole thing would stop working if I was to try to do something like that..haha).

Thanks for the info.

[dmorris]

If you could provide a couple tcpdump records on the inside and outside interface while doing a yum update.

tcpdump -i eth0 -s 0 -w eth0.yum.ptrace "tcp port 80" &
tcpdump -i eth1 -s 0 -w eth1.yum.ptrace "tcp port 80" &
<<do a yum update>>
killall tcpdump

then email them to us @ support@untangle.com

then we can file a bug and fix it - otherwise its hard to tell whats going on.

[MoreDakka]

sure, now it's not doing it. I'll get those logs to you as soon as it errors on me again.

Thanks!

[MarkF]

Hi, DMorris!

I'm unfortunately not set up right now to give you the logs, but it's an easy problem to understand. Yum requests only a portion of the file using the HTTP 1.1 range header extensions, but at least with Astaro, the transparent proxy delivers the complete file.

If you Google 'http range request yum', you'll see that this is a common problem with proxies, and yes, it failed for me with Untangle, as well. This comes and goes dependent upon the server that you actually connect with and its specific capabilities.

Best Regards,
MarkF

[woodrowbone]

Hi all!
I have the same problem to get my mail, I am using Thunderbird under XP.
When I turn off the virus/spam/Phish blocker it works like a charm.
I get this message from Thunderbird mail client:"The RETR command did not succeed. Error retrieving a message"

Any ideas:confused:

[Stielf]

Untangle works great except for once a week or so I get an email in that causes this same problem.

"I have the same problem to get my mail, I am using Thunderbird under XP.
When I turn off the virus/spam/Phish blocker it works like a charm.
I get this message from Thunderbird mail client:"The RETR command did not succeed. Error retrieving a message"

I use an Mdeamon Mail Server behind my Untangle computer. I get the error recieving message on an email that has a blank message. The email server will read thru the email list with no problem and time out when it hits the bad email while downloading it. Then it does this over and over again.

I can go on the ISP's web mail client and delete the email that Untangle hangs on and everything will start working correctly. I can also shut off the Untangle Virus module and reboot the Untangle server to fix the problem also.

I get this on multiple Untangle Servers that have an Mdeamon email server behind it useing pop3 to pull down the emails.

It seems that the Virus detection is waiting to scan the body of the message and since there isn't anything there, it times out, causing the email server to start over in an endless loop.

Mdeamon Email Server with it's virus software works just fine on these spam emails without Untangle in front of it.

[Stielf]

Untangle works great except for once a week or so I get an email in that causes this same problem.

"I have the same problem to get my mail, I am using Thunderbird under XP.
When I turn off the virus/spam/Phish blocker it works like a charm.
I get this message from Thunderbird mail client:"The RETR command did not succeed. Error retrieving a message"

I use an Mdeamon Mail Server behind my Untangle computer. I get the error recieving message on an email that has a blank message. The email server will read thru the email list with no problem and time out when it hits the bad email while downloading it. Then it does this over and over again.

I can go on the ISP's web mail client and delete the email that Untangle hangs on and everything will start working correctly. I can also shut off the Untangle Virus module and reboot the Untangle server to fix the problem also.

I get this on multiple Untangle Servers that have an Mdeamon email server behind it useing pop3 to pull down the emails.

It seems that the Virus detection is waiting to scan the body of the message and since there isn't anything there, it times out, causing the email server to start over in an endless loop.

Mdeamon Email Server with it's virus software works just fine on these spam emails without Untangle in front of it.

[dlasher]

I'll just throw my "me too" in. I had to completely disable the virus scanning to get yum updates to go through. Even tried creating some additional file types ".rpm etc" and telling it to ignore them, to no avail.

buggers.

[HomeNet]

Yes, I saw something similar with a few of my Thunderbird users. They all have XP and Outlook Express broke a while back so they now use Thunderbird. When I installed the Untangle box the guys who used Thunderbird kept getting the "The RETR command did not succeed. Error retrieving a message." error and I had to shut down a few services in the Untangle box. If I was using the Spam Blocker, Phish Blocker or the Virus Blocker, Thunderbird would return that same error. It didn't matter if I use one, two or all three of those blocking utilities...

Is there a fix for this yet?

[HomeNet]

So is there a workaround or what? I'd like to re-enable these features to better protect my clients who paid us to install this piece of hardware.

[mdh]

Dunno as far as a workaround goes, but the yum issue is in Engineering now.

[dlasher]

Dunno as far as a workaround goes, but the yum issue is in Engineering now.

Do you still need more data? I can attach/email a TCPDUMP, with what ever params you need. As of right now I still have to turn off the virus scanning to get yum to update. I've even set up "exemptions" and it still screws em up.

[mdh]

dlasher,

We'd be silly to turn it down. Please feel free to send it to us. I have attached dmorris's quote from earlier in the thread which has the specs we are looking for. Thanks for the offer!

If you could provide a couple tcpdump records on the inside and outside interface while doing a yum update.

tcpdump -i eth0 -s 0 -w eth0.yum.ptrace "tcp port 80" &
tcpdump -i eth1 -s 0 -w eth1.yum.ptrace "tcp port 80" &
<<do a yum update>>
killall tcpdump

then email them to us @ support@untangle.com

then we can file a bug and fix it - otherwise its hard to tell whats going on.

[juank]

The only workaround I found that works was to change the source lists from HTTP to FTP sites.

[HomeNet]

The only workaround I found that works was to change the source lists from HTTP to FTP sites.

Are you speaking about my query?

[dmorris]

tracking of this bug here:

http://bugzilla.untangle.com/show_bug.cgi?id=3210

It appears to be an issue related to partial fetching.

edit: we already got a tcpdump and everything we need.
the bug is currently scheduled to be fixed in 5.1 by allowing users to turn of partial fetching blocking.
By default it blocks partial fetches because this gets around the ability to virus scan downloads.
Unfortunately, yum uses a web client that partial fetches the whole file
[0...size] instead of just requesting the file.

[juank]

No, I was talking about YUM.

[HomeNet]

What about the Dual Virus Scanner? Does anyone know if this happens with that scanner? I have this customer set up with Avast (managed) and it's about to expire. I want to know if I should renew the Avast license or sell them the Dual Virus Scanner. I'd rather use the Dual Virus Scanner since it's easier to manage then a busted XP machine (Once again, these people never take my advise! There is no domain and they are all XP Home boxes!) running the Avast server software. If there will be an issue, I'd like to know about it. Any ETA on a fix yet?

11-08-07
1059 EST
Rob @ HomeNet

[yonnie]

On my thunderbird using windows xp and on my evolution using fedora I'm getting trouble trying to download email. It looks close to two months since anyone has discussed this issue. Am I working with an old version of untangle, or is this problem not fixed yet? version doesn't seem to indicate it has updated 5.0.3.1-1, is this a good version?

[HomeNet]

On my thunderbird using windows xp and on my evolution using fedora I'm getting trouble trying to download email. It looks close to two months since anyone has discussed this issue. Am I working with an old version of untangle, or is this problem not fixed yet? version doesn't seem to indicate it has updated 5.0.3.1-1, is this a good version?

I was told, by my Untangle sales rep, that it will be fixed in the next release which is to be in February. He got his info from the developers.

12-28-07
0819 EST
Rob @ HomeNet

[yonnie]

thanks for the reply!

[m.goode]

Is there any way to use the spam filter if you have users receiving retr errors in the current version?

[HomeNet]

Is there any way to use the spam filter if you have users receiving retr errors in the current version?

As far as I know, there is no workaround from Untangle yet. If you are trying to workaround the Thunderbird issue, you could set it up with an IMAP account instead of a standard POP3 (or maybe POP3 will work too) and have it run through a secure connection (SSL). Obviously, you'd have to have a mail server that supports IMAP and an SSL connection but if you can get that set up, the data should pass through the spam filter without getting touched. I've not tested this but it sounds good in theory.

Beyond all that stuff, I've never looked forward to February so much in my life! :D

01-11-08
1153 EST

[m.goode]

Thanks for the suggestion. I will try this for POP3 and IMAP off hours tonight or tomorrow and post the results.

[HomeNet]

Thanks for the suggestion. I will try this for POP3 and IMAP off hours tonight or tomorrow and post the results.

Yesterday, I was on one of my sites that has this issue. I had to move a bunch of profiles and that meant moving their mail to the new PC as well. I figured I'd try getting this working and was able to do so. Many are Outlook Express users but some use T-Bird. In all 15 cases, I was able to have them use SSL with their POP3 accounts.

01-15-08
0751 EST
Rob @ HomeNet

[HomeNet]

As I mentioned above, I was able to get T-Bird to work with SSL. However, T-Bird will nag you about the security cert if it's out of date or whatever but there's a check box to stop that nag. My issue was with the "Domain Name Mismatch" notice I'd get since the cert was for my company and not the domain on which the client was checking his mail and there is no check box for this notice. I did some digging and found an extension for FF and TB that gives you the check box that keeps this notice from bothering you every time you open TB. Here (https://addons.mozilla.org/en-US/firefox/addon/2131) it is...

I'm still waiting on the new update which is to fix the initial error as the Spam/Phish/Virus blockers cannot filter things out if it's running on an encrypted connection.

01-16-08
1018 EST
Rob @ HomeNet

[m.goode]

We may have a solution to the Thunderbird RETR problem. We didn't want to use SSL because of a couple issues with overhead and the security cert. We set POP3 to a forward to the mail server from a non-standard port. It seems to be working. We can change back to port 110 and get the error and then change to the non-standard port and it works. We are going to test this for a while hopefully it is the solution we are looking for.

[HomeNet]

We may have a solution to the Thunderbird RETR problem. We didn't want to use SSL because of a couple issues with overhead and the security cert. We set POP3 to a forward to the mail server from a non-standard port. It seems to be working. We can change back to port 110 and get the error and then change to the non-standard port and it works. We are going to test this for a while hopefully it is the solution we are looking for.

I suppose as long as your mail server is listening on that port, it should work fine. Personally, I'm waiting on the new release which should be out any day now (hint-hint, coder guys at Unatngle :) ).

02-13-08
1125 EST
Rob @ HomeNet

[Silver Bullet]

We may have a solution to the Thunderbird RETR problem. We didn't want to use SSL because of a couple issues with overhead and the security cert. We set POP3 to a forward to the mail server from a non-standard port. It seems to be working. We can change back to port 110 and get the error and then change to the non-standard port and it works. We are going to test this for a while hopefully it is the solution we are looking for.

Is the Spam Filter still scanning your POP mail while using the non-standard port?

[mdh]

Subtle hint is to no avail...they're coding and testing, not reading forums.:lol

[HomeNet]

Subtle hint is to no avail...they're coding and testing, not reading forums.:lol

It costs nothing to dream...

[itconsultant]

I don't know if the dual antivirus question was answered but I would recommend having it both on the firewall and on the individual pc. Even if it is an extra pain because there is no domain. Someone could plug an infected laptop in to the network behind the firewall and allow the virus to spread uncontrolled.

[HomeNet]

I don't know if the dual antivirus question was answered but I would recommend having it both on the firewall and on the individual pc. Even if it is an extra pain because there is no domain. Someone could plug an infected laptop in to the network behind the firewall and allow the virus to spread uncontrolled.

Yeah, I generally drop ClamWin (http://www.clamwin.com/) on these machines. I have them scheduled to scan nightly in case some nimrod brings in his craptop with a few bugs on it.

02-14-08
0748 EST
Rob @ HomeNet

[m.goode]

I suppose as long as your mail server is listening on that port, it should work fine. Personally, I'm waiting on the new release which should be out any day now (hint-hint, coder guys at Unatngle :) ).

02-13-08
1125 EST
Rob @ HomeNet

The mail server is still listening to 110. We just have the client use a non-standard port (109) and use the router to forward those requests to the server's 110 port. It is working we have just had to advise customers to modify there POP port as they call in (only about 15 so far). The problem we are having now is that we feel it is responding slowly to smtp requests. Sometimes 20 seconds. It is not the mail server either. As soon as we turn spam filtering off smtp headers come back immediatly.

[m.goode]

Is the Spam Filter still scanning your POP mail while using the non-standard port?

Yes it is scanning and marking just fine.

[HomeNet]

The mail server is still listening to 110. We just have the client use a non-standard port (109) and use the router to forward those requests to the server's 110 port. It is working we have just had to advise customers to modify there POP port as they call in (only about 15 so far). The problem we are having now is that we feel it is responding slowly to smtp requests. Sometimes 20 seconds. It is not the mail server either. As soon as we turn spam filtering off smtp headers come back immediatly.

Another thing you may want to look out for... From what I've heard, MS-Outlook will try to change ports on the fly. It will start out using the default ports but if the connections aren't made, it will try again on alternate ports. The ports are normally industry standard ports but some antivirus apps will not like it when Outlook tries this. Avast (http://www.avast.com/) is one that I know will piss and moan when Outlook tries this. Just keep an eye out for things like that.

02-14-08
1000 EST
Rob @ HomeNet

[m.goode]

Is the Spam Filter still scanning your POP mail while using the non-standard port?

Sorry, Actually it does not scan the 109 port, but we are still getting the benefit of tar pitting and the 110 port is still being scanned.

[darklogic]

Just want to start off by saying sorry in the length of this post.
I'm running a POP3 server and when trying to receive e-mails from outside of the network over an IPSec tunnel or a FQDM POP3 will error out if you have SPAM, Phishing, and Virus blocker turned on, but if you do a PPTP into the internal network which will give you a internal IP of that network and force all traffic through the PPTP VPN, the POP3 will pass and e-mails come right into your inbox without any issues. After almost 6 months ago on a post with this issue, still no fix I see. One other note, this issue remains on any e-mail client, not just Thunderbird.

Most threats to a network come from e-mail and browsing the web right!!! Well how can I be affective with the Untangle system if I must disable 3 mods which include SPAM filtering, Phishing filtering, and Virus filtering just to be able to get e-mail remotely from the network? I can't go around and change standard ports on over 300 machines. This is just not practical. I know I may sound irritated, but only because this was brought up by others and myself months ago on this thread and others. I stopped receiving any responses on that issue. Now I see the same issue popping up in new threads. Plus I addressed this issue in beta testing and still no response. Beta2 5.1 and still no fix.

I persist with this issue only because I cannot find really any other issues with the Untangle system other than in the reports and that is a plus, but this issue has been a drag for way to long. I have used other systems to protect our e-mail until Untangle gets a resolution for this, the question is when? Clark Connect does not have as many features as Untangle, but still uses the spam assassin engine and ClamAV. I have to run Untangle in transparent mode behind a Clark Connect system that does proxy filtering for our incoming SMTP due to not being able to have Untangles filters enabled. And yes I have tried many solutions for front end firewalls such as, Monowall, PFsense, Smoothwall, Endian, MFN2, Sonicwall, Cisco PIX 506E, ISA2006, and Vyatta. Oh and I tried having Untangle as a standalone firewall. I just want to know if this issue is going to be fixed anytime soon. I can see you ignoring this post only because of my tone, but others have this issue as well, so I’m not just complaining over nothing.

[ThisMedved]

I found this thread looking for other Thunderbird causes for my Mail trouble.
Bug http://bugzilla.untangle.com/show_bug.cgi?id=3210 for YUM has been closed as duplicate for http://bugzilla.untangle.com/show_bug.cgi?id=2524 also resolved.

Is another bug open for the POP retrieval issue or is more information needed?

I have changed Thunderbird settings to download headers and leave on server until deleted by the mail client. This is allowing me to narrow down which Untangle module causes Thunderbird to fail. Thunderbird continues to fail downloading many e-mail bodies.

Downloads have been successful with only Virus scanning enabled.

Downloads from the same POP server with Outlook are successful.

Any advice would be appreciated.

[XeOn]

I know this is old, but I have the same problem with Untangle 5.2 and Thunderbird/Eudora.
Outlook express works fine, but then again outlok express chooses different port if 110 doesn't work.
Switching off Spam Blocker & Virus Blocker or Phish Blocker works and all our emails are received. Switching to SSL port (995) also works, but none of these fixes actually works in real life, since it doesn't scans emails.

Any thoughts?

Thanks!

[sky-knight]

Ever consider that Thunderbird might be the problem? I have random pop retrieval issues with every mail client in existence... Outlook (express), Thunderbird, Pine, Entourage, etc...

They all have one thing in common, a usually spam e-mail is sitting on the server and something about it causes the POP session to puke and clients complain of duplicated e-mails. The only solution I've ever found is to delete the message using a webmail client and try again. Also, mail clients configured to leave messages on the server for any length of time seem more prone to this failure, as they invariably leave stuff on the server they really shouldn't and things get out of sync.

I haven't seen anything in UT 5.1, 5.2, 5.2.1 that would indicate the pop3 proxy being anymore bug/failure prone than most AV companies local pop3 proxies. Which incidentally, they are in the mix too causing more problems. The long and short is the more software you get involved with any given process the more likely it is that something will go wrong. The only way you can narrow this down and pin it on UT is get a message that won't download and use Telnet to manually retrieve it...

If you can do this with a packet capture running even better, it will be required to lock down the bug and fix it.