On 12/05/2012 01:43 AM, Grant wrote:
>>
>> I switched to msmtp when nbsmtp was treecleaned. The switch was
>> uneventful; it just works, which is high praise.
>>
>> You can't encrypt your password unless you're going to be physically
>> present to decrypt it (with some other password). If your machine is
>> physically secure, you can just make the msmtp config file read-only to
>> yourself. If someone can log in as you, they can get your password
>> anyway. There's only a risk if e.g. you're not root, or someone else can
>> get root (access to grub) or walk off with the hard drive.
>>
>> If you're worried about either of those scenarios, set up a separate
>> account for your email alerts.
> 
> I like the separate account idea.  Any tips on locking it down?  Maybe
> that account on the mail server should somehow only be allowed to
> deliver to a single email address (mine)?  Would it need a shell
> account?  Certainly not allowed in sshd_config.
> 

It depends on how you're authenticating. We've got our users in
Postgres, and postfix uses Dovevot's SASL backend to auth. That way a
"user" is just an email address/password combination and can't do
anything except send/receive mail.

The general defense against hacked user accounts is to do rate-limiting
on the MTA with something like postfwd, and at least notify postmaster
if someone begins sending hundreds of messages. That way if a user gets
hacked, you find out about it and can disable them.

In this case I wouldn't even worry about it. If someone can log on to
your server and read the msmtp config, you've already got a big problem.
The real benefit to using a separate account is that if that does
happen, they can't see Grant's personal email password (which is
essentially the keys to the kingdom).

Another thing you might consider is getting added to the feedback loops
of some major providers. When one of our users gets hacked, I find out
quickly because AOL sends me a copy of every message that they get from
us which is marked as junk. This is a Good Idea anyway, and mitigates
the stolen-password problem in that unlikely event.

Reply via email to