This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Date: Tue, 21 Nov 2000 19:53:20 -0800
From: Rick Moen <rick@linuxmafia.com>
To: svlug@svlug.org
Subject: Re: [svlug] Mail servers at a glance [was Re: What is the requirement...]
begin J C Lawrence quotation:
> True, but this is really a question of trusting a monolithic model
> versus a distributed model. Neither one is inherently safer than the
> other, and arguably, for all the gains made by moving to simple/small
> distributed tools, you also lose some in having to spread/extend your
> trust model and ensuring that the state transitions between nodes is
> inherently secure (not entirely trivial).
I think security guys would agree that, all other things being equal[1],
the package with fewer lines of suid root code wins. Postfix's design
deliberately minimises such code through modular design and validation
of data passed between modules.
Either approach can screw up in implementation, but Postfix's strikes me
as incontrovertibly better as a theoretical security design. But
security is as security does.
> Its also worth nothing that Exim and Postfix have a very small
> history of exploits and security bugs....
Argument assumes extrapolation of past data points. Dubious.
(Joey chewed me out very competently on this, when I made a similar
assertion about Proftpd. Serves me right, to hear it back.)
[1] Insert ObJibe here.
===
Date: Wed, 22 Nov 2000 17:48:55 -0800 (PST)
From: Wayne Earl <wayne@qconcepts.net>
To: Rick Moen <rick@linuxmafia.com>
Subject: Re: [svlug] Mail servers at a glance [was Re: What is the requirement...]
On Tue, 21 Nov 2000, Rick Moen wrote:
> I think security guys would agree that, all other things being equal[1],
> the package with fewer lines of suid root code wins. Postfix's design
> deliberately minimises such code through modular design and validation
> of data passed between modules.
Unfortunately, qmail wins here with the least SUID code (at least, the
last time I checked; approx. a year ago). Though qmail is very, very
secure, I agree with Rick that it is an absolute pain to work with.
Qmail sucks in the admin dept., which I why I no longer use it.
On a related topic: can anyone point me to docs for ripping Sendmail out
of a Red Hat system, and replacing it with exim?
===
Date: Wed, 22 Nov 2000 18:26:52 -0800
From: Rick Moen <rick@linuxmafia.com>
To: svlug@svlug.org
Subject: Re: [svlug] Mail servers at a glance [was Re: What is the requirement...]
begin Wayne Earl quotation:
> On a related topic: can anyone point me to docs for ripping Sendmail out
> of a Red Hat system, and replacing it with exim?
Not exactly -- but exim supports all of sendmail's command-line modes,
which means it's a drop-in replacement, once you have an exim.conf that
does what your sendmail.cf did.
===
To: Rick Moen <rick@linuxmafia.com>
Subject: Re: [svlug] Mail servers at a glance [was Re: What is the requirement...]
Date: Wed, 22 Nov 2000 18:39:08 -0800
From: J C Lawrence <claw@kanga.nu>
On Wed, 22 Nov 2000 18:26:52 -0800
Rick Moen <rick@linuxmafia.com> wrote:
> begin Wayne Earl quotation:
>> On a related topic: can anyone point me to docs for ripping
>> Sendmail out of a Red Hat system, and replacing it with exim?
> Not exactly -- but exim supports all of sendmail's command-line
> modes, which means it's a drop-in replacement, once you have an
> exim.conf that does what your sendmail.cf did.
<nod>
I've done this a couple times, mostly on RH 4.2 boxes without
trouble or particular effort. You can pretty well take a default
exim.conf and run with it. That said I generally edit it to:
-- use procmail as an LDA if there's a .procmailrc in the user's $HOME
-- define a custom received line that has a bit more data in it
(ripped from the Debian defaults):
received_header_text = "Received: \
${if def:sender_fullhost {from ${sender_fullhost} \
${if def:sender_ident {(${sender_ident})}}\n\t}\
{${if def:sender_ident {from ${sender_ident} }}}}\
by ${primary_hostname} \
${if def:received_protocol {with ${received_protocol}}} \
(Exim ${version_number} #${compile_number} (Debian))\n\t\
id ${message_id}"
-- up how much data is logged (log_received_recipients,
log_received_sender, log_refused_recipients,
log_smtp_confirmation etc)
-- tweak the system load settings (smtp_load_reserve,
deliver_load_max, queue_only_load, queue_run_max, smtp_connect_backlog)
-- touch up the transports for delivery_date_add, envelope_to_add,
return_path_add
===
From: Drew Bertola <drew@drewb.com>
Date: Thu, 23 Nov 2000 08:41:04 +0000 ()
To: Wayne Earl <wayne@qconcepts.net>
Cc: svlug@svlug.org
Subject: Re: [svlug] Mail servers at a glance
Wayne Earl writes:
> On a related topic: can anyone point me to docs for ripping Sendmail out
> of a Red Hat system, and replacing it with exim?
Try installing postfix. It's pretty easy, works flawlessly, and use
files common with sendmail (i.e. /etc/aliases ) and sendmail
executables are automatically linked to postfix executables.
The only difference is configuration (which is bound to be easier).
===
Date: Tue, 24 Oct 2000 09:43:41 -0700
From: Todd Lyons <todd@mrball.net>
To: World Domination <svlug@svlug.org>
Subject: [svlug] text mode mail questions
When one uses the mail command to send mail (i.e. echo "Testing this
crap" | mail user@domain.com -s Testing), it automatically calls
/usr/sbin/sendmail to send it. I'm guessing that it uses the -U command
to actually send it. Another user successfully was able to break this
behavior on his system by removing the symbolic link /usr/sbin/sendmail
which pointed to exim.
First question is, is there any way to specify (to mail) which MTA you
want to use? It seems that /usr/sbin/sendmail is hardcoded in to the
mail binary. So the answer is probably as simple as create a link
/usr/sbin/sendmail and whichever MTA you use should support the exact
same parameters as sendmail does.
Second question is, during this time frame that sendmail is called is
there a guarantee that it is only sending and that it is not listening
for incoming mail and not processing the queue?
And by the way, unless it's specifically forbidden, I'm going to forward
useful replies back to the original mailing list from which these
questions have sprung.
===