I'm actually the other Evolution mail hacker (NotZed being the other):-)
My biggest complaint about sleepycat (other than it being slow) is that they change formats between minor releases.
You'll note that Evolution REQUIRES libdb-3.1.17 for the addressbook for this very reason. While we could most likely easily make Evolution able to use various versions of libdb, the simple fact that upgrading your libdb instantly breaks your contacts database is a major downside.
It also means that copying the addressbook.db file to another machine running Evolution linked against a different version of libdb would simply not work.
This is why we require exactly version 3.1.17 of the library.
The original design of the indexer used libdb as a storage but that turned out to be unbearably slow and the indeces were massive.
The second design used a custom file format consisting of blocks but required you to load it into memory in order to use the information, which means that it's not very scalable (it scaled ok up to ~10,000 messages per folder).
the third design (only in the CVS development branch) again uses custom file formats (there are now multiple files) based on that on-disk hash table design above. This gives us the advantage of not having to load the entire index into memory before being able to use it (making it much more scalable - easily handles >100,000 messages per folder? I don't really know the statistics on it). On the downside, it means we have to make I/O calls. However, the design of the file formats makes it extremely fast lookups and so the user still hardly notices it (if they notice it at all?) even at 10,000 messages in a single folder.
Anyways, if you are really interested - you can checkout cvs evolution and read evolution/camel/developer-docs/camel-index.txt
I gather you've never READ the MIME rfcs, have you?;-)
MIME solves i18n issues as well. Not to mention that uuencoded blocks in the middle of a text stream do not even come close to solving all the problems that MIME solves.
MIME was designed to solve problems that could not be addressed using uuencode. Think of uuencode as a quick hack that worked so long as you you only intended to send US-ASCII email messages.
Then along came MIME, the properly designed transport medium, that solved i18n issues, solved the problem of some transport agents not understanding 8bit characters, and allowed logic structuring of data (not to mention "better compression" which seems to be the rave these days with yenc which simply does a horrible job of trying to solve the same problem that MIME has already solved).
so no, uuencode did not solve what MIME solves and has solved since ~1995.
considering the fact that he pretty much knows the RFCs by heart (he wrote most of the MIME parser in Evolution), i'd say he knows it a lot better than you:-)
XML will not speed up disk access. You'd still have to parse the file... and MIME is a XML-ish type format to begin with, so adding XML on top of that just adds bloat and nothing more.
if you want to speed up disck access to a folder in, say, mbox format - what you do is keep a summary file which stores the offsets of each message (and probably other some other pre-parsed information such as from/to/cc/subject/date/in-reply-to/references headers so that you can easily display a message-list and optionally thread it wihout having to parse the messages again).
You could perhaps encode this file in XML, but it'd be a lot faster if it were a binary file.
read (fd,
is a lot faster than decoding XML which requires massive amounts of mallocing and freeing on top of the file I/O.
it is a well-known fact that XML is slow.
the only plus that XML has is that it gives you a lexer for free and it's in a human readable format. These are not necesary for a file that can be auto-generated at will on an mbox file (for example).
Why would you want to waste even more space by putting an easily parsable MIME message into XML? What could you POSSIBLY hope to gain here?
The whole point of MIME is to make messages easily parsable. XML will do absolutely nothing but bloat the file. Not to mention you can't actually pre-parse the message into XML and get rid of the MIME formatting because then the format would be completely useless in that you wouldn't be able to verify signatures. Not to mention that XML can't handle binary data, so you'd still have to encode.
yEnc is a complete waste of time. Had the author of yEnc actually gone out and read some pre-existing MIME specifications before going out and re-inventing (a square) wheel, he would have found that MIME already defines an encoding that gets even better compresion than yEnc. It's called "binary". Yes, MIME can handle binary content.
Content-Transfer-Encoding: binary
it's as simple as that.
Btw, I've implemented the yEnc specification in my library GMime
My favourite part of the yEnc authors defense for why he implemented yEnc is "but most news clients don't implement MIME". Hah, join the real world where NO news reader implemented yEnc. (yes, I know there are clients that implement it now, in fact my code is used in a few of them).
Believe me as someone who spends time hacking on news and mail readers, yEnc is nothing but a headache.
1. Evolution is NOT "Basically mbox with database features". It can use Maildir or MH as the backend (and you can write your own plugin to extend this if you like).
2. Evolution's body indexing and summary files are extremely fast and efficient, about the best you'll get. I hear MySQL has text indexing capabilities that are extremely fast, but I'm not sure if they are faster than Evolution's indexer or not. Might be interesting to check this out.
3.
> But the thing that bugs me most is disk space. Typical inboxes are > made of 5% to 10% of Text including Headers and HTML. The rest are > BASE64- (or UU-) encoded pictures, word documents, zip archives and so > on. The problem here is the encoding which wastes considerable amounts > of space (at least one third).
It's theoretically possible, if you wrote your own Evolution storage plugin, to change the Content-Transfer-Encoding header value of binary attachments to "binary" (and text attachments to "8bit") before writing the message out to disk (or wherever) thus magically making it so that you no longer save the encoded text of the attachments but rather in-line binary data content. (Yes, it's as easy as setting an enum value in the CamelMimePart structure).
However, you have to be aware of the consequences of this. Most importantly, you will not be able to validate any of your PGP/MIME or S/MIME signed messages as according to the RFCs for these types, the signed MIME parts MUST be treated as opaque (meaning that you may not modify them in any way).
Now on to your ideas...
> One file per Mailbox-folder, allowing multiple folders per user. > Should those files reside in one central location or in users > Homedirs?
How is this different from mbox? (btw, CVS Evolution can handle mbox files and directory trees in external locations - ie, not within the ~/evolution directory).
> Compression: Should messages be broken into pieces and the > MIME-attachments stored separately (thus searching of the text parts > would still be possible without decompressing the whole file)?
If you break apart the MIME parts, you run into the same problem I described above about not being able to verify signatures.
However... if you took a normal mbox and gzipped it, you would certainly save space (at the expense of speed). I've been thinking about writing a CamelMimeFilterGzip class for gzip compresing/decompressing streams which would allow Evolution to read and write to gzipped mbox files for example.
Once the class is written (which should be fairly simple), allowing Evolution to read gzipped mboxes should be as simple as doing:
camel_stream_filter_add (MboxStream, GzipFilter);
...before feeding 'MboxStream' to the MIME parser.
> File format: gdbm, Sleepycat db? Something new?
Please not Sleepycat. If you are so sure that a generic database backend will be better than what Evolution's got, at least have the sense to use MySQL or PostgreSQL.
I'm personally against using a generic database as a storage and heres why:
1. The average user does not have an SQL database installed on their desktop systems, and so this is a completely rediculous dependency for them. If you think library dependencies are bad, just wait till you have to go installing, configuring, and maintaining a multi-user database running on your system. This may be fine for a company solution, but not the average end-user.
2. I'm not too familiar with MySQL or PostgreSQL, but I recall there being problems with mailers that use SQL database backends that tried to store the content of the messages as part of the table (due to them making the size of the table too small or whatever). If you can set the size to be "infinite", then I guess that's not a problem.
If your plan is just to have the database index the folder and actually store the contents as separate files, then you've instantly gained nothing over Maildir except that now you have a hefty database that you have to maintain and very little to no speed improvements (especially if you have a well designed/implemented summary index like Evolution does).
The only improvements you might gain here is body indexing? As I said earlier, MySQL supposedly has a REALLY good text indexer and so it might be a little faster than Evolution's. I'm really not sure on the comparison here.
> Should the security model allow users to directly access their > files, grep them, copy them around?
Is there a reason NOT to? I don't see one. It's their mail.
> Shared folders, virtual domains?
This doesn't really have anything to do with folder formats and everything to do with features of the client itself.
(Evolution can do this).
> Unicode support in folder names? Imap message-IDs, flags, useragent > specific state-information?
Unicode support in folder names I'd say is a pretty important feature. I'm not sure what you mean by "Imap message-IDs". Do you mean UIDs? Evolution, for example, has a UID assigned for each message whether it be in an mbox folder, Maildir folder, MH folder, or IMAP folder. So this isn't necessarily dependant on folder format (though it could be if you used a database backend for example, you might want a UID in the table).
I don't feel that UIDs are a must though, but I would suggest them. They are definetely useful especially for folders that can be accessed by multiple clients at once.
Flags are good. I'd go so far as to say a MUST have.
As far as user-agent specific state-information, it'd be nice to not need it. But if the client needs to keep it's own info, it'd be nice to be able to map the info to UIDs and keep it's own state file somewhere else (not necessarily alongside of the mail storage).
For example, IMAP doesn't have any means for the client to store state information on it, but that's perfectly fine. If a client chooses to have it's own state, then it can save it locally.
It would be nice if the storage could handle user-defined flags/tags though. This would allow the client to extend the native features of the format (Flag-for-Followup, message colouring, etc).
> How would MTAs deliver mail? How would clients access? File-locking > (NFS)?
This is one reason to just stick with what's available:-)
File locking is a MUST have (or a scheme to make it not needed, such as Maildir).
-- You know, I have one simple request...and that is to have messages with freakin' laser beams attached to their headers. Now evidently my MIME specification informs me that that can't be done. Uh, can you remind me what I pay you people for? Honestly, throw me a bone here. What do we have?
While Evolution is broken for inline pgp, I have to ask - did you submit bug reports?:-)
Most of the in-line pgp bug reports didn't start flowing in until after the 1.0 release which by that point was too late to fix for the most part because it to fix it right, we have to redesign the way we handle it completely.
btw, I as well as the mutt maintainer and every other mail client author that implements in-line pgp will agree that in-line pgp is just plain broken to begin with.
if you read the bug report that you linked to, you'll notice that there are a lot of possible security holes that all clients must face when implementing in-line pgp.
I would highly suggest you convince your friends to use PGP/MIME. There is some slight brokeness in Evolution's PGP/MIME implementation too (it sometimes says a signature isn't valid when it is, but it will never ever say a signature is valid when it isn't) but this is being fixed in the development branch. If you have questions about why this didn't work, feel free to email me or the evolution mailing lists and I will explain it in as much detail as you want.
> evolution has promised this, even had the dialog boxen in, but still nothing on the backend.
Being the author of 100% of any written S/MIME code, I can tell you there is/was a lot more code in the backend than there ever was in the front-end;-)
I'd say that the S/MIME backend code is mostly finished for Evolution, the only thing remaining is turning on the GUI again and writing a certificate manager component. After that, I suspect I have a few bugs in the S/MIME code but I would wager that it should mostly "just work".
We didn't finish it for 1.0 because of time constaints and because Netscape keeps changing the certificate API in libnss.
Frankly, I don't see the difference between the UI's of all these mail clients. They all have a folder bar, they all have a message list, they all have a preview pane, and they all have a menu/toolbar at the top. Honestly, how can Eudora's UI be any better than Outlooks? Or vise versa even...they look the same to me. In fact every mail client looks the same to me. I think I need to stop writing mail clients...
I guess your definition of monolithic is a bunch of small applications that work together and that load run-time loadable modules when they are needed?
I think you need to go out and buy a dictionary before you make yourself look like a fool again;-)
In the most recent versions, you are able to read folders (maildir and mbox) outside of ~/evolution
Also, for Drafts, Sent, etc - you are able to specify whichever folder you want to act as a Draft or Sent folder. And they don't need to begin with a capital letter...
and yes, Evolution supports PGP...much better than any other clients that I've seen - linux or win32 (including mutt).
Thanks for the usability report;-)
I think that somehow bonobo-config must be broken on your system if Evolution isn't saving your config info:(
Anyways, I was the guy writing S/MIME support (I finished PGP) but we will not have S/MIME finished for 1.0, instead we plan to support it by version 1.1 or so...
You had a good point about the calendar/tasks sharing the timezone config... I'll have to mention that (or if you submit some bugzilla bugs, definetely make sure to say something about that one).
I sorta agree that the PGP settings are kind of non-intuitive, but I'm not sure of the best UI for that. This is definetely something our UI expert needs to take a look at when she gets a chance. I mostly just took the UI from other mailers that do PGP like Spruce/etc.
If you click on the "View -> Folder Bar" menu item, the folder-tree will pop up and stay up (you can also click on the pin icon in the upper-right corner of the folder-tree to make it stick).
I also happened to write the SSL code which should work with OpenSSL but I mostly wrote it to work with libnss from Mozilla.
Anywyas, you had some good overall comments - I hope you enter them into our bugzilla system;-)
Jeff
Slashdot Mirror
I'm actually the developer of GMime - so much thanks for the compliment!
Actually, AC is correct - Novell *is* continuing with Evolution development. Being that I'm an Evolution developer, I think that puts me in the know.
We've also been busy extending GroupWise's protocol so that Evolution can talk to it for remote Calendaring (and Contacts too I think?).
This will all be available with Evolution 2.0 and the next release of GroupWise (6.5. something er other).
There are also plans to integrate iFolder as an Evolution backend for Contacts.
-- fejj
I'm actually the other Evolution mail hacker (NotZed being the other) :-)
p df.
My biggest complaint about sleepycat (other than it being slow) is that they change formats between minor releases.
You'll note that Evolution REQUIRES libdb-3.1.17 for the addressbook for this very reason. While we could most likely easily make Evolution able to use various versions of libdb, the simple fact that upgrading your libdb instantly breaks your contacts database is a major downside.
It also means that copying the addressbook.db file to another machine running Evolution linked against a different version of libdb would simply not work.
This is why we require exactly version 3.1.17 of the library.
The new Evolution mail indexer is based on an on-disk hash table design (http://primates.ximian.com/~fejj/idealhashtrees.
The original design of the indexer used libdb as a storage but that turned out to be unbearably slow and the indeces were massive.
The second design used a custom file format consisting of blocks but required you to load it into memory in order to use the information, which means that it's not very scalable (it scaled ok up to ~10,000 messages per folder).
the third design (only in the CVS development branch) again uses custom file formats (there are now multiple files) based on that on-disk hash table design above. This gives us the advantage of not having to load the entire index into memory before being able to use it (making it much more scalable - easily handles >100,000 messages per folder? I don't really know the statistics on it). On the downside, it means we have to make I/O calls. However, the design of the file formats makes it extremely fast lookups and so the user still hardly notices it (if they notice it at all?) even at 10,000 messages in a single folder.
Anyways, if you are really interested - you can checkout cvs evolution and read evolution/camel/developer-docs/camel-index.txt
Jeff
I gather you've never READ the MIME rfcs, have you? ;-)
MIME solves i18n issues as well. Not to mention that uuencoded blocks in the middle of a text stream do not even come close to solving all the problems that MIME solves.
MIME was designed to solve problems that could not be addressed using uuencode. Think of uuencode as a quick hack that worked so long as you you only intended to send US-ASCII email messages.
Then along came MIME, the properly designed transport medium, that solved i18n issues, solved the problem of some transport agents not understanding 8bit characters, and allowed logic structuring of data (not to mention "better compression" which seems to be the rave these days with yenc which simply does a horrible job of trying to solve the same problem that MIME has already solved).
so no, uuencode did not solve what MIME solves and has solved since ~1995.
considering the fact that he pretty much knows the RFCs by heart (he wrote most of the MIME parser in Evolution), i'd say he knows it a lot better than you :-)
that should read:
read (fd, &offset, 4);
XML will not speed up disk access. You'd still have to parse the file... and MIME is a XML-ish type format to begin with, so adding XML on top of that just adds bloat and nothing more.
if you want to speed up disck access to a folder in, say, mbox format - what you do is keep a summary file which stores the offsets of each message (and probably other some other pre-parsed information such as from/to/cc/subject/date/in-reply-to/references headers so that you can easily display a message-list and optionally thread it wihout having to parse the messages again).
You could perhaps encode this file in XML, but it'd be a lot faster if it were a binary file.
read (fd,
is a lot faster than decoding XML which requires massive amounts of mallocing and freeing on top of the file I/O.
it is a well-known fact that XML is slow.
the only plus that XML has is that it gives you a lexer for free and it's in a human readable format. These are not necesary for a file that can be auto-generated at will on an mbox file (for example).
Why would you want to waste even more space by putting an easily parsable MIME message into XML? What could you POSSIBLY hope to gain here?
The whole point of MIME is to make messages easily parsable. XML will do absolutely nothing but bloat the file. Not to mention you can't actually pre-parse the message into XML and get rid of the MIME formatting because then the format would be completely useless in that you wouldn't be able to verify signatures. Not to mention that XML can't handle binary data, so you'd still have to encode.
*sigh*
yEnc is a complete waste of time. Had the author of yEnc actually gone out and read some pre-existing MIME specifications before going out and re-inventing (a square) wheel, he would have found that MIME already defines an encoding that gets even better compresion than yEnc. It's called "binary". Yes, MIME can handle binary content.
Content-Transfer-Encoding: binary
it's as simple as that.
Btw, I've implemented the yEnc specification in my library GMime
My favourite part of the yEnc authors defense for why he implemented yEnc is "but most news clients don't implement MIME". Hah, join the real world where NO news reader implemented yEnc. (yes, I know there are clients that implement it now, in fact my code is used in a few of them).
Believe me as someone who spends time hacking on news and mail readers, yEnc is nothing but a headache.
A couple things:
:-)
1. Evolution is NOT "Basically mbox with database features". It can use Maildir or MH as the backend (and you can write your own plugin to extend this if you like).
2. Evolution's body indexing and summary files are extremely fast and efficient, about the best you'll get. I hear MySQL has text indexing capabilities that are extremely fast, but I'm not sure if they are faster than Evolution's indexer or not. Might be interesting to check this out.
3.
> But the thing that bugs me most is disk space. Typical inboxes are
> made of 5% to 10% of Text including Headers and HTML. The rest are
> BASE64- (or UU-) encoded pictures, word documents, zip archives and so
> on. The problem here is the encoding which wastes considerable amounts
> of space (at least one third).
It's theoretically possible, if you wrote your own Evolution storage plugin, to change the Content-Transfer-Encoding header value of binary attachments to "binary" (and text attachments to "8bit") before writing the message out to disk (or wherever) thus magically making it so that you no longer save the encoded text of the attachments but rather in-line binary data content. (Yes, it's as easy as setting an enum value in the CamelMimePart structure).
However, you have to be aware of the consequences of this. Most importantly, you will not be able to validate any of your PGP/MIME or S/MIME signed messages as according to the RFCs for these types, the signed MIME parts MUST be treated as opaque (meaning that you may not modify them in any way).
Now on to your ideas...
> One file per Mailbox-folder, allowing multiple folders per user.
> Should those files reside in one central location or in users
> Homedirs?
How is this different from mbox? (btw, CVS Evolution can handle mbox files and directory trees in external locations - ie, not within the
~/evolution directory).
> Compression: Should messages be broken into pieces and the
> MIME-attachments stored separately (thus searching of the text parts
> would still be possible without decompressing the whole file)?
If you break apart the MIME parts, you run into the same problem I described above about not being able to verify signatures.
However... if you took a normal mbox and gzipped it, you would certainly save space (at the expense of speed). I've been thinking about writing a CamelMimeFilterGzip class for gzip compresing/decompressing streams which would allow Evolution to read and write to gzipped mbox files for example.
Once the class is written (which should be fairly simple), allowing Evolution to read gzipped mboxes should be as simple as doing:
camel_stream_filter_add (MboxStream, GzipFilter);
...before feeding 'MboxStream' to the MIME parser.
> File format: gdbm, Sleepycat db? Something new?
Please not Sleepycat. If you are so sure that a generic database backend will be better than what Evolution's got, at least have the sense to use MySQL or PostgreSQL.
I'm personally against using a generic database as a storage and heres why:
1. The average user does not have an SQL database installed on their desktop systems, and so this is a completely rediculous dependency for them. If you think library dependencies are bad, just wait till you have to go installing, configuring, and maintaining a multi-user database running on your system. This may be fine for a company solution, but not the average end-user.
2. I'm not too familiar with MySQL or PostgreSQL, but I recall there being problems with mailers that use SQL database backends that tried to store the content of the messages as part of the table (due to them making the size of the table too small or whatever). If you can set the size to be "infinite", then I guess that's not a problem.
If your plan is just to have the database index the folder and actually store the contents as separate files, then you've instantly gained nothing over Maildir except that now you have a hefty database that you have to maintain and very little to no speed improvements (especially if you have a well designed/implemented summary index like Evolution does).
The only improvements you might gain here is body indexing? As I said earlier, MySQL supposedly has a REALLY good text indexer and so it might be a little faster than Evolution's. I'm really not sure on the comparison here.
> Should the security model allow users to directly access their
> files, grep them, copy them around?
Is there a reason NOT to? I don't see one. It's their mail.
> Shared folders, virtual domains?
This doesn't really have anything to do with folder formats and everything to do with features of the client itself.
(Evolution can do this).
> Unicode support in folder names? Imap message-IDs, flags, useragent
> specific state-information?
Unicode support in folder names I'd say is a pretty important feature. I'm not sure what you mean by "Imap message-IDs". Do you mean UIDs? Evolution, for example, has a UID assigned for each message whether it be in an mbox folder, Maildir folder, MH folder, or IMAP folder. So this isn't necessarily dependant on folder format (though it could be if you used a database backend for example, you might want a UID in the table).
I don't feel that UIDs are a must though, but I would suggest them. They are definetely useful especially for folders that can be accessed by multiple clients at once.
Flags are good. I'd go so far as to say a MUST have.
As far as user-agent specific state-information, it'd be nice to not need it. But if the client needs to keep it's own info, it'd be nice to be able to map the info to UIDs and keep it's own state file somewhere else (not necessarily alongside of the mail storage).
For example, IMAP doesn't have any means for the client to store state information on it, but that's perfectly fine. If a client chooses to
have it's own state, then it can save it locally.
It would be nice if the storage could handle user-defined flags/tags though. This would allow the client to extend the native features of the format (Flag-for-Followup, message colouring, etc).
> How would MTAs deliver mail? How would clients access? File-locking
> (NFS)?
This is one reason to just stick with what's available
File locking is a MUST have (or a scheme to make it not needed, such as Maildir).
--
You know, I have one simple request...and that is to have messages with freakin' laser beams attached to their headers. Now evidently my MIME specification informs me that that can't be done. Uh, can you remind me what I pay you people for? Honestly, throw me a bone here. What do we have?
uh, anytime someone says to do --nodeps or --force - you know that they haven't a clue as to what they are talking about.
you think red-carpet messed up your system? I guarentee that
rpm -e --nodeps `rpm -qa | grep ximian`
will leave your system in an even less usable state than anything red-carpet could do.
While Evolution is broken for inline pgp, I have to ask - did you submit bug reports? :-)
Most of the in-line pgp bug reports didn't start flowing in until after the 1.0 release which by that point was too late to fix for the most part because it to fix it right, we have to redesign the way we handle it completely.
btw, I as well as the mutt maintainer and every other mail client author that implements in-line pgp will agree that in-line pgp is just plain broken to begin with.
if you read the bug report that you linked to, you'll notice that there are a lot of possible security holes that all clients must face when implementing in-line pgp.
I would highly suggest you convince your friends to use PGP/MIME. There is some slight brokeness in Evolution's PGP/MIME implementation too (it sometimes says a signature isn't valid when it is, but it will never ever say a signature is valid when it isn't) but this is being fixed in the development branch. If you have questions about why this didn't work, feel free to email me or the evolution mailing lists and I will explain it in as much detail as you want.
Actually, Mono is not affected. For further information please see the Mono mailing list archives for today.
no
There is a description of why it won't bother Mono on the mono mailing lists.
uh, routing headers have nothing to do with Evolution and *everything* to do with sendmail
Evolution doesn't put a single routing header in any message it sends, so don't blame evolution.
> evolution has promised this, even had the dialog boxen in, but still nothing on the backend.
;-)
Being the author of 100% of any written S/MIME code, I can tell you there is/was a lot more code in the backend than there ever was in the front-end
I'd say that the S/MIME backend code is mostly finished for Evolution, the only thing remaining is turning on the GUI again and writing a certificate manager component. After that, I suspect I have a few bugs in the S/MIME code but I would wager that it should mostly "just work".
We didn't finish it for 1.0 because of time constaints and because Netscape keeps changing the certificate API in libnss.
Frankly, I don't see the difference between the UI's of all these mail clients. They all have a folder bar, they all have a message list, they all have a preview pane, and they all have a menu/toolbar at the top. Honestly, how can Eudora's UI be any better than Outlooks? Or vise versa even...they look the same to me. In fact every mail client looks the same to me. I think I need to stop writing mail clients...
I guess your definition of monolithic is a bunch of small applications that work together and that load run-time loadable modules when they are needed?
;-)
I think you need to go out and buy a dictionary before you make yourself look like a fool again
http://cvs.gnome.org/ there's a link to bonsai and lxr there.
what features would these be? According to the user's on the mailing lists, we don't have *enough* features. Go figure.
Actually, Evolution is made up of a bunch of small reusable parts.
:-)
Now, while you couldn't embed an Evolution Inbox inside Mozilla, you *could* embed it in say Nautilus
I'd also like to point out that imap, mbox, pop, smtp, maildir, mh, etc are all run-time loadable modules.
maybe you'd like to read the source code and ecide for yourself?
:-)
Or, perhaps you are challenging us and would like to prove how good you are by implementing something as good as evolution in fewer lines of code?
I hope you are issuing a challenge
In the most recent versions, you are able to read folders (maildir and mbox) outside of ~/evolution
Also, for Drafts, Sent, etc - you are able to specify whichever folder you want to act as a Draft or Sent folder. And they don't need to begin with a capital letter...
and yes, Evolution supports PGP...much better than any other clients that I've seen - linux or win32 (including mutt).
Thanks for the usability report ;-)
I think that somehow bonobo-config must be broken on your system if Evolution isn't saving your config info :(
Anyways, I was the guy writing S/MIME support (I finished PGP) but we will not have S/MIME finished for 1.0, instead we plan to support it by version 1.1 or so...
You had a good point about the calendar/tasks sharing the timezone config... I'll have to mention that (or if you submit some bugzilla bugs, definetely make sure to say something about that one).
I sorta agree that the PGP settings are kind of non-intuitive, but I'm not sure of the best UI for that. This is definetely something our UI expert needs to take a look at when she gets a chance. I mostly just took the UI from other mailers that do PGP like Spruce/etc.
If you click on the "View -> Folder Bar" menu item, the folder-tree will pop up and stay up (you can also click on the pin icon in the upper-right corner of the folder-tree to make it stick).
I also happened to write the SSL code which should work with OpenSSL but I mostly wrote it to work with libnss from Mozilla.
Anywyas, you had some good overall comments - I hope you enter them into our bugzilla system ;-)
Jeff