Then update Horde when an exploit is found and fixed.
But once again, if you tighten the security at the POP server level 
then you prevent attacks from *any* application connecting to it, not 
just POP.



Obviously, you can do whatever hacking you need to on your local 
server, but there is absolutely no need for this kind of security 
check in IMP or Horde.  Completely redundant and unnecessary.

The POP server is not visible to the public network, but IMP runs on 
the same server. The scenario that comes to my mind is:

1. Attacker finds an exploit to gain restricted access (the Horde help 
bug for example)

2. Attacker uses IMP to remotely (possibly from different addresses to 
cover his track) to find the root password

I imagine the situation where IMP runs on the mail server, but POP is 
limited to the internal network only is actually quite common, so this 
is likely something that other users might be struggling with as well.

I added the following code to _authenticate() in imp/lib/Auth/imp.php 
to prevent this attack, but a more generic solution wouldn't hurt.



if( !strcasecmp( $userID, "root" ) )

{

         mail( "admin@my_network", "WARNING!", "'$userID' login 
attempt from $_SERVER[REMOTE_ADDR] in horde!", "From: 
hordeadm@my_network" );

         return false;

}

Like configuring your POP server to prevent this.  Disabling access 
via IMP does nothing to protect security - since an attacker could 
just directly connect to the port and try username/password 
combinations all day long and just bypass any restrictions in IMP.

I noted that using IMP as the authentication plug-in it offers no 
protection to prevent "root" authentication through a POP server. This 
allows an attacker to try different root passwords remotely while 
remaining quite anonymous. I think there should be a blacklist of 
accounts that are never allowed to login or some other way to prevent 
trying an uncounted number of account/password pairs remotely.