Hi.

OK, after struggling with the email client in Opera7, I have given up. It's the most non-intuitive, byzantine piece of crap I've come across for some time.

Can anyone suggest a REAL email client I can get (NOT under ANY circumstances anything that's been anywhere near microsoft!) that supports IMAP and runs under Win2K? I need one that correctly handles folders (the way Opera M2 does it is both warped in the extreme and apparently broken anyway), and preferably multiple mailboxes.

pca

I still use Eudora. www.eudora.com

I believe it does everything you're asking.

Best of all : it hasn't got anything to do with MS!

I've yet to find a decent IMAP client under Windows as well. Everybody seems to only support POP3 properly.

Speaking of which, if you're using Opera 7.0 you need to upgrade to 7.01. There was a whole bunch of security holes in it and Opera have released a new version that fixes them.

- Trevor

Mozilla's mail client isn't bad, but I still use Pine.

I second Mozilla. It may be a little bloated, but it works well and doesn't choke on badly-formatted or very large messages.

Oh, and the quoted-printable option in Mozilla should be (depending somewhat on version, I suppose):

Edit -> Preferences -> Mail & Newsgroups -> Composition -> For messages that contain 8-bit characters ...

I rather like PocoMail. I've only used it for POP, but I believe it does do IMAP too. It's very configurable, has its own scripting language, has spam-filters built in, can handle HTML email (though it can be prevented from downloading stuff), it's skinnable (if you're into that sort of stuff), and, best of all, it's got nothing to do with MS.

Bryan.

I like mulberry from cyrusoft, (the fact that they do kerberos and have a linux version makes big points for them) but it seems to be hit or miss whether other people do. Handles folders and multiple mailboxes, though what makes folder handling "correct" is beyond me

Can anyone suggest an imap ssl-capable mail client for PalmOS? Only thing I found is papi-mail, and I need to buy it before I can try the thing I'm worried about not working, ssl, so unless I can find someone who has it to let me try it with my mail server on their Palm, I'm not buying...

I gave up finding an IMAP email client that I liked. I thought about writing my own, but gave up when I read the RFC for IMAP...

I now use http://www.squirrelmail.org/ on my server and so don't use a local client anymore. At least that way I can alter Squirrel mail to suit me.

Hmmm. I always thought that the IMAP RFC was fairly consise. I often telnet to my IMAP port to do random maintenance on my mail folders.

Not nearly as concise as POP

Okay. Concise for something that has more than one feature.

It might be concise for very simple actions. Making an efficient complex client is another matter. IMAP isn't as simple as most of the other Internet protocols, it has all sorts of complications over and above things like SMTP, HTTP etc

IMAP is not a simple question, answer, question, answer (ad infinitum) protocol. You can get data back in an answer that isn't directly connected with the question for example (telling you that the message counts have changed).

If you want an efficient client it needs to be much more stateful than the average Internet protocol client app.

Also, if I wrote a client I would want to "do it properly" which means making it work with various servers that don't quite do what the RFC suggests that they should...

Okay. Concise for something that has more than one feature.

I've really got to stop drinking tea while I read the BBS in the mornings.

Another one you may want to look into is IMP, part of The Horde Project. See the attachment for the hacks I have done to the multiframe view in IMP to make it feel like a normal e-mail program.

I did try IMP before ending up on Squirrel. I ran into problems just getting the thing up and running. It had too many prerequisites to get it to run, which is a shame because it looks good. I didn't really want to mess around installing (and in some cases updating) too many components as I'm running it on my mail DNS/mail server...

Squirrel in comparison was much easier to get running (only took 15 minutes).

If you want an efficient client it needs to be much more stateful than the average Internet protocol client app.

Hear, hear. IMAP is baroque and hairy for the simple things[1] without actually providing the complex things you want (there's no way to search in multiple folders, for instance, let alone isearch, and no way to change a message's title in case you want to relabel "Re: Functional Spec" as "Marketing go off on one about EQ").

Peter

[1] Try and find, for instance, an unambiguous description of how to derive "part numbers" for FETCH BODY[4.2.1] from the insane pseudo-Lisp you get from FETCH BODYSTRUCTURE.

Had XML existed back when IMAP was invented I think it would have been a very different protocol...

...or maybe not

It had too many prerequisites to get it to run, which is a shame because it looks good.

Agreed. If I remember right, I had to compile a new PHP version to get it to run, as the one in my distro didn't quite have all the bits it wanted. The install I'm running hasn't been upgraded in a long time due to this. Squirrelmail is also running on my system as well, as one of the other miniinfo.net users prefers it.

If you plan on archiving a ton of e-mail and later searching it, I do recommend investing the time into IMP though. It seems to be much less resource intensive then Squirrelmail for searching, and much quicker. I have all my e-mail back to 98 archived in it.

One thing that is nice about Horde is the API. I'm slowly finishing a web based procmail editor that will simply plug into Horde. I'm also looking at the other Horde projects to help justify my time investment in getting it installed

I'm going to be reloading my Linux server here in the next few months, I'll let you know if anything has improved on the installation front.

Had XML existed back when IMAP was invented I think it would have been a very different protocol...

Yes, why invent your own insane pseudo-Lisp when there's a ready-made insane pseudo-Lisp you could use instead?

Actually I agree, XML would be a much saner pseudo-Lisp to have used.

Peter

Actually I agree, XML would be a much saner pseudo-Lisp to have used.

Then my IMAP client could just be a bunch XSL transforms. Now that would be fun...

And just think, instead we'd need to pull an XML parser into every mail client. Not better, not worse, just differently evil.

One more nod for Mozilla. It's gotten noticably more stable in recent releases and the new 1.3alpha has a nifty Bayesean spam filter feature. According to MozillaZine, they're in the code-freeze stage for 1.3beta, with something like seven "blocking" bugs remaining. Expect the obligatory Slashdot announcement soon. That might be a good point to give Mozilla a shot.

That would suit me fine

I rarely write a bit of code that doesn't involve using an XML DOM and an XSL processor.

Try and find, for instance, an unambiguous description of how to derive "part numbers" for FETCH BODY[4.2.1] from the insane pseudo-Lisp you get from FETCH BODYSTRUCTURE.

no way to search in multiple folders

no way to change a message's title

Okay, I realize that you're not saying POP is better, but it is the only current alternative, and, as such, it reminds me of when Microsoft, trying to spread some FUD about Sun E10k machines said:

System boards that are hosting non-pageable kernel data structures cannot be removed from a domain without interrupting service. The Solaris operating system has to undertake a special "quiesce," or suspend, operation while the critical pages are migrated to another board.

So their machine can do remarkable things that yours can't even begin to think about doing, and you're complaining that one has to expend some effort to get it to work or that it has some limitations?

I'll admit that parsing BODYSTRUCTUREs is non-trivial at best, but POP has nothing of the sort. Okay; I think you can get just the headers of the message, or just the first n bytes, but nothing intelligent.

It's not exactly hard to send the same search to multiple folders, and POP doesn't even have the concept of multiple folders.

I'd say that changing a message's title is beyond the scope of any mail client. However, you could rewrite the message and push it back to the IMAP server, which I'm pretty sure you can't do with POP.

I'll admit that parsing BODYSTRUCTUREs is non-trivial at best, but POP has nothing of the sort. Okay; I think you can get just the headers of the message, or just the first n bytes, but nothing intelligent.

POP isn't an attempt to solve the problem (of remote mailstore access). IMAP is a flawed attempt to solve the problem. This means that IMAP is more deserving of criticism.

It's not exactly hard to send the same search to multiple folders, and POP doesn't even have the concept of multiple folders.

It's not hard, but it shouldn't be the client's job. There's a lot of protocol baggage associated with SELECTing each folder in turn (you can only search the currently-selected folder), whereas the server has all the information to do it all in one go.

I'd say that changing a message's title is beyond the scope of any mail client. However, you could rewrite the message and push it back to the IMAP server, which I'm pretty sure you can't do with POP.

You can't rewrite it exactly the same IIRC (you can't set the envelope). But semantically, you don't want to rewrite the message, you want to annotate it. You can associate binary flags with the message (if the server supports it) but not text. Acorn's !Email let you change the title that appeared in message lists (when you opened the message you saw its original title).

Peter

IMAP is a flawed attempt to solve the problem. This means that IMAP is more deserving of criticism.

Yes, but it's also the only attempt to solve the problem. (Also, I'd argue that POP is a half-assed attempt to do anything, and is more deserving of a swift kick in the ass.)

Which, of course, is not to say that IMAP can't be improved. Searching multiple folders, or at least allowing a search on a non-selected folder, would make a lot of sense. I suppose annotations aren't a bad idea, but it's nothing I would be very interested in, and I doubt it's of much interest to many people. And you can insert the exact same message that already exists. The big differences are that it would have a different UID and be in a different position in the natural order of the IMAP folder. The envelope, if you're talking about an SMTP envelope, isn't recorded on an IMAP server, IIRC, and, in this case, the replacement message wouldn't even have one, as it never went through SMTP channels.

Oh, I think the BODYSTRUCTURE is pretty well defined in the BNF at the bottom of RFC2060.

The envelope, if you're talking about an SMTP envelope, isn't recorded on an IMAP server, IIRC, and, in this case, the replacement message wouldn't even have one, as it never went through SMTP channels.

It's not available via IMAP (except that the "internal date" comes from the envelope) but that doesn't mean it's not recorded. If the server keeps its mail in Berkeley mailfiles, the "From<space>" line (as opposed to the "From<colon><space>" line) contains the SMTP envelope From, which cannot be written correctly by IMAP APPEND (it always writes the email address of the imapd user). This issue is what the last paragraph of RFC2060 sec 6.3.11 is trying to alert people to.

For the same reason, you can't sensibly remove attachments but keep the message.

Oh, I think the BODYSTRUCTURE is pretty well defined in the BNF at the bottom of RFC2060.

Yes, it's well-defined how to parse it, it's figuring out what part-specifiers refer to what parts that's "interesting". (The rules are deterministic, they're just baroque.) Or at least I found them highly counterintuitive.

In case you're wondering how I developed these strong opinions, I did write about three-quarters of a Qt-based IMAP mail client once (it does all the reading stuff but the composer is only half-done and the address book isn't there yet). I gave up when Evolution came along, and now it doesn't compile against modern versions of Qt. The long-term game-plan had been (1) vanilla IMAP client (2) vanilla IMAP server less ludicrous than UW (3) IMAP extensions (hey, at least they got the extensibility right) for all the missing features such as whole-server search, isearch-with-summaries, annotations, server-side address book and so on -- but even step (1) proved to be an unnecessarily gigantic amount of work.

Peter

The note? Yeah, I was confused by that too, as they never reference SMTP envelopes outside that sentence.

My answer to both your Berkeley mailfiles point and bullet 2 is Cyrus. It's head and shoulders above UW in pretty much every aspect.

Cyrus is annoying to build, not hard to set up, but very nice to administer. A small amount of my code is in Cyrus, and I've worked with every one of the lead developers, in sequence

Of course, the current lead developer is in the office next to mine...