[quote user="Thomas R. Stephenson"]> RFCs aside, it is just common sense: If the client sent a command (Delete Mail X) and the server confirmed the execution of the command
> ("OK"), then the server is responsible to retain this information.
> There must be a very specific reason for "forgetting" such a command long after the fact, and in this case, I cannot see such a reason.

The most common reason is that it is better to not delete mail from the server until you know that this was what was desired by the user properly closing the session.  The same reasoning is used for POP3 as well, all delete flags are removed if the session is not properly closed.

[/quote]

I heartily disagree: While this behavior made sense with POP3, where a session has a very specific, predetermined purpose (get list of mails, download certain mails, delete other mails, close session). If during all those steps an error happens, the client can start from the beginning.

The usage of IMAP4 is completely different: The session is left open for hours, or even days. The user does many different "transactions" during this session (reading a mail, moving another, going back to the first to delete it etc.). All this is interactive. Every single step must be considered as final, since after hours (or days!) in this open connection, you do not want your actions from way back to suddenly be reversed. Also, it's not like Mercury magically reverts your mailbox to the state before the connection was opened: Only the deleted flag vanishes. Copied mails stay copied, Replied to mails retain that tag etc.

IMAP4 is used hugely differently from POP3. The mailserver has to treat it that way.

Also, one of the new features of 4.73 was, that the index files are now written immediately. I think everyone took this to mean, that all relevant information is saved immediately. Change of a flag, especially "Deleted" is relevant information.

Greetings

Markus Borst

Also, and this is not small problem: Mercury crashes from time to time, mostly on corrupt mailboxes. In this case, the server has no chance to retroactively save the Deleted flag, it is simply lost without any user error at all. 

Hello.

I distribute the mail in my office using MercuryI (see my other post for configuration).

I noticed that if I delete a mail, it's correctly marked as deleted. However, this status is not retained; e.g. if I quit Outlook 2007 (without purging, obviously), and then restart it, the deleted messages are no more marked as deleted.

Anyone can help me? Did I miss something?

Filippo

Mercury waits for an Expunge or Logout command before updating files. So if the IMAP session is terminated without any such command deletions will be ignored. There are more comments about this in this thread:

http://community.pmail.com/forums/thread/29082.aspx

/Rolf

[quote user="Filippo72"]

Hello.

I distribute the mail in my office using MercuryI (see my other post for configuration).

I noticed that if I delete a mail, it's correctly marked as deleted. However, this status is not retained; e.g. if I quit Outlook 2007 (without purging, obviously), and then restart it, the deleted messages are no more marked as deleted.

Anyone can help me? Did I miss something?

Filippo

[/quote]

Yes, I am also seeng this behavior with Thunderbird (latest version).  I also use Horde/Imp as a webmail interface for when I'm away from home, and see this issue.  My wife accesses her mailbox with an iPhone, and also has the same problem.  Interestingly enough, we did not see this in Mercury 4.72; it's only started since the upgrade to 4.73.  In Thunderbird and Imp, one must explicitly "empty trash," or the messages come back into the inbox.

Thunderbird has an option to expunge on exit - it's under Account Settings > Server Settings. I've found that 4.73 is much more rigorous about not allowing deletions or moves (which are actually copy + delete) when more than one user is logged in. With 4.72, you would often be able to do it, even though Mercury didn't support it. With 4.73 I have sometimes found that logging out the the user doing the deletion, leaving one user, results in the deletion being made, but this doesn't always work.

We have the problem because Thunderbird is set up to access multiple accounts, so each account may be open on more than one machine. I'm experimenting with separate Thunderbird profiles for each account.

 Chris

Confirmed; I tried 4.72, and the problem disappeared. Roling back to 4.72...

[quote user="Rolf Lindby"]

Mercury waits for an Expunge or Logout command before updating files. So if the IMAP session is terminated without any such command deletions will be ignored. There are more comments about this in this thread:

http://community.pmail.com/forums/thread/29082.aspx

/Rolf

[/quote]

This is a correct description of what Mercury does. As several people here have noticed, this leads to deleted mails reappearing, for no apparent reason (from the users perspective). Several people reported that they had to switch back to 4.72 because of this, indicating that this behavior is not what users expect (to put it mildly).

So, the question is: When will a fixed version of MercuryI be released?

Greetings

Markus

[quote user="Rolf Lindby"]

Mercury waits for an Expunge or Logout command before updating files. So if the IMAP session is terminated without any such command deletions will be ignored. There are more comments about this in this thread:

http://community.pmail.com/forums/thread/29082.aspx

/Rolf

[/quote]

Well, as I said, my wife primarily uses her iPhone to retrieve mail which, I don't believe, has a way to send an "expunge" command or effect a logout of the mail account.  The Mercury behavior as you describe is obviously new as of 4.73.

Devices that have an IMAP 4rev1 client are expected to follow the RFC (http://community.pmail.com/forums/thread/138.aspx):

A client SHOULD NOT unilaterally close the connection, and instead SHOULD issue a LOGOUT command. 

The intended behavior if an IMAP session is closed without Expunge or Logout was as far as I understand not changed between versions 4.72 and 4.73, but there were a lot of IMAP revisions in 4.73 and it could be that version 4.72 and earlier in fact did behave differently in some cases.

/Rolf 

[quote user="Rolf Lindby"]

Devices that have an IMAP 4rev1 client are expected to follow the RFC (http://community.pmail.com/forums/thread/138.aspx):

A client SHOULD NOT unilaterally close the connection, and instead SHOULD issue a LOGOUT command. 

The intended behavior if an IMAP session is closed without Expunge or Logout was as far as I understand not changed between versions 4.72 and 4.73, but there were a lot of IMAP revisions in 4.73 and it could be that version 4.72 and earlier in fact did behave differently in some cases.

/Rolf 

[/quote]

The cited RFC is pretty clear: While the client should always issue a logout, it is in no way mandatory, i.e. the server MUST NOT rely on the client to send a logout.

This is self evident, since the connection can break because any number of reasons: Flaky WLAN, crashed imap client, blue screen / core on operating system, system going into suspend mode, Mercury server crashing (!) etc.

RFCs aside, it is just common sense: If the client sent a command (Delete Mail X) and the server confirmed the execution of the command ("OK"), then the server is responsible to retain this information. There must be a very specific reason for "forgetting" such a command long after the fact, and in this case, I cannot see such a reason.

So all things considered, this behaviour is new in 4.73 and in everyday use of the server it causes problems. Those problems are serious enough that people go back the the previous version. Will there be a fixed version coming out soon?

Greetings

Markus

> RFCs aside, it is just common sense: If the client sent a command (Delete Mail X) and the server confirmed the execution of the command
> ("OK"), then the server is responsible to retain this information.
> There must be a very specific reason for "forgetting" such a command long after the fact, and in this case, I cannot see such a reason.

The most common reason is that it is better to not delete mail from the server until you know that this was what was desired by the user properly closing the session.  The same reasoning is used for POP3 as well, all delete flags are removed if the session is not properly closed.