[quote user="Barius"]Hmm, who's definition of 'soon' are we going by here...?[/quote]

Where did you get 'soon' from?  Did you read the original thread?  Nobody made any promises of when it would be done.

I don't see a bug forum, so I'm posting this here.

Since upgrading our Mercury server to v4.6x (from v4.5x) our POP3 server has developed a strange problem.  Every few days the POP3 process will prevent users from getting their mail with the following message in the log window:

Connection refused short-term from <ip address>, <date>

These are valid users, with the correct passwords.  They are not accidentally using the wrong username or password.  Connecting clients include Pegasus, Thunderbird and Outlook.

Symptoms of the problem are the following:

- When it starts happening it prevents about 4 in 5 users but lets 1 in 5 through.

- The problem goes away simply by stopping and restarting Mercury.

- I am not entirely sure, but I think that the only users affected are all behind the same IP address (users behind our firewall/gateway).  I will have to watch for this the next time it happens, and I'll update this post.

- Other modules (e.g. MercuryS) do not seem to be affected.

The system config is:

- Standard Intel x86 workstation

- Windows XP Sp3 w/ regular patches.

- Just the standard WinXP firewall.

My understanding is that David has added multi-threading code in the 4.6x branch of Mercury.  Could this have anything to do with it?
Whatever the culprit, it's a fairly annoying new 'feature'.

This almost sounds like MercuryP is set to refuse connections after x number of failures and you are getting connection failures.  IIRC v4.62 implemented a limit on the number of password failures and put the connection on the short term black list.  This means that all connections from that IP address would be blocked for 30 minutes.  . 

Turn on session logging in MercP to find the culprit. Don't forget to turn it off when you are finished.

That certainly sounds like a possible culprit.  I'll check the session logs to verify, but in the mean time is there a way to disable this new feature?

Yup, that seems to be the problem.  There were a couple of users with older clients that hadn't been updated, though I have no idea why they are even using said clients when they can't have been working for months...

Eitherway, this new 'feature' needs to be configurable.  In fact, I don't think it was a good idea in the first place.  I could understand temp-banning a specific username but not an IP address.  Too many networks rely on IP masquerading to make this feature useful as is.  It could potentially be made relevant if it respected the Connection Control settings, but currently it does not and I'd still find it more useful if based on login name.

Thanks for you help.

In fact, I don't think it was a good idea in the first place.  I could

understand temp-banning a specific username but not an IP address.

Some were getting all sorts of attacks on the server from specific IP addresses trying all sorts of usernames and passwords.  I believe the IP blocking was a result, it might alow be blocking on the username after x number of tries as well.  I do not know if there is a way to either turn it off or whitelist specific IP addresses but there is a connection control that you can use to allow certain IP addresses.  Maybe the IP addresses in the allow list are not blocked.

some of us have massive attacks against MercuryS, MercuryP and MercuryI that try to harvest account information.

The simplest way to stop them trying is to ban the IP they use in short term automatically.

That's fine, but the rest of us still need an on/off switch.

Also, as stated before, this 'feature' does not respect the connection control settings.  If it did, it would not have been a problem for me since I already have the IP address explicitly allowed.

Yes that's true. It is on the wish list that the connection control settings have some more settings. F.ex. for MercuryS to let through only authenticated connections - but this is not likely to be adopted until the next major overhaul of the Mercury feature-set. But in any case,, the wrong password submisison of a POP3 client only triggers if the poll frequencey is high, and under all cases the short term ban is lifted automatically - and that is not a bug.

To answer your initial question: No there is no "bug forum". What happens is that when someone from the beta test teams can confim a flaw or suspect a flaw, we then report that back to David.

>> But in any case,, the wrong password submisison of a POP3 client only

triggers if the poll frequencey is high, and under all cases the short

term ban is lifted automatically - and that is not a bug.

The problem is that it is banning an IP behind which there are 200 users all trying to connect approx. every 5 mins.  Wrong passwords are bound to happen, it's simply a fact of life.  Banning the IP, even for 30 seconds, is a bug in my situation.  Without the ability to properly configure this, my only choice is to downgrade back to v4.5 because clearly this feature was implemented too hastily and without proper investigation of the consequences.

I don't want to sound ungrateful, but I am a programmer myself and I know how easily an on/off switch could have been implemented.   It is frustrating to be told to wait for the next *major* release, which could be more than a year from now given past release history.  I really think David should give consideration to providing a patch.

Hmm, never thought of the connection scenario you have, with many users behind a NAT/PAT and not the opposite, meaning one mistyping user can ruin for so many - of course you're absolutely right about the urgency regarding your scenario. Could you draw me the network topology with DMZ and gateway settings. Your scenario should have more ramifications than just the POP3 blacklisting. Fex. SMTP but maybe you don't authenticate them - or? Are you using graywall or do you have separate instances for inboud/outbound?

When I feel I have a clear picture I'll pass the information and urgency along to David.

Thank you for clarifying this.

No DMZ, the server has it's own address on the 'net, it was just easier this way 10 (15?) years ago when my predecessor set it up (before today's point-and-click DMZ configuration GUIs).  It serves a small office of users who are all behind a single gateway firewall.  They usually connect from the office, but mobile users may connect from anywhere.  It probably should have been setup within a proper DMZ in the first place, but doing so now would require significant hardware changes so I've been putting it off.

The connection controls for both POP3 and SMTP have the external gateway address 'allowed'.  Authentication for POP3 is per-user and verifies against a Novell Netware server.  SMTP is encrypted via TLS and requires authentication, but has only one user/pass which is shared by all (Note that I've requested Novell Netware/LDAP per-user SMTP authentication in the wishlist previously).

Aside from this glitch with POP3, everything else works fine.  Graywall doesn't seem to have any issues, though Spamwall does occasionally blacklist internal users.  It doesn't recognize them as internal because we use shortened aliases of their Netware usernames and Spamwall isn't programmed to respect the aliases file setting.

E.g.

Full Internal name: <username>.<organizational unit>.<organization>@<our domain>.com
External name: <username>@<our domain>.com

I'm not concerned about the Spamwall thing though, we're phasing it out in favour of client-side filtering.

Thanks.

Just FYI:

We normally set up a CISCO ASA5505 for customer environments like yours. It is not expensive (all is relative of course) and is a proper fw with IDS and has capabilities to allow multiple subnets, multiple ISPs and full VPN support. The smallest product you'd need has art. no: ASA5505-UL-BUN-K9, and costs about 420EUR. I have ready config scripts I can share with you if you'd like. But it's just a suggestion.

For clients behind DSL lines we install a small IP-reporting tool on their server that reports back to a web-service we have, telling us their external IP-nbr. We can then connect over VPN to their ASA equipment and save hours by not having to drive all over Sweden. It also makes it very easy to maintain their machinery during off-hours without the need to access their physical location. Saved hours and increased efficiency and security is very easy to sell to the management.

[quote user="Barius"]I really think David should give consideration to providing a patch.[/quote]

This issue was discussed back in July soon after 4.62 was released.  David replied in the thread and said he would look into providing a patch.  See  http://pmail.praktit.se/forums/thread/10291.aspx

Thx Paul, reliable memory neurons as always [:D]

Hmm, who's definition of 'soon' are we going by here...?

To be honest, and this is just a guess, is maybe this year. I believe David focuses on releasing Pegasus Mail.