Your comments

Interesting. For me out refuses to work unless ownership is mail:mailmail and permissions are 777. It worked no problem as 755 until the last update for me
Apologies for the typos, i was typing this from my phone, and i must say This forum is pretty awful when it comes to using mobile devices. Let me correct the typos.

*Switching to Ajenti-V
*Roundcube is configured to connect to localhost
It seems Fail2ban in ajenti has a TON of non standard configs, im afraid of breaking something here, any advice where to go? it actually seems that fail2ban is only protecting the ssh system not the mail system as well? how is this set up?
Alright so i updated ajenti and the issue returned! this time the file authdaemon was owned by daemon:daemon so i once again switched it from daemon:daemon to mail:mail however the issue still persisted, so i gave it back 777 permissions and it once again worked. switching the owner back to daemon:daemon breaks it again. It must be mail:mail and 777 permissions. the concerning part there is the 777 permissions. why should the world have read write and execute access to something like that?
ok i chowened the dir for authdaemon to mail instead of root and changed permissions from 777 to 755 (i dont think the world should have write access to authdeamon...) and everything seems to be working now.
courier is running permissions for the folder are 777 and im on ubuntu so it'd be apparmour which is enabled by default.
thanks fo rthe location there, im used to postfix and didnt think to check the exim folder (duh)

ok this is what i am seeing in there:

2014-11-26 04:50:02 login authenticator failed for ( []: 435 Unable to authenticate at present ( failed to connect to socket /var/run/courier/authdaemon/socket: Permission denied
righ tif i change the hostname in the panel to the panel no longer works (which was the issue here even though the panel worked fine on this configuration previously)
right. i mentioned that i got it working. is it required that the hostname be set to the ip and not the fqdn?
never mind, i got it sorted for some reason after working for a few weeks with the hostname set as the server's fqdn, it no longer wanted that after the upgrade, i now needed to use the server's ip.