On Mon, Mar 08, 2004 at 10:33:20AM -0700, Craig White wrote:
> If sendmail isn't listening to anything but 127.0.0.1 - what is the
> difference? No need to patch unless you ARE using it for local delivery
> - in which case, the only exposure is to exploits such as ultra long
> headers
If you have a root exploit turn up in your MTA, a local user could take
advantage of it. Granted, it's "only" a local exploit at that point
rather than a remote exploit, but it's still an exploit nonetheless.
One could make the argument that you shouldn't give any accounts to
users you can't trust, but that's not always possible and it is possible
that one of your trusted users could succumb to temptation. Also, if
you fail to patch another remote exploit, say for user-level privileges
only, they combine to form a remote root exploit.
> I don't know what mailx is.
It's the Berkeley mail(1) command.
$ ls -l /usr/bin/[Mm]ail{,x}
lrwxrwxrwx 1 root root 4 Dec 26 18:26 /usr/bin/Mail -> mail*
-rwxr-xr-x 1 root root 71592 Apr 11 2002 /usr/bin/mail*
lrwxrwxrwx 1 root root 4 Dec 26 18:26 /usr/bin/mailx -> mail*
$ dpkg -S /usr/bin/mail
mailx: /usr/bin/mail
You can also 'rpm -qf `which mail`' (or 'qpkg -f `which mail`'), if
that's your preference.
> procmail is typically a hand in hand with sendmail. Procmail has no
> clue on what mail is to be received by system and is rather simple
> minded.
"Received", agreed. "Delivered", disagreed. In a typical setup,
Sendmail or some other MTA will receive the mail and figure out where it
should go (based on files like /etc/mail/aliases.db and
/etc/mail/virtusertable.db) and then hand it off to procmail, an MDA, to
deliver locally, although Sendmail is perfectly capable of doing local
delivery itself. (Traditionally, procmail was only invoked if there was
a .forward file in the user's home directory, but procmail of course
does much more than forwarding, so it's more common now for procmail to
handle *all* delivery so that users don't have to set up odd .forward
files just to get filtering.)
procmail(1) identifies the program as "procmail - autonomous mail
processor" and states, in the description, "If running suid root or with
root privileges, procmail will be able to perform as a functionally
enhanced, backwards compatible mail delivery agent." Try shutting down
your MTA and sending mail to yourself via 'procmail -d <username>'
(taking care to type in a correctly-formatted mail message).
> /bin/mail functions as a send / read utility but cannot 'receive'.
I never claimed otherwise.
> I think that you will find Hans and some others like the simple
> mindedness of exim.
Exim's wonderful. I like its config file format. I've used it on my
workstation. I currently use Sendmail on my main server since my
friends, when I was setting the whole thing up, had more expertise with
it, so it made more sense to use that rather than something else in case
I had questions. I've heard great things about Postfix and I'm keeping
an eye out for an excuse to try it.
> That being said, out of the box, sendmail would have done exactly what
> you wanted.
I'm not debating the fact that recent Linux distributions generally have
an MTA configured sanely and that it should Just Work. I was
speculating as to why the original poster might want to avoid running an
MTA.
> Little fear or need to continually patch/update if your not exposing
> it to the outside world.
Agreed; the risk is greatly minimized. Even moreso if you're not on a
network at all.
> Also, for the record, even if you use fetchmail, you still need an MTA
> to process the mail.
Not true, as of three years ago. Fetchmail's changelog states, for
version 5.7.3 (March 11, 2001), "Added FALLBACK_MDA; fetchmail now looks
for procmail or sendmail at build time and uses it if it can't open port
25 for local delivery." See also the "mda" option for the .fetchmailrc
in the documentation.
--
Bill Jonas * bill@billjonas.com * http://www.billjonas.com/
"It's a dangerous business, Frodo, going out your front door. You step
into the Road, and if you don't keep your feet, there is no knowing
where you might be swept off to." -- Bilbo Baggins
(text/plain)