Disable harvest defense in 6.0.2? (DEFEND_ACCOUNT_HARVEST)

[bthom73]

Hello all,

We just recently upgraded from v5.0.11 to v6.0.2 (network edition) and are now intermittently seeing the following errors when users try to send email via the web interface. The error message that the user sees is a pop-up dialog box that says "Permission denied". And, if they click on the "See details" button, they see:

Permission denied.
method: SendMsgRequest
msg: permission denied: can not access account
code: service.PERM_DENIED
detail: soap:Sender
trace: btpool0-70://zimbrapro/service/soap/SendMsgRequest:1257264147022:c06e79876b84b30b
request: Body:...


Some messages go through fine and some don't. Is anyone aware of a workaround to disable what appears to be some sort of harvest protection?

Thanks,
Brian

2009-11-03 10:42:12,703 WARN  [btpool0-64://zimbrapro/service/soap/SendMsgRequest] [ip=10.10.10.10;] SoapEngine - unable to construct SOAP context
com.zimbra.common.service.ServiceException: permission denied: can not access account
ExceptionId:btpool0-64://zimbrapro/service/soap/SendMsgRequest:1257262932703:c06e79876b84b30b
Code:service.PERM_DENIED
        at com.zimbra.common.service.ServiceException.DEFEND_ACCOUNT_HARVEST(ServiceException.java:286)
        at com.zimbra.soap.ZimbraSoapContext.<init>(ZimbraSoapContext.java:220)
        at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.java:201)
        at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.java:156)
        at com.zimbra.soap.SoapServlet.doWork(SoapServlet.java:291)
        at com.zimbra.soap.SoapServlet.doPost(SoapServlet.java:212)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
        at com.zimbra.cs.servlet.ZimbraServlet.service(ZimbraServlet.java:181)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
        at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502)
        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
        at org.mortbay.servlet.UserAgentFilter.doFilter(UserAgentFilter.java:81)
        at org.mortbay.servlet.GzipFilter.doFilter(GzipFilter.java:132)
        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1148)
        at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:379)
        at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
        at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
        at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
        at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
        at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
        at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
        at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
        at org.mortbay.jetty.handler.rewrite.RewriteHandler.handle(RewriteHandler.java:230)
        at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
        at org.mortbay.jetty.handler.DebugHandler.handle(DebugHandler.java:77)
        at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
        at org.mortbay.jetty.Server.handle(Server.java:324)
        at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:525)
        at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:882)
        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747)
        at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
        at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:387)
        at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
        at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:451)

[bthom73]

Here's a bit more information regarding this failure in 6.0.2 -

The issue seems to happen specifically to people who actively use their "Drafts" folder. By that I mean the user starts to reply to an email message from their inbox. As they're typing they decide to temporarily save the reply as a draft and go do something else. They later come back and double-click on the message in their Drafts folder to finish the composition and click send. That's when the issue most often occurs.

The workaround is to copy the text from the failed outgoing message, go back to the Inbox and find the original message that needed to be replied to, paste the text in as the reply, and click send. Then delete the failed outgoing message from the Drafts folder.

This is a production system in question and I'll go ahead and use one of our alotted support tickets if I have to, but it seems like more of a bug than a support question.

Thanks,
Brian