security.md

@@ -2,15 +2,44 @@
 title: Security Notes
 ---
 
-# Relaying
+# Relaying and From forgery prevention
 
-When setting up [port forwarding](setup/04-port-forwarding), 
+tl;dr: This system has some additional protections, but also some of the same weaknesses as a typical workstation email setup.  Understand the below conversation in that context.
 
-blocking nncp-to-nncp relaying
+By default, Exim will:
+
+- Reject any message that comes in from NNCP and has a non-local destination.  NNCP relaying should happen at the NNCP protocol level (with `via` configuration), not at the MTA level.
+- Reject any message that comes in from NNCP with a From: address that is a mismatch with the calculated `nncpnet.org` domain name for the sending node.
+- Permit locally-submitted messages (to `/usr/sbin/sendmail` or SMTP port 25) to go anywhere
+- Not perform SMTP authentication
+
+This mirrors a typical default local MTA setup in which messages are accepted on localhost or via `/usr/sbin/sendmail` to anywhere.  Note that local attempts to forge the domain in the From: header will be rejected.  However, as is typical with MTA setups, the user-part of the From: line is not validated.  Doing so would require SMTP authentication which starts to get complicated
+
+When setting up [port forwarding](setup/04-port-forwarding), you may expose the SMTP server to more connections.  The setup as configured **is not suitable for exposing to your network interface or the Internet**.
+
+What this boils down to is: this is pretty well ready to run as a single-user mail node, and if doing port forwarding, can even be fine on a single-user laptop/workstation/etc.
+
+If you are doing any kind of multiuser mail node, you should have a separate SMTP system in front of this one that performs any necessary validation.
+
+## An additional note on local From: forgery
+
+A careful reading of the above discussion will highlight that nncpnet-mailnode will protect you from forged From: lines on mail coming in from other systems.  However, you may note that a local user can still submit a message with a forged From: domain.  If targeting a remote system, the message will travel to that system, at which point nncpnet-ingest will reject it.
+
+If targeting a user on the *local* system, there is nothing to reject it there.  Since it does not traverse the NNCP infrastructure, the From: line can still be forged locally.  Again this mirrors a typical setup.
+
+Just blocking these messages outright will break some mail setups.  Basically, the summary is: you probably don't want to have untrusted users on your local system.
 
 # On-disk encryption
 
+NNCP protects the messages while in transit.  At the sending and destination servers, however, they may be stored in plaintext in places like the Exim queue and user's home directories.  This is the same as with typical mail systems, since this IS a typical mail system, just with different transport.  If this is an issue for you, storing the `/persist` volume on a LUKS-encrypted filesystem may be a good plan, or you can use OpenPGP or other encryption.
+
 # TLS
 
-use a proxy ahead of it
+TLS isn't really supported inside nncpnet-mailnode.  While Dovecot IMAP will technically offer TLS, it will use a self-signed cert.
+
+Since nncpnet-mailnode uses NNCP to exchange mail, TLS is irrelevant at the mail exchange step.
+
+Getting TLS into these containers is a difficult proposition because the containers may not have Internet access, and in any case, addresses under nncpnet.org cannot be reached by public verification bots such as those used by Let's Encrypt.
+
+If you really need TLS for these services, I recommend using a proxy in front of them with your own domain name.