[sf-lug] how to read root's email?

[Rick Moen]

Quoting jim (jim at well.com):

> rick's response seems worth chewing: what is your objection to running
> sendmail? okay to use sendmail as a normal process rather than a
> daemon?  okay to use postfix or exim rather than sendmail, and if so,
> why? would be interesting to know your answers. 

If I guess / understand correctly, Alison mostly just wants to read any
necessary mail elsewhere, on the (unspecified) webmail system -- but
figures that running a full-blown MTA just to lob system mail for the
root user over to a remote webmail site would entail a lot of hassle.

On Debian, one would just go with the flow on installation defaults,
which puts in a minimal configuration of the (relatively small and
simple) Exim4 MTA.  The package tools ask you what sort of system you're
running, e.g., whether you're intending to relay outbound mail to a
"smarthost".  You'd pick that option (remote smarthost), specify your
webmail system's full-qualified hostname for that, and you're done.

I'm not a big sendmail fan, either.  (Been there, done that.)

> consider using a monitoring tool such as nagios or osiris or phpadmin
> or some such.

Er, that still leaves the problem of getting the locally generated mail
for the root user from point A (the machine where it's generated) to
point B (the webmail system where Alison prefers to read her mail).  The
conventional answer would be "use an MTA".

I'm sure there are also a lot of creative answers, e.g., "have the local
mail delivery agent be a shell script that uses rsync to copy
/var/spool/mail/[local_admin_user] over to the webmail box" -- which of
course would necessitate having shell on the webmail box, which isn't
true on GMail, Yahoo Mail, etc. but might be on Alison's _own_ webmail
box.

> seems no one will ever get around to reading /var/log/messages before
> there's a problem, and some argument they shouldn't (why scan
> blindly?)

Normally, you should _not_ have to read /var/log/messages.  If there's
regularly something important getting written to the logs, something
like logwatch should parse that and tell you about it -- via e-mail.
Just looking at /var/log/messages raw, you're very unlikely to spot 
important things except in rare cases when you know what you're looking
for -- and, even then, you might be better off grepping.  ;->

>    can you use the mail client on your local
> systems to send mail to "out there"? if so, maybe
> set up a cron job to check root's mail and chown it
> or copy its contents and mail it to you?

See, a "mail client" means a mail user agent.  Mail user agent is a
local role that (in its pure implementation, at least[1]) doesn't include
ability to send outbound SMTP.  /usr/bin/mail, /usr/bin/mailx,
/usr/bin/mail-local cannot, for example.

It's a matter of specialisation.  This page and diagram illustrate the
roles of MTAs, MUAs, and MDAs:

http://en.kioskea.net/contents/courrier-electronique/fonctionnement-mta-mua.php3

An explanation without pictures:
http://wiki.mutt.org/?MailConcept

[1] Some MUAs aka mail clients incorporate "stub MTA" code by which
they're capable of handing off outbound mail via an SMTP connection to
one particular specified remote SMTP host, which then takes over (if
it's willing to do so) the process of forwarding the mail to its real
end-destination.  This is particularly common in graphical clients.
Most console MUAs more-closely follow the modular model, and expect to
hand off outbound mail to a local MTA process.