Server admin often needs a way to communicate to it’s users, to inform them on server downtimes, policy changs, service termination, etc.
AFAIK in case of DC it’s not possible right now.
Admin of public chatmail server usually don’t know it’s clients personally, and can’t write to them, despite he has a list of their email addresses.
Broadcast messages may be a solution, if all server users will be subscribed right after login creation. But I don’t know if it will be possible at all.
Public groups have many disadvantades in this case, so not a solution.
If the server had all the public keys of all its accounts, it might be a spam target. Perhaps having an extra QR code on the server homepage which is the contact for a server-messages list would be a good solution.
I definitely look forward to having a multi-transport option and I’m sure this will be very beneficial for reliability but I’m not convinced that this entirely obviates the need for announcement channels. In my view it is still basic courtesy if not a matter of importance to give users notice about things like end-of-service and policy changes. For example I was unaware when nine.testrun.org shortened the time it keeps messages for and I continued to make false assumptions about that for some time, I don’t know how long.
By the way @9er there is also some discussion about this here:
I got it. But in conditions where internet access is censored it’s trivial for censor to get all the application’ servers addresses, and block them. Custom server with limited number of users is more robust solution. I’m mostly thinking about this scenario.
Ok, this is another question turning to FR.
Quote from RFC9051 “Internet Message Access Protocol (IMAP) - Version 4rev2”:
7.1. 'Server Responses - Generic Status Responses"
ALERT
The human-readable text contains a special alert that is presented to the user in a fashion that calls the user’s attention to the message.
Content of ALERT response codes received on a connection without TLS or SASL security-layer confidentiality SHOULD be ignored by clients
(…)
Alerts received after successful establishment of a TLS/SASL confidentiality layer MUST be presented to the user.
(The only difference with older RFC 3501 is it allows to send such ALERT messages over plaintext connection, and sure it was exploited.)
How it may be used:
(1) chatmail server will send ‘* OK [ALERT …’ by postlogin shell script; no Postfix code modification needed
see Post-login scripting — Dovecot documentation
at this point, connection is alreary TLS-encrypted and authentificated; there is no need for additional encryption; it can be send only on first login, or on some conditions checked by the script
(2) on the first such alert, DC client will create ‘contact’ named e.g. as server DNS name, maybe with some preset ‘generic server image’ avatar; text input field is not needed (like in broadcast channel)
(3) the first message in thet channel should be auto-generated warning about rogue or cracked servers, not clicking links, etc.
This alert is actually standard IMAP feature, so theoretically should be supported on any IMAP client and server. Don’t know what is actual situation.
