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

Re: BTS says qmail's sendmail-clone is broken

On Tue, Feb 02, 1999 at 11:42:54AM -0500, Phillip R. Jaenke wrote:
> The sendmail replacement bin likely isn't broken. The qmail-src package
> is. Quite badly. The entire intent of qmail is *fast* and *secure*. The
> qmail-src package is fast, yes, but NOT secure. It does NOT follow the way
> qmail was meant to be built by default.

	No it isn't. By your measurements, the whole of Unix is 
	insecure. And the Debian Policy too.

> Using /var/spool/mail/$USER is where it blows up. That's not what qmail is
> meant to do. Qmail is meant to deliver using the MBOX format. Which means
> mail is delivered to $HOME/Mailbox, as opposed to /var/spool/mail/$USER.
> This is a much safer and more secure method. Of course, with network
> mounted home directories, sometimes you might lose bits and pieces, but
> it'll happen with a network mounted /var/spool too.

	You are over-exaggerating /var/spool/mail's vulnerability.
	But, leaving that aside (haven't used /var/spool/mail for
	years), there's no need to suffer from that, even if you
	do use qmail-src.deb; edit /etc/init.d/qmail line alias_empty
	(and in general, RTFM).

	My only gripe is that qmail.deb depends on procmail, even if
	I have never touched procmail; one 2000-user installation
	here, and a a biggish server farm with _every_ single machine
	having procmail. Duh. Could we have something smaller (and easier
	to trust) to deliver to /var/spool/mail?

	PS. The whole dot-locking issue in the policy has never touched
	    me, 100% maildir here. Heartily suggested.
foo | +358505486010 | tv-nospam-sig-1@hq.yok.utu.fi | mknod /dev/trash c 1 3

Reply to: