Mailing List Archive

"D. J. Bernstein" <djb@koobera.math.uic.edu> writes:

> qmail 1.00 is available through http://pobox.com/~djb/qmail.html.
>
> No code changes from 0.96. I have lots of cleanups scheduled, and I'll
> have to add IPv6 support someday, but 1.00 should be an adequate MTA for
> the next several years.

Installed and happy on NetBSD 1.2C (-current) even with the VM problems
in the current kernel. :)

BTW, is there any possibility of installing the binaries in /usr/local
but keeping the mail queue and control files in /var/qmail?

It seems to me that that is the right thing to do.

--Michael

On 21 Feb 1997, Michael Graff wrote:

> BTW, is there any possibility of installing the binaries in /usr/local
> but keeping the mail queue and control files in /var/qmail?

My "right thing to do" sensor :-) says that binaries and man pages should
go in one of:

/usr/qmail default
/usr/local/qmail for people who don't like /usr/qmail
/usr/contrib/qmail when qmail is distributed as a "contrib" product
(not officially supported)
/opt/qmail for newer SVR4.2 ie: HPUX 10

My "right thing to do" sensor for data says it should be in one of:

/var/qmail default
/var/opt/qmail for newer SVR4.2 ie: HPUX 10

My "right thing to do" sensor says it is never OK to put binaries in /var.

The separation of binaries and data is especially useful with something
like the HPUX diskless NFS, where /usr is mounted off a server read-only.

Evan
--
Evan Champion * Director, Network Operations
mailto:evanc@synapse.net * Directeur, Exploitation du reseau
http://www.synapse.net/ * Synapse Internet

Evan Champion <evanc@synapse.net> writes:

> My "right thing to do" sensor :-) says that binaries and man pages should
> go in one of:
>
> /usr/qmail default
> /usr/local/qmail for people who don't like /usr/qmail
> /usr/contrib/qmail when qmail is distributed as a "contrib" product
> (not officially supported)
> /opt/qmail for newer SVR4.2 ie: HPUX 10

I would reverse the first two (make /usr/local/qmail the default) but I
could see either being correct. In fact, I could see /usr being the
default for if (when?) NetBSD starts shipping with qmail. If it is a part
of the system (as released by the OS maintainer) /usr is fine. If not,
well, /usr/local should be where it goes.

> My "right thing to do" sensor for data says it should be in one of:
>
> /var/qmail default
> /var/opt/qmail for newer SVR4.2 ie: HPUX 10
>
> My "right thing to do" sensor says it is never OK to put binaries in /var.

My right thing to do sensor agrees with yours. :)

On Sat, 22 Feb 1997, Mark Delany wrote:

> As has been pointed out quite as few times I think. There are alway symlinks
> if you want to put directories in other places. There is so much diversity
> about what is considered the "correct" location that qmail is unlikely ever
> to arrive at something satisfactory to all.

It would be nice if you could set the paths at compile time, sort of like
how the compiler is chosen via conf-cc.sh.

Evan
--
Evan Champion * Director, Network Operations
mailto:evanc@synapse.net * Directeur, Exploitation du reseau
http://www.synapse.net/ * Synapse Internet

"Fred Lindberg" <lindberg@id.wustl.edu> writes:

> AFAIK, for the linux file system standard,
>
> /usr/bin for binaries
> /usr/man for man
> /etc/qmail for config stuff. I assume ~alias/.qmail-... should go here too.
>
> All this could also be in /usr/local hierarchy.

IMHO, /usr/local/var is _just wrong_, as is /usr/local/etc.

/usr/[local/]bin for binaries,
/etc/qmail if you want that (I don't really care :)
/var/qmail/ for the queue and other system state.

In the BSD world, /var is supposed to be for "system state" on a per-system
basis. /etc for config files, /var for things like mail queues and
/var/run/ where pid's go.

Of course, "supposed to be" and "is used as" are two drastically different
things.

--Michael

AFAIK, for the linux file system standard,

/usr/bin for binaries
/usr/man for man
/etc/qmail for config stuff. I assume ~alias/.qmail-... should go here too.

All this could also be in /usr/local hierarchy.

I don't know why all qmail stuff is on /var, but it makes sense from the point
of view that if the /var partition is not available, mail won't work anyway,
and also from a performance point of view if /var is optimized via RAID or
such, then all qmail files will take advantage of it. It's easy enough to make
/var/qmail/man part of the MANPATH and to put in symlinks in /usr/local/[s]bin
for manual execution of some of the commands.

-Sincerely, Fred

(Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)

As has been pointed out quite as few times I think. There are alway symlinks
if you want to put directories in other places. There is so much diversity
about what is considered the "correct" location that qmail is unlikely ever
to arrive at something satisfactory to all.

Some people do this:

cd /var/qmail
mv bin /usr/local/sbin/qmail
ln -s /usr/local/sbin/qmail bin
mv control /etc/qmail
ln -s /etc/qmail control

etc.

AFAIK, the only restriction is that much of queue must reside on one file
system otherwise link to your hearts content.



At 05:29 PM 2/21/97 -0600, Fred Lindberg wrote:
>AFAIK, for the linux file system standard,
>
>/usr/bin for binaries
>/usr/man for man
>/etc/qmail for config stuff. I assume ~alias/.qmail-... should go here too.
>
>All this could also be in /usr/local hierarchy.
>
>I don't know why all qmail stuff is on /var, but it makes sense from the
point
>of view that if the /var partition is not available, mail won't work anyway,
>and also from a performance point of view if /var is optimized via RAID or
>such, then all qmail files will take advantage of it. It's easy enough to
make
>/var/qmail/man part of the MANPATH and to put in symlinks in
/usr/local/[s]bin
>for manual execution of some of the commands.
>
>-Sincerely, Fred
>
>(Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
>
>
>

-----BEGIN PGP SIGNED MESSAGE-----

On 21 Feb 1997, D. J. Bernstein wrote:

> qmail 1.00 is available through http://pobox.com/~djb/qmail.html.
>
> No code changes from 0.96. I have lots of cleanups scheduled, and I'll
> have to add IPv6 support someday, but 1.00 should be an adequate MTA for
> the next several years.

I've been using qmail for a number of releases, and recommending it to a
fairly large number of users on the IRC support network I run. I've been
waiting to see what the license for the production version would be:

>[root@austin; /usr/local/src/qmail-1.00] grep -qie license *;echo $?
>1

I'm disappointed. The web page on url http://pobox.com/~djb/qmail.index
points to information that suggests that the distribution policy (distribute
an unmodified tar file, no `package' formats or precompiled binaries without
special permission) still holds.

I've been using qmail since 0.90 or so, and am very happy with it. It's
certainly a lot better alternative for the experienced admin than sendmail.
As a result, I've been recommending it fairly heavily on the IRC support
network I run.

I had hoped that qmail would make an impact on the Internet as free software
(BSD license, GPL, whatever), but it's hard to see how it's going to make
much of an impact when distribution is so tightly-controlled.

Sendmail, in particular, is available in several `plug-and-play' varieties,
and will be up and running in the second or two it takes to install it, for
example, from a Red Hat or Debian Linux distribution. Qmail has the
potential to be just as flexible, but the chosen `default' licensing,
involving having all distributors ask for special permission to distribute
qmail with modified packaging, seems likely to encourage fewer, rather than
more, installations.

I know it's been heard before, but I'd really been hoping something more
flexible could be done---I regret that I'll have to stop recommending the
package for new users, since they are the people who will be offering advice
in mailer selection, based on their own experiences, in a year or two.


lilo

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBMw+pep23L4XLlypxAQG2PQP7BNzAPF8YFLVkZ+Pu4fd6nBq4er4gIZbC
ZtkgQBOGQQL/qq7uVc0h77kb3B5GqgEjoGaxh+K+TccqEvBWxHr+0vUcNBjptTQr
Qk7BwVWvT4RxO/0K3R8XcPVaP+hrPF7QshYp5TeshBpTR2L3ZJBSfHIoEx3zb7rw
JKiEr8qdHL0=
=FvXo
-----END PGP SIGNATURE-----

lilo writes:

> I'm disappointed. The web page on url http://pobox.com/~djb/qmail.index
> points to information that suggests that the distribution policy (distribute
> an unmodified tar file, no `package' formats or precompiled binaries without
> special permission) still holds.

Well, for the sake of truth, these are greater permissions than have
applied to pre-1.00 versions of qmail. At least we can distribute the
unmodified sources now.

However, I must concur with lilo. If the whole point behind qmail is
to crush sendmail, it should be as freely copyable as sendmail is. I
understand Dan's concern about rogue modifications damaging qmail's
reputation. The proper way to protect reputations is through the
trademark system (or through cryptographic signatures), not the
copyright system. Instead of insisting that the software can only be
distributed in source form, Dan should create a trademarkable name for
qmail, and insist that the software can only use the trademarked name
if it meets his criteria.

--
-russ <nelson@crynwr.com> http://www.crynwr.com/~nelson
Crynwr Software sells network driver support | PGP ok
521 Pleasant Valley Rd. | +1 315 268 1925 voice | Peace, Justice, Freedom:
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | pick two (only mostly true)

-----BEGIN PGP SIGNED MESSAGE-----

On 23 Feb 1997, Russell Nelson wrote:

> lilo writes:
>
> > I'm disappointed. The web page on url http://pobox.com/~djb/qmail.index
> > points to information that suggests that the distribution policy (distribute
> > an unmodified tar file, no `package' formats or precompiled binaries without
> > special permission) still holds.
>
> Well, for the sake of truth, these are greater permissions than have
> applied to pre-1.00 versions of qmail. At least we can distribute the
> unmodified sources now.
>
> However, I must concur with lilo. If the whole point behind qmail is
> to crush sendmail, it should be as freely copyable as sendmail is. I
> understand Dan's concern about rogue modifications damaging qmail's
> reputation. The proper way to protect reputations is through the
> trademark system (or through cryptographic signatures), not the
> copyright system. Instead of insisting that the software can only be
> distributed in source form, Dan should create a trademarkable name for
> qmail, and insist that the software can only use the trademarked name
> if it meets his criteria.

Hmmm. I don't want to spend too much time on this issue, because it's
certainly Dan's right to do whatever he wants with the software he's
produced. Broader use of qmail is an issue only if he considers it to be.

But I will point out that, for freely-available software packages on the
Internet, a certain regime exists. The author puts out periodic releases;
if he or she has been successful in maintaining a usable package, those
releases will be considered the `canonical' ones. The free software market
judges the result.

Authors who put the amount of effort into their software that Dan Bernstein
has into his, with the quality of result we've seen in qmail, have little to
worry about in terms of keeping control of their packages.

If Dan wants to see broader use of qmail as a free software product, he has
to be willing to let go of the product enough that the users can consider it
`their' product. If he's not willing to do that, and let the free software
market judge the result, perhaps he should consider making qmail a commer-
cial, binary-only product and competing in that arena. Perhaps that's his
ultimate aim; I'm no mind-reader.

I just want to be able to continue recommending qmail to new users. It's
small, it's tight, it's secure, and it could function nicely as a freely-
available black box for people who have little experience with Internet mail
and need a better option than sendmail. But I can't recommend it to the
people who could get the most use out of it, so I've got to either go back
to touting sendmail or look for another free alternative. I wish Dan would
reconsider his approach in re licensing.



lilo

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBMxAdo523L4XLlypxAQFd6wP+PpOleHs+dKyslxSYwoDzWcx/c7t3Ptxd
TlPokteD2nctkdR54b72QgyjNKritcqPNseVqZiwMxwlOe2y2YCRAEtqC+9dAzL5
Dnmeu/kW5r+4aolaouY5sbdHI/B7kA6zjOJ/bV1ZHShuhwvBeJNAfUGTIyruLW1+
rK6Ho7J7ao4=
=uwGi
-----END PGP SIGNATURE-----

copyright system. Instead of insisting that the software can only be
distributed in source form, Dan should create a trademarkable name for
qmail, and insist that the software can only use the trademarked name
if it meets his criteria.

Does this restriction on the distribution on qmail mean that one has
to get a permission to upload a qmail src.rpm as well? (src rpm
contains the original sources, but it also includes possible patches)

Mate
Mate Wierdl
mw@moni.msci.memphis.edu
University of Memphis

>BTW, is there any possibility of installing the binaries in /usr/local
>but keeping the mail queue and control files in /var/qmail?

mkdir /var/qmail
ln -s /usr/local/bin /var/qmail/bin
ln -s /usr/local/man /var/qmail/man
install qmail

-Dave