K9 / OE6 Problem
06 Jan
I've just switched to Outpost from ZoneAlarmPro but now can't get a connection to my ISP smtp server via K9. Wasn't a problem on the actual day I uninstalled ZAP and installed Outpost but subsequently I can't get K9 to make a connection (K9 will connect if Outpost is not running).
Nothing in the Outpost logs indicating K9 or OE blocked.
K9 log says "Unable to connect to remote address. Error 10060"
The OE error message is:
"Your server has unexpectedly terminated the connection. Possible causes for this include server problems, network problems, or a long period of inactivity. Account: 'news_reply', Server: '127.0.0.1', Protocol: POP3,
Port: 9999, Secure(SSL): No, Error Number: 0x800CCC0F"
Any ideas?
tia
Marc
I just checked to see if an AVG update were available. I have a rule set for AVG (including the AVG remote IP address) that has enabled me to get through to AVG with any Outpost prompts several times before. Yet when I tried today, AVG threw up the 'create rule' prompt! I 'ok'd for the new rule and got connected. I then went into the rule set and deleted this newly created rule, leaving just the original rule I had previously created and ran the AVG check for update again. This time it connected to AVG using the original rule without any prompt. Yet, a minute earlier, Outpost seemed to ignore that rule and invited me to create a (new) rule. The AVG IP address in my rule was the same that AVG connected to both times. I recall a similar thing happening before with another rule for another app (can't recall which one).AVG will request a connection to a domain name (which depends on the exact version of AVG you are using - the free one uses free.grisoft.cz IIRC). To cope with network loading, they may be using multiple servers with a Round Robin DNS setup (the first time you do a DNS lookup you get IP address A, the second time B, etc looping back to A). Try deleting the rule and recreating it via Options/Application - this should pick up all IP addresses for a domain while rules created via the Rules Wizard only seem to pick up one.And if things get any more interestinger, I might wind up sending for some of those meds touted in the spam mail
;)One question - do you have a rule allowing incoming connections for K9 and AVG? Outpost 2.5 tightened up on local proxies so such a rule is required - if you do not have it add the following to their rulesets:
Protocol TCP, Incoming, Remote Address 127.0.0.1, Allow
I've not dropped by the forums the past few days, so I thought I'd catch up a bit today.
Sounds like OP is protecting your system pretty well, but it sure seems to be making itself somewhat annoying in the process. :rolleyes: We'd sure miss your presence around here if you do switch away. ZA does a pretty good job, it just doesn't have the fine-grained level of control and options that OP has. As you've seen, sometimes all these extras can cause problems.
Occasionally I"ve seen posters note that a complete removal and reinstall of OP (besides, there's a new version available now) cures a multitude of problems. Lotsa work though.
Your notes about OP poping up a Rules Wizard dialog when there's a perfectly good rule available is not unknown. I had/have the same thing occasionally with Avast updates. My log often shows blocked entries for Avast data file updates, but when I check the Avast "About" dialog, it shows that it did get the latest updates. If I check the "Allowed" logs there'll be entries showing that Avast D/L'd its updates just file shortly after OP blocked it. :confused: :confused: I've decided that it's probably just sunspot activity causing the problem and as long as Avast gets updated in a reasonable time-frame, I'm happy.
At any rate, best of luck to you. If you have the time, stick around. Your experiences with OP may be of help to the next guy in line. ;)
It just gets interestinger and interestinger, eh? ;)
any thoughts on why Outpost sometimes blocks OE when the 'offending' app is listed as a component in the OE rule set?Listing Cactus as a component of OE is a good idea. That way updates to Cactus shouldn't cause a popup. However, this sounds like OP's "Open Process Control" feature has identified that Cactus has actually modified something in OE's executable memory range. :eek:
Any chance that Cactus somehow tells OE that a message is spam through such a memory manipulation? Open Process Crontrol is an all-or-nothing function associated with OP's Component Control system and can't be set on an app by app basis. In other words, adding to C-C won't affect Open Process Control alerts. (Somebody slap me if I'm wrong here. :D )
I'm not familiar with Cactus. Does it modify the header? Are OP's alerts consistent with Cactus finding a spam message?
As Artie Johnson used to say: "Verrrrrry in-ter-esting"
I only found Cactus the other day when searching for a no-host-contact K9 replacement and I don't really know how it works internally.
From a user's pov, Cactus adds a classified-as-spam notifier to the email subject line (eg *** CACTUS SPAM *** Prescription Drugs). This is displayed in the OE client mail viewer and is also in the 'message source'. The Outpost warning message said that Cactus has written to OE's memory so I guess that's where the subject line is modified and this is what Outpost objected to.
When I was experimenting yesterday, what generally tended to happen (ie I don't think there was 100% behaviour consisitency) was that if I shutdown OE and then reloaded it, I would get the warning message. If I then shutdown OE and reloaded again, the message wouldn't be there. This shutdown/reload sequence occured without downloading any messages.
When I booted up today, OE loaded and I downloaded messages without problem or warnings, including a number of these messages being marked as spam by Cactus. I've downloaded messages a number of times so far today and no warning message. What baffles me is the apparent inconsistency in Outpost's behaviour in throwing up warning these messages. The next time it happens, I'll try a few more experiments and document the results.
And while I'm on the topic of Outpost's behaviour.....
I just checked to see if an AVG update were available. I have a rule set for AVG (including the AVG remote IP address) that has enabled me to get through to AVG with any Outpost prompts several times before. Yet when I tried today, AVG threw up the 'create rule' prompt! I 'ok'd for the new rule and got connected. I then went into the rule set and deleted this newly created rule, leaving just the original rule I had previously created and ran the AVG check for update again. This time it connected to AVG using the original rule without any prompt. Yet, a minute earlier, Outpost seemed to ignore that rule and invited me to create a (new) rule. The AVG IP address in my rule was the same that AVG connected to both times. I recall a similar thing happening before with another rule for another app (can't recall which one).
I don't know whether it's me or Outpost, but Outpost's behaviour is starting to make me wonder if I did the right thing in switching from ZoneAlarmPro. If I continue to experience problems, I might go back to ZAP - it wasn't perfect but its behaviour was pretty consistent and rarely left me sitting scratching my head as Outpost is starting to do. Time will tell.
And if things get any more interestinger, I might wind up sending for some of those meds touted in the spam mail
;)
My last note was misleading re AVG - I haven't used the AVG email scanner since installing Oupost as I wanted to get the basic OE/K9 config working before I added AVG into the mix.
However, since today K9 seems to be working ok - why it's working now when it wouldn't before, I don't know. Whether it will still be working tomorrow....
Digressing tangentially, as I couldn't get K9 configured to work, I had a scout about for an alternative spam filter that didn't talk to the server and came across Cactus (as things stand now, I'm running both K9 and Cactus, although only one of my (several...) accounts is currently configured for K9).
To run Cactus with OE, Outpost needs to have Cactus added as a 'component' in the OE rule set. No problem. However, *sometimes* when I start OE, I get a warning message informing that network access was blocked for OE because its memory was written to by Cactus. If I then shutdown OE and open it again, it (usually) starts ok without that warning. I don't know if this inconsisitent behaviour is because Cactus doesn't do whatever it does to OE each time OE starts (which would be strange, I think) or whether it's the way Outpost checks the components listed for a given app.
Assuming Cactus is acting in a consistent manner, any thoughts on why Outpost sometimes blocks OE when the 'offending' app is listed as a component in the OE rule set?
Outpost is turning out to be more of an adventure than I had anticipated......
I have a similar configuration working perfectly. Mine is probably more complex than yours needs to be because I use Avast Anti-Virus scanner in the chain as well. Also my ISP pre-filters for spam and I prefer to let K9 to the filtering. I have to have two OE accounts, one for regular mail and one for the mail that my ISP claims to be spam. I have to connect to a non-standard POP port to D/L this "greymail." And, of course, I have Avast scanning both accounts. :D
Since you didn't mention an A-V scanner I'll presume you don't use one. (Shame on you :eek: )
Try these settings. (Use what's in the quotes, don't include the quotes.)
K9:
Listen on port: "9999"
Server/Port/user delimeter: "/"
OE Account:
Incoming mail: "127.0.0.1"
Outbound mail: "
Account name: "127.0.0.1/110/
OPP:
Use the presets for Outlook Express. (Uncheck any rules you don't need such as LDAP, IMAP) if you don't use them, but keep the default Send and Receive rules.
Now for the magic: Create a new rule as follows:
Protocol: "TCP"
Direction: "Outbound"
Remote host: "127.0.0.1" This is the rule that lets OE ask K9 to check the incoming mail.
This should work for you. Please post back and let us know.
Glad to see you do use an A-V scanner. ;) I can't remember if AVG requires an OP rule or not. If it's still setting itself up as a proxy, I think it would need a rule to allow it to communicate with either the next app in the chain or your email server.
What's the flow for your POP 3 email? Server--->AVG--->K9--->OE? If so AVG must have a connection to the server and so it must have a rule. (I think) If it sits in between K9 and OE, then no rule needed UNLESS you have the OP System Global loopback rule disabled.
I have this rule disabled and so I have to have a rule to allow OE to request K9 to get the mail. OE talks to K9 on the loopback address and so without a specific rule to allow OE out on the local address, K9 never sees the request. If I had the System Global loopback rule allowed, the the OE rule would be unnecessary.
Disable any AVG rules (temporarily) and do a quick email check using rules wizard. See if you get a pop up for AVG. Hit "Allow Once" and check the logs and create an appropriate rule (or just use the preset rule if you like, probably a bit "loose" but you could trim it down if you like.)
I'd also recheck the allowed and blocked logs right after the email check and maybe post back both logs.
We'll get it going. It can't be that tough. We've got the best brains in the business around here. (I'm just filling up time until they show up :D )
I love a challenge.
Tks for your input. I think I had the K9 and OE rules configured ok (in effect the same as I had them in ZAP). However, as the connection works ok when Outpost is shutdown, then Outpost must have some affect somewhere or other.
Below is some output from the K9 and Outpost logs for a failed connection attempt:
K9 LOG
Mon Jan 10 2005 11:24:29 AM # Connection accepted from 127.0.0.1 port 1374
Mon Jan 10 2005 11:24:29 AM (4) < +OK K9 - 1.28 - http://keir.net ready
<4619953>
Mon Jan 10 2005 11:24:29 AM (4) > USER pop3.blueyonder.co.uk/110/MYUSERNAME
Mon Jan 10 2005 11:24:29 AM # Attempting to connect to 195.188.53.61 port
110
Mon Jan 10 2005 11:24:50 AM # Unable to connect to remote address. Error
10060
Mon Jan 10 2005 11:24:50 AM # Closing external connection
Mon Jan 10 2005 11:24:50 AM # Closing internal connection
Mon Jan 10 2005 11:24:50 AM # 0 entries in the Good IP cache
Mon Jan 10 2005 11:24:50 AM # 0 entries in the Spam IP cache
OUTPOST ALLOW LOG:
11:24:29 k9.exe OUT TCP pop3.blueyonder.co.uk POP3 1375
Receive mail by Default E-Mail Client
11:24:29 k9.exe IN TCP localhost 1374 9999 Allow
Loopback
11:24:29 msimn.exe OUT TCP localhost 9999 1374 MSIMN Rule #1
NB: There are no entries for either K9 or msimn in the Outpost 'Block' log.
So as things stand now, if I want to use K9, I have to shutdown Outpost, download email, and then restart Outpost. :(
BTW I use AVG7 (and also BOClean) ;)
If Cactus is performing its modification only when email is downloaded, then this would explain why - Outpost should in this case only block OE after downloading email triggering a modification by Cactus. This block would come into effect (and you would see the prompt) on the next network connection attempt by OE.
Cactus examines each email as it is downloaded and adds a 'spam' indicator to the subject line of each email it thinks is spam. I've downloaded email with Cactus running several dozen times without any problem but occasionally Outpost baulks and I get the Outpost error message. The last time it happened was when Cactus threw up a message box asking if a particular email should be classified as spam or not (a common occurrence when Cactus is in 'training' mode) so I assume the problem is related to this although I have had and replied to that messagebox many times before without problems.. At that last occurrence, Outpost displayed the error message each time I started OE no matter how many times I shut OE down and restarted it. This behaviour was different from what had happened previously. I've now turned off 'training mode' (it's identifying spam pretty accurately) and the problem hasn't reappeared, so far. We live in hope....
AVG will request a connection to a domain name (which depends on the exact version of AVG you are using - the free one uses free.grisoft.cz IIRC). To cope with network loading, they may be using multiple servers with a Round Robin DNS setup (the first time you do a DNS lookup you get IP address A, the second time B, etc looping back to A). Try deleting the rule and recreating it via Options/Application - this should pick up all IP addresses for a domain while rules created via the Rules Wizard only seem to pick up one.One question - do you have a rule allowing incoming connections for K9 and AVG? Outpost 2.5 tightened up on local proxies so such a rule is required - if you do not have it add the following to their rulesets:
Protocol TCP, Incoming, Remote Address 127.0.0.1, Allow
I've recently upgraded to 375 and am now mostly using default rules. The previous AVG rule was ignored just the once out of being invoked dozens of times. Although I didn't have a 127.0.0.1 rule for it, there was nothing in the logs indicating any blocks. I don't think I had an incoming rule either.
I can't recall whether I had a 127.0.0.1 rule for K9 (but I did give it a fair amount of scope) but again there was nothing in the logs indicating any blocks. Curiously, for a brief time after my original post I had K9 and Cactus both working (on different accounts) . I don't know why K9 started connecting again but it did, although after a few days K9 stopped connecting as before. Again, I don't know why it stopped.
I think I'll stick with the default rules for the time being until I'm confident that Outpost behaves consistently with them and will then start tightening them up one app at a time. If I still can't get Outpost to behave consistently after doing that, I'll probably dump it and go back to ZAP.
#If you have any other info about this subject , Please add it free.# |
