This is an example of a successful imap login as seen in the mailbox.log in Zimbra. (one single line, though it is appearing word-wrapped here)
2008-05-18 01:10:24,999 INFO [ImapSSLServer-2009] [name=sue@example.com;ip=1.2.3.4;] imap - user sue@example.com authenticated, mechanism=login
Compare what happens with a bad password (one nice log line followed by 20 lines of stack trace)
2008-05-18 01:10:25,109 WARN [ImapSSLServer-2010] [ip=1.2.3.4;] imap - login failed
com.zimbra.cs.account.AccountServiceException$AuthFailedServiceException: authentication failed for bob@example.com
Code:account.AUTH_FAILED
at com.zimbra.cs.account.AccountServiceException$AuthFailedServiceException.AUTH_FAILED(AccountServiceException.java:120)
at com.zimbra.cs.account.AccountServiceException$AuthFailedServiceException.AUTH_FAILED(AccountServiceException.java:116)
at com.zimbra.cs.account.ldap.AuthMechanism$ZimbraAuth.doAuth(AuthMechanism.java:112)
at com.zimbra.cs.account.ldap.LdapProvisioning.verifyPasswordInternal(LdapProvisioning.java:2795)
at com.zimbra.cs.account.ldap.LdapProvisioning.verifyPassword(LdapProvisioning.java:2768)
at com.zimbra.cs.account.ldap.LdapProvisioning.authAccount(LdapProvisioning.java:2647)
at com.zimbra.cs.account.ldap.LdapProvisioning.authAccount(LdapProvisioning.java:2626)
at com.zimbra.cs.security.sasl.AuthenticatorUtil.authenticate(AuthenticatorUtil.java:25)
at com.zimbra.cs.imap.ImapHandler.authenticate(ImapHandler.java:1012)
at com.zimbra.cs.imap.ImapHandler.login(ImapHandler.java:988)
at com.zimbra.cs.imap.ImapHandler.doLOGIN(ImapHandler.java:984)
at com.zimbra.cs.imap.ImapHandler.executeRequest(ImapHandler.java:435)
at com.zimbra.cs.imap.TcpImapHandler.processCommand(TcpImapHandler.java:151)
at com.zimbra.cs.tcpserver.ProtocolHandler.processConnection(ProtocolHandler.java:160)
at com.zimbra.cs.tcpserver.ProtocolHandler.run(ProtocolHandler.java:128)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Thread.java:619)
WTF is the point with including all that java stack trace garbage in the log when it is a simple bad password?
Catch the bad password event, log it, and move on.
Do not dirty my logs with stupid stack traces that just fill up the disk and provide no value.
I see this in many other java products too, btw. Including where I am currently working. Gives me endless heartburn.
Lazy. Ass. Java. Propeller Heads. Learn to use Log4J or whatever and keep those stack traces for only really dire circumstances.