I would not expect concurrent writes for per user carddav or caldav storage, might as well be unsupported.
Just a bit of info on our preferred auth - we would like to use local CDB (constant db) lookups instead of sql or imap (as per my mail ~sircmpwn) For example using:
This is our preferred way for auth lookups at migadu and here it is preferred as it allows separation of DAV accounts from imap. We can expand on that later.
We cannot add the domain, as alps may be run with many different domains (cnamed host). Strangely, the document domain in the iframe matches the parent. It could be an issue while running in localhost though.
Images are by default not loaded in HTML views. The views are iFrames where we insert srcdoc. When the images need to be loaded however, on click, we proxy them through the app, so alps fetches them from remote and serves them from the webmail server. This hides the user's IP as well avoids HTTPS warnings.
In Firefox this does not work, it seems because of the sameSite policy Firefox has now:
Content Security Policy: The page’s settings blocked the loading of a resource at http://localhost:1323/proxy?src=https%3A%2F%2Fwww.post.ch%2Fstatic%2FNotifica%2F%2Fcicd%2Fpost-logo-de.png (“default-src”).
Iframe domain has to match the one of the app. I think the issue may be in the Content-Security-Policy given in server.go
What happens here is that the cookie in the proxy request does not get sent and the proxying request gets redirected to the login page.
We obviously need that cookie sent or else the server will become an open proxy.
I am starting to dislike the whole idea of background sending, we are just adding to complexity it seems. I need some contemplating here.
If we receive the message with the \Deleted flag, we should simply skip it and not show it, which would solve it?
Currently a list of all mailboxes is shown, subscribed and unsubscribed, but only Inbox shows unread count next to it.
Server side filters and rules may place messages in other folders. In Migadu case, we use plus addressing to move to folders automatically. Without an indicator in the webmail on the mailbox, these new messages will go unnoticed.
I think it is great to show all folders, however we could treat them differently.
The mailbox list template variable needs a flag whether user is subscribed to that mailbox or not. If it is subscribed, then new messages count could be shown next to it. Unsubscribed mailboxes are not shown any counters.
Inside of the mailbox view, a button could be presented for subscribing/unsubscribing. This would then change the behavior by checking for new messages count.
Now, it is insane to check all mailboxes on each sync. There must be a better way?
This one boils down to having more data for the mailbox list. Will close and open another one.
Subscription would be needed in case a new message comes into a mailbox, to show a new message is present. With SIEVE filtering and sorting, this may be a must otherwise no one will know they got a message until they click on the mailbox. We do not show count of new messages on folders, hence subscriptions are not useful yet.
~sircmpwn, The way you've implemented create/delete, I think it would make sense to have a button [Subscribe] or [Unsubscribe] next to the [Delete] button on the mailbox view (for non-system mailboxes).
So I guess this boils down whether we should support subscriptions at all. We currently show all mailboxes, regardless of subscriptions.I can imagine having unsubscribed mailboxes shown grayed out in the mailboxes list. Those that are not grayed out, they show the count of unread messages contained.
Also, current mailbox creation creates it but it does not subscribe to the created mailbox, hence it will not appear on other mail clients such as Thunderbird. I would suggest auto-subscribe along with creation.
This is an HTML only email, but it is shown as "Plain text" tab (though with rendered HTML). No HTML tab present.