Re: ActiveSync client displays messages that were deleted in IMAP

Michael J Rubinsky <[email protected]> Sat, 18 Aug 2018 17:40:05 +0000
Newsgroups	gmane.comp.horde.user
Message-ID	<20180818174005.Horde.izInlxi3N4XBIONMSTpgWUc@tarn.theupstairsroom.com>
Quoting Kevin <[email protected]>:

>> On Aug 11, 2018, at 1:52 PM, Michael J Rubinsky <[email protected]> wrote:
>>
>>> I would argue that it there is no inconsistency in this case.  
>>> After all, the message actually does exist in the mailbox. The  
>>> only difference is the EAS client doesn't mark that it's flagged  
>>> with the DELETED flag - because it doesn't know about such a flag.
>>>
>>> IMO, actually deleting the message over ActiveSync is inconsistent  
>>> since now the mailbox on the EAS client shows that the message is  
>>> actually NOT in the mailbox at all - you can't "show deleted" and  
>>> you can't remove the deleted flag. In clients that allow marking  
>>> message deleted, you still see them, or have the ability to show  
>>> them, in the mailbox, albeit marked with a deleted flag which you  
>>> have the ability to remove. You would have no such ability in the  
>>> eas client if it is "deleted" from the mailbox.
>>>
>>> Anyway, I do get what you are saying though :)
>>
>> Another point to consider is that this leads to issues if there are  
>> changes to the email that is marked for deletion. Like  
>> adding/removing another flag, or actually expunging it. This  
>> triggers a change to be detected and sent to the client. If the  
>> message is "deleted" on the client it can't do anything with it in  
>> the best case and for not-well-behaved-clients, can cause crashes.   
>> This would also require some workarounds when removing the deleted  
>> flag. Since it's just a change in a flag, this change would never  
>> be reflected on the client since the original message is no longer  
>> on the client. Anyway... I'm done now :)
>
> Thanks for the explanation. I get it now, and I can at least make an  
> informed choice about how to handle things. Probably we'll just deal  
> with it by explaining how things work to other users. Quitting Mail  
> more often seems to be an easy way to deal with it. That seems to  
> expunge the messages immediately.
>
> Maybe you know why this other inconsistent behavior I'm seeing  
> happens? If I use Junk as my spam folder (Junk is the name in  
> dovecot) then setting Junk as the spam folder in the web interface  
> settings cause the iPhone to not show Junk anymore, but Spam. The  
> phone doesn't seem to know to use Spam as Junk.

ActiveSync doesn't have a notion of a "Spam" folder, so it's up to the  
client to decide what to do. IIRC, iOS will only recognize the name  
"Junk" (Though I thought it was "Junk Email").

It's not ActiveSync that's changing the name, it's IMP. When you set  
the preference to use a folder as Spam, it changes the label of that  
folder to be "Spam". When ActiveSync builds it's folder list, it gets  
the list of mailboxes from IMP's API - which uses the label names. We  
do this to have consistency between the names that a user sees in IMP  
and the folder names that are shown in the ActiveSync client.

> Is there a reason ActiveSync changes the name? Can that behavior be  
> turned off somehow so I can use Junk as my Spam folder in the web  
> interface and have it's spam functions work and the phone's junk  
> functions work.
>
> Right now I just set the spam folder to none in the web settings  
> since it's the least used client and handle all the junk marking and  
> moving with the phone or desktop client.
>
> Thanks,
> Kevin
> --
> Horde mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: [email protected]



-- 
mike
The Horde Project
http://www.horde.org
https://www.facebook.com/hordeproject
https://www.twitter.com/hordeproject

-- 
Horde mailing list
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: [email protected]
(unnamed) (application/pgp-keys, 9.1 KB) - not displayed
signature.asc (application/pgp-signature, 821 B)