qmail Digest 0 Jan 1900 00:00:00 -0000 Issue 761
Topics (messages 30289 through 30371):
Re: Return Receipts
30289 by: Anand Buddhdev
30321 by: Russell Nelson
30367 by: Claus F�rber
Re: Odd Error w/ Virtual Domains
30290 by: Anand Buddhdev
Re: Kurt's Closet on qmail
30291 by: Anand Buddhdev
30292 by: Robin Bowes
30294 by: Petr Novotny
30295 by: Petr Novotny
30296 by: Vince Vielhaber
30301 by: Fred Lindberg
30302 by: Petr Novotny
30304 by: Fred Lindberg
30308 by: Daniluk, Cris
30310 by: craig.jcb-sc.com
30311 by: Lyndon Griffin
30312 by: Josh Pennell
30314 by: Adam D . McKenna
30315 by: Timothy L. Mayo
30317 by: Lyndon Griffin
30318 by: Russell Nelson
30319 by: Dave Sill
30320 by: Dave Sill
30322 by: Patrick Berry
30324 by: Lyndon Griffin
30325 by: Lyndon Griffin
30327 by: Roger Merchberger
30328 by: Dave Sill
30329 by: Eric Rahmig
30333 by: Lyndon Griffin
30335 by: Racer X
30336 by: Adam D . McKenna
30338 by: Lyndon Griffin
30339 by: Kevin Waterson
30341 by: Russell Nelson
30344 by: Lyndon Griffin
30345 by: Adam D . McKenna
30347 by: Jim Gilliver
30349 by: James J. Lippard
30350 by: Russell Nelson
30353 by: Russ Allbery
30354 by: Russ Allbery
30355 by: Russ Allbery
30356 by: Mirko Zeibig
30357 by: Mirko Zeibig
30360 by: Russ Allbery
30361 by: craig.jcb-sc.com
30364 by: James J. Lippard
30368 by: Chris Green
30369 by: craig.jcb-sc.com
30371 by: craig.jcb-sc.com
addressrewriting-problems with ofmipd
30293 by: harry_rueter.gmx.de
30300 by: Dave Sill
Users and default
30297 by: Puck
Re: qmail-smtpd/tcpserver connection limit
30298 by: Dave Sill
Re: Corrupt Message Body
30299 by: Dave Sill
size of locals
30303 by: Van Liedekerke Franky
30305 by: Russell Nelson
Russ Nelson's open-smtp patch
30306 by: Michael
30307 by: Vince Vielhaber
30309 by: David Harris
30316 by: Russell Nelson
30358 by: Mirko Zeibig
Re: Reading "aliases.cdb"?
30313 by: Adam D . McKenna
When will qmail back off to the next MX?
30323 by: Greg Owen
30326 by: Dave Sill
30334 by: Greg Owen
30340 by: Russell Nelson
30346 by: Greg Owen
30348 by: Karl Lellman
30352 by: Sam
30363 by: Strange
/etc/skel
30330 by: Luka Gerzic
30331 by: Timothy L. Mayo
Checkpassword won't work (still) on Caldera
30332 by: Barry Dwyer
30351 by: Sam
SMTP problems.
30337 by: Larry H. Raab
30343 by: David Dyer-Bennet
/var/qmail/control/locals and regex
30342 by: Robert Sander
Virtual Domains again
30359 by: Qmail-User
.qmail and notification
30362 by: B. Engineer
SMTP lookups
30365 by: Mark Parker
CNAME error - more information
30366 by: Mark Parker
qmail distro
30370 by: Kevin Waterson
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To bug my human owner, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
On Tue, Sep 14, 1999 at 04:27:30PM -0400, Thomas Blauvelt wrote:
> > man qreceipt
>
> Yes, but is anyone sucessfully using this?
Don't know. I've tested it, and it works just fine.
> Are there any mailers which use the necessary
> Notice-Requested-Upon-Delivery-To header field?
Again, I don't know, but most unix mailers (and some good windows based
ones) will allow you to insert any arbitrary headers in a message, so it
should be easy to setup such a client for use with qreceipt.
--
See complete headers for more info
Thomas Blauvelt writes:
> On Mon, 13 Sep 1999, Anand Buddhdev wrote:
>
> > man qreceipt
>
> Yes, but is anyone sucessfully using this?
>
> Are there any mailers which use the necessary
> Notice-Requested-Upon-Delivery-To header field?
That's a good question. It's very nice for Dan to pronounce that
everybody else's receipt standard is broken, but introducing his own
standard isn't likely to be helpful if nobody adopts it.
What's wrong with having a program which acts on Netscape's
"Disposition-Notification-To: <samp>RFC822-address</samp>" ? It could
be included in a .qmail file similar to qreceipt.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Russell Nelson <[EMAIL PROTECTED]> schrieb/wrote:
> What's wrong with having a program which acts on Netscape's
> "Disposition-Notification-To: <samp>RFC822-address</samp>" ? It could
> be included in a .qmail file similar to qreceipt.
I think it would be easier to add it to qreceipt. On the other hand, why
bother? None of the receipt-request headers does actually work reliably
and I don't think many people have added qrecepit to their .qmail files.
I think it's better to stick with RFC 1891 ff. and UA-side MDNs (Message
Disposition Notices).
The first one will only work if every MTA supports it, but at least the
last supporting MTA will send you a notice.
MDNs give you a notice of what happened to the message after delivery.
--
Claus Andre Faerber <http://www.faerber.muc.de>
PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E 25 56 69 A5 C6 A0 C9 DC
On Tue, Sep 14, 1999 at 06:29:26PM -0400, Shishir Gundavaram wrote:
> But if I use a MUA, like Netscape, to send the message to
> [EMAIL PROTECTED], it's getting sent to: [EMAIL PROTECTED],
> and I see this in the logs:
This is your clue to solve the problem. The fact that the delivery is
being done to "[EMAIL PROTECTED]" means that Netscape sent the
message with an envelope recipient of "[EMAIL PROTECTED]" instead of
"[EMAIL PROTECTED]". Look for the problem in Netscape (could be any
number of things, including perhaps a wrong address book entry).
--
See complete headers for more info
On Wed, Sep 15, 1999 at 11:42:45AM +0100, Petr Novotny wrote:
> ... for something better. BTW, if you couldn't configure sendmail
> properly, odds are that you will have problems with
> qmail/postfix/whatever too.
I somewhat disagree with that statement. I always had trouble
understanding sendmail.cf, and qmail was so much easier to understand. I
had it running in 1 hour. At that time, I wasn't even fully conversant
with SMTP.
--
See complete headers for more info
Petr Novotny <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 15 Sep 99, at 11:09, Magnus Bodin wrote:
> > > have you seen
> > > http://www.securityportal.com/direct.cgi?/closet/closet19990915.html
> > >
> > > Anyone cares to comment?
> >
> > * qmail is not painful to configure and maintain.
>
> Depends. I have had no problems (my first qmail installation was
> up and running in 10 minutes), but the amount of questions in this
> conference (and replies "Go read Life with qmail") suggests
> otherwise.
This does not infer that qmail is "painful to configure and maintain". It
does however require a certain degree of competence to use qmail, as does
the adminisatration of any MTA, and, as the architecture is significantly
different than sendmail it is inevitable that questions will arise. The
fact that many questions can be answered with either RTFM or "Go read Life
with qmail" suggests that people are running into the same issues rather
than finding qmail "painful".
>
> > * the qmail license may be unclear in some points, but I can't see why
> > Kurt
> > is quoting the clearest part of the "license".
> >
> > DJB:s main point is that you can't distribute binary qmail
distributions
> > or modified source distributions and still claim that it's qmail.
>
> But some important parts are really missing. What's the licence for
> daemontools? For rblsmtpd? For qmail-analog? Am I allowed to
> start my syslogd or rc5des client under supervise if I haven't
> installed qmail?
These aren't anything to do with qmail. They're all seperate programs by
the author of qmail. They have seperate (and different) licensing.
R.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 15 Sep 99, at 13:07, Anand Buddhdev wrote:
> > ... for something better. BTW, if you couldn't configure sendmail
> > properly, odds are that you will have problems with
> > qmail/postfix/whatever too.
>
> I somewhat disagree with that statement. I always had trouble
> understanding sendmail.cf, and qmail was so much easier to understand. I
> had it running in 1 hour. At that time, I wasn't even fully conversant
> with SMTP.
I thought someone would eventually get at this; I should have been
more explicit:
If you know _what_ you want to achieve, it's only a technicality to
do that in /var/qmail/control or sendmail.cf. It might take some
time, but you'll do that.
If you don't know what you're doing, or you don't care, then qmail is
not going to be helpful at all.
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2 -- QDPGP 2.60
Comment: http://community.wow.net/grt/qdpgp.html
iQA/AwUBN9+LMFMwP8g7qbw/EQLkwgCdGOzdEqyhD4IPPeCsNhd8q99No/MAn2c3
A16lQbEC3xgmuGhlopU+sah2
=PKYe
-----END PGP SIGNATURE-----
--
Petr Novotny, ANTEK CS
[EMAIL PROTECTED]
http://www.antek.cz
PGP key ID: 0x3BA9BC3F
-- Don't you know there ain't no devil there's just God when he's drunk.
[Tom Waits]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 15 Sep 99, at 11:21, Robin Bowes wrote:
> > But some important parts are really missing. What's the licence for
> > daemontools? For rblsmtpd? For qmail-analog? Am I allowed to start my
> > syslogd or rc5des client under supervise if I haven't installed qmail?
>
> These aren't anything to do with qmail. They're all seperate programs by
> the author of qmail. They have seperate (and different) licensing.
My installation of qmail would be certainly crippled without
tcpserver, supervise and rblsmtpd. Since I don't have licence to
those programs, it's possible that I'm breaking the law by using
qmail in the "documented and supported" way.
It's nice that you know the licence for qmail-1.03.tar.gz - but this
package per se is somewhat unuseful. What's the licence for
tcpserver?
While I am not afraid to be awoken at three in the morning by the
software police, my lawyer might ask me some questions if I
started my business selling e-mail service with qmail.
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2 -- QDPGP 2.60
Comment: http://community.wow.net/grt/qdpgp.html
iQA+AwUBN9+NHFMwP8g7qbw/EQLilgCXUnnGYoPIogszuYNxMT+HPv/ZkACeOhG2
GhTwI/ylESoz3vRXJ2HAjvc=
=9iOY
-----END PGP SIGNATURE-----
--
Petr Novotny, ANTEK CS
[EMAIL PROTECTED]
http://www.antek.cz
PGP key ID: 0x3BA9BC3F
-- Don't you know there ain't no devil there's just God when he's drunk.
[Tom Waits]
On Wed, 15 Sep 1999, Petr Novotny wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 15 Sep 99, at 11:21, Robin Bowes wrote:
> > > But some important parts are really missing. What's the licence for
> > > daemontools? For rblsmtpd? For qmail-analog? Am I allowed to start my
> > > syslogd or rc5des client under supervise if I haven't installed qmail?
> >
> > These aren't anything to do with qmail. They're all seperate programs by
> > the author of qmail. They have seperate (and different) licensing.
>
> My installation of qmail would be certainly crippled without
> tcpserver, supervise and rblsmtpd. Since I don't have licence to
> those programs, it's possible that I'm breaking the law by using
> qmail in the "documented and supported" way.
>
> It's nice that you know the licence for qmail-1.03.tar.gz - but this
> package per se is somewhat unuseful. What's the licence for
> tcpserver?
>
> While I am not afraid to be awoken at three in the morning by the
> software police, my lawyer might ask me some questions if I
> started my business selling e-mail service with qmail.
I don't know that Dan's actually come up with licensing terms for the
remaining items. I know that he knows that I'm using tcpserver for more
than just qmail-smtpd. We've discussed it at length. I'm using it for
backups between systems, I've got LabVIEW systems talking to unix systems
with it, data logging, qpopper, imapd, and even for encrypted credit card
data with a java app. Probably more things that haven't come to mind yet!
It's also about to replace inetd's remaining stuff here - it seems the
problem I had with telnetd is contained to the HP machine and it was just
retired.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null
# include <std/disclaimers.h> TEAM-OS2
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
On Wed, 15 Sep 1999 07:30:34 -0400 (EDT), Vince Vielhaber wrote:
>I don't know that Dan's actually come up with licensing terms for the
>remaining items. I know that he knows that I'm using tcpserver for more
>than just qmail-smtpd. We've discussed it at length. I'm using it for
www.pobox.com/~djb/rights.html:
"I don't know which of these theories will succeed in court. I also
don't think you should have to care. So I promise I won't sue you for
copyright violation for downloading documents from my server."
www.pobox.com/~djb/softwarelaw.html:
"Once you've legally downloaded a program, you can compile it. You can
run it. You can modify it. You can distribute your patches for other
people to use. If you think you need a license from the copyright
holder, you've been bamboozled by Microsoft. As long as you're not
distributing the software, you have nothing to worry about."
-Sincerely, Fred
(Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 15 Sep 99, at 8:53, Fred Lindberg wrote:
> www.pobox.com/~djb/rights.html:
>
> "I don't know which of these theories will succeed in court. I also
> don't think you should have to care. So I promise I won't sue you for
> copyright violation for downloading documents from my server."
That's about something different: That's about some lame theory
which says that if you're requesting a document by http, you're
making a copy and you need authorization. I fail to see
daemontools-something.tar.gz as a document.
Anyway, for anal-retentive types, a promise "I won't sue you" put
somewhere on the web by someone claiming to be djb doesn't cut
it.
And yes, I'm being anal retentive now.
> www.pobox.com/~djb/softwarelaw.html:
>
> "Once you've legally downloaded a program, you can compile it. You can run
> it. You can modify it. You can distribute your patches for other people to
> use. If you think you need a license from the copyright holder, you've
> been bamboozled by Microsoft. As long as you're not distributing the
> software, you have nothing to worry about."
That may be the way the copyright law works in US - I don't know
what makes the legality of downloading a program - but that's
probably not how the law works in other countries. "Do you have a
licence? If not, stop using the program." Been there, heard that.
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2 -- QDPGP 2.60
Comment: http://community.wow.net/grt/qdpgp.html
iQA/AwUBN9+00VMwP8g7qbw/EQJTJACg1rAI2FPnwpw2YfOd69hXLeU9P68An2dD
KvcMLMjrUs4eXOC1jWZZs3rn
=IGyW
-----END PGP SIGNATURE-----
--
Petr Novotny, ANTEK CS
[EMAIL PROTECTED]
http://www.antek.cz
PGP key ID: 0x3BA9BC3F
-- Don't you know there ain't no devil there's just God when he's drunk.
[Tom Waits]
On Wed, 15 Sep 1999 16:01:38 +0100, Petr Novotny wrote:
>That's about something different: That's about some lame theory
>which says that if you're requesting a document by http, you're
>making a copy and you need authorization. I fail to see
>daemontools-something.tar.gz as a document.
Of course it's a document.
>Anyway, for anal-retentive types, a promise "I won't sue you" put
>somewhere on the web by someone claiming to be djb doesn't cut
>it.
>And yes, I'm being anal retentive now.
Would you be happy if someone claiming to be DJB had put up a
daemontools package on the same site and in it given you the same info,
or said that it's GPL? Would you require a PGP signature? Would a PGP
signature have any legal value?
DJB should decide to sue me for using daemontools (p<epsilon), I think
that I could make a very reasonable argument: Why would he put it
there, document and advertize it, if he didn't want people to use it?
-Sincerely, Fred
(Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
Some companies don't want to have to make that argument :)
> -----Original Message-----
> From: Fred Lindberg [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 15, 1999 3:59 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Kurt's Closet on qmail
>
>
> On Wed, 15 Sep 1999 16:01:38 +0100, Petr Novotny wrote:
>
> >That's about something different: That's about some lame theory
> >which says that if you're requesting a document by http, you're
> >making a copy and you need authorization. I fail to see
> >daemontools-something.tar.gz as a document.
>
> Of course it's a document.
>
> >Anyway, for anal-retentive types, a promise "I won't sue you" put
> >somewhere on the web by someone claiming to be djb doesn't cut
> >it.
> >And yes, I'm being anal retentive now.
>
> Would you be happy if someone claiming to be DJB had put up a
> daemontools package on the same site and in it given you the
> same info,
> or said that it's GPL? Would you require a PGP signature? Would a PGP
> signature have any legal value?
>
> DJB should decide to sue me for using daemontools (p<epsilon), I think
> that I could make a very reasonable argument: Why would he put it
> there, document and advertize it, if he didn't want people to use it?
>
>
> -Sincerely, Fred
>
> (Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
>
>
>
>www.pobox.com/~djb/softwarelaw.html:
>
>"Once you've legally downloaded a program, you can compile it. You can
>run it. You can modify it. You can distribute your patches for other
>people to use. If you think you need a license from the copyright
>holder, you've been bamboozled by Microsoft. As long as you're not
>distributing the software, you have nothing to worry about."
I was told last night by an IP lawyer that "click-through licenses
have been upheld in court". That is, if you download what *appears*
to be free software via FTP or the Web, get it on your machine, run
it, and it says "click ACCEPT if you accept <whatever terms>,
else click DENY and you must destroy all copies of this software [or
whatever]", and you click ACCEPT but do not abide by the terms (even
though you abide by the *legislated* terms for copyrighted works,
i.e. you don't redistribute the code), you are liable for --
something, I guess, infringing the copyright, even though you didn't,
or infringing the license, even though you did not agree to it
in any legally binding contract with another person, organization,
or duly appointed agent thereof.
So it appears whatever Microsoft et al want, they get. This lawyer
was actually quite happy with the decisions, despite implicit recognition
that it was extra-legal (in the sense that the judge just invented
new law on the spot) -- she pointed out how that's often how new
"law" gets made. She said it was better this way, because, in *my*
words, wouldn't it be doggone inconvenient to make people take another
30 seconds to a couple of minutes to read and approve a license during
an on-line transaction *before* taking the 1 hour to download so-called
"free" software or bringing the shrink-wrapped software they have
supposedly "bought" home. I.e. it's better to put them into the position
of reading and approving that license *later*, after they've already
invested so much additional time and effort that the pressure to conform
and accept a license they'd have easily disagreed with at the point of
sale (or FTP), or even just recognize that they're now "talking" to a
machine and thus have no legal *or ethical* compunction to "tell the
truth" ("thou shalt not bear false witness against thy neighbor" does
not cover conversation with your *computer*), so they're either
conforming users or targets of litigation.
I haven't done any research on the decisions yet, but that's the gist
of her interpretation, and it is more consistent with *recent* explanations
of what licenses can and cannot get away with than my previous
understanding.
So apparently the proprietary software industry is willfully and
illegally abetted by judges who make law instead of adjucating it,
at the expense of end users.
I wonder if anyone's working on bringing a class-action lawsuit against
proprietary software producers who promise, via ads, that users will
actually "own" copies of the software, with all that implies via
copyright law and freedoms resulting thereby, but who then retroactively
take back some of those freedoms, and who even use the courts to
create new law for them that the *legislatures* have the sole province
to create, with the input from ordinary citizens that approach would
at least appear to imply? (Not that I exactly *trust* them to do so;
but legislation is a *vastly* better way to inform the public of what
it is allowed to do than litigation via a corruptible judiciary, because
the former is before-the-fact, the latter amounts to retroactive
legislation...not to mention the opportunities for relief are more
plentiful.)
Perhaps the threat of a few billion dollars of repayment, e.g. triple
damages of the difference between sale price plus time/resources spent
by users obtaining the software and the typical rental/lease price
(targeting those licenses that amount to changing the transaction from
a sale into a rental/lease), would get the software developers to
change their tune.
Of course, such a lawsuit would implicate the (presumably) corrupt judges
who facilitated these tactics in court, and even juries can be effectively
bought off to return verdicts in accord with the desires of their
neighbors and friends (an anti-MS verdict in Seattle? yeah, right ;-),
without being overturned by judges who should, and often do, know
better. So the legal profession, which includes most judges, could
be expected to defend their profession against any and all attacks,
no matter how legitimate.
In the end, there's always the Second Amendment. I've just exercised
my rights vis-a-vis the First -- I hope those who've corrupted our
legal system have an opportunity to pay attention. (Since I choose
non-violence and don't own a gun, the only role the Second Amendment
plays for me, personally, is to speak out sufficiently so *others* have
less reason to take up arms against those who attack our Constitution,
including our system of government, whether from without or within.
Those who wilfully do violence to that system, on the assumption that
they're never going to be physically harmed as a result, might, someday,
be rather disappointed that I and others stop exercising our First
Amendment rights to speak out against violence when it's directed at
them -- I, for one, tend to get *very* quiet when I see bullies, especially
those who've already been warned, about to get the **** beaten out of them.)
tq vm, (burley)
> > But some important parts are really missing. What's the licence for
> > daemontools? For rblsmtpd? For qmail-analog? Am I allowed to
> > start my syslogd or rc5des client under supervise if I haven't
> > installed qmail?
>
> These aren't anything to do with qmail. They're all seperate programs by
> the author of qmail. They have seperate (and different) licensing.
But they are something to do with qmail, and not just because they have djb
in common. Any newb stopping by this list or reading on of the how to's
will get the following information: get qmail, but to make it work, also
get daemontools and ucspi-tcp. On top of that, near the top of the home
page you can read that qmail no longer works with inetd (or am I dreaming),
which means if you want to be able to receive email with qmail, you need
tcpserver or something similar. Or am I just being thick headed, again?
I did feel a twinge of pain setting up qmail for the first time, but I
*still* have trouble getting sendmail to work on a regular basis.
<:) Lyndon
Hmmm. Inetd under OpenBSD 2.5 consistently envokes the qmail-1.03 smtpd
daemon. I don't run daemontools, ucspi-tcp or tcpserver.
I also had qmail running under solaris 2.6 (x86 ver) without the above
requirements?
So what gives? Is it that qmail-1.04 won't work with inetd?
One last note, as the senior developer here always says, "if it was hard
to write it should be hard to read" ;)
> get qmail, but to make it work, also
> get daemontools and ucspi-tcp. On top of that, near the top of the home
> page you can read that qmail no longer works with inetd (or am I
dreaming),
> which means if you want to be able to receive email with qmail, you need
> tcpserver or something similar. Or am I just being thick headed, again?
qmail runs fine under inetd. It is just not officially supported by the
author or by this mailing list.
The reason it's not supported is because of the large differences in tcpd and
inetd between the different unices. These differences can sometimes cause
support headaches.
--Adam
On Fri, Aug 20, 1999 at 06:34:50AM -0700, Josh Pennell wrote:
> Hmmm. Inetd under OpenBSD 2.5 consistently envokes the qmail-1.03 smtpd
> daemon. I don't run daemontools, ucspi-tcp or tcpserver.
>
> I also had qmail running under solaris 2.6 (x86 ver) without the above
> requirements?
>
> So what gives? Is it that qmail-1.04 won't work with inetd?
>
> One last note, as the senior developer here always says, "if it was hard
> to write it should be hard to read" ;)
>
>
> > get qmail, but to make it work, also
> > get daemontools and ucspi-tcp. On top of that, near the top of the home
> > page you can read that qmail no longer works with inetd (or am I
> dreaming),
> > which means if you want to be able to receive email with qmail, you need
> > tcpserver or something similar. Or am I just being thick headed, again?
>
qmail works just fine under inetd. It is just that Dan and most people on
this list will no longer support you if you have problems getting it
configured in the first place if you are trying to use inetd. There are
too many busted inetd implementations out there.
On Fri, 20 Aug 1999, Josh Pennell wrote:
> Hmmm. Inetd under OpenBSD 2.5 consistently envokes the qmail-1.03 smtpd
> daemon. I don't run daemontools, ucspi-tcp or tcpserver.
>
> I also had qmail running under solaris 2.6 (x86 ver) without the above
> requirements?
>
> So what gives? Is it that qmail-1.04 won't work with inetd?
>
> One last note, as the senior developer here always says, "if it was hard
> to write it should be hard to read" ;)
>
>
> > get qmail, but to make it work, also
> > get daemontools and ucspi-tcp. On top of that, near the top of the home
> > page you can read that qmail no longer works with inetd (or am I
> dreaming),
> > which means if you want to be able to receive email with qmail, you need
> > tcpserver or something similar. Or am I just being thick headed, again?
>
>
---------------------------------
Timothy L. Mayo mailto:[EMAIL PROTECTED]
Senior Systems Administrator
localconnect(sm)
http://www.localconnect.net/
The National Business Network Inc. http://www.nb.net/
One Monroeville Center, Suite 850
Monroeville, PA 15146
(412) 810-8888 Phone
(412) 810-8886 Fax
thanks everyone for the quick response... now, my next question - does it
not seem a little extreme to say that simply
"qmail 1.03 no longer supports inetd."
and then link to the ucspi-tcp package, which you kinda have to figure out
for yourself that that's what the link is trying to tell you, when it is, as
you all say, quite possible that qmail-smptd WILL run under inetd (maybe OS
dependent)?
Or is the intent of Russ and DJB to get us all downloading and using
software which we all still argue about licensing over, which in the end
they will come out and charge us for back usage or get the hell off?
Sure, that's an extreme scenario, but maybe THAT's the kind of information
we should see on the site - with no room for misinterpretation, this package
runs on some inetds - click here to see the list. Oh, and by the way, we
recommend that you instead use our ucspi package, which only costs $x in
licensing fees.
What I'm hearing a lot of on this list and on the web site is "qmail is
great, everything else is broken," which I'm prone to believe, but the
longer I hang around, it seems exactly the opposite.
> -----Original Message-----
> From: Timothy L. Mayo [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 15, 1999 10:44 AM
> To: Josh Pennell
> Cc: Lyndon Griffin; [EMAIL PROTECTED]
> Subject: RE: Kurt's Closet on qmail
>
>
> qmail works just fine under inetd. It is just that Dan and most people on
> this list will no longer support you if you have problems getting it
> configured in the first place if you are trying to use inetd. There are
> too many busted inetd implementations out there.
>
> On Fri, 20 Aug 1999, Josh Pennell wrote:
>
> > Hmmm. Inetd under OpenBSD 2.5 consistently envokes the qmail-1.03 smtpd
> > daemon. I don't run daemontools, ucspi-tcp or tcpserver.
> >
> > I also had qmail running under solaris 2.6 (x86 ver) without the above
> > requirements?
> >
> > So what gives? Is it that qmail-1.04 won't work with inetd?
> >
> > One last note, as the senior developer here always says, "if it was hard
> > to write it should be hard to read" ;)
> >
> >
> > > get qmail, but to make it work, also
> > > get daemontools and ucspi-tcp. On top of that, near the top
> of the home
> > > page you can read that qmail no longer works with inetd (or am I
> > dreaming),
> > > which means if you want to be able to receive email with
> qmail, you need
> > > tcpserver or something similar. Or am I just being thick
> headed, again?
> >
> >
>
> ---------------------------------
> Timothy L. Mayo mailto:[EMAIL PROTECTED]
> Senior Systems Administrator
> localconnect(sm)
> http://www.localconnect.net/
>
> The National Business Network Inc. http://www.nb.net/
> One Monroeville Center, Suite 850
> Monroeville, PA 15146
> (412) 810-8888 Phone
> (412) 810-8886 Fax
>
>
Lyndon Griffin writes:
> thanks everyone for the quick response... now, my next question - does it
> not seem a little extreme to say that simply
> "qmail 1.03 no longer supports inetd."
> and then link to the ucspi-tcp package, which you kinda have to figure out
> for yourself that that's what the link is trying to tell you, when it is, as
> you all say, quite possible that qmail-smptd WILL run under inetd (maybe OS
> dependent)?
Maybe we just have too high an opinion of your intelligence?
> Or is the intent of Russ and DJB to get us all downloading and using
> software which we all still argue about licensing over, which in the end
> they will come out and charge us for back usage or get the hell off?
Is there any evidence that that's {my,our,his} intent? I agree that
the lack of copyright permissions is a little unusual, but it makes
perfect sense once you understand it. You simply have no right to
copy what Dan has given you a copy of. So why include a copyright
permissions message, when it would be empty? To give people the warm
fuzzies? Get your own warm fuzzies, quit trying to take ours.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
"Lyndon Griffin" <[EMAIL PROTECTED]> wrote:
>thanks everyone for the quick response... now, my next question - does it
>not seem a little extreme to say that simply
> "qmail 1.03 no longer supports inetd."
>and then link to the ucspi-tcp package, which you kinda have to figure out
>for yourself that that's what the link is trying to tell you, when it is, as
>you all say, quite possible that qmail-smptd WILL run under inetd (maybe OS
>dependent)?
"A little extreme"? Perhaps. But there's a fine line between saying "X
works" and saying "X is supported". DJB tends to say what he means, so
when he says "X is unsupported", that shouldn't be interpreted as "X
doesn't work".
>Or is the intent of Russ and DJB to get us all downloading and using
>software which we all still argue about licensing over, which in the end
>they will come out and charge us for back usage or get the hell off?
That's silly, if not paranoid and delusional.
>Sure, that's an extreme scenario, but maybe THAT's the kind of information
>we should see on the site - with no room for misinterpretation, this package
>runs on some inetds - click here to see the list. Oh, and by the way, we
>recommend that you instead use our ucspi package, which only costs $x in
>licensing fees.
It's not about $ or market share. Inetd isn't supported (by those who
don't support it, including DJB and other qmail list members) because
it's a support nightmare. If *you* want to support it, feel free:
answer inetd questions here, publish the ultimate qmail+inetd web
site, etc., but don't stamp your feet and demand that other people
support it.
>What I'm hearing a lot of on this list and on the web site is "qmail is
>great, everything else is broken," which I'm prone to believe, but the
>longer I hang around, it seems exactly the opposite.
Neither is true, but qmail (and other djbware) is less broken than 99%
of the alternatives...in my personal experience.
If you think the opposite, what are you doing here?
-Dave
"Lyndon Griffin" <[EMAIL PROTECTED]> wrote:
>But they are something to do with qmail, and not just because they have djb
>in common. Any newb stopping by this list or reading on of the how to's
>will get the following information: get qmail, but to make it work, also
>get daemontools and ucspi-tcp.
That's "advice", not "information". I recommend ucspi-tcp and
daemontools, but they're *not* required to use qmail.
-Dave
PS: newb? 2 qt. reale.
>>> Dave Sill had the thought that... <<<
> "Lyndon Griffin" <[EMAIL PROTECTED]> wrote:
>
> >But they are something to do with qmail, and not just because they have djb
> >in common. Any newb stopping by this list or reading on of the how to's
> >will get the following information: get qmail, but to make it work, also
> >get daemontools and ucspi-tcp.
>
> That's "advice", not "information". I recommend ucspi-tcp and
> daemontools, but they're *not* required to use qmail.
>
> -Dave
>
> PS: newb? 2 qt. reale.
It's also advice that makes the newb's life much easier down the road.
At least, that is what I have found.
Pat
--
Patrick Berry --- Code Creation --- Freestyle Interactive --- 415.778.0610
http://www.freestyleinteractive.com
>
> Maybe we just have too high an opinion of your intelligence?
>
In that case, the web site should bear the following disclaimer:
Warning - this site is only intended for expert qmail users. Please get
bashed on the mailing list for help, and maye after you're all bloody and
hurting, we may help you out. Or, just go f* off and figure out yourself.
Or use sendmail.
Hey, I *LIKE* qmail. It's pretty easy to use. It's definitely easy to
build, and you don't have to know m4. I had no idea that you could use it
with inetd, however (based on the qmail home page), and I was simply trying
to make the following point (to get back to the beginning of the thread)
qmail gets bad press because of exactly this. We never fix the public
image, the web site is not clear on such issues, and we just bash people if
they don't understand what the hell is going on.
> > Or is the intent of Russ and DJB to get us all downloading and using
> > software which we all still argue about licensing over, which
> in the end
> > they will come out and charge us for back usage or get the hell off?
I agree this is absurd. That's why I wrote it. I don't think that this
will actually happen, but if you'd step back and take a look around you,
it's easy to see how some people (and lets face facts, here, most internet
lusers are paranoid and often delusional) could draw this conclusion.
I know you don't CARE what non-qmail users think of qmail. It's pretty
obvious. At least in this forum, it is. Are you this non-committal about
licensing when you're trying to sell one of your prospective clients a
qmail-based solution? Or is Crynwr just a front? I mean, if anyone here
knows anything definitive about the qmail licensing scheme, as well as
others, it would be you. And, based on the amount of traffic it gets on
this list, the topic should be in bright bold red blinking letters at the
top of the home page.
>Get your own warm fuzzies, quit trying to take ours.
I'm trying to, but you seem to bent on preventing me from getting them.
> "A little extreme"? Perhaps. But there's a fine line between saying "X
> works" and saying "X is supported". DJB tends to say what he means, so
> when he says "X is unsupported", that shouldn't be interpreted as "X
> doesn't work".
Right - but what the web page says is not this
"qmail 1.03 users and web site no longer support inetd"
but rather this
"qmail 1.03 no longer supports inetd"
That is about the most misleading statement I have ever read. Say what you
mean and this type of discussion will not be necessary.
Rumor has it that Lyndon Griffin may have mentioned these words:
>
>> "A little extreme"? Perhaps. But there's a fine line between saying "X
>> works" and saying "X is supported". DJB tends to say what he means, so
>> when he says "X is unsupported", that shouldn't be interpreted as "X
>> doesn't work".
>
>Right - but what the web page says is not this
> "qmail 1.03 users and web site no longer support inetd"
>
>but rather this
> "qmail 1.03 no longer supports inetd"
>
>That is about the most misleading statement I have ever read. Say what you
>mean and this type of discussion will not be necessary.
Not really... qmail out of the box doesn't support inetd. There are
configuration changes you have to make *on your own* to get it to work, and
the web site doesn't support or explain these changes. (I'm sure that if
you wanted to support inetd stuff on this list, no-one else here would have
a problem; and would probably even welcome that help, but I speak only for
me.)
Linux out of the box doesn't support the PalmPilot. Plain and simple.
However, with modifications, someone has actually got a minimal (read:
subset thereof) linux kernel and bash to run on an 8Meg PalmPilot!!! You'll
not know that from the www.kernel.org or any other main Linux site, *nor*
will you find that info on www.palm.com. It's not supported, period. Hell,
www.palm.com won't even tell you that an 8Meg Palm III is possible. Why???
they don't support it. Go to www.superpilot.com, however, and you'll find
out that they TRG in fact offers an 8 Meg upgrade for most any PalmPilot.
(BTW, if you're interested in the Palm Linux project, go here:
http://www.uclinux.org/
Just because it can be gotten to work, doesn't mean it's supported. In my
eyes, the statement means exactly what it says.
[[Erm... Oops! I ment to sent this to the list, but Eudora vs. Jove goofed
me up again! Whaddya mean <CTRL-E> sends the message immediately??? ;-)
Sorry for the extra noise, Lyndon!]]
Anyway, as always, this is MHO, YMMV, grains of salt, and all that jazz.
Thanks for the bandwidth,
Roger "Merch" Merchberger
--
Roger "Merch" Merchberger --- sysadmin, Iceberg Computers
Recycling is good, right??? Ok, so I'll recycle an old .sig.
If at first you don't succeed, nuclear warhead
disarmament should *not* be your first career choice.
"Lyndon Griffin" <[EMAIL PROTECTED]> wrote:
>Right - but what the web page says is not this
> "qmail 1.03 users and web site no longer support inetd"
>
>but rather this
> "qmail 1.03 no longer supports inetd"
>
>That is about the most misleading statement I have ever read. Say what you
>mean and this type of discussion will not be necessary.
What the web page (www.qmail.org) says is entirely correct. "qmail
1.03" no longer supports inetd. Dan Bernstein, author of qmail 1.03,
has declared that qmail 1.03 does not support inetd. Russ Nelson,
owner of www.qmail.org, the *unofficial* qmail web site, is merely
repeating what Bernstein said.
Every couple of months, some qmail newbie comes along and starts
pointing out everything that's wrong with qmail, the qmail list, or
the qmail web site. These newbies invariably had a bad experience with
the thing they complain about, and their frustration points out areas
for potential improvement. But, also invariably, they seem to expect
everyone to swoon at their brilliant insights and set to work making
things "right".
It doesn't work that way.
We've been doing qmail, the list, and the web site for years, and,
although things aren't perfect, they're pretty darned good. We're
happy to listen to calm, reasoned requests for change from people who
demonstrate that they've done their homework, and these requests might
eventually lead to changes. But when know-it-all newbies come in and
try to tell us how to do things, well, we're naturally less receptive.
Your "about the most misleading statement I have ever read" comment is
a good example of the kind of declaration that has zero chance of
causing change.
-Dave
Russell Nelson writes:
>Lyndon Griffin writes:
> > thanks everyone for the quick response... now, my next question - does it
> > not seem a little extreme to say that simply
> > "qmail 1.03 no longer supports inetd."
> > and then link to the ucspi-tcp package, which you kinda have to figure out
> > for yourself that that's what the link is trying to tell you, when it is, as
> > you all say, quite possible that qmail-smptd WILL run under inetd (maybe OS
> > dependent)?
>
>Maybe we just have too high an opinion of your intelligence?
Come on, is this kind of comment really necessary? Good grief.
--
Eric Rahmig
[EMAIL PROTECTED]
> Not really... qmail out of the box doesn't support inetd. There are
> configuration changes you have to make *on your own* to get it to
> work, and
> the web site doesn't support or explain these changes. (I'm sure that if
> you wanted to support inetd stuff on this list, no-one else here
> would have
> a problem; and would probably even welcome that help, but I speak only for
> me.)
----------------------------------------------------------------
(from INSTALL in qmail-1.03 source distribution)
16. Set up qmail-smtpd in /etc/inetd.conf (all in one line):
smtp stream tcp nowait qmaild /var/qmail/bin/tcp-env
tcp-env /var/qmail/bin/qmail-smtpd
17. Reboot. (Or kill -HUP your inetd and mke sure the qmail daemons
are running.)
----------------------------------------------------------------
There you have it... "make setup check" doesn't add/change that line in
inetd.conf for you, but other than that it looks pretty "out of the box" to
me. Then, to read that in conjunction with the statement on the web site IS
confusing and misleading.
Now, if this configuration isn't supported, the instructions in the
distribution need to be changed. Or something needs to change, like maybe
including tcpserver as part of the qmail distribution, if that is the
supported method. Or is there a supported method?
hate to jump in late here, but to both sides: where exactly does DJB say he
doesn't support inetd? i can't seem to find anywhere in the source or on
his site. in fact, the main qmail.html page sez:
"qmail's design inherently limits the machine load, so qmail-smtpd can
safely run from your system's inetd."
www.qmail.org is the only place i see that actually sez "not supported," and
it's reasonably clear that the creator of qmail does not maintain that page,
so i'm not sure what the big deal is.
shag
=====
Judd Bourgeois | CNM Network +1 (805) 520-7170
Software Architect | 1900 Los Angeles Avenue, 2nd Floor
[EMAIL PROTECTED] | Simi Valley, CA 93065
Quidquid latine dictum sit, altum viditur.
----- Original Message -----
From: Lyndon Griffin <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wed 15 Sep 1999 13.24
Subject: RE: Kurt's Closet on qmail
> > Not really... qmail out of the box doesn't support inetd. There are
> > configuration changes you have to make *on your own* to get it to
> > work, and
> > the web site doesn't support or explain these changes. (I'm sure that if
> > you wanted to support inetd stuff on this list, no-one else here
> > would have
> > a problem; and would probably even welcome that help, but I speak only
for
> > me.)
>
> ----------------------------------------------------------------
> (from INSTALL in qmail-1.03 source distribution)
> 16. Set up qmail-smtpd in /etc/inetd.conf (all in one line):
> smtp stream tcp nowait qmaild /var/qmail/bin/tcp-env
> tcp-env /var/qmail/bin/qmail-smtpd
>
> 17. Reboot. (Or kill -HUP your inetd and mke sure the qmail daemons
> are running.)
> ----------------------------------------------------------------
>
> There you have it... "make setup check" doesn't add/change that line in
> inetd.conf for you, but other than that it looks pretty "out of the box"
to
> me. Then, to read that in conjunction with the statement on the web site
IS
> confusing and misleading.
>
> Now, if this configuration isn't supported, the instructions in the
> distribution need to be changed. Or something needs to change, like maybe
> including tcpserver as part of the qmail distribution, if that is the
> supported method. Or is there a supported method?
>
>
On Wed, Sep 15, 1999 at 01:24:28PM -0700, Lyndon Griffin wrote:
> There you have it... "make setup check" doesn't add/change that line in
> inetd.conf for you, but other than that it looks pretty "out of the box" to
> me. Then, to read that in conjunction with the statement on the web site IS
> confusing and misleading.
"make install" for any other program doesn't add lines to your inetd.conf
either. I don't see how this is relevant.
> Now, if this configuration isn't supported, the instructions in the
> distribution need to be changed. Or something needs to change, like maybe
> including tcpserver as part of the qmail distribution, if that is the
> supported method. Or is there a supported method?
The decision to not support inetd was made after qmail 1.03 was released and
was announced on this list. I assume that the documentation will be
corrected in the next version.
I don't really know what your agenda is here. There are a lot of different
ways to install qmail. The instructions in INSTALL work for most people.
They worked fine for me the first time, even though I had to adapt the
settings to xinetd. I didn't ask here how to configure my xinetd, I
consulted the xinetd documentation.
--Adam
((DOH - Sorry, Adam, for the double))
> The decision to not support inetd was made after qmail 1.03 was
> released and
> was announced on this list. I assume that the documentation will be
> corrected in the next version.
So then the assumption is that all qmail users subscribe to - and read -
every message on this list. Not only that, new users have also gone back
and read every message that was ever posted.
Seems pretty shaky to me, but I've carried this torch enough for one day.
Cheers,
<:)� Lyndon Griffin
Magnus Bodin wrote:
>
>
> The most important statement to all administrators and OS distributors out
> there is to finally DUMP sendmail.
>
>
We have a linux distribution that is nearing beta and have removed sendmail
entirely
Sendmail has been replaced with qmail and it is hoped all will benifit from it
and
other OS distributors will follow suit.
When the distro is complete we will be seeking beta testers.
Anyone who wishes to be part of this effort may contact me at
[EMAIL PROTECTED]
or through this list.
Kevin Waterson
Eric Rahmig writes:
> Russell Nelson writes:
> >Lyndon Griffin writes:
> > > thanks everyone for the quick response... now, my next question - does it
> > > not seem a little extreme to say that simply
> > > "qmail 1.03 no longer supports inetd."
> > > and then link to the ucspi-tcp package, which you kinda have to figure out
> > > for yourself that that's what the link is trying to tell you, when it is, as
> > > you all say, quite possible that qmail-smptd WILL run under inetd (maybe OS
> > > dependent)?
> >
> >Maybe we just have too high an opinion of your intelligence?
>
> Come on, is this kind of comment really necessary? Good grief.
Obviously, it is necessary. By linking to ucspi-tcp and telling
people that inetd is no longer supported, that should be taken as a
clue for what to do next. Since this is obviously not obvious, I need
to point out why I consider that such a link is an indication of the
high esteem in which I hold qmail users.
Is everything clear now?
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
> Obviously, it is necessary. By linking to ucspi-tcp and telling
> people that inetd is no longer supported, that should be taken as a
> clue for what to do next. Since this is obviously not obvious, I need
> to point out why I consider that such a link is an indication of the
> high esteem in which I hold qmail users.
>
> Is everything clear now?
Sounds good, and in a way, I guess we should all be flattered. Remember the
warm fuzzies? I get them from reading something, not from inferring it on
my own. Thanks,
<:) Lyndon Griffin
On Wed, Sep 15, 1999 at 02:27:28PM -0700, Lyndon Griffin wrote:
> > The decision to not support inetd was made after qmail 1.03 was
> > released and
> > was announced on this list. I assume that the documentation will be
> > corrected in the next version.
>
> So then the assumption is that all qmail users subscribe to - and read -
> every message on this list. Not only that, new users have also gone back
> and read every message that was ever posted.
No, the assumption is that when a qmail user follows the instructions, and
can't get qmail to work with inetd for some reason, he comes here and asks
for help. He is then told that inetd is not officially supported and that he
should use tcpserver.
The user is in effect given an "update". The latest qmail source tarball is
quite old, and since there will be no more releases of qmail 1.0, dan probably
figured that it doesn't make sense to release 1.04 for a minor documentation
change. *That* is what this list and www.qmail.org are for. *WE* are the
cutting edge qmail users that know all the latest info. Expecting current
info to be in a two year old distribution is kind of unrealistic, IMO. So is
expecting an author to release a new version of software just to make
documentation changes.
--Adam
> >Maybe we just have too high an opinion of your intelligence?
>
> Come on, is this kind of comment really necessary? Good grief.
No... especially not when no-one has too high an opinion of anyone ELSE's
intelligence ;)
To ask a quick question (to try and keep on the topic):
When I read through any of the licensing details I could find for qmail (not
many!) I was under the impression that the qmail package was made freely
available, as long as no-one distributed a modified (no matter how slightly)
version of qmail. Isn't the point of this to make sure qmail always
functions exactly the same in any given environment? To prevent things like
"do <blabla> to qmail to make it work.... except in the case of Fuqix
v4.36.3w656.36 where you should do <blablabla>"?
I was also under the impression that I was perfectly able to distribute
qmail as long as I (a) did not sell it and (b) did not distribute binaries
(to prevent qmail failing on a differently configured system).
Do I have anything wrong?
Actually, I have to agree that the wording that "qmail 1.03 no longer
supports inetd" seems to mean that qmail 1.03 doesn't work with inetd. But
the web site (at least as of this moment) has perfectly clear wording:
Inetd is no longer recommended for use with qmail 1.03. Use tcpserver
instead.
BTW, I agree with Eric about being unnecessarily insulting.
Jim Lippard [EMAIL PROTECTED] http://www.discord.org/
Unsolicited bulk email charge: $500/message. Don't send me any.
PGP Fingerprint: 0C1F FE18 D311 1792 5EA8 43C8 7AD2 B485 DE75 841C
On Wed, 15 Sep 1999, Russell Nelson wrote:
> Eric Rahmig writes:
> > Russell Nelson writes:
> > >Lyndon Griffin writes:
> > > > thanks everyone for the quick response... now, my next question - does it
> > > > not seem a little extreme to say that simply
> > > > "qmail 1.03 no longer supports inetd."
> > > > and then link to the ucspi-tcp package, which you kinda have to figure out
> > > > for yourself that that's what the link is trying to tell you, when it is, as
> > > > you all say, quite possible that qmail-smptd WILL run under inetd (maybe OS
> > > > dependent)?
> > >
> > >Maybe we just have too high an opinion of your intelligence?
> >
> > Come on, is this kind of comment really necessary? Good grief.
>
> Obviously, it is necessary. By linking to ucspi-tcp and telling
> people that inetd is no longer supported, that should be taken as a
> clue for what to do next. Since this is obviously not obvious, I need
> to point out why I consider that such a link is an indication of the
> high esteem in which I hold qmail users.
>
> Is everything clear now?
>
> --
> -russ nelson <[EMAIL PROTECTED]> http://russnelson.com
> Crynwr sells support for free software | PGPok | Government schools are so
> 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
> Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
>
James J. Lippard writes:
> Actually, I have to agree that the wording that "qmail 1.03 no longer
> supports inetd" seems to mean that qmail 1.03 doesn't work with inetd. But
> the web site (at least as of this moment) has perfectly clear wording:
>
> Inetd is no longer recommended for use with qmail 1.03. Use tcpserver
> instead.
>
> BTW, I agree with Eric about being unnecessarily insulting.
I don't feel like I have to spell everything out. If you're smart
enough to install and configure an MTA, you're smart enough to figure
out that link. But sigh, I've changed it to make it more obvious.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Petr Novotny <[EMAIL PROTECTED]> writes:
> BTW, how's that really with the licence to Postfix? Are you allowed to
> distribute your patches?
Yes.
> Patched postfix?
Yes.
> In binary form?
Yes.
--
Russ Allbery ([EMAIL PROTECTED]) <URL:http://www.eyrie.org/~eagle/>
Petr Novotny <[EMAIL PROTECTED]> writes:
> On 15 Sep 99, at 8:53, Fred Lindberg wrote:
>> www.pobox.com/~djb/softwarelaw.html:
>> "Once you've legally downloaded a program, you can compile it. You can
>> run it. You can modify it. You can distribute your patches for other
>> people to use. If you think you need a license from the copyright
>> holder, you've been bamboozled by Microsoft. As long as you're not
>> distributing the software, you have nothing to worry about."
> That may be the way the copyright law works in US - I don't know what
> makes the legality of downloading a program - but that's probably not
> how the law works in other countries. "Do you have a licence? If not,
> stop using the program." Been there, heard that.
If that's how it works in the United States, that's probably also how it
works in other countries. If that's not how it works in other countries,
that's probably not how it works in the United States. Except for a few
weird exceptions, mostly not related to software, copyright law is fairly
effectively international under the Berne Convention.
I will say that the above paragraph from Dan's web site contradicts my
reading of the actual copyright statute, which specifically grants
exceptions for making an archival or backup copy and copying which is
necessary for the operation of the software (ie, the copy made in memory
when the computer executes the program) and no other copying. By my
reading of the current US copyright law, downloading, compiling, and
running the software Dan puts on his web site is fine but modifying it is
not, and distributing patches would only be okay if it were ruled that the
patch wasn't a derivative work (which I find unlikely).
It is, of course, always possible that the law has some legal meaning
which isn't clear to a lay person, and I'm not a lawyer (and this isn't
legal advice, etc.). US residents might want to go to the copyright
office pages at <URL:http://lcweb.loc.gov/copyright/> and download the PDF
files of USC title 17 (under Legislation) and read them. Chapter one is
the part of primary interest, IIRC.
--
Russ Allbery ([EMAIL PROTECTED]) <URL:http://www.eyrie.org/~eagle/>
craig <[EMAIL PROTECTED]> writes:
> I was told last night by an IP lawyer that "click-through licenses have
> been upheld in court".
Yes, I believe that's been the case for a while. A click on ACCEPT
appears to be legally roughly equivalent to the signature on a contract,
provided you can prove the person did that (signatures are a bit more
permanent and lasting and easier to establish). This is a Good Thing; if
this weren't the case, ISP AUPs and the like would be uninforceable and
e-commerce would become very difficult. I don't have a problem with that.
> That is, if you download what *appears* to be free software via FTP or
> the Web, get it on your machine, run it, and it says "click ACCEPT if
> you accept <whatever terms>, else click DENY and you must destroy all
> copies of this software [or whatever]", and you click ACCEPT but do not
> abide by the terms (even though you abide by the *legislated* terms for
> copyrighted works, i.e. you don't redistribute the code), you are liable
> for -- something, I guess, infringing the copyright, even though you
> didn't, or infringing the license, even though you did not agree to it
> in any legally binding contract with another person, organization, or
> duly appointed agent thereof.
I'd double-check some of the rest of this with another IP lawyer. *Until
you have accepted the contract* you aren't bound by its provisions; you're
bound by whatever basics of copyright law apply. (IANAL, but this is just
obvious common sense -- contracts don't apply to you until you agree to
them.) If you are in legal possession of a copy of a piece of software,
you're still in legal possession of that copy even if you don't agree to
some additional later contract. In order to make you agree to the
contract as a condition of getting a copy of the software, I'm pretty sure
they have to *make* that a condition; that's why if you download, say,
Postfix from IBM's web site, they put the license up on the screen and
make you accept it before you get a copy.
So the only way I can see the above working is if somehow you're not in
legal possession of the software after you rejected the contract, which
makes no sense to me at all.
Copyright law in the United States specifically gives you the right to
make whatever copies of software are necessary for the normal running of
the software package. However, I can see the argument that in this case,
this only implies your right to run the software and get that dialog box;
you're then presented with a contract you have to agree to to continue.
So my non-lawyer *opinion* is that you're not required to destroy the
software, you still have a legal copy, and you're permitted to make
archival and backup copies of it and run it as many times as you want to
see that dialog box, but you can't do any more than that with it without
accepting the contract.
--
Russ Allbery ([EMAIL PROTECTED]) <URL:http://www.eyrie.org/~eagle/>
On Wed, Sep 15, 1999 at 12:15:37PM -0700, Lyndon Griffin wrote:
> Right - but what the web page says is not this
> "qmail 1.03 users and web site no longer support inetd"
>
> but rather this
> "qmail 1.03 no longer supports inetd"
>
> That is about the most misleading statement I have ever read. Say what you
> mean and this type of discussion will not be necessary.
Joop, I did wonder about this statement as well, as I ran qmail-1.03 both
with inetd, later on with xinetd without problems (on RedHat-Linux). Now I
use Mate's wonderful RPMs and stay with the tcpserver-stuff, which IMHO is
easier to figure out than tcpd's host.allow,*.deny-scheme.
Well, RedHat users are really lucky as Mate does steer them in the right
direction, then ;-).
Regards
Mirko
On Wed, Sep 15, 1999 at 05:01:06PM -0700, Russ Allbery wrote:
> If that's how it works in the United States, that's probably also how it
> works in other countries. If that's not how it works in other countries,
> that's probably not how it works in the United States. Except for a few
> weird exceptions, mostly not related to software, copyright law is fairly
> effectively international under the Berne Convention.
Well, if I go to my local book-store and buy a book, I understand that I am
not allowed to sell copies of that book. On the other hand, I may scribble
tons of comments into the book, rip out some pages I am actually interested
in, correct errors I find etc. and have not seen any disclaimers which would
not allow me to do so.
I guess (not a lawyer), the same is true with software, regarding the single
copy I have. Of course, I will not wonder if support is going to bash me for
my actions afterwards ;-).
Regards
Mirko
Mirko Zeibig <[EMAIL PROTECTED]> writes:
> On Wed, Sep 15, 1999 at 05:01:06PM -0700, Russ Allbery wrote:
>> If that's how it works in the United States, that's probably also how
>> it works in other countries. If that's not how it works in other
>> countries, that's probably not how it works in the United States.
>> Except for a few weird exceptions, mostly not related to software,
>> copyright law is fairly effectively international under the Berne
>> Convention.
> Well, if I go to my local book-store and buy a book, I understand that I
> am not allowed to sell copies of that book. On the other hand, I may
> scribble tons of comments into the book, rip out some pages I am
> actually interested in, correct errors I find etc. and have not seen any
> disclaimers which would not allow me to do so.
> I guess (not a lawyer), the same is true with software, regarding the
> single copy I have.
This is a very interesting question, but I don't believe it is the same
with software. There's a very odd explanation for that.
Most of us think of "copying software" as distributing it, but the law
doesn't actually define it that way. Copying is making any copy, whether
internal to your computer or not. Running a program requires copying it.
You're given an explicit exemption in the law to make any copies that
"occur normally as part of the process of using the software" or something
roughly equivalent to that.
If you *modify* the software, however, you're creating a derivative work.
In order to create that derivative work, you're actually copying the
software (by loading it into your editor and by writing it out to disk
again). As near as I can tell from reading the actual law, this appears
to be a violation of the copyright at least in the United States.
I think this all sounds completely demented from the perspective that most
of us bring to computer software, but as near as I can tell that's how the
laws are written. The laws do *not* take into account the idea of easily
copied works, having been written for print and film and the like, and
therefore have a lot of implicit assumptions about how frequently
something is copied and how much work it represents, and those assumptions
appear to be applied wholesale to software except for a few back-patched
exceptions to try to make the result not completely illogical.
--
Russ Allbery ([EMAIL PROTECTED]) <URL:http://www.eyrie.org/~eagle/>
>craig <[EMAIL PROTECTED]> writes:
>
>> I was told last night by an IP lawyer that "click-through licenses have
>> been upheld in court".
>
>Yes, I believe that's been the case for a while. A click on ACCEPT
>appears to be legally roughly equivalent to the signature on a contract,
>provided you can prove the person did that (signatures are a bit more
>permanent and lasting and easier to establish). This is a Good Thing; if
>this weren't the case, ISP AUPs and the like would be uninforceable and
>e-commerce would become very difficult. I don't have a problem with that.
Yes, that's the reasoning, and I understand it perfectly well...to a
point.
Exactly *who* are the parties to the "[rough] equivalent to the
signature on a contract", though?
Remember, the assumption here is that the transaction between the
parties (FTP client and FTP server operators and their correlative
software agents; or customer and salesperson exchanging money and
shrinkwrap software) has *already happened*.
After that transaction, which is an *implied contract* (I assume),
there can be *no* after-the-fact changes to the contract without
*both* parties agreeing to that.
When you're *later* running that computer program, you are *not*
engaging in contract negotiations with a second party. In fact,
you are dealing with no legally recognized entity at all. You
can't sue it for making false representations, for example.
I'm not interested in what we can *infer* that software did based
on the code. I'm only interested in what *legislation* exists
that grants software the right to, on its own volition, enter
into an enforceable contract with an individual such that the
individual is liable for damages, can be imprisoned, and so on,
when the *software* is under no such legal liabilities.
Put another way: if you buy a JimBobBoy Toy for your 5-year old,
take it out of the store, assuming the transaction has completed,
what right does that *toy* have to suddenly, two months later,
"decide" it will no longer "play" with your son as it has (perhaps
implicitly) been promised to do in the past *unless* you tell it
you agree to some *new* license terms?
I'm aware of *no* legal or ethical compulsion under which I should
be required to tell the truth to *software*. To another person
*via* software as a recording device, yes -- if that's part of
what is clearly a valid contract-agreement process, for example.
But when I'm running software on my computer, it's unconnected to
the net, or if I've *clearly* been led to believe that I've
purchased it (or obtained it for "free" via download), then I can't
see how any attempt by that software to get me to engage in *further*
contract negotiations have any validity.
Now, I'm a *totally* committed Christian who doesn't believe it's
right to lie, cheat, steal, or kill, *ever*, period.
Yet I have no problem lying to a computer program. (Okay, honesty
time, maybe I *have*, in the past, and thus not clicked-through
a license I didn't want to accept. But no longer, now that I clearly
see the issues.)
As far as convenience for etrade and such: poppycock. First, the
courts' jobs are to interpret the *law*, not invent new law for
the convenience of industry. That's for the legislatures to
undertake.
Second, in any situation where a vendor chooses to use a manner of
delivery that creates the clear impression that a transaction has
been completed as of purchase or download, that vendor must be
interpreted, *legally*, to have agreed to continue abiding by the
terms of the transaction ever after, regardless of what it claims
its software might or might not ask, or be told, by its user.
If the vendor disagreed with that, it is up to the *vendor* to
choose a *different* method of delivery. E.g. provide *non*-anonymous
FTP access via a login/password combination after getting something
akin to an online signature verifying that the potential customer
agrees to the license terms *up front*.
It's called "the cost of doing business". And it's trivial, both
for FTP access to "free" software that tries to add post-transaction
constraints, as well as for overshelf sales of shrink-wrap software,
as well as telephone-based sales of shrink-wrap software.
In all cases, if the *legislation* doesn't grant independently acting
software the rights to act on behalf of a party, *or* if the *other*
party in a transaction is not warned ahead of time that a seemingly
"complete" transaction is going to, in fact, be further negotiated
*by that agent* (the software) *afterwards*, then the vendor has
committed *fraud* by claiming that the terms of the agreement are
modified *after* the transaction.
In my opinion, unless somebody can show legislation that itself
provides clear, up-front notification to consumers of software
(via shrink-wrap transactions or anon-FTP downloads of "free"
software) that they were going to have to deal with *software*
as if they were *duly appointed agents* of the party with whom
they would otherwise have believed they'd *completed* a transaction
(with contract, implied or otherwise)...
...we have the potential for a *huge* class-action suit here.
So, please, where's the USC or other code I look up that grants
such after-the-fact authorization of renegotiation of contract
by software?
>I'd double-check some of the rest of this with another IP lawyer. *Until
>you have accepted the contract* you aren't bound by its provisions; you're
You've accepted the contract that was implied during the transaction.
After that, nothing you say or do on your computer constitutes
modification of a contract, or agreement with a contract, or
anything similar, since *you aren't negotiating with anybody*.
>In order to make you agree to the
>contract as a condition of getting a copy of the software, I'm pretty sure
>they have to *make* that a condition; that's why if you download, say,
>Postfix from IBM's web site, they put the license up on the screen and
>make you accept it before you get a copy.
Excellent. That's as it *should* be. I don't mind one bit a
splash screen that *confirms* (but cannot reduce) those terms,
e.g. in case somebody illegally puts up the copy on another
web site without the pre-download protection.
>So the only way I can see the above working is if somehow you're not in
>legal possession of the software after you rejected the contract, which
>makes no sense to me at all.
No, the case I mean is where I accepted the *implicit*, or *explicit*,
contract when I downloaded or bought software.
Then I run the software, stand-alone mode, and it tells me I must
accept *further* conditions to run it.
I claim that, at this point, I have no ethical or legal compunction
to tell the truth to a piece of software, since it is, in this
case, not in any way acting as a duly appointed agent for the
party of a contract, especially not in a contract negotiation that
pertains to my use of that software...since I already *negotiated*
that contract.
>Copyright law in the United States specifically gives you the right to
>make whatever copies of software are necessary for the normal running of
>the software package. However, I can see the argument that in this case,
>this only implies your right to run the software and get that dialog box;
>you're then presented with a contract you have to agree to to continue.
I argue that I'm presented with a *purported* contract, that has no
more legal or ethical force than when your three-year-old daughter
asks you "daddy, when I grow up, will you marry me?" and you say
"yes, dear".
>So my non-lawyer *opinion* is that you're not required to destroy the
>software, you still have a legal copy, and you're permitted to make
>archival and backup copies of it and run it as many times as you want to
>see that dialog box, but you can't do any more than that with it without
>accepting the contract.
Just to reiterate, I already accepted the only *legally and ethically
binding* contract on the transaction that resulted in my getting
a copy of the software.
If the software wants to play games with me and pretend I have to agree
to other terms, I'm perfectly within my rights to lie to it and say
"ACCEPT", then brazenly violate *those terms*, as long as I'm still
within the terms of the *real* contract.
(Practically, I realize that if some judge has ruled otherwise, this
might not be smart. But I claim it *is* entirely legal and ethical
*unless* someone can show the legislation that informed me, up front,
that I should be prepared to continue negotations, post-transaction,
with an automaton.)
tq vm, (burley)
There is proposed new law on the matter--recent revisions to the
Uniform Commercial Code, Section 2B, a/k/a UCITA (Uniform Computer
Information Transactions Act). It has been approved by the National
Conference of Commissioners for Uniform State Law and will be introduced
in most state legislatures early next year. Do a web search for "UCITA"
or "UCC 2B" and you'll find all kinds of opposition web pages.
Jim Lippard [EMAIL PROTECTED] http://www.discord.org/
Unsolicited bulk email charge: $500/message. Don't send me any.
PGP Fingerprint: 0C1F FE18 D311 1792 5EA8 43C8 7AD2 B485 DE75 841C
On 16 Sep 1999 [EMAIL PROTECTED] wrote:
> >craig <[EMAIL PROTECTED]> writes:
> >
> >> I was told last night by an IP lawyer that "click-through licenses have
> >> been upheld in court".
> >
> >Yes, I believe that's been the case for a while. A click on ACCEPT
> >appears to be legally roughly equivalent to the signature on a contract,
> >provided you can prove the person did that (signatures are a bit more
> >permanent and lasting and easier to establish). This is a Good Thing; if
> >this weren't the case, ISP AUPs and the like would be uninforceable and
> >e-commerce would become very difficult. I don't have a problem with that.
>
> Yes, that's the reasoning, and I understand it perfectly well...to a
> point.
>
> Exactly *who* are the parties to the "[rough] equivalent to the
> signature on a contract", though?
>
> Remember, the assumption here is that the transaction between the
> parties (FTP client and FTP server operators and their correlative
> software agents; or customer and salesperson exchanging money and
> shrinkwrap software) has *already happened*.
>
> After that transaction, which is an *implied contract* (I assume),
> there can be *no* after-the-fact changes to the contract without
> *both* parties agreeing to that.
>
> When you're *later* running that computer program, you are *not*
> engaging in contract negotiations with a second party. In fact,
> you are dealing with no legally recognized entity at all. You
> can't sue it for making false representations, for example.
>
> I'm not interested in what we can *infer* that software did based
> on the code. I'm only interested in what *legislation* exists
> that grants software the right to, on its own volition, enter
> into an enforceable contract with an individual such that the
> individual is liable for damages, can be imprisoned, and so on,
> when the *software* is under no such legal liabilities.
>
> Put another way: if you buy a JimBobBoy Toy for your 5-year old,
> take it out of the store, assuming the transaction has completed,
> what right does that *toy* have to suddenly, two months later,
> "decide" it will no longer "play" with your son as it has (perhaps
> implicitly) been promised to do in the past *unless* you tell it
> you agree to some *new* license terms?
>
> I'm aware of *no* legal or ethical compulsion under which I should
> be required to tell the truth to *software*. To another person
> *via* software as a recording device, yes -- if that's part of
> what is clearly a valid contract-agreement process, for example.
>
> But when I'm running software on my computer, it's unconnected to
> the net, or if I've *clearly* been led to believe that I've
> purchased it (or obtained it for "free" via download), then I can't
> see how any attempt by that software to get me to engage in *further*
> contract negotiations have any validity.
>
> Now, I'm a *totally* committed Christian who doesn't believe it's
> right to lie, cheat, steal, or kill, *ever*, period.
>
> Yet I have no problem lying to a computer program. (Okay, honesty
> time, maybe I *have*, in the past, and thus not clicked-through
> a license I didn't want to accept. But no longer, now that I clearly
> see the issues.)
>
> As far as convenience for etrade and such: poppycock. First, the
> courts' jobs are to interpret the *law*, not invent new law for
> the convenience of industry. That's for the legislatures to
> undertake.
>
> Second, in any situation where a vendor chooses to use a manner of
> delivery that creates the clear impression that a transaction has
> been completed as of purchase or download, that vendor must be
> interpreted, *legally*, to have agreed to continue abiding by the
> terms of the transaction ever after, regardless of what it claims
> its software might or might not ask, or be told, by its user.
>
> If the vendor disagreed with that, it is up to the *vendor* to
> choose a *different* method of delivery. E.g. provide *non*-anonymous
> FTP access via a login/password combination after getting something
> akin to an online signature verifying that the potential customer
> agrees to the license terms *up front*.
>
> It's called "the cost of doing business". And it's trivial, both
> for FTP access to "free" software that tries to add post-transaction
> constraints, as well as for overshelf sales of shrink-wrap software,
> as well as telephone-based sales of shrink-wrap software.
>
> In all cases, if the *legislation* doesn't grant independently acting
> software the rights to act on behalf of a party, *or* if the *other*
> party in a transaction is not warned ahead of time that a seemingly
> "complete" transaction is going to, in fact, be further negotiated
> *by that agent* (the software) *afterwards*, then the vendor has
> committed *fraud* by claiming that the terms of the agreement are
> modified *after* the transaction.
>
> In my opinion, unless somebody can show legislation that itself
> provides clear, up-front notification to consumers of software
> (via shrink-wrap transactions or anon-FTP downloads of "free"
> software) that they were going to have to deal with *software*
> as if they were *duly appointed agents* of the party with whom
> they would otherwise have believed they'd *completed* a transaction
> (with contract, implied or otherwise)...
>
> ...we have the potential for a *huge* class-action suit here.
>
> So, please, where's the USC or other code I look up that grants
> such after-the-fact authorization of renegotiation of contract
> by software?
>
> >I'd double-check some of the rest of this with another IP lawyer. *Until
> >you have accepted the contract* you aren't bound by its provisions; you're
>
> You've accepted the contract that was implied during the transaction.
> After that, nothing you say or do on your computer constitutes
> modification of a contract, or agreement with a contract, or
> anything similar, since *you aren't negotiating with anybody*.
>
> >In order to make you agree to the
> >contract as a condition of getting a copy of the software, I'm pretty sure
> >they have to *make* that a condition; that's why if you download, say,
> >Postfix from IBM's web site, they put the license up on the screen and
> >make you accept it before you get a copy.
>
> Excellent. That's as it *should* be. I don't mind one bit a
> splash screen that *confirms* (but cannot reduce) those terms,
> e.g. in case somebody illegally puts up the copy on another
> web site without the pre-download protection.
>
> >So the only way I can see the above working is if somehow you're not in
> >legal possession of the software after you rejected the contract, which
> >makes no sense to me at all.
>
> No, the case I mean is where I accepted the *implicit*, or *explicit*,
> contract when I downloaded or bought software.
>
> Then I run the software, stand-alone mode, and it tells me I must
> accept *further* conditions to run it.
>
> I claim that, at this point, I have no ethical or legal compunction
> to tell the truth to a piece of software, since it is, in this
> case, not in any way acting as a duly appointed agent for the
> party of a contract, especially not in a contract negotiation that
> pertains to my use of that software...since I already *negotiated*
> that contract.
>
> >Copyright law in the United States specifically gives you the right to
> >make whatever copies of software are necessary for the normal running of
> >the software package. However, I can see the argument that in this case,
> >this only implies your right to run the software and get that dialog box;
> >you're then presented with a contract you have to agree to to continue.
>
> I argue that I'm presented with a *purported* contract, that has no
> more legal or ethical force than when your three-year-old daughter
> asks you "daddy, when I grow up, will you marry me?" and you say
> "yes, dear".
>
> >So my non-lawyer *opinion* is that you're not required to destroy the
> >software, you still have a legal copy, and you're permitted to make
> >archival and backup copies of it and run it as many times as you want to
> >see that dialog box, but you can't do any more than that with it without
> >accepting the contract.
>
> Just to reiterate, I already accepted the only *legally and ethically
> binding* contract on the transaction that resulted in my getting
> a copy of the software.
>
> If the software wants to play games with me and pretend I have to agree
> to other terms, I'm perfectly within my rights to lie to it and say
> "ACCEPT", then brazenly violate *those terms*, as long as I'm still
> within the terms of the *real* contract.
>
> (Practically, I realize that if some judge has ruled otherwise, this
> might not be smart. But I claim it *is* entirely legal and ethical
> *unless* someone can show the legislation that informed me, up front,
> that I should be prepared to continue negotations, post-transaction,
> with an automaton.)
>
> tq vm, (burley)
>
On Thu, Sep 16, 1999 at 02:05:14AM -0000, [EMAIL PROTECTED] wrote:
> >So my non-lawyer *opinion* is that you're not required to destroy the
> >software, you still have a legal copy, and you're permitted to make
> >archival and backup copies of it and run it as many times as you want to
> >see that dialog box, but you can't do any more than that with it without
> >accepting the contract.
>
> Just to reiterate, I already accepted the only *legally and ethically
> binding* contract on the transaction that resulted in my getting
> a copy of the software.
>
Surely also, since you haven't accepted the 'new' contract you can
still (under basic copyright law) modify the software etc. and thus
bypass the bit that asks you to accept the new terms anyway.
--
Chris Green ([EMAIL PROTECTED])
Home: [EMAIL PROTECTED] Work: [EMAIL PROTECTED]
WWW: http://www.isbd.co.uk/
>There is proposed new law on the matter--recent revisions to the
>Uniform Commercial Code, Section 2B, a/k/a UCITA (Uniform Computer
>Information Transactions Act). It has been approved by the National
>Conference of Commissioners for Uniform State Law and will be introduced
>in most state legislatures early next year. Do a web search for "UCITA"
>or "UCC 2B" and you'll find all kinds of opposition web pages.
Yes, I'm interested in *new* law too, and have already skimmed
enough material in magazines and online to get the impression
that UCITA is not exactly widely heralded...!
Still, I'm *primarily* interested in what *existing* law grants
special dispensation to computer programs to serve as after-the-fact
agents to contract negotiations without prior agreement by *all*
parties to the negotiations...and, unless some such law *already*
existed, whether attempts to make it appear that these programs
*have* that dispensation, and especially attempts to enforce it
via litigation, might constitute fraud.
tq vm, (burley)
>> Just to reiterate, I already accepted the only *legally and ethically
>> binding* contract on the transaction that resulted in my getting
>> a copy of the software.
>>
>Surely also, since you haven't accepted the 'new' contract you can
>still (under basic copyright law) modify the software etc. and thus
>bypass the bit that asks you to accept the new terms anyway.
Apparently such modification isn't inherent (or implicit) in
the sort of transaction I'm talking about, so, no, this line
of argument doesn't wash. (I've tried it, though. ;-)
The simplest line of argument is "Sure, I clicked ACCEPT, even
though I did not accept the terms. I already negotiated the
terms with another party, the result being that I now own a copy
of the software. Any interactions I have with the software afterwards
cannot possibly be construed as a legally binding contract, since
that software is not a duly appointed agent for that other party."
I still don't see how copyright law can prevent me from either *reading*
the (binary!) code, and thus reverse-engineering it; or having
my computer jump into the *middle* of it, perhaps avoiding the
license screen; or, *most* interestingly, have a *different*
automaton execute the program, such that the screen is avoided
altogether.
But, while these are interesting arguments as well, to me, the
simplest and most direct one (as well as being the easiest for
anyone to undertake) is what I've already stated: the computer
program is not a party to a contract negotiation, under those
circumstances, so it can be "lied" to without fear of criminal
or civil penalties. Further, I'm sure God Himself would have
no problem with that.
tq vm, (burley)
Hi,
i', a newby in configuring qmail.
I have a private network (192.168.1.x),
qmail is running on a Linux-Machine , which has a
ppp-connection to the Internet (and my provider : gmx).
The clients use W9x and Netscape 4.xx as mailprogramms.
What i want is the following :
if a client writes a mail to a local address
([EMAIL PROTECTED] -> [EMAIL PROTECTED]) there shall not be any from-rewriting.
if a local client writes a mail to a remote address
([EMAIL PROTECTED] -> [EMAIL PROTECTED])
the from-addres should be changed.
I have installed ofmipd so that it can do this by
using the cdb-programms.
But ofmipd does too much , it rewrites messages
that should be delivered locally too.
The reason is,that it just looks to the cdb-database if
there`s a hit and beginns to rewrite.
But in this case (local->local) it should look f the receiver
is a local one and then ofmipd should decide not to rewrite.
I tried to patch ofmipd , but i failed cause i`m not a professional
programmer.
I tried to do the following :
if the receiver is not in the cdb-database a n d
if the address is in the "from-address" then
the from-addres shall be rewritten.
Has anybody any suggestions ?
Thanks Harry :-)
PS.: Please apologize for my broken english.
[EMAIL PROTECTED] wrote:
> i', a newby in configuring qmail.
> I have a private network (192.168.1.x),
> qmail is running on a Linux-Machine , which has a
> ppp-connection to the Internet (and my provider : gmx).
> The clients use W9x and Netscape 4.xx as mailprogramms.
I've got the same setup at home.
> if a client writes a mail to a local address
> ([EMAIL PROTECTED] -> [EMAIL PROTECTED]) there shall not be any from-rewriting.
> if a local client writes a mail to a remote address
> ([EMAIL PROTECTED] -> [EMAIL PROTECTED])
> the from-addres should be changed.
The classic wrench in the works is a message addressed to both local
and remote recipients. What to do?
In general, this "two from addresses" approach is a bad idea. I just
use the remote form of the From everywhere.
> PS.: Please apologize for my broken english.
OK: I'm sorry your English is broken. :-) Seriously, though, don't
worry: you got your points across very clearly. Meine Deutche is nicht
so gut.
-Dave
HI !
I've tried several things bot nothing seemed to work.
I have a vdomain, just-kidding.de.
If a mail for a NONEXISTING User @just-kidding.de arrives, it
shell go to [EMAIL PROTECTED]
i've put a .qmail-justk-default in ~alias with the line
[EMAIL PROTECTED] in it, but mail always returns to the sender
with an error message "vdeliver: Invalid or unknown virtual user"
What's wrong?!
Thanks,
Thomas
"Daniluk, Cris" <[EMAIL PROTECTED]> wrote:
>What is the general course of events when qmail-smtpd reaches the limit
>imposed on it by tcpserver? Does tcpserver hold the incoming connections in
>a TIME_WAIT state, deny the connection, respond with a try again later, or
>what?
The FM says:
-climit
Do not handle more than limit simultaneous connec-
tions. If there are limit simultaneous copies of
program running, defer acceptance of a new connec-
~~~~~~~~~~~~~~~~
tion until one copy finishes. limit must be a pos-
itive integer. Default: 40.
-Dave
[EMAIL PROTECTED] wrote:
> This is my first time posting to this listserv so please bear with any
>etiquette faux-pas I might commit.
Like calling a mailing list a "listserv"? :-)
>... Has anyone
>seen anything like this before?
Yeah, I've seen this. It's a common problem. The fix is to enable
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXX
this helps.
-Dave
Hi,
just a small question:
how big can the size of locals get out of a performance point of view?
For rcpthosts it is said that, when more than 50 entries are in it, one
should use morercpthosts as well. But what is the equivalent for locals?
Franky
Van Liedekerke Franky writes:
> how big can the size of locals get out of a performance point of view?
> For rcpthosts it is said that, when more than 50 entries are in it, one
> should use morercpthosts as well. But what is the equivalent for locals?
locals is read into memory once when qmail-send starts, and it is
built into a hash table. rcpthosts, on the other hand, needs to be
available to qmail-smtpd, which is executed once for every incoming
smtp connection.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Can anyone explain how to install Russ Nelson's open-smtp patch for
qmail?
I am interested in patching my qmail installation to allow relaying for POP3
authenticated users. I have downloaded the code, but the README just
says to patch checkpassword, but I am unfamilar with patching programs.
Additionally, there are 2 checkpassword.patch files in the tar:
checkpassword.patch
checkpassword.patch~
Would anyone mind explaining the patch process? (Russ :) ?)
Thanks,
Michael Lundberg
On Wed, 15 Sep 1999, Michael wrote:
> Can anyone explain how to install Russ Nelson's open-smtp patch for
> qmail?
>
> I am interested in patching my qmail installation to allow relaying for POP3
> authenticated users. I have downloaded the code, but the README just
> says to patch checkpassword, but I am unfamilar with patching programs.
> Additionally, there are 2 checkpassword.patch files in the tar:
>
> checkpassword.patch
> checkpassword.patch~
>
> Would anyone mind explaining the patch process? (Russ :) ?)
An easier way than patching is to use David Harris' smtp-poplock. I
just installed it here and it looks like it's gonna work so I can do
the last step in the installation :)
http://www.davideous.com/smtp-poplock/
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null
# include <std/disclaimers.h> TEAM-OS2
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
Vince Vielhaber [mailto:[EMAIL PROTECTED]] wrote:
> An easier way than patching is to use David Harris' smtp-poplock. I
> just installed it here and it looks like it's gonna work so I can do
> the last step in the installation :)
>
> http://www.davideous.com/smtp-poplock/
The main advantage of smtp-poplock is that you don't have to patch any of the
programs, and it can work with any of the checkpassword variants. There had
been some lingering problems with the checkpassword authentication logging tie
in, but they were solved in the latest release.
There are two tie ins, basically. First to log the POP3 authentication, you
just insert lobpopauth-pre and logpopauth-post before and after checkpassword
in the (tcpserver or inetd.con) chain of commands. For the second tie in, you
just add "relaylock" before qmail-smtpd in your (tcpserver) chain of commands.
The "relaylock" program simply sets the RELAYCLIENT environment variable if
that host has authenticated with POP3, allowing them to relay mail.
- David Harris
Principal Engineer, DRH Internet Services
Michael writes:
> Can anyone explain how to install Russ Nelson's open-smtp patch for
> qmail?
>
> I am interested in patching my qmail installation to allow relaying for POP3
> authenticated users. I have downloaded the code, but the README just
> says to patch checkpassword, but I am unfamilar with patching programs.
> Additionally, there are 2 checkpassword.patch files in the tar:
>
> checkpassword.patch
> checkpassword.patch~
> Would anyone mind explaining the patch process? (Russ :) ?)
Unpack open-smtp3.tar.gz
Unpack checkpassword-0.81.tar.gz (found on koobera).
cd into checkpassword-0.81
Issue the following command: patch <../open-smtp/checkpassword.patch
Make checkpassword as per usual.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
On Wed, Sep 15, 1999 at 01:46:34PM -0400, Russell Nelson wrote:
> Michael writes:
> > checkpassword.patch
> > checkpassword.patch~
> > Would anyone mind explaining the patch process? (Russ :) ?)
>
> Unpack open-smtp3.tar.gz
> Unpack checkpassword-0.81.tar.gz (found on koobera).
> cd into checkpassword-0.81
> Issue the following command: patch <../open-smtp/checkpassword.patch
> Make checkpassword as per usual.
Here is a slightly improved script for /usr/local/bin/pop3-record:
#!/bin/sh
TCPDIR=/etc/tcprules.d
SMTPRULES=$TCPDIR/qmail-smtpd
PATH=$PATH:/usr/local/bin/
# First see if $TCPREMOTEIP is handled by existing rules
tcprulescheck $TCPDIR/qmail-smtpd.cdb ``$TCPREMOTEIP'' | \
grep RELAYCLIENT > /dev/null && exit 0
echo ``$TCPREMOTEIP''':allow,RELAYCLIENT=''''' >> $TCPDIR/smtp.filter.newer
cat $TCPDIR/smtp.filter.* > $SMTPRULES
tcprules $SMTPRULES.cdb $SMTPRULES.tmp < $SMTPRULES
In /etc/tcrules.d you may include a file called smtp.filter.zintern for internal
networks you always trust (chose .zintern to make sure this is read last).
Regards
Mirko
/var/qmail/bin/printforward < /etc/aliases.cdb
--Adam
On Wed, Sep 15, 1999 at 03:53:32AM -0500, Ben Beuchler wrote:
> I am using the fastforward package. I've set up quite a few entries but
> somehow seem to have wiped out my original '/etc/aliases' file. I assume
> that if I just add new entries to a blank '/etc/aliases' file, it will wipe
> out my existing entries. So... Is there a way for me to un-cdb the
> aliases.cdb file? I would be a lot more comfortable with a plain-text
> version around somewhere...
>
> Gracias,
> Ben
>
When will qmail decide to back off the primary MX and try to use
lower priority MX hosts?
In particular, if the primary MX allows a connection and immediately
drops it, will qmail ever decide to try the next MX?
I'm seeing this problem right now with two systems: wb.xerox.com and
snet.net. The primary MX (pmdf.cinops.xerox.com and pop.snet.net) in each
case accepts and drops connections to port 25, like such:
# telnet pmdf.cinops.xerox.com 25
Trying 13.250.20.175...
Connected to pmdf.cinops.xerox.com.
Escape character is '^]'.
Connection closed by foreign host.
Now, in Xerox's case, their normal method is to have two MX records:
one for the internal mail server, and one for the internet-accessible mail
relay (in this case, mailer-east.xerox.com). When attempts to reach the
pmdf.cinops machine fail, the remote MTA should drop back to mailer-east,
which can relay it inside the firewall.
But it seems that qmail isn't backing off, probably because it gets
a connect rather than getting a refusal.
Should qmail be backing off? Is accepting+dropping connections
documentably wrong, that I should complain to them about it? What's the
deal?
--
gowen -- Greg Owen -- [EMAIL PROTECTED]
Greg Owen <[EMAIL PROTECTED]> wrote:
> When will qmail decide to back off the primary MX and try to use
>lower priority MX hosts?
When it decides that the primary is permanently down.
> In particular, if the primary MX allows a connection and immediately
>drops it, will qmail ever decide to try the next MX?
No.
> But it seems that qmail isn't backing off, probably because it gets
>a connect rather than getting a refusal.
Correct.
> Should qmail be backing off? Is accepting+dropping connections
>documentably wrong, that I should complain to them about it? What's the
>deal?
RFC 974 is unclear on this. It says:
If the list of MX RRs is not empty, the mailer should try to deliver
the message to the MXs in order (lowest preference value tried
first). The mailer is required to attempt delivery to the lowest
valued MX. Implementors are encouraged to write mailers so that they
try the MXs in order until one of the MXs accepts the message, or all
the MXs have been tried. A somewhat less demanding system, in which
a fixed number of MXs is tried, is also reasonable.
It doesn't say mailers MUST try alternative MX's, but it does
encourage trying others when one fails to accept a message.
See also:
http://www.ietf.org/rfc/rfc0974.txt
-Dave
> But it seems that qmail isn't backing off, probably
> because it gets a connect rather than getting a refusal.
>
> Should qmail be backing off? Is accepting+dropping connections
> documentably wrong, that I should complain to them about it?
> What's the deal?
Part of the problem cleared up - the accept+drop behavior appears to
be what you get when you turn off the SMTP proxy capabilities of Raptor
firewall. I'm guessing that the "connect" is accepted by the firewall,
which then drops it when it figures out the actual target isn't available.
Are there gauntlet/raptor users out there who are familiar with
qmail through the firewall? We had our ISP turn off the SMTP proxy
capabilities because they were making it hard for me to figure out why some
mail wasn't delivering well, so maybe it does the same with or without SMTP
proxy enabled...
--
gowen -- Greg Owen -- [EMAIL PROTECTED]
Greg Owen writes:
> When will qmail decide to back off the primary MX and try to use
> lower priority MX hosts?
When it cannot contact the primary MX.
> In particular, if the primary MX allows a connection and immediately
> drops it, will qmail ever decide to try the next MX?
No, never.
> Should qmail be backing off? Is accepting+dropping connections
> documentably wrong, that I should complain to them about it? What's the
> deal?
Yes, it's wrong. Why are they advertising an MX if they never intend
to allow connections to it?
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
> > Should qmail be backing off? Is accepting+dropping connections
> > documentably wrong, that I should complain to them about
> > it? What's the deal?
>
> Yes, it's wrong. Why are they advertising an MX if they never intend
> to allow connections to it?
It looks like my firewall is the one "accepting" and then dropping
connections; the remote primary MXs simply refuse connection, so if the
firewall isn't in place it works fine.
Xerox, and some other sites I've seen, use MX records to make mail
routing administration easier. The mail store machine is the top priority,
but only Xerox machines can reach it. All internet hosts fail to reach it
and must back off to the Internet-accessible corporate mail relays. By
controlling this via DNS, control over mail delivery is in the hands of the
individual organization rather than having a central mail authority need to
know about every server in the company.
It's arguably unfriendly and arguably stupid, but I've never seen an
argument that claimed it wasn't legal. Two other sites which seem to be
doing it are snet.net and viewlogic.com.
--
gowen -- Greg Owen -- [EMAIL PROTECTED]
Greg,
I have encountered this problem before with a couple of different 'proxy'
based firewalls.
I discussed the problem with the firewall developers, who appreciated my
dilemma, but pointed out that it is not a fault, but a characteristic of a
proxy based firewall. The only solution on the firewall side of things, was
to install a SMTP server on the firewall to act as a relay, which in
depending on the circumstances may not be suitable.
I then discussed the problem with a couple of different developers who have
written SMTP implementations, and the general consensus was that although
the RFC guidelines are quite vague, Dan has put a bit too much thought in to
the MTA, and shouldn't differentiate between a connection timeout or drop,
and just step to the next MX record.
Don't get me wrong, I love Qmail, but this is just one thing that has
frustrated me.
I was provided some information on how to modify the Qmail code to address
this issue, but being a non-programmer, I decided not to go butchering the
code. Here's the details...
>
> modify the routine smtp() to close the smtpfd socket and return if the
> connection is dropped?
>
> if (smtpcode() != 220) { close(&smtpto); return; };
>
> near the top should probably do the trick.
>
> notes... because of the way your firewall works you can't rely on qmail's
> tcpto mechanism to prevent excessive connections to the firewall if its
> demarc/internet connection fails -- qmail can't tell if it;s a problem
> with the firewall or the remote end of the smtp connection. otherwise I'd
> have re-ordered the code around the call to smtp() not to mark the mta as
> 'up'.
Anyway, that's my 2c worth, I hope I haven't offended anyone (Dan
especially).
Karl Lellman
Systems Consultant
Extranet Technologies Limited
Level 3, 60 Cook Street, Auckland, New Zealand
P.O. Box 7726, Wellesley Street, Auckland, New Zealand
Phone +64 9 3771122, Fax +64 9 3771109, Mobile +64 21 771188
e-mail: [EMAIL PROTECTED]
-----Original Message-----
From: Greg Owen [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 16 September 1999 08:31
To: 'Qmail List'
Subject: RE: When will qmail back off to the next MX?
> But it seems that qmail isn't backing off, probably
> because it gets a connect rather than getting a refusal.
>
> Should qmail be backing off? Is accepting+dropping connections
> documentably wrong, that I should complain to them about it?
> What's the deal?
Part of the problem cleared up - the accept+drop behavior appears to
be what you get when you turn off the SMTP proxy capabilities of Raptor
firewall. I'm guessing that the "connect" is accepted by the firewall,
which then drops it when it figures out the actual target isn't available.
Are there gauntlet/raptor users out there who are familiar with
qmail through the firewall? We had our ISP turn off the SMTP proxy
capabilities because they were making it hard for me to figure out why some
mail wasn't delivering well, so maybe it does the same with or without SMTP
proxy enabled...
--
gowen -- Greg Owen -- [EMAIL PROTECTED]
Russell Nelson writes:
> > Should qmail be backing off? Is accepting+dropping connections
> > documentably wrong, that I should complain to them about it? What's the
> > deal?
>
> Yes, it's wrong. Why are they advertising an MX if they never intend
> to allow connections to it?
They have a double whammy:
1) They don't have anyone with enough brains to set up split DNS.
2) They don't have anyone with enough brains to set up a mail relay with
hardcoded paths.
This is basically the idiot's solution to the issue of how to set up an
E-mail firewall -- with bogus DNS records.
--
Sam
On Wed, 15 Sep 1999, Greg Owen wrote:
> Xerox, and some other sites I've seen, use MX records to make mail
> routing administration easier. The mail store machine is the top priority,
> but only Xerox machines can reach it.
Well, then they've screwed up or they're lazy. If only Xerox machines can
reach it, only Xerox machines should see the MX -- certainly only Xerox
machines should see a TCP connect complete. They need a split DNS. Xerox
is a tech company. I work for a media/entertainment company which has had
split DNS for about 8 years. You'd think Xerox could figure it out.
> All internet hosts fail to reach it and must back off to the
> Internet-accessible corporate mail relays. By controlling this via DNS,
> control over mail delivery is in the hands of the individual
> organization rather than having a central mail authority need to know
> about every server in the company.
Cough. *BALONEY* Cough.
You can delegate subdomains, have multiple top domains, and delegate
portions of the internal DNS to other internal DNS authorities.
> It's arguably unfriendly and arguably stupid, but I've never seen an
> argument that claimed it wasn't legal. Two other sites which seem to be
> doing it are snet.net and viewlogic.com.
Hmm. What's more interesting is that a lot of the problem is Raptor (and
not proxy) specific. Gauntlet will refuse the connection, period, if the
connecting host is not allowed. Raptor, which seems to want to run its
proxies on *all* interfaces, has to use post-connect rules; that or the
admin has to use packet filtering to avoid the connect-and-drop behavior
(and most don't bother, more's the shame).
-M
Michael Brian Scher (MS683/MS3213) Anthropologist, Attorney, Policy Analyst
Mainlining Internet Connectivity for Fun and Profit
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Give me a compiler and a box to run it, and I can move the mail.
huh.. another question.. .
what maildir program realy do ? just create ~/Maildir and below directories
or there is something else ?
I'm asking this becouse i like to make maildir in /etc/skel
and in that way make users w/o starting maildir program, is that possible ?
Thank you all for time, i hope to hear you all soon.
Luka
-----
D r e n i k N e t w o r k s / Y u g o s l a v i a
Luka Z. Gerzic
Graphic design, prepress, html, networking
home page: http://www.linux.drenik.net
email: [EMAIL PROTECTED] / GSM +381 64 11 0 29 56
On Tue, 14 Sep 1999, Luka Gerzic wrote:
>
> huh.. another question.. .
>
> what maildir program realy do ? just create ~/Maildir and below directories
> or there is something else ?
It just creates ~/Maildir and subdirectories under ~/Maildir.
>
> I'm asking this becouse i like to make maildir in /etc/skel
> and in that way make users w/o starting maildir program, is that possible ?
Yes and it is the recommended way of creating it for all new users on
systems that support it. :)
>
> Thank you all for time, i hope to hear you all soon.
> Luka
>
> -----
> D r e n i k N e t w o r k s / Y u g o s l a v i a
>
> Luka Z. Gerzic
> Graphic design, prepress, html, networking
> home page: http://www.linux.drenik.net
> email: [EMAIL PROTECTED] / GSM +381 64 11 0 29 56
>
>
>
---------------------------------
Timothy L. Mayo mailto:[EMAIL PROTECTED]
Senior Systems Administrator
localconnect(sm)
http://www.localconnect.net/
The National Business Network Inc. http://www.nb.net/
One Monroeville Center, Suite 850
Monroeville, PA 15146
(412) 810-8888 Phone
(412) 810-8886 Fax
I'm back at the beginning with this problem: checkpassword won't
authenticate a valid user on a Caldera 2.2 (col 2.2.5) system.
I compiled checkpassword from the sources and during compiliation there
was an error about a missing 'crypt' library. Yet checkpassword appears
to run. I've also tried using checkvpw and one other password checker,
all compiled from the source, all reporting a missing 'crypt' library
and all failing to authenticate valid pop users.
Is there someone on the list who has qmail 1.03 pop3d working with a
password-checking util? I need to make this work!!
Thanks,
Barry Dwyer
Barry Dwyer writes:
> I'm back at the beginning with this problem: checkpassword won't
> authenticate a valid user on a Caldera 2.2 (col 2.2.5) system.
>
> I compiled checkpassword from the sources and during compiliation there
> was an error about a missing 'crypt' library. Yet checkpassword appears
> to run. I've also tried using checkvpw and one other password checker,
> all compiled from the source, all reporting a missing 'crypt' library
> and all failing to authenticate valid pop users.
>
> Is there someone on the list who has qmail 1.03 pop3d working with a
> password-checking util? I need to make this work!!
There are a couple of things you can do.
First, change the Makefile to remove the reference to crypt. It is
possible that Caldera simply added the crypt functions to libc, and you
don't need to explicitly link with crypt.
Now, if you can get everything to link properly, but it still fails, check
if Caldera's Linux uses MD5 password hashes, like Red Hat, I don't know if
it does or does not. I do not believe that checkpassword supports MD5
hashing, instead of crypt. If Caldera uses MD5 hashing, which is something
that you can figure out yourself simply by looking at /etc/shadow, you have
a couple of options:
1. If Caldera uses PAM authentication, you might be able to find a version
of checkpassword somewhere out there that uses PAM, and you can go with
that. PAM does require a little bit of tweaking to get working, but after
all's said and done, you just set it, and forget it.
2. Figure out how to turn off MD5 password hashing. This may not be an
option if the reason that you don't have a crypt library is because Caldera
chosen to go with MD5 password hashing only, and left out crypt altogether,
which is very possible. But, if you do have the crypt library, just figure
out what needs to be done to fall back to crypt passwords, then just have
everyone reenter their passwords, so they can be rewritten as crypted
entries in /etc/shadow.
So, you really need to know a couple of data items before you can proceed.
You need to find out whether your default login passwords use crypt, or MD5
hashing, and if you have crypt passwords even available at all.
If you determine that Caldera uses MD5 password hashing, and if it uses the
same kind of MD5 password hashing as Red Hat, and if you feel like hacking
checkpassword yourself, I can release GPLed code that does MD5 password
hashing that appears to be compatible with Red Hat's, as far as I can tell.
--
Sam
|
I have set up my Qmail with the help of a few great
people here and the POP3 is working great.
But I have followed what it says in the HOW-TO as
well as the information in the FAQ and I still get the message:
'The recipent isn't in the list of allowed host in
the RCPTHOST'
Could anyone give me some more clues on what to do
here?
Thanks a ton...you are great people.
Larry Raab
|
Larry H. Raab <[EMAIL PROTECTED]> writes on 15 September 1999 at 15:26:48 -0600
> I have set up my Qmail with the help of a few great people here and the POP3 is
>working great.
> But I have followed what it says in the HOW-TO as well as the information in the FAQ
>and I still get the message:
> 'The recipent isn't in the list of allowed host in the RCPTHOST'
> Could anyone give me some more clues on what to do here?
I'm sorry if some of this duplicates stuff you already understand. I
neither remember exactly which advice, phrased how, has been given
before, nor (of course) how you have understood it. No offense
intended by repeating what may be entirely obvious to you.
"Relaying" means receiving (via SMTP) email not intended for delivery on this
system, and passing it on. The situation gets complicated by the fact
that some mail programs and nearly all POP mailers use SMTP for their
outbound mail. So very often you need to allow selective relaying for
even simple, basic, mail sending to work. You definitely want to turn
*off* promiscuous relaying; otherwise spammers will use you to relay
their stuff and cause you endless grief, and / or anti-spammers will
put you on a blocking list.
To turn off promiscous relaying, create the file
~qmail/control/rcpthosts, and place in that file the fqdnames that you
wish to receive email for. At this point, SMTP mail entering your
system will only be accepted for the addresses listed in rcpthosts.
If you have POP users or whatever who need to relay their outbound
mail through your system, this won't be satisfactory yet; their
attempts to send email anywhere accept to one of the addresses given
in rcpthosts will fail with the error message you cite. However,
locally-injected mail (through qmail-inject, NOT through SMTP) will go
out to any system.
To enable relaying selectively, use tcpserver to set the RELAYCLIENT
environment variable to an empty string for SMTP connections
originating from IP addresses you want to enable relaying from. These
might include 127.0.0.1 ("localhost"), and the actual IP address of
your server, if there are people using locally a mailer that sends its
outbound via SMTP (Pine can do this, for example). These might also
include IPs belonging to your local LAN, if other systems on the lan
need to relay out through your server. These might also include all
the IPs belonging to your company.
If in addition you have people coming from changing IPs that you do
not own, who need to be allowed to relay (try to avoid this; they
really should be relaying through the server of the provider they're
getting the IP address from), you need to look at one of the "relay
after POP" solutions (several available on www.qmail.org), which use
one or another method to authenticate that the current holder of an IP
should be allowed to relay, and then enable doing so temporarily.
More details about how to do the things I describe are in the FAQ and
elsewhere. I'm trying to give you the overview really clearly; I'm
hypothesizing that so far some part of the general way things works
with qmail hasn't gotten through to you. When it does, you'll
suddenly understand how to use it do get what you want :-) .
If the problem *isn't* at this conceptual level, we're going to need a
*lot* more detail than you gave to actually diagnose the problem.
--
David Dyer-Bennet ***NOTE ADDRESS CHANGES*** [EMAIL PROTECTED]
http://dd-b.lighthunters.net/ (photos) Minicon: http://www.mnstf.org/minicon
http://www.dd-b.net/dd-b (sf) http://ouroboros.demesne.com/ Ouroboros Bookworms
Join the 20th century before it's too late!
Hi!
I made a patch to qmail-1.02 to have regular expressions in
.../control/locals. This avoids the need to put every host in the local
domain into that file. I think it is stable, but Your mileage may vary.
I haven't testet it under heavy load, it depends on how fast the regexec
function is. Maybe it could be faster than the old hash-function when
dealing with a large amount of hostnames, but I am not sure.
Now case ignoring extended regular expression are allowed in locals. And
if you prepend a regular expression with "!", it is negated. Order is now
important, the first match counts. Doing it this way you can have a
general regex for your domain and before that a special one excepting
some hostnames.
Please send any comments to me via personal mail.
P.S.: my SYSTYPE is linux-2.2.12-:i386-:-:ppro-:-
Greetings
--
Robert Sander "Is it Friday yet?"
@Home http://home.pages.de/~gurubert
pgp available there
qmail_regex.tar.gz
I have two domain names:
cyberscapes.com.au
peakimpact.net
The first works without any problems but the second I have yet to have
working. I have added the following to "virtualdomains":
pekimpact.net:peakimpact
I have set up a user who is peakimpact. I have two files under the
peakimpact user:
.qmail-vpl
.qmail-ajr
Inside these files I have put the following:
&[EMAIL PROTECTED]
and
&[EMAIL PROTECTED]
respectively. Am I correct so far? I want also for these users to able
to send mail to other people without those people seeing anything to do
with cyberscapes.com.au. Either e-mail have their username followed by
their domain eg. [EMAIL PROTECTED]
Can you please give me some pointers?
Thanks
Vivian Lal
Hello:
I have a need to be notified when I recieve an email. I have a
procmail recipe that works off of the .qmail file kinda like..
cat .qmail
| DEFAULT=$HOME/Mailbox /var/qmail/bin/preline /usr/local/bin/procmail -p
-m /export/home/bne/procmailrc '[EMAIL PROTECTED]'
./Mailbox
and it works fine.
Well, all I need is the From address and the subject so procmail seems
like a heavy hitter. I would like to ask this list, the MOST efficient
way to grab the From address, the subject line and send a notification
email off.
I know about maildrop but cannot get it to compile cause of iostream.h
not found or some such thing..so I gues I do not have a working C++
compiler.
I am receiving this error in my mail logs
"CNAME_lookup_failed_temporarily."
where the recipient address is like [EMAIL PROTECTED]
When I do a nslookup from various name servers ther all indicate that the
domain does not exist. Yet, when I do a lookup for "mail.domain.com.au" and
www.domain... etc they are give valid IP addresses.
This has become an issue as people used to be able to use this address
previously, and other sites still can, so the address is still valid.
Is there an underlying error that may be evident either in the setup of my
qmail or DNS?? I thought that if the domain name could not be resolved, then
obviously the mail could not be delivered.
Any words of wisdom would be greatly appreciated.
Many thanks
Mark Parker
Sorry for this followup message, but I thought it would help.
I have also applied the qmail-103.patch and recompiled and installed. This
made no difference. as I still received the same errors.
Something however I did not mention previously was that we moved our DNS
server off the same server we are running qmail on. We found BIND to be
falling over due to resource issues, so we moved it onto another server.
Once we had done this, the CNAME errors occurred for almost every email. On
the qmail server nslookup worked fine and could resolve addresses.
I have moved the DNS back onto the qmail server, as a quick solution, and
qmail is happily distributing the email once again.
Does anyone have an insight into what may be going on??
Many thanks again.
Mark Parker
I have put together the first beta of a RH clone
and deleted sendmail and used qmail instead.
What I need is approx 2 gig of server space outside
of Australia as Australia has limited bandwidth.
This would be a major distribution point, so
high bandwidth would be needed.
I am not looking for a handout and am willing to pay
for the service.
I need only ftp access and need to load up a distro
+ source + iso
Please contact me if you can provide such a service or
know of a provider who can
Kind regards
Kevin
