[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Status of inetd for etch



On Tue, Aug 15, 2006 at 10:29:46AM -0400, Jim Crilly wrote:
> On 08/15/06 09:49:54AM +0200, Andreas Metzler wrote:
> > Hello,
> > This seems to be totally overengineered. Having MTA a provide sendmail
> > which uses MTA b for remote deliveries is no common usage scenario on
> > which any effort should be spent in the Debian packaging
> > infrastructure.

It is a common usage scenario for e-mail delivery in bastion hosts.

> > Actually the only sane explanation for wanting to install two MTAs I
> > ever heard of was "I am running X now and want to switch to Y. - I'd like
> > to test Y in the real system before going live."
> > 
> 
> I know of at least one firewall product that includes 2 copies of sendmail,
> one for accepting messages from the Internet and one for processing and
> sending them to the internal servers. They do this along with an RBAC
> system like SELinux so that break into the network via sendmail is
> virtually impossible since even if you break into the externally accessible
> sendmail you can't go any farther. Whether Debian should work on making
> this possible too or not, I can't say.

Actually, the first firewall product that implement that was TIS' Firewall
Toolkit (fwtk), the first open source firewall (later converted into the
commercial Gauntlet firewall), probably the most ancient firewall, used in
the first connection of the White House to the Internet [1]. 

It was actually a really good design decision to use sendmail for delivery
and smapd for e-mail reception [2], unlike sendmail, not that many (security)
bugs were found in smapd [3]. The same type of good design that has postfix
have multiple different daemons to isolate errors and contain damanage.

I'd say that Debian should make it possible to have that kind of setup.

Just my 2c.

Javier

[1] http://en.wikipedia.org/wiki/Trusted_Information_Systems
[2] http://www.fwtk.org/fwtk/docs/mjr-slides/sld073.htm
[3] AFAIK, only CVE-2001-1456 (which was severe, however, since at the time
no RBAC or MAC system was implemented in Gauntlet)

Attachment: signature.asc
Description: Digital signature


Reply to: