Comment 25 for bug 365270

Ayeyiyi. Knut, please stop trying to impress everyone with your credentials and consider that you might actually not know everything about everything quite yet, regardless of how much you know about databases. I've been programming on UNIX since before POSIX even existed and I certainly understand the concepts quite well. I'll post one last message in the hopes that others reading this will understand what's going on, at least.

Since you've done a lot of DB work apparently, consider Evolution as if it were a generic open source SQL client program that can connect to lots of different types of SQL servers: Oracle, Postgres, MySQL, etc. The data is left on the server (for at least some of the protocols) and the client only provides access to the data. The client can only perform the operations that the server makes available: you can't perform Oracle-specific SQL commands on a Postgres server, etc. Suppose this client could also access databases that are local and don't have a server (sqlite databases maybe). That's a good analogy for what Evolution is. You didn't tell us what kind of server you're trying to talk to but people are assuming IMAP so I will too. If you're using something different let us know: that would be very helpful information.

First, SMTP is a mail *transfer* protocol. It defines the network protocol for two mail *servers* (e.g., sendmail etc.) to talk to each other to exchange mail. In SMTP parlance these are known as MTAs, or Mail Transfer Agents. Evolution is NOT an MTA. Evolution is a Mail User Agent (MUA). The SMTP standard has virtually nothing to say about the "protocol" that MUA's use to talk to MTA's. In short, Evolution has virtually nothing to do with with SMTP at all (Evolution has the ability to connect directly to MTA's to _send_ mail, but it cannot, and neither does any other client, use SMTP at all when _reading_ mail, as we are discussing in this bug).

Second, Evolution as an email client actually can use lots of different methods to retrieve email. It can get mail from a POP server, from an IMAP server, from a Microsoft Exchange server, or from a Novell Groupwise server. It can even read from USENET. And, of course, it can read from local mail spool files of various types. One of these types is the traditional UNIX mail spool that sendmail uses, and others are spool files left by other types of local software. Each of these uses a different protocol for getting mail.

Third, Evolution does not implement the server software, at all. If you connect to a POP server then someone else wrote that POP server. It may not even be free software at all; your ISP (that you download your email from) decides all that. Ditto for all the other ways Evolution gets email. Even the local spool files are created by other software such as sendmail, etc., that Evolution has no control over.

Fourth, for a number of those server types, including IMAP, Exchange, Groupwise, etc., Evolution does not manage your email locally. The email is left on the server and Evolution sends commands to the server to ask it to manipulate your email. This is what I mean when I say that the IMAP protocol doesn't support MOVE: you don't have a local copy of the email so only the server can manipulate it, and you can only ask the server to perform the commands that it supports.

With other types of mailbox, such as local mail spools and POP servers, Evolution downloads your mail to your local system and manipulates it there. Obviously in these environments Evolution has a lot more flexibility in the operations it can perform.

Finally, WRT searching, searching is very safe, at least in IMAP. Every addition to an email folder only ever adds to the end of the folder, never inserts in the middle, and every new message number is higher than any other message number (for that folder) that has been used before so there's never duplication. Every change to the folder is atomic (you don't get half a message added, or half an expunge performed). Every search starts at the beginning of the folder and goes to the end by first finding the current maximum message ID, then going through the folder message by message (ignoring missing messages) until that maximum is reached. If new items have been added since the search started they will have larger message IDs and are not seen for that search. Alternatively sometimes the client asks the server for a complete list of message IDs, then goes through that list. In any event, it's never a problem to have new messages added during searches.