Over the years I evolved different ways of using email.

First I started with the classic graphical mail user agent (e.g. thunderbird), and subsequently switched to mutt, as I started to learn how to use a shell.

Initially I used mutt with both SMTP and IMAP support.

Over time I learned how mutt's IMAP support is not brilliant, and that it
works much better to have an external process to synchronize the mailboxes.
I switched to mbsync, while keeping mutt's SMTP support for outgoing email.

After further thinking, I figured that I don't want to place passwords in
user agent configurations (.muttrc for SMTP, .mbsyncrc for IMAP), as a compromised process might read it.

I figured that the credentials would be safe if it was the system to use them. I learned some basis of Postfix, and now the SMTP interaction, on my system, is handled by a cocktail of sender-dependent settins, with authenticated relay hosts. The SMTP password of relay hosts is owned by root, and a rogue process can't access it.

At this point I'd like to do something similar with mbsync, but it seems
not to be suited for this task.

Moving the mbsync configuration at system level poses a couple of question marks: First off, I don't like the idea of operating mbsync with a root user, since this is not a secure approach (by contrast, postfix is dropping permissions). And even if it was acceptable to do so, the updated mailboxes would be polluted with root-owned files.

How would you handle this?


- dacav
--- Synchronet 3.18b-Linux NewsLink 1.113

On Thu, 1 Oct 2020, Dacav Doe wrote:

Moving the mbsync configuration at system level poses a couple of question marks: First off, I don't like the idea of operating mbsync with a root user, since this is not a secure approach (by contrast, postfix is dropping permissions). And even if it was acceptable to do so, the updated mailboxes would be polluted with root-owned files.

How would you handle this?

- dacav

Are you reading/sending mail right on the mail server's machine?
(You know, like how most tilde servers' emails work)

If no; then may I know the details of your mail delivery topology?

If yes...

Mutt is (AFAIK) geared for plain old Unix mail workflow.
So, why not use plain old Unix mail workflow,
and top it up by using SMTP-capable MTA [a la Postfix]
and Maildir-capable IMAP server [a la Dovecot]?

(Actually, if you don't need to read email remotely,
you could just omitted the latter part entirely)

This way; on outgoing, you can just make Mutt use `sendmail` program [1]
while logged-in (it'll know who you are, without having to enter password).
And for incoming, Mutt can read from your maildir directly.
It will be like your local mailman (Postfix) delivering your mail
right to your $HOME.

Outgoing path...

+----------------------------+
| MTA (Postfix) |--------SMTP(S)--------> / The Net Out There /
| | (Beware of Dragons)
| |<-------SMTP(S)--------- - - - - - - - - - +
| |<-------SMTP(S)--------- + . +----------------------------+ . .
^ ^ . .
|add spool |add spool . .
| | System realm . / User ~jane / [Sendmail]..........[Sendmail]....................... . (Connected from
^ . ^ User realm . The Net Out There)
\run . \run .
\ . \ .
[ MUA (Mutt) ] . [ MUA (Mutt) ] + - - -/ User ~john /
. (Connected from
User ~john . User ~jane The Net Out There)


Incoming path...

+----------------------------+
| MTA/MDA (Postfix) |<-------SMTP(S)--------- / The Net Out There /
| | (Beware of Dragons) +----------------------------+
| |
|drop mail |drop mail
| | System realm ..v..................v...............................
[~/.mail/ folder] .[~/.mail/ folder] User realm
|\ . |\
| \read . | \read
| v . | v
| [ MUA (Mutt) ] . | [ MUA (Mutt) ]
| . |
| . |read
| . v
| . [ MDA (Dovecot) ]----IMAP(S)----> / User ~jane /
|read . (Connected from
v . The Net Out There)
[ MDA (Dovecot) ].
\ .
\ User ~john . User ~jane
\ .
+----------------------------------IMAP(S)----> / User ~john /
(Connected from
The Net Out There)


I'm using this configuration on tilde.club as a user
as I read mails right on the server most of the time;
though but with Alpine rather than Mutt as my MUA.

(My Alpine configuration still is a bit haphazard,
but it is able to send and receive mails at least)

Regards,
~xwindows

-----

[1] In Postfix-based installation, this is Postfix-disguised-as-Sendmail.
--- Synchronet 3.18b-Linux NewsLink 1.113

Dacav Doe <dacav@tilde.institute> wrote:

Over the years I evolved different ways of using email.

First I started with the classic graphical mail user agent (e.g. thunderbird),
and subsequently switched to mutt, as I started to learn how to use a shell.

Initially I used mutt with both SMTP and IMAP support.

Over time I learned how mutt's IMAP support is not brilliant, and that it works much better to have an external process to synchronize the mailboxes.
I switched to mbsync, while keeping mutt's SMTP support for outgoing email.

After further thinking, I figured that I don't want to place passwords in user agent configurations (.muttrc for SMTP, .mbsyncrc for IMAP), as a compromised process might read it.

[snip]

How would you handle this?

I'm setting up a similar thing as part of my X internet client
configuration (I've blabbered about that plenty at my Phlog if
interested - more blabberings to add actually: killed one laptop
already, and does /etc/X0.hosts actually work _anywhere_?!), though
the Email stuff is among the bottom of my priorities.

Actually I'm at the same point as you, except that I picked different
software. I'm using msptp for sending mail with SMTP, and it offers
the following options for handling passwords (copied from the example .msmptrc):

# Password method 1: Add the password to the system keyring, and let msmtp get # it automatically. To set the keyring password using Gnome's libsecret:
# $ secret-tool store --label=msmtp \
# host smtp.freemail.example \
# service smtp \
# user joe.smith

# Password method 2: Store the password in an encrypted file, and tell msmtp
# which command to use to decrypt it. This is usually used with GnuPG, as in
# this example. Usually gpg-agent will ask once for the decryption password. #passwordeval gpg2 --no-tty -q -d ~/.msmtp-password.gpg

# Password method 3: Store the password directly in this file. Usually it is not
# a good idea to store passwords in cleartext files. If you do it anyway, at
# least make sure that this file can only be read by yourself.
#password secret123

# Password method 4: Store the password in ~/.netrc. This method is probably not
# relevant anymore.

# Password method 5: Do not specify a password. Msmtp will then prompt you for # it. This means you need to be able to type into a terminal when msmtp runs.

I like to enter passwords manually and keep them off the HDD
entirely, so with a bit of cumbersome scripting I got a terminal
window to pop up and ask me to enter the password before sending
mail - and afterwards, whether to try again in case it didn't work.

I haven't got to setting up IMAP yet (sorry I've honestly already
forgotten all of the MTA MDA etc. terminology again since looking
into this) - my plan is to run fdm on the "internet client" to store
into mailboxes that can then be accessed by MUAs (hey I remembered
one!) on other computers over my LAN using NFS.

Fdm allows you to launch an external command in .netrc like method 2
for msmtp:


%%% The .netrc file

If the user name or password is omitted in POP3 or IMAP account definitions, fdm will attempt to look it up in the .netrc file in the invoking user's home directory.

The .netrc file format is shared with ftp(1) and some other programs. It consists of a number of 'machine' sections and optionally one 'default' section containing a username ('login') and password for that host. fdm accepts entries only if the machine name matches the POP3 or IMAP server string exactly. If no matches are found and a 'default' section exists, it is used.

An example .netrc file is:

machine "my.mail-server.com"
login "nicholas"
password "abcdef"

machine "pop.googlemail.com"
password "pass1"

default
login "bob"
password "moo"

fdm will abort if the .netrc file is world-writable or world-readable.

%%% Passwords from a command

fdm can read the password from a command by using command substitution
with $(). For example:

user "fdm@example.com" pass $(gpg --quiet --decrypt ~/.password.gpg)

From:
https://github.com/nicm/fdm/blob/master/MANUAL

--

- The Free Thinker | gopher://aussies.space/1/%7efreet/
--- Synchronet 3.18b-Linux NewsLink 1.113

Hey xwindows,

Thanks for the explanation!

On 2020-10-02, xwindows <xwindows@tilde.club> wrote:

Are you reading/sending mail right on the mail server's machine?
(You know, like how most tilde servers' emails work)

Unfortunately not.

None of my machines so far are exposed to the Open Internet.
My long term goal is to host my own services, perhaps
including email, but I don't have the time and energy to
keep it up, at least in this phase of my life.

Still I'd like to improve my local installations from the
security standpoint and keeping it as much "Unix-pure" as I
can get away with, and maybe gathering some experience in
the process.

If no; then may I know the details of your mail delivery topology?

Pretty much this for now:

.NAT/FW
.
+-----------------+ . +----------+
| MTA (Postfix) |--SMTP---->| provider |--SMTP(S)-->dragons
| | [1] | |
+-----------------+ . +----------+
^ | ^ . |
| | | . |
cron | | add spool . |
v | . | The Internets
+---------+ | . |
| maildir | | . |
+---------+ [sendmail] . |
| ^ . |
v | +---------+ . |
[MUA] | maildir |<---IMAP--`
+---------+ [2] .
.
Local Machine .


[1] SASL authenticated relay using:
sender_dependent_relayhost_maps = ...
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = ...
relayhost = [stmp.fastmail.com]:submission

[2] mbsync fetching from provider.

The outgoing path is good: the relay is authenticated, and
the password database is owned by root: it cannot be read by
a rogue process running as unprivileged user.

Given that the machine is not exposed on the open internet,
but depends on a mail provider, for the incoming path I must
access an IMAP service, that is [2].

I'd like to have a maildir style delivery, as similar as
possible to what would happen with an internet-exposed
machine.

This is currently handled by mbsync, whose configuration
allows either:

- authentication by plaintext password in the configuration
file

- authentication by the output of a user-defined command
e.g. `pass show mail`

Considering the idea of a periodic (cron-based) fetch, the
first option is very convenient but not secure (again, think
of rogue process).

The second option is more secure but not conveninent: the
gpg key that protects the password must be handled by an
agent, if the gpg-agent session expires, the periodic fetch
fails.

Thinking of it, I might have a solution, that I'll try now
to implement: a root-controlled cron-job loads the IMAP
password, then spawns a process that becomes the
unprivileged user (losing super-cow powers). The process
runs mbsync via exec(2), while obtaining the passphrase from
the parent process by means of some IPC mechanism (e.g. a
pipe, or even an env variable).

It might work but it is somewhat clunky... :-/
--- Synchronet 3.18b-Linux NewsLink 1.113