overcomplicated and bloated for the simple task. Not an option. KISS!
Just tell both of your Postfixes (on the server and notebook) to drop
-email as a mail via NNCP to specified node. This is done similarly as
-with UUCP and as written in
+email as a mail via NNCP (@ref{nncp-mail}) to specified node. This is
+done similarly as with UUCP and as written in
@url{http://www.postfix.org/UUCP_README.html, Postfix documentation}.
Look @ref{Postfix, here} for further information. All mail will be
stored in NNCP @ref{Spool, spool}, that after exchanging and tossing
-will call local @command{sendmail} command to deliver them just that was
-happened on the same machine.
+will call local @command{sendmail} command to deliver them just like
+that happened on the same machine.
@node UsecaseUnreliable
@section Unreliable/expensive communication link
Assume that you have got slow modem/radio/cellular link that frequently
disconnects and causes TCP timeouts. Not all HTTP servers support file
download continuation. SMTP does not support resuming at all and heavy
-messages is a problem to retrieve. Moreover, each disconnect leads to
-the same data retransmission again, that can be expensive to afford.
+messages is problematic to retrieve. Moreover, each disconnect leads to
+the same data retransmission again, that can not be afforded sometimes.
-Just send your mail and files through NNCP. You can use either offline
-delivery methods -- read about them in the next section, or you can use
-included NNCP TCP daemon.
+Just send your @ref{nncp-mail, mail} and @ref{nncp-file, files} through
+NNCP. You can use either offline delivery methods -- read about them in
+the next section, or you can use included NNCP @ref{nncp-daemon, TCP
+daemon}.
-The command below:
+The command:
@verbatim
% nncp-file file_i_want_to_send bob:
media for transferring packets to other nodes.
Assume that you send two files to @emph{bob} node. Insert USB storage
-device, mount it and run:
+device, mount it and run @ref{nncp-xfer}:
@verbatim
% nncp-xfer -node bob /media/usbstick
@end verbatim
to find all packets related to their node and copy them locally for
-further processing. @ref{nncp-xfer} is the only command used with
-removable devices.
+further processing. nncp-xfer is the only command used with removable
+devices.
@node UsecaseF2F
@section Private, isolated MitM-resistant networks
and forged nodes. However they are harder to support and require more
time to be done right.
-NNCP's TCP daemon uses @url{http://noiseprotocol.org/, Noise-IK}
-protocol to mutually authenticate peers and provide effective (both
-participants send payload in the very first packet) secure transport
-with forward secrecy property.
+NNCP's @ref{nncp-daemon, TCP daemon} uses
+@url{http://noiseprotocol.org/, Noise-IK} protocol to mutually
+authenticate peers and provide effective (both participants send payload
+in the very first packet) secure transport with forward secrecy
+property.
@verbatim
% nncp-daemon -bind [::]:5400
via: [bob]
@end verbatim
-That configuration file tells that we have got two known neighbours:
-@emph{bob} and @emph{bob-airgap}. @emph{bob} can be reached via online
-connection using @emph{lan} address. @emph{bob-airgap} can be reached by
-sending intermediate relay packet through the @emph{bob}.
+That @ref{Configuration, configuration file} tells that we have got two
+known neighbours: @emph{bob} and @emph{bob-airgap}. @emph{bob} can be
+reached via online connection using @emph{lan} address.
+@emph{bob-airgap} can be reached by sending intermediate relay packet
+through the @emph{bob}.
Any command like @command{nncp-file myfile bob-airgap:} will
automatically create an encapsulated packet: one for the destination
entertainment content delivering and popular social networks access
(that are already bloated with advertisements, locally executed
proprietary JavaScript code (for spying on user activities, collect data
-on them), shamelessly exploiting of very basic interhuman need of
-communication).
+on them), shamelessly exploiting the very basic human need of communication).
This is their natural wish. But nobody forces you to obey huge
corporations like Apple, Google or Microsoft. It is your choice to
-create isolated friend-to-friend network with piles of harmless content
-and private messaging. Only predators silently watch for their victims
-in mammals world -- it harms your health being watched and feeling that
-you are the victim that has already done something wrong.
+create an isolated friend-to-friend network with piles of harmless
+content and private messaging. Only predators silently watch for their
+victims in mammals world -- it harms your health being watched and
+feeling that you are the victim that has already done something wrong.
@node UsecaseSpy
@section Reconnaissance, spying, intelligence, covert agents
be pretty fast, allowing to quickly fire chunks of queued packets.
Very important property is that compromising of those dead drops and
-storages must not be fatal and even dangerous. Packets sent through the
-network and exchanged via those devices are end-to-end @ref{Encrypted,
-encrypted} (but unfortunately lacking forward secrecy). No filenames,
-mail recipients are seen.
+storages must be neither fatal nor even dangerous. Packets sent through
+the network and exchanged via those devices are end-to-end
+@ref{Encrypted, encrypted} (but unfortunately lacking forward secrecy).
+No filenames, mail recipients are seen.
All communications are done with so-called @ref{Spool, spool} area:
directory containing only those unprocessed encrypted packets. After
packet transfer you still can not read any of them: you have to run
-another stage: tossing, that involves your private cryptographic keys.
-So even if your loose your computer, storage devices and so on -- it is
-not so bad, because you are not carrying private keys with it, you do
-not "toss" those packets immediately on the same device. Tossing
-(reading those encrypted packets and extracting transferred files and
-mail messages) could and should be done on a separate computer.
+another stage: @ref{nncp-toss, tossing}, that involves your private
+cryptographic keys. So even if your loose your computer, storage devices
+and so on -- it is not so bad, because you are not carrying private keys
+with it (don't you?), you do not "toss" those packets immediately on the
+same device. Tossing (reading those encrypted packets and extracting
+transferred files and mail messages) could and should be done on a
+separate computer.