68 lines
3.3 KiB
Markdown
68 lines
3.3 KiB
Markdown
|
# FAQ
|
||
|
|
|
||
|
|
Answers to questions that come up but aren't 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 via a `smol://` link is safe to get wrong: worst case, you
|
||
|
|
add the wrong person, but nobody can intercept your messages because of it.
|
||
|
|
|
||
|
|
Trusting a mail server is a bigger deal. Once you trust a server, it's
|
||
|
|
allowed to act on your behalf — register your address, hand you your mail,
|
||
|
|
delete it. Because of that, a server has to be trusted through some channel
|
||
|
|
you actually control — someone telling you in person, a message from
|
||
|
|
someone you already know, a company handing you the address directly — not
|
||
|
|
a link that could show up in an email or a random webpage. If server trust
|
||
|
|
worked via clickable links, anyone could send you a link that quietly
|
||
|
|
switches which server you trust, and you'd have no way to tell.
|
||
|
|
|
||
|
|
So adding a server is a manual, deliberate step, on purpose — never a link
|
||
|
|
you can be tricked into clicking.
|
||
|
|
|
||
|
|
## Why does Smol Mail not have native WebSocket support?
|
||
|
|
|
||
|
|
It does — but kept separate, as an optional add-on ([WS.md](WS.md)), not
|
||
|
|
built into the core mail protocol. That's deliberate.
|
||
|
|
|
||
|
|
The core protocol talks over a plain, minimal connection with nothing extra
|
||
|
|
attached: no certificates, no expiry dates, nothing to configure. A
|
||
|
|
WebSocket is only needed because web browsers can't open that kind of plain
|
||
|
|
connection directly, and some networks only allow the kind of traffic
|
||
|
|
websites use. Baking WebSocket support into the core would mean baking in
|
||
|
|
everything that comes with it — web certificates, browser security rules —
|
||
|
|
none of which the mail protocol actually needs, and none of which is part
|
||
|
|
of how it decides what to trust (that's still just the server's key, exactly
|
||
|
|
as without WebSocket).
|
||
|
|
|
||
|
|
So instead, the WebSocket support is a small side process that sits next to
|
||
|
|
a mail server and simply passes the same data through unchanged. It doesn't
|
||
|
|
hold any keys and doesn't need to understand mail at all — it's a pipe, not
|
||
|
|
a participant. A server that doesn't run it is still perfectly usable by
|
||
|
|
every other client.
|
||
|
|
|
||
|
|
This mirrors how the separate delivery method over the Reticulum network
|
||
|
|
works too: an alternate way to reach a mailbox, kept outside the core
|
||
|
|
protocol 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 haven't approved that person yet — that's what the Requests
|
||
|
|
folder is for.
|
||
|
|
|
||
|
|
A mail server can't see who's sending you mail, only that something
|
||
|
|
arrived. Without some way to tell "someone I know" apart from "a stranger
|
||
|
|
or spam," anyone who knew your address could flood your mailbox. So by
|
||
|
|
default, mail from anyone you haven't approved goes into 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, or simply replying to them has the same
|
||
|
|
effect. From then on, their mail goes straight to your main mailbox;
|
||
|
|
withdrawing your approval (`block`) sends them back to Requests.
|
||
|
|
|
||
|
|
This is on purpose and there's no way to skip it for a first message: your
|
||
|
|
server can tell approved senders apart from everyone else without ever
|
||
|
|
learning who any of them actually are, which is what keeps your mailbox
|
||
|
|
both usable and private.
|