> Of these servers: one delivers to its ISP SMTP service, with no
> authentication needed;
That seems fine to me: the threat model here is that if you your machine
gets compromised, the attacker can send mail/spam through your ISPs SMTP
server. Many networks enable unauthenticated mail relay from their own IPs.
Since you establish a SSH connection to your home network, you do not
expose any credentials.
> the other delivers to another ISP SMTP service and uses the
> sasl_passwd approach you rightly fear (only because sometimes it must
> reach that ISP SMTP service from "outside" the ISP's client network).
Since the authentication happens over a TLS connection, I don't fear
the SASL approach per se. Rather, I worry about the credentials being
stored in the clear.
> Since all three of these have the message delivered via an ssh tunnel to
> their 127.0.0.1 listening port, no authentication is needed to get to the
> server.
>
> So in truth I sidestep the password issue I'm afraid.
Yeah, kinda :-). By having the SSH tunnels, you effectively shift the
issue of plaintext passwords to the remote location, which can be only
accessed from your end. For your ISP SMTP relay, it's not an issue
because you don't need credentials.
> There doesn't seem to be an obvious way to plug in an arbitrary command to
> provide username:password credentials for use in outbound SMTP
> authentication.
That's what I inferred as well.
> Does the OSX keychain actually get you better security here? I suppose the
> keychain files themselves are encrypted whereas the sasl_passwd file is
> cleartext, and that gets into backups in the clear etc. But other than that,
> does it matter. You can (I believe) tell the postfix smtp client to require
> TLS so that the credentials are encrypted over the network. Is that enough?
It's a good question whether you get better security. Here's how I think
about the threat model: I use full-disk encryption to avoid that
attackers can simply mount the hard drive after stealing my laptop. Any
plain text file would be safe in that it depends on the security of the
full-disk encryption. But further, I worry that a random software
vulnerability gives attackers access to my laptop, say because I browse
to the wrong site and a Safari or due to some other bugs. In the worst
case of remote code exec, the attacker could run any code with my user
privileges, e.g., `security find-generic-password -s mutt -g` and grab
my (application-specific) password right off the keychain. In this case
the keychain doesn't really help and proves as effective as a plain text
file. Where it does matter is when the compromise is not as severe as
arbitrary code exec, say just limited to browsing reading files. That's
the use case I'd like to prevent, as I personally deem it to be a
reasonable balance between usability and security. More broadly, you
also mention the valid concern of accidental leakage of the plaintext
file into backups. That said, by simply avoiding unencrypted password
storage, I try to raise the bar to a point where a severe software
vulnerability must occur (such as arbitrary code exec with user privs).
Ultimately the safest solution to me seems to avoid establishing a
direct connection to the GMail SMTP relay in the first place and instead
use the relay host of your ISP via an SSH tunnel, provided you can
establish that tunnel from everywhere.
I realized that I don't need to rely on GMail as sole SMTP service and
can also SSH into a location allowing unauthenticated (but encrypted)
mail relay.
Matthias
