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

[routerguy]

Also on production system running 6.03. Did you file a bug report or get this resolved?

[bthom73]

Nope, it's still an issue, no solution yet...

I haven't filed an actual support ticket for it yet though (I got sidetracked with some other work issues). Thanks for the reminder though. I'll try to open a ticket and start working with their tech support later this week.

-Brian

[routerguy]

Submitted as bug 43034

[veronica]

Did you try running zmfixperm --extended ?

[bthom73]

Nope, but on a production server I'm not about to start experimenting...

What does "zmfixperm --extended" do?

Thanks,
Brian

[phoenix]

What does "zmfixperm --extended" do?

/opt/zimbra/libexec/zmfixperms --help

[bthom73]

Sorry, I meant at a lower level (i.e. what does it actually do to the filesystem and/or databases, as opposed to what the purpose of the command is).

Even the purpose of the command is still unclear though -
"-extended Extended fix, includes store, index, backup directories"

I do appreciate the suggestion, but without more info I'm not sure if it's worth spending a day to build up a mirror of the production server in order to try it.

At this point in time it probably makes more sense to go the support contract/support ticket route since it's been almost a month since the original posting and based on the replies it appears that it's not an obvious(common) problem.

Thanks,
Brian

[phoenix]

At this point in time it probably makes more sense to go the support contract/support ticket route since it's been almost a month since the original posting and based on the replies it appears that it's not an obvious(common) problem.

I'd suggest you contact support and give them full details of the problem and whether you're using the proxy (and what the configuration is with the multi-servers) and if this is in a shared folder or delegated account etc., also include the information to posted in the first post.