[Alpine-info] Web Alpine bugs

[Marius Micluta]

On Tue, 10 Jun 2008, Eduardo Chappa wrote:


> This is the usual behavior of filters. Normally messages are expunged at 

> the time the folder is closed. If it worked differently in version 1.00 it 

> was probably a bug in 1.00, even though you would like to be that way, it 

> is actually supposed to work the other way around.


This is exactly how things work in Web Alpine 1.00 - deleted messages are 
expunged at the time the folder is closed. On the contrary, deleted messages 
may never be automatically expunged in Web Alpine 1.10, whatever configuration 
options are used; only manual expunge works. Which is the normal behavior? 
 

> The main technical issue is that *as designed*, the EXPUNGE command is 

> "atomic", in the sense that it expunges *all* messages marked deleted, not 

> just a few of them. This means that filtered messages, and those that are 

> marked for deletion will be expunged. So if the filter sent an EXPUNGE 

> command to the server, messages that you have marked for deletion will 

> also be expunged, and that may not be desirable.


Let me state it clearly: the issue is not about technical standards and 
Alpine, but about Web Alpine's behavior, as different from that of Alpine. 
There are of course several functionality differences between the two 
incarnations of Alpine, but I presume both should adhere to the same 
IMAP standards and implement them identically.

There has been for a long time a very useful configuration options tandem which
works perfectly in both Pine and Alpine, namely the "auto-move-read-msgs" and
"expunge-without-confirm" pair, which allows to automatically move read
messages from the inbox to the read-messages folder. While
"expunge-without-confirm" behaves as expected in Alpine, it does absolutely
nothing in Web Alpine. Read messages are copied to the read-messages folder
according to the "auto-move-read-msgs" option, but they remain in the inbox,
marked as deleted; they are not even hidden in the folder view. Moreover, the
"no-expunge-without-confirm" option, which is activated when the "Expunge INBOX
Without Confirming" box in the Configuration menu is unchecked, does not
trigger any confirmation request for the expunge operation, which is totally
ignored. Therefore, in order to have in Web Alpine the same functionality as in
Pine and Alpine, I resorted to filtering rules. It happens that they work as I
expected in the "buggy" version 1.00, but in version 1.10 they behave as if
ordinary private mailboxes were shared mailboxes, such as an exclude operation
is performed instead of an expunge one. In Alpine, the configuration options
above always take precedence over filtering rules. If a filtering rule set to
move deleted messages to a thrash folder is defined and the
"expunge-without-confirm" option is present, the deleted messages are expunged,
but they are not copied to the thrash folder. When the
"no-expunge-without-confirm" option is selected instead, the effect is the same
as above if one answers "Yes" to the expunge confirmation request. On the
contrary, if the answer is "No", the messages are not immediately expunged from
the inbox, so they get the chance to be copied and then expunged by the
filtering rule. In all cases, the behavior seems consistent to me, and no
messages marked as deleted are left in the inbox.


> There is, however, an extension to IMAP, in RFC 4315, that could be used 

> as a work around to this problem, but you need a server that supports the 

> UIDPLUS extension, and that is not a guarantee. I think UW-IMAP started 

> supporting UIDPLUS with the release of Alpine 1.00, so it is something new 

> in that server too.


I had not the time to study the subtleties of the RFCs defining the IMAP
protocol standards, but I will hardly believe that they could imply such
striking violations of common sense. By filtered message I meant a message
complying to a number of criteria from the selectable folder and message
conditions. Let us forget about deleted messages and put instead, e.g., a
specific "From: " field. I expect then that the specified filter actions be
performed on the selected (i.e., filtered) messages. If I choose the filtered
messages to be moved to an alternate folder, I expect them to be copied to the
destination folder and then deleted from the source folder, once for good. The
way filtering rules in Web Alpine 1.10 "move" messages, by copying them to the
destination folder at each new login, without never deleting them from the
source folder, is a Sorcerer's Apprentice nonsense. By the way, I use the last
version of uw-imapd, 2007b.


>From my point of view, this question is closed for the moment, as I found

alternatives to circumvent it. I only intended to signal it to the (Web) Alpine
community. But I also mentioned another unsolved issue in my first post
(accessing mail folders placed in subdirectories of a user's folder collection
directory), which did not trigger any feedback. Shall I open a new thread?