[thaumasiotes]

I had email service expire on a domain and moved it to fastmail. Fastmail, obviously, did not have copies of the email I received before the move. But my phone did.

When I updated the configuration in K-9, it contacted the fastmail server, found that the mail it had locally wasn't also present there, and immediately deleted all my local copies.

That's not a "bug" in the sense of unintended behavior of the software, but it certainly seems like the software designer's goal is to hurt the user. I obviously didn't want that to happen. There is no scenario where I would want that to happen.

Email clients make some strange assumptions about what kind of actions make sense under what conditions.

[berkes]

I'd wager that this is marked as "by design" because it technically follows some IMAP spec. What the app does, purely on a technical level, is correct.

I've so often had debates and threads in issues where a developer entrenched in a domain has so much domain-knowledge (ie. tunnel vision) that "technically correct" or "by the spec" is the only correct way. I've been that developer in many cases too, in hindsight.

[1718627440]

I got also bitten by this. While IMAP would allow for syncing, most MUAs don't have a local mailbox. Instead they have a cache and the offline mode means to put as much as possible in to the cache. But if you want an actual local mail storage, you will eventually have merge conflicts, because how do you deal with a message that is present locally and was on the server, but is no longer? Do you assume the user wants it deleted, or that it should be reuploaded to the server? Either way will be wrong. (Also if you reupload, it will get a new UID, so another MUA will again reupload it, i.e. you will get a copy per MUA.)

So if you want a mailbox sync tool, use a proper program for that like mbsync/isync. (But this can't cope with cross mailbox moves besides (not) propagating them.)

[account42]

Some developers incorrectly think a spec defines what your program should do instead how to do what your users want.

Another example is HTTP Strict-Transport-Security which specifies that browsers should take control away from users.

[berkes]

Yes, a spec is a technicality that, ideally, should be abstracted away completely (and alas, all abstractions are leaky somewhat).

It's another thing that got me interested in DDD. Where the user, domain, business and such define what things are called, how they operate, what events they undergo or emit etc. And not a spec, language or framework

And where e.g. "the IMAP spec" is a clear bounded domain, probably a service, an adapter or even library. Within that domain, "The Spec" dictates all the naming, conventions, logic etc, but where the border of this domain is another language. E.g. in a "MessageAdapterImap" something is called "EXPUNGE" with all the intricacies of what this means in IMAP. But in the outside it's e.g. part of a "cleanup()" interface, or whatever the domain calls it when it removes messages.

[fouronnes3]

You make a good point but this is not a "strange assumption" by any stretch. You see Thunderbird has a "move" action. It allows you to move emails from a folder to another. Now somehow, this is apparently NOT implemented as:

1. Copy from source to destination

2. Verify copy has completed without issue

3. Delete from source

but... some other way? So when you try to move from a server folder to a local client folder by an innocent looking drag an drop, combine this with a poor network connection, a garbage tier legacy protocol like IMAP and decade old C++ spaghetti code, and you get this textbook 17 year old severity 1 bug that will never get fixed.

[thaumasiotes]

Well, interestingly, Thunderbird insists that that is exactly the implementation they're already using.

(see https://bugzilla.mozilla.org/show_bug.cgi?id=462156#c69 )

Of course, it isn't; they're relying on an unstable proxy for "copy has completed without issue" in preference to just checking whether that happened or not. Several rather angry users have pointed this out. It doesn't seem to have sunk in.