I replied to you.

If I could only find a client that worked like Eudora…Take care and thanks for rattling the cages.  I sure someone takes notice…or at the very least contact that “person” who had a hand in writing the backend library for php-imap.

Thanks again for bringing this problem back into the light…

OH this was EMC’s official response to my problem.–

several users reported the same issue, it’s an issue directly connected to GoDaddy server’s, even though we’re trying to resolve this issue, our options are limited
as it is a problem on GoDaddy’s side.

We believe fix for the issue should come soon, please be patient.

Thank you for understanding,

Posting with ALL CAPS won’t help to make your point come across.

With all respect to Marc Crispin he’s not very liked in the IMAP community or by the IMAP server authors because of his stubbornness and constant refusal to solve real world problems. The NAMESPACE command was added to IMAP precisely by those people that were trying to fix a problem with the base IMAP protocol that was left unspecified by the base specification. Note that RFC 2060 specifies the very same “IMAP4rev1” protocol as RFC 3501, only RFC 3501 actually makes the text and requirements clearer. Since NAMESPACE is an *extension* there was no need to make a new revision when the base protocol was updated. You can clearly check that RFC 3501 doesn’t make RFC 2342 obsolete and there’s no separate document that makes RFC 2342 deprecated (which is common practice when deprecating obsolete extensions, authentication schemes and so on). Other elementary extensions such as UIDPLUS specified by RFC 2342 weren’t updated for years after RFC 3501 was released (RFC 3501 was released in 2003, RFC 4315 which updated RFC 2342 was released 2 years later).

Disabling the NAMESPACE command on Cyrus without the “alternate namespace” option has the effect that eM Client can’t determine where personal folders are and thus they are all placed under INBOX. While this is exact representation of what the server sends it is not what many users expect and it’s also not what is usually displayed in their web clients. Creating a folder in the client then results in attempts to create a folder in the root and not under INBOX, which obviously fails horribly with errors.

> EMC doesn’t know the difference between “Reference” and “Context” and “wildcard.”  Nor does it know the difference between “namespace” and “root tree.”

That’s because many of these terms are loosely defined, implementation dependant and not properly implemented by the servers. While the references might made a sense in the original *nix servers where the mailboxes were directly mapped to file system hierarchy that’s not the case anymore for security and other reasons. We dropped usage of “reference names” because they were poorly implemented by servers and don’t offer any benefit for normal use case scenarios, possibly no scenarios at all given the fact that the only server that actively exploited them was the discontinued UC IMAP server (made by no one else but Mark Crispin).

Also the use of “%” wildcard instead of “*” wildcard was actually proposed by Mark Crispin himself (http://dovecot.org/client-commandments.txt) “Link httpdovecotorgclient-commandmentstxt”). We only later discovered how poorly it is implemented by different servers and how many problems are caused by crippled servers (including Gmail and its case-(in)-sensitive handling of INBOX). We didn’t change the implementation in eM Client yet, but if I were to write a client today I would never use the “%” wildcard because of these problems.

Namespaces provide a way to distinguish root trees (and not only them) in the IMAP hierarchy. The base protocol has no such feature and your “shared” folder is no different than any other folder for the client even though the function is very different.

The “#” namespace convention mentioned in RFC 3501 isn’t used in practice as widely as you believe.

I don’t want to go into the discussion about SUBSCRIBE/UNSUBSCRIBE/LSUB. The intentions of these commands are perhaps good and in some use cases they actually make sense, but the fundamental problem is that many servers misimplement them and many clients automatically subscribe any folder you create.

Godaddy uses the NSA data stores in Utah.

Of course, it’s the NSA’s fault that EMC can’t speak IMAP, right?

Maybe “the fix” is a CIA drone strike? 

We are very aware of the missing feature (no support for displaying non-personal namespaces in the client) and we offered a workaround for one sever (Cyrus) that actually makes it usable. While we acknowledge that there is a deficiency in eM Client and that the workaround may not be universally applicable a majority of our customers are using servers where the problem doesn’t arise in the first place. You are free to open a feature request that can be voted upon, but insulting us won’t help the case.

In the words of General George S Patton… “NUTS!”


I’m not sure what the response was for, but GoDaddy uses modified Courier IMAP software that routinely breaks different things. Most recently it was the NOOP/CHECK/IDLE commands. We pointed out that their change actually breaks the RFC 3501 and outlined the specific parts of the specification that were not followed. The only response we got back is that they are not going to fix it since it works with Outlook (which wasn’t exactly true either).

We are definitely not as clueless as you think. The world is not ideal. We are not developing a client that has to work with one IMAP server. We have to support many IMAP servers and plenty of them are buggy and not even RFC 3501 compliant.

Do yourself a favor…

Research and study the C-Library behind the PHP php-imap library.

>>> We have to support many IMAP servers and plenty of them are buggy and not even RFC 3501 compliant.  <<<

That’s why they call it a “protocol”.  Protocols are STRICT.  You either get it right or you go out of business.

Examples:  Ethernet, VLANs, IP, TCP, Arcnet, X25, … ad nauseum… get the picture?

ps…  And… Match up the code to the ABNF Formal Syntax of 3501. 

Food for thought:


Why?  What’s the Formal Syntax say?

1 list * *
* LIST (\HasChildren) “.” INBOX
* LIST (\HasNoChildren) “.” INBOX.Contacts
* LIST (\HasNoChildren) “.” INBOX.Drafts
* LIST (\HasNoChildren) “.” INBOX.Junk
* LIST (\HasNoChildren) “.” INBOX.Notes
* LIST (\HasNoChildren) “.” INBOX.Outbox
* LIST (\HasNoChildren) “.” INBOX.PCI
* LIST (\HasNoChildren) “.” INBOX.PII
* LIST (\HasChildren) “.” INBOX.Sent
* LIST (\HasNoChildren) “.” INBOX.Sent.ZXc
* LIST (\HasNoChildren) “.” INBOX.Spam
* LIST (\HasChildren) “.” INBOX.Trash
* LIST (\HasNoChildren) “.” INBOX.Trash.ASDF
* LIST (\HasNoChildren) “.” INBOX.Trash.SAD
* LIST (\HasNoChildren) “.” INBOX.Trash.asdfasdfasdfasdfasdfasdf
* LIST (\HasChildren) “.” INBOX.adsfasdfasdf
* LIST (\HasNoChildren) “.” INBOX.adsfasdfasdf.asdfasdf
* LIST (\HasNoChildren) “.” INBOX.documents
* LIST (\HasNoChildren) “.” INBOX.frank
* LIST (\HasNoChildren) “.” INBOX.hold
* LIST (\HasNoChildren) “.” INBOX.sdfgsdfhgsdfg
* LIST (\HasNoChildren) “.” INBOX.test
* LIST (\HasNoChildren) “.” INBOX.testcal
* LIST (\HasNoChildren) “.” INBOX.testcontacts
* LIST (\HasNoChildren) “.” news.general
* LIST (\HasNoChildren) “.” shared.keepers
* LIST (\HasChildren) “.” user.ebay
* LIST (\HasNoChildren) “.” user.ebay.Drafts
* LIST (\HasNoChildren) “.” user.ebay.Junk
* LIST (\HasNoChildren) “.” user.ebay.Notes
* LIST (\HasNoChildren) “.” user.ebay.Outbox
* LIST (\HasNoChildren) “.” user.ebay.Sent
* LIST (\HasNoChildren) “.” user.ebay.Trash
* LIST (\HasChildren) “.” user.mailmgr
* LIST (\HasNoChildren) “.” user.mailmgr.Drafts
* LIST (\HasNoChildren) “.” user.mailmgr.EPHI
* LIST (\HasNoChildren) “.” user.mailmgr.GLBA
* LIST (\HasNoChildren) “.” user.mailmgr.Junk
* LIST (\HasNoChildren) “.” user.mailmgr.Outbox
* LIST (\HasNoChildren) “.” user.mailmgr.PCI
* LIST (\HasNoChildren) “.” user.mailmgr.PII
* LIST (\HasNoChildren) “.” user.mailmgr.Sent
* LIST (\HasNoChildren) “.” user.mailmgr.TLS
* LIST (\HasNoChildren) “.” user.mailmgr.Trash
* LIST (\HasNoChildren) “.” user.starnet

Hi, thank you for your constructive criticisms, your thoughts and your input on this issue is very valuable to us. We understand this may be causing some issues with selected servers and we’ll be happy to consider making improvements for future releases. What you’re describing is currently not supported in eM Client and we understand this may be causing troubles on your end, if you’re a paying customer we we’ll be happy to offer you a discount on your purchase or refund your purchase completely while we’ll be working on resolving this issue, if you’re unable to use this product as you expected.

Once again thank you for all your input and hard work you’ve put into helping us find the right direction for this issue, we appreciate it, but please not resolving such issues and developing new features may take some time before changes take effect.

Hope you understand, if you have any future queries to pinpoint to us, I’ll be more than happy to hear your thought on the application, you can even contact me directly at mcgregor@emclient.com.

Thank you for understanding,
Paul McGregor.