Recent (probably MacOS) mail app provoking endless cyrus.index writes on 2.3 server. [WARNING: DKIM validation failed]

Bron Gondwana brong at fastmail.fm
Thu Oct 22 18:37:28 EDT 2015



On Fri, Oct 23, 2015, at 08:39, ktm at rice.edu wrote:
> On Thu, Oct 22, 2015 at 10:54:28PM +0200, Eric Luyten wrote:
> > On Thu, October 22, 2015 10:39 pm, ktm at rice.edu wrote:
> > > On Thu, Oct 22, 2015 at 10:32:40AM -0400, bacon wrote:
> > >
> > >> Apple released OS 10.11.1 update yesterday.  It shows that it includes,
> > >>
> > >>
> > >> - Fixes an issue where outgoing server information may be missing from
> > >> Mail
> > >> - Resolves an issue that prevented display of messages and mailboxes in
> > >> Mail
> > >>
> > >>
> > >> Does anyone know if this fixed the problem.  I've asked my users not to
> > >> use Mail on El Capitan until this bug is fixed.
> > >>
> > >> Meanwhile, I'm working in my spare time to upgrade my cyrus-imapd on
> > >> RedHat Enterprise Linux 6 from the 2.3 series distributed by RedHat to
> > >> the 2.5 series which I'll have to build and maintain myself.  That's an ugly
> > >> job and one that I don't really want to do.
> > >>
> > >> Fred
> > >>
> > >>
> > >
> > > Hi Fred,
> > >
> > >
> > > It does not appear to have addressed the problem. We are trying to gather
> > > more information.
> > 
> > 
> > In
> > 
> >    https://discussions.apple.com/thread/7267399
> > 
> > someone states older Cyrus servers are returning a syntactically not quite
> > correct response to the EXPUNGE command but I'm having a hard time buying
> > this for an explanation.
> > 
> > Oh, and someone in there asks for help to get the Apple bug report (22996765)
> > escalated.
> > 
> > I think at our site we have reached the count of 100 (one hundred) El Capitan
> > Mail.app users.
> > 
> > 
> > Eric.
> > 
> 
> Hi Eric,
> 
> If they are thinking that the example in the RFC is the specification, they are
> not correct. The IMAP server responses to determine completion of the EXPUNGE
> command are "OK" for a completed EXPUNGE, "NO" for a failure, and "BAD for unknown
> command or invalid arguments. Everything after those words are not germane to
> whether or not the command completed. The tag is what links the OK to the EXPUNGE
> command and not the "EXPUNGE completed". Sigh, they had it right and now it is
> broken.

Actually, the ImapTest command complained about this too:

http://imapwiki.org/ImapTest

>From RFC3501:

response-tagged = tag SP resp-cond-state CRLF


resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text
                    ; Status condition

resp-text       = ["[" resp-text-code "]" SP] text

text            = 1*TEXT-CHAR

So the exact text after the OK response doesn't matter, but it MUST be SP followed by at least 1 TEXT-CHAR.

This is pretty easy to patch in 2.3.x if you're forced to remain there for reasons.  It is, of course, fixed in later versions.

Bron.


-- 
  Bron Gondwana
  brong at fastmail.fm


More information about the Info-cyrus mailing list