31 lines
3.1 KiB
Markdown
31 lines
3.1 KiB
Markdown
# FAQ
|
|
|
|
Answers to questions that come up but are not spelled out elsewhere.
|
|
|
|
## Why can't I just click a link to add a mail server, the way I can add a contact?
|
|
|
|
Adding a contact through a `smol://` link is safe to get wrong. The worst case is that you add the wrong person, and nobody can intercept your messages because of it.
|
|
|
|
Trusting a mail server carries more. Once you trust a server, it is allowed to act on your behalf: register your address, hand you your mail, delete it. A server therefore has to reach you through a channel you actually control, such as someone telling you in person, a message from someone you already know, or a company handing you the address directly. A clickable link is not such a channel. If server trust worked via links, anyone could send you one that quietly switches which server you trust, and you would have no way to tell.
|
|
|
|
Adding a server is a manual, deliberate step. It is never a link you can be tricked into clicking.
|
|
|
|
## Why does smolmail not have native WebSocket support?
|
|
|
|
It does, kept separate as an optional annex ([WS.md](WS.md)) rather than built into the core protocol.
|
|
|
|
The core protocol talks over a plain, minimal connection with nothing attached: no certificates, no expiry dates, nothing to configure. A WebSocket is needed only because browsers cannot open that kind of connection directly, and because some networks pass only the traffic websites use. Baking WebSocket support into the core would mean baking in everything that comes with it, web certificates and browser security rules, none of which the mail protocol needs, and none of which takes part in how it decides what to trust. Trust is still the server's key, exactly as without WebSocket.
|
|
|
|
The WebSocket support is instead a small side process that sits beside a mail server and passes the same data through unchanged. It holds no keys and does not need to understand mail. It is a pipe, not a participant, and a server that does not run it remains usable by every other client.
|
|
|
|
This mirrors the delivery method over the Reticulum network (SPEC.md §13): an alternate way to reach a mailbox, kept outside the core so the core stays simple regardless of how people connect to it.
|
|
|
|
## Why do new smolmails always end up in my Requests folder?
|
|
|
|
Because you have not approved that person yet. That is what the Requests folder is for.
|
|
|
|
A mail server cannot see who is sending you mail, only that something arrived. Without a way to tell someone you know apart from a stranger or spam, anyone who knew your address could flood your mailbox. Mail from anyone you have not approved therefore goes to a separate, smaller Requests folder with limited retention, instead of your main mailbox.
|
|
|
|
To fix this for someone, approve them. The reference client's `accept` command does this in one step, and replying to them has the same effect. From then on their mail goes to your main mailbox, and withdrawing your approval with `block` sends them back to Requests.
|
|
|
|
There is no way to skip this for a first message, and that is the point. Your server can tell approved senders apart from everyone else without ever learning who any of them are, and that is what keeps your mailbox both usable and private.
|