qmail Digest 3 Jan 2000 11:00:00 -0000 Issue 869
Topics (messages 34966 through 34997):
Re: Anal-ness
34966 by: nascheme.enme.ucalgary.ca
34967 by: Marek Narkiewicz
34968 by: lbudney-lists-qmail.nb.net
34969 by: Irwan Hadi
34970 by: Russell Nelson
34971 by: Russell Nelson
34974 by: craig.jcb-sc.com
34975 by: Russ Allbery
34976 by: lbudney-lists-qmail.nb.net
34977 by: Russell Nelson
34979 by: listy-dyskusyjne Krzysztof Dabrowski
34980 by: Claus F�rber
q-mail relay responses (revisited)
34972 by: Dustin Miller
34973 by: Chris Johnson
34978 by: Dustin Miller
34981 by: James R Grinter
34983 by: David Cunningham
34986 by: John R. Levine
Re: max messages queued?
34982 by: Benjamin de los Angeles Jr.
34984 by: bert hubert
cgi program will not work to qmail-inject - PLEASE READ
34985 by: Brock M. Eastman
The Canonical Set of qmail Patches
34987 by: Russell Nelson
34991 by: bert hubert
qmail patch list?
34988 by: Peter Cavender
34989 by: Russell Nelson
34990 by: Chris L. Mason
Virtual domains..?
34992 by: Peter Cavender
Re: tcpserver: fatal: unable to bind: address already used
34993 by: Andy Bradford
Re: The bare linefeed problem with PGP
34994 by: elm.comnets.uni-bremen.de
Domain relaying (host relaying?) or something
34995 by: Marthe Nes�en Gangfl�t
34996 by: petervd.vuurwerk.nl
34997 by: Marthe Nes�en Gangfl�t
Administrivia:
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To subscribe to 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 Sun, Jan 02, 2000 at 02:39:40AM -0800, David Cunningham wrote:
> Would this license also prohibit me from modifying the source for my own
> personal use (not for redistribution?)
No, just like any other license can't prohibit you:
http://cr.yp.to/softwarelaw.html
Interesting reading.
Neil
--
"The percentage of users running Windows NT Workstation 4.0 whose PCs stopped
working more than once a month was less than half that of Windows 95 users."
-- microsoft.com/ntworkstation/overview/Reliability/Highest.asp
On Sun, 2 Jan 2000 05:42:53 -0700, [EMAIL PROTECTED] wrote:
>On Sun, Jan 02, 2000 at 02:39:40AM -0800, David Cunningham wrote:
>> Would this license also prohibit me from modifying the source for my own
>> personal use (not for redistribution?)
>
>No, just like any other license can't prohibit you:
>
> http://cr.yp.to/softwarelaw.html
>
>Interesting reading.
>
>
> Neil
Anyone else who's interested and hasn't already, check out these urls.
http://cr.yp.to/qmail/dist.html
http://pobox.com/~djb/qmail/var-qmail.html
cheers,
--
Marek Narkiewicz, Webmaster Intercreations
Reply to <-marek @ intercreations . com->
"Dogs are everywhere"
Pulp
Dogs are Everywhere
Russell Nelson <[EMAIL PROTECTED]> writes:
>
> An OSI-approved Open Source license...And RMS (Richard M. Stallman)
Note that many things are good and right, though unblessed by OSI and
Richard "Source code for the workers or we shoot you" Stalin.
Qmail's restrictions may be a "moral" downer for some. However, in a
practical sense the restrictions don't prevent any desired use of
qmail--except including a forked qmail in distributions.
Note, too, that Dan seems to define "forking" differently than Eric
Raymond. Changing the locations of vital files (usually for no
particular reason) counts with Dan as a "fork". This may not matter
for atomic programs, but for complete systems, like qmail, it does.
As Dan pointed out before (and I hadn't realized till then), the author
is responsible for supporting his product on every OS that runs it--RedHat
and Debian, but also FreeBSD, Solaris, AIX, HP/UX and Unixware.
Dan doesn't want to be ``faced with a support nightmare---forever'', and
I can't say I blame him.
Len.
At 23:47 01/01/2000 -0700, John Gonzalez/netMDC admin wrote:
I just want to know, is there any MTA called fmail (not qmail), because
nowadays there are some spammers who like to spam me with their own mail
server, using fmail as its MTA.
I 'm afraid fmail is qmail with a bit modifications, because the header is
the same like qmail (fmail xxxxx invoked from network)
-------
AFLHI 058009990407128029/089802---(102598//991024)
David Cunningham writes:
> Would this license also prohibit me from modifying the source for my own
> personal use (not for redistribution?)
It's complicated. According to US copyright law, once you have a
copy, it is yours to dispose of as you wish. However, the software
may have attempted to bind you to more restrictive terms using a
shrink-wrap or click-through license. In some jurisdictions,
shrink-wrap licenses are valid; in others, not. If the proposed UCITA
passes in your state, then they will be valid.
Dan just uses copyright law to protect qmail from unwanted
redistribution, so the answer here is "no." He's got an extended
explanation of software user's rights at http://cr.yp.to/softwarelaw.html
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | "Ask not what your country
521 Pleasant Valley Rd. | +1 315 268 1925 voice | can force other people to
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | do for you..." -Perry M.
[EMAIL PROTECTED] writes:
> Russell Nelson <[EMAIL PROTECTED]> writes:
> >
> > An OSI-approved Open Source license...And RMS (Richard M. Stallman)
>
> Note that many things are good and right, though unblessed by OSI and
> Richard "Source code for the workers or we shoot you" Stalin.
I think you should listen more closely to what RMS actually says these
days. Yes, he was rather strident in the past, but he has become much
more reasonable these days. He's willing to work with anyone who will
make their software more free than it currently is. But still, he
won't sign a nondisclosure, and he won't use software which is not
free (sometimes at great personal pain; e.g. he refrains from using
proprietary voice recognition software even though he has bad RSI).
> Note, too, that Dan seems to define "forking" differently than Eric
> Raymond. Changing the locations of vital files (usually for no
> particular reason)
The Debian standards put configuration files under /etc for a
particular reason (this has *always* been the standard place for Unix
configuration files). qmail does not, also for a particular reason.
The reasons differ and one could argue which is the best reason, but
because qmail is not open source, Dan wins the argument without need
for persuasion.
> As Dan pointed out before (and I hadn't realized till then), the author
> is responsible for supporting his product on every OS that runs it--RedHat
> and Debian, but also FreeBSD, Solaris, AIX, HP/UX and Unixware.
Right, and if someone changes the software, that person takes on the
support nightmare. Dan could quite reasonably say "I will only help
you if you are using an unpatched qmail."
> Dan doesn't want to be ``faced with a support nightmare---forever'', and
> I can't say I blame him.
There are many patches available for qmail, and Dan can neither detect
nor stop people from applying them, yet he does not seem to be living
a support nightmare.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | "Ask not what your country
521 Pleasant Valley Rd. | +1 315 268 1925 voice | can force other people to
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | do for you..." -Perry M.
Presumably there's nothing stopping anyone truly committed to GPL'ing
qmail from buying the copyright to it from Dan...other than Dan
setting too high a price. (No, I'm not planning to do this myself,
just pointing out that it is, presumably, possible.)
Having developed GPL'ed software myself, despite being generally
close to feeling that's the best way, I can see much validity to
Dan's reasons for protecting qmail as he does, given the nature
of that particular product.
I'm not sure I'd come to the same decision myself, though, since
I'd probably be in much more need of cooperative, "bazaar-style"
development to produce something like qmail than was Dan. But if
I did develop a product whose architecture, design, and implementation
I considered to be of a nature that permitted little outside
interference, and I believed it was the kind of product that would
appear to *invite* such interference from others, I might consider
using Dan's approach to ensure that, while it is somewhat free, it
isn't so free that people could corrupt it via changes that made
it seem "better" and thus were highly popular, but were, in fact,
wrong-headed. GPL'ing it later wouldn't be out of the question --
I might do it after the product had demonstrated a history of meeting
real needs effectively without being corrupted by others, so that,
after such corruption, it would be more clear where the problems
began (and therefore what caused them).
I do think, though, that some of these problems of corruption stem
from our not having a popular language in which to express certain
types of specification, and therefore no easy way to write, share,
and have automated tools check against top-level specifications for
components. E.g. just as "int foo(int, int);" is, in its own primitive
way, a top-level specification that distinctly disallows some hacker
adding "foo (0);" to some code as well as changing the definition of
foo to "float foo(float x, float y) {...}" without having to also
change the top-level specification -- an action that can be seen more
clearly as changing a public interface than the other two types of
change -- it would be helpful to have a common language in which we
could express requirements about timing, security, and so on. (I don't
mean an imperative language, of course; more of a specification language.)
With such a language in common use and widely appreciated, I think
some of the problems I, at least, worry about (and see happen) in
bazaar-style development (Linux, GCC, etc.) would be significantly
reduced, or at least eliminated. Heck, lots of email discussions
(and confusion over terminology that often occurs in them) would be
replaced by code containing, or even patches to, what I'm thinking
of as top-level specifications.
At that point -- when an author (designer) of a program can fairly
easily encapsulate critical specifications in a form that can be
automatically checked against the corresponding implementations --
there might be less resistance to letting random people participate
in improving certain types of products (e.g. OSS development of mission-
critical systems like mail transport agents). That is,
the author can more easily spot changes to the specifications
themselves, and the automated checking can help catch changes to
the implementations that violate the specifications. (Ideally,
automatic generation of implementation from specifications could
someday occur, but first things first.)
tq vm, (burley)
Russell Nelson <[EMAIL PROTECTED]> writes:
> David Cunningham writes:
>> Would this license also prohibit me from modifying the source for my
>> own personal use (not for redistribution?)
> It's complicated. According to US copyright law, once you have a copy,
> it is yours to dispose of as you wish.
Which does not include the right to make derivative works, even if you
don't redistribute them, by my reading of the actual U.S. copyright
statute. Anyone in the U.S. who's curious should really read the actual
law on <URL:http://www.loc.gov/copyright/>.
--
Russ Allbery ([EMAIL PROTECTED]) <URL:http://www.eyrie.org/~eagle/>
Russell Nelson <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] writes:
> > Richard "Source code for the workers or we shoot you" Stalin.
>
> ...what RMS actually says these days.
Granted; he's doing much better. As an ethic, his ideas are wonderful; as
potential laws, they would amount to socialized software.
> > ...Dan seems to define "forking" differently...
>
> The Debian standards put configuration files under /etc for a particular
> reason (this has *always* been the standard place for Unix configuration
> files).
With plenty of exceptions; /var/spool/*, /usr/lib/*, /sbin/init.d (on HP/UX).
> qmail does not, also for a particular reason.
True; but I don't see the objection. Dan's licence permits any variant
on the following (or their reverses):
# ln -s /var/qmail /etc/qmail
OR
# ln -s /var/qmail/bin /usr/local/qmail/bin
# ln -s /var/qmail/control /etc/qmail
# ln -s /var/qmail/queue /var/spool/qmail
...
So the Debian folks can have anything they want in /etc, as long as they
keep <12 symlinks under /var.
> The reasons differ and one could argue which is the best reason...
Granted.
> ...but because qmail is not open source, Dan wins the argument without
> need for persuasion.
But I haven't heard of anything people can't accomplish with qmail,
obeying Dan's license, except possibly ``Never have a /var directory
on any of our machines.'' Which was my original point; concerns over
Dan's licensing seem to be a tempest in a teapot.
Len.
[EMAIL PROTECTED] writes:
> Russell Nelson <[EMAIL PROTECTED]> writes:
> > ...but because qmail is not open source, Dan wins the argument without
> > need for persuasion.
>
> But I haven't heard of anything people can't accomplish with qmail,
> obeying Dan's license, except possibly ``Never have a /var directory
> on any of our machines.'' Which was my original point; concerns over
> Dan's licensing seem to be a tempest in a teapot.
The in-depth answer goes into much more detail than is appropriate for
either of these fora, however I can summarize it by noting that it's
not enough for me to be forced to make the choices I would make if I
had free will. I have to have free will itself.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | "Ask not what your country
521 Pleasant Valley Rd. | +1 315 268 1925 voice | can force other people to
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | do for you..." -Perry M.
>Right, and if someone changes the software, that person takes on the
>support nightmare. Dan could quite reasonably say "I will only help
>you if you are using an unpatched qmail."
>
> > Dan doesn't want to be ``faced with a support nightmare---forever'', and
> > I can't say I blame him.
>
>There are many patches available for qmail, and Dan can neither detect
>nor stop people from applying them, yet he does not seem to be living
>a support nightmare.
Russ and all the great qmail supporters/patchers.
Have you ever thought about something like a semi-forked version of qmail?
I'm thinking about something like ezmlm-idx which is probably THE ezmlm
everyone uses these days.
Why can't we make something like this (qmail-whatever)?
This way we can port all the exisiting patches that everyone is applying
these days into one bit patch
and later on supporters can work off this patch to add more feautres?
Applying a lot of patches to qmail these days leads me into reading diffs
manualy and adding them by hand.
Is this idea anything good in your opinion?
Kris
David Cunningham <[EMAIL PROTECTED]> schrieb/wrote:
> Would this license also prohibit me from modifying the source for my own
> personal use (not for redistribution?)
No. Also, distributing patches is allowed.
--
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
I was going over the qmail pictures to see if I could get a little more
insight into the hows and whys of qmail's failure to throw an exception of
some kind the moment someone unauthorized attempts a relay. As it is, it
doesn't give any indication to the end user that he's not allowed to be
doing what he's doing, so all of us get random messages from security
people, blah blah blah.
Here's the deal.
Here's the "unauthorized relay" picture from the qmail package:
---[ begin picture ]---
qmail-smtpd Receive message by SMTP from another host:
MAIL FROM:<[EMAIL PROTECTED]>
RCPT TO:<[EMAIL PROTECTED]>
Is $RELAYCLIENT set? No.
Is irs.gov in rcpthosts? No.
Reject RCPT.
---[end picture ]---
But qmail doesn't immediately reject RCPT. Rejecting the RCPT here would
not give up any security information (that I can see). AFAICT, qmail waits
until after the data command is passed and ended with a "." before it barks
up that you can't relay.
Can't this behavior be changed?
Dustin
On Sun, Jan 02, 2000 at 10:40:59AM -0600, Dustin Miller wrote:
> I was going over the qmail pictures to see if I could get a little more
> insight into the hows and whys of qmail's failure to throw an exception of
> some kind the moment someone unauthorized attempts a relay. As it is, it
> doesn't give any indication to the end user that he's not allowed to be
> doing what he's doing, so all of us get random messages from security
> people, blah blah blah.
>
> Here's the deal.
>
> Here's the "unauthorized relay" picture from the qmail package:
>
> ---[ begin picture ]---
> qmail-smtpd Receive message by SMTP from another host:
>
> MAIL FROM:<[EMAIL PROTECTED]>
> RCPT TO:<[EMAIL PROTECTED]>
>
> Is $RELAYCLIENT set? No.
> Is irs.gov in rcpthosts? No.
> Reject RCPT.
> ---[end picture ]---
>
> But qmail doesn't immediately reject RCPT. Rejecting the RCPT here would
> not give up any security information (that I can see). AFAICT, qmail waits
> until after the data command is passed and ended with a "." before it barks
> up that you can't relay.
qmail DOES immediately reject the recipient. The above is all wrong.
Chris
It seems, from RoadRunner's recent probe of my qmail installation (yes, I
know, the test was bogus) that qmail DIDN'T flag it as a bad RCPT host.
I've enclosed the SMTP conversation between their security test and my qmail
server. It doesn't seem to announce that a bad RCPT was given.
Connecting to 24.131.161.83 ...
<<< 220 wfdevelopment.com ESMTP
>>> HELO hrnva-sec01.rr.com
<<< 250 wfdevelopment.com
>>> MAIL FROM:<openrelaytest@localhost>
<<< 250 ok
>>> RCPT TO:<[EMAIL PROTECTED]>
>>> RSET
<<< 250 flushed
>>> MAIL FROM:<openrelaytest>
<<< 250 ok
>>> RCPT TO:<[EMAIL PROTECTED]>
>>> RSET
<<< 250 flushed
>>> MAIL FROM:<>
<<< 250 ok
>>> RCPT TO:<[EMAIL PROTECTED]>
>>> RSET
<<< 250 flushed
>>> MAIL FROM:<openrelaytest@[24.131.161.83]>
<<< 250 ok
>>> RCPT TO:<[EMAIL PROTECTED]>
>>> RSET
<<< 250 flushed
>>> MAIL FROM:<[EMAIL PROTECTED]>
<<< 250 ok
>>> RCPT TO:<[EMAIL PROTECTED]>
>>> RSET
<<< 250 flushed
>>> MAIL FROM:<openrelaytest@[24.131.161.83]>
<<< 250 ok
>>> RCPT TO:<[EMAIL PROTECTED]@[24.131.161.83]>
<<< 250 ok
>>> DATA
<<< 354 go ahead
>>> (message body)
<<< 250 ok 945363799 qp 29925
-----Original Message-----
From: Chris Johnson [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 02, 2000 10:59 AM
To: Dustin Miller
Cc: [EMAIL PROTECTED]
Subject: Re: q-mail relay responses (revisited)
On Sun, Jan 02, 2000 at 10:40:59AM -0600, Dustin Miller wrote:
> I was going over the qmail pictures to see if I could get a little more
> insight into the hows and whys of qmail's failure to throw an exception of
> some kind the moment someone unauthorized attempts a relay. As it is, it
> doesn't give any indication to the end user that he's not allowed to be
> doing what he's doing, so all of us get random messages from security
> people, blah blah blah.
>
> Here's the deal.
>
> Here's the "unauthorized relay" picture from the qmail package:
>
> ---[ begin picture ]---
> qmail-smtpd Receive message by SMTP from another host:
>
> MAIL FROM:<[EMAIL PROTECTED]>
> RCPT TO:<[EMAIL PROTECTED]>
>
> Is $RELAYCLIENT set? No.
> Is irs.gov in rcpthosts? No.
> Reject RCPT.
> ---[end picture ]---
>
> But qmail doesn't immediately reject RCPT. Rejecting the RCPT here would
> not give up any security information (that I can see). AFAICT, qmail
waits
> until after the data command is passed and ended with a "." before it
barks
> up that you can't relay.
qmail DOES immediately reject the recipient. The above is all wrong.
Chris
"Dustin Miller" <[EMAIL PROTECTED]> writes:
> It seems, from RoadRunner's recent probe of my qmail installation (yes, I
> know, the test was bogus) that qmail DIDN'T flag it as a bad RCPT host.
>
> I've enclosed the SMTP conversation between their security test and my qmail
> server. It doesn't seem to announce that a bad RCPT was given.
What is very odd is that this conversation doesn't show any
acknowledgements of the RCPT TO:<> values, until the final go.
> Connecting to 24.131.161.83 ...
> <<< 220 wfdevelopment.com ESMTP
> >>> HELO hrnva-sec01.rr.com
> <<< 250 wfdevelopment.com
> >>> MAIL FROM:<openrelaytest@localhost>
> <<< 250 ok
> >>> RCPT TO:<[EMAIL PROTECTED]>
[no response code here]
> >>> RSET
> <<< 250 flushed
Each time, there's an 'RSET' logged apparently directly after the RCPT
TO, until the final attempt:
> >>> RSET
> <<< 250 flushed
> >>> MAIL FROM:<openrelaytest@[24.131.161.83]>
> <<< 250 ok
> >>> RCPT TO:<[EMAIL PROTECTED]@[24.131.161.83]>
> <<< 250 ok
> >>> DATA
> <<< 354 go ahead
> >>> (message body)
> <<< 250 ok 945363799 qp 29925
which someone previously explained is because the mailbox part is
considered to be '[EMAIL PROTECTED]', until another component of qmail
rightly bounces it as a non-existent user.
The '[24.131.161.83]' domain literal, being the MTA host, is
presumably meant to test for the ability to relay with a local
sender's address.
As a demonstration:
% mconnect agent57.gbnet.net
connecting to host agent57.gbnet.net (194.70.126.12), port 25
connection open
220 agent57.gbnet.net ESMTP
helo blodwen.watching.org
250 agent57.gbnet.net
mail from:<[EMAIL PROTECTED]>
250 ok
rcpt to:<[EMAIL PROTECTED]>
553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)
quit
221 agent57.gbnet.net
So there you go. 'agent57.gbnet.net' won't relay for me, won't
accept 'acm.org' as local, *and* rejects it immediately.
James.
There are a variety of sites on the internet that will perform such a relay
probe for you. It's important to consider the possibility that the probe
script at some of these sites may not be perfect and the dialog echoed back
to your browser (or telnet session) may not be complete. (i.e. reject
messages may not be properly echoed back to your browser by the script.)
----- Original Message -----
From: Dustin Miller <[EMAIL PROTECTED]>
To: Chris Johnson <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, January 02, 2000 1:24 PM
Subject: RE: q-mail relay responses (revisited)
> It seems, from RoadRunner's recent probe of my qmail installation (yes, I
> know, the test was bogus) that qmail DIDN'T flag it as a bad RCPT host.
>
> I've enclosed the SMTP conversation between their security test and my
qmail
> server. It doesn't seem to announce that a bad RCPT was given.
>
> Connecting to 24.131.161.83 ...
> <<< 220 wfdevelopment.com ESMTP
> >>> HELO hrnva-sec01.rr.com
> <<< 250 wfdevelopment.com
> >>> MAIL FROM:<openrelaytest@localhost>
> <<< 250 ok
> >>> RCPT TO:<[EMAIL PROTECTED]>
> >>> RSET
> <<< 250 flushed
> >>> MAIL FROM:<openrelaytest>
> <<< 250 ok
> >>> RCPT TO:<[EMAIL PROTECTED]>
> >>> RSET
> <<< 250 flushed
> >>> MAIL FROM:<>
> <<< 250 ok
> >>> RCPT TO:<[EMAIL PROTECTED]>
> >>> RSET
> <<< 250 flushed
> >>> MAIL FROM:<openrelaytest@[24.131.161.83]>
> <<< 250 ok
> >>> RCPT TO:<[EMAIL PROTECTED]>
> >>> RSET
> <<< 250 flushed
> >>> MAIL FROM:<[EMAIL PROTECTED]>
> <<< 250 ok
> >>> RCPT TO:<[EMAIL PROTECTED]>
> >>> RSET
> <<< 250 flushed
> >>> MAIL FROM:<openrelaytest@[24.131.161.83]>
> <<< 250 ok
> >>> RCPT TO:<[EMAIL PROTECTED]@[24.131.161.83]>
> <<< 250 ok
> >>> DATA
> <<< 354 go ahead
> >>> (message body)
> <<< 250 ok 945363799 qp 29925
>
> -----Original Message-----
> From: Chris Johnson [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, January 02, 2000 10:59 AM
> To: Dustin Miller
> Cc: [EMAIL PROTECTED]
> Subject: Re: q-mail relay responses (revisited)
>
>
> On Sun, Jan 02, 2000 at 10:40:59AM -0600, Dustin Miller wrote:
> > I was going over the qmail pictures to see if I could get a little more
> > insight into the hows and whys of qmail's failure to throw an exception
of
> > some kind the moment someone unauthorized attempts a relay. As it is,
it
> > doesn't give any indication to the end user that he's not allowed to be
> > doing what he's doing, so all of us get random messages from security
> > people, blah blah blah.
> >
> > Here's the deal.
> >
> > Here's the "unauthorized relay" picture from the qmail package:
> >
> > ---[ begin picture ]---
> > qmail-smtpd Receive message by SMTP from another host:
> >
> > MAIL FROM:<[EMAIL PROTECTED]>
> > RCPT TO:<[EMAIL PROTECTED]>
> >
> > Is $RELAYCLIENT set? No.
> > Is irs.gov in rcpthosts? No.
> > Reject RCPT.
> > ---[end picture ]---
> >
> > But qmail doesn't immediately reject RCPT. Rejecting the RCPT here
would
> > not give up any security information (that I can see). AFAICT, qmail
> waits
> > until after the data command is passed and ended with a "." before it
> barks
> > up that you can't relay.
>
> qmail DOES immediately reject the recipient. The above is all wrong.
>
> Chris
>
>
In article <006d01bf5579$81bfd5e0$[EMAIL PROTECTED]> you write:
>There are a variety of sites on the internet that will perform such a relay
>probe for you. It's important to consider the possibility that the probe
>script at some of these sites may not be perfect and the dialog echoed back
>to your browser (or telnet session) may not be complete.
Yup. Roadrunner's running a modified version of the script I wrote
for the MAPS RSS and the abuse.net tester. It's spoofed by qmail,
since some of the relay tests are accepted by the SMTP daemon and
bounced later, only the tester can't tell that at SMTP time. My
script is full of warnings like "the system MAY or MAY NOT be an open
relay, depending on whether it mails the message back to you or
bounces it." But people ignore the warnings and panic. Sigh.
When I have a chance, I plan to make it look at at the SMTP banner,
and if it recognizes a particular MTA, reorder the tests to put the
most useful ones first and warn about the ones that may be spoofed.
>> >>> MAIL FROM:<openrelaytest@[24.131.161.83]>
>> <<< 250 ok
>> >>> RCPT TO:<[EMAIL PROTECTED]@[24.131.161.83]>
>> <<< 250 ok
>> >>> DATA
>> <<< 354 go ahead
>> >>> (message body)
>> <<< 250 ok 945363799 qp 29925
--
John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 387 6869
[EMAIL PROTECTED], Village Trustee and Sewer Commissioner, http://iecc.com/johnl,
Member, Provisional board, Coalition Against Unsolicited Commercial E-mail
On Sat, 1 Jan 2000, Russell Nelson wrote:
> Benjamin de los Angeles Jr. writes:
> > On Sat, 1 Jan 2000, Russell Nelson wrote:
> >
> > > Benjamin de los Angeles Jr . writes:
> > > > What's the maximum number of messages that can be queued in Qmail?
> > >
> > > There is no limit, however, there is only one level of hashing in the
> > > queue. Depending on your filesystem, the practical limit may be as
> > > low as 10,000,000, once you have increased conf-split.
> > >
> >
> > I'm using ext2 fs, and where can conf-split be found? How can you
> > know the maximum limit for the hash for every file system?
>
> conf-split is one of the compile-time configuration files in the
> qmail-1.03 source directory. There is no "maximum" limit, only what
> has proven to be a reasonable size given the performance of the file
> system on the available hardware. That is, in my experience, about
> 3,000 for ext2 fs. You *can* go a lot higher, however the directory
> access time starts to dominate any file operations, since it searches
> linearly. 3,000 is about the most files you want in any directory
> which is going to be frequently accessed.
>
Ok, btw I can see that the value in conf-split is actually the number of
directories in /var/qmail/queue/local(remote,mess,info).
How do you know if lots of emails are getting queued, that I need to
increase the value in conf-split or install another instance of qmail?
By default, the value of conf-split is 23, and I don't know how much
queued emails can this handle.
On Mon, Jan 03, 2000 at 07:25:28AM +0800, Benjamin de los Angeles Jr. wrote:
> increase the value in conf-split or install another instance of qmail?
> By default, the value of conf-split is 23, and I don't know how much
> queued emails can this handle.
When I tried to send a message to all customers simultaneously, the number
of queued messages grew to 70.000 on a Solaris box. According to the mrtg
graphs, qmail was still operating quite efficiently.
(on a side note, any clues on what would be the best way to send mail to lots
of people located on a limited number of servers?)
Your filesystem matters a great deal. If you decide to use ext2 (linux)
without the sync-patches, your performance will be staggering. This at the
cost of losing mail in case of a crash.
Solaris UFS is incredibly slow and might run into performance problems when
queueing a number of messages which Linux (or BSD with softupdates for that
matter) would handle just fine.
UFS is however a very safe choice for guaranteeing the arrival of each and
every message, even in the case of a crash.
I'm not yet sure, but it appears it can be a big gain to have
/var/qmail/queue on another filesystem then your actual Maildirs.
Regards,
bert.
--
+---------------+ | http://www.rent-a-nerd.nl
| nerd for hire | |
+---------------+ | - U N I X -
| | Inspice et cautus eris - D11T'95
|
Hello All,
I recently installed the daemontools
package, and created the initscripts as described by Dave Sill's Life With Qmail
webpage. Here is the problem.
Before, I had qmail w/ tcpserver starting
up our of the /etc/rc.d/rc.local file, and I had to reboot the system to restart
qmail.
So I installed the daemontools,etc. Qmail
starts up fine, and I can send and recieve mail through pop3, etc.
On my server, I have many webpage mail
forms which referenced the /var/qmail/bin/qmail-inject line, and it worked
fine for over a year.
Now that I have installed the new
daemontools package, this does not work anymore. In fact, I cannot get any
cgi program to open mail up and send it.
Here is a copy below when I do ps
aux | grep qmail on my Red Hat 5.1 system.
_______________________________
qmaild 32702 0.0 0.6
844 416 ? S N 17:02 0:00
/usr/local/bin/tcpserver -v -R -p -x /etc/tcp.smtp.cdb -u 503 -g 502 0
sm
qmaill 299 0.0 0.4
756 260 ? S N Dec 28 0:00
/usr/local/bin/multilog t /var/log/qmail/smtpd
qmaill 300 0.0 0.3
744 208 ? S N Dec 28 0:00
/usr/local/bin/multilog t /var/log/qmail
qmaill 32706
0.0 0.5 756 360 ? S N
17:02 0:00 splogger qmail
qmailq 32709
0.0 0.4 744 296 ? S N
17:02 0:00 qmail-clean
qmailr 32708 0.0
0.4 740 276 ? S N 17:02
0:00 qmail-rspawn
qmails 32703 0.0 0.5
788 340 ? S N 17:02 0:00 qmail-send
root 293 0.0
0.3 732 228 ? S N Dec 28 0:00
supervise qmail-send
root 294
0.0 0.3 732 212 ? S N Dec
28 0:00 supervise log
root
295 0.0 0.3 732 208 ? S N Dec
28 0:00 supervise qmail-smtpd
root 296 0.0 0.3
732 200 ? S N Dec 28 0:00 supervise log
root 32707 0.0 0.4
744 280 ? S N 17:02 0:00 qmail-lspawn
./Maildir/
_______________________________
Has anyone else had this problem? If so, please let me know
asap. Thanks.
Brock Eastman
[EMAIL PROTECTED]
Network
Administrator
2INTERACTIVE.COM
PHONE: (530)343-0947
FAX:
1-209-844-8334
|
listy-dyskusyjne Krzysztof Dabrowski writes:
> Why can't we make something like this (qmail-whatever)?
> This way we can port all the exisiting patches that everyone is applying
> these days into one bit patch
> and later on supporters can work off this patch to add more feautres?
> Applying a lot of patches to qmail these days leads me into reading diffs
> manualy and adding them by hand.
>
> Is this idea anything good in your opinion?
Sure. Propose a canonical set of patches. About the only thing I
install, and only on very high volume sites, is big-todo. Oh, and the
rblsmtpd multiple -r option patch. Given that MAPS
(http://mail-abuse.org) has adopted the DUL and RSS zones, you really
need multiple zones. And running multiple copies of rblsmtpd (Dan's
suggested solution) is too much of a hack, given the simplicity of
Aaron Nabil's patch.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | "Ask not what your country
521 Pleasant Valley Rd. | +1 315 268 1925 voice | can force other people to
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | do for you..." -Perry M.
On Sun, Jan 02, 2000 at 11:17:51PM -0500, Russell Nelson wrote:
> Sure. Propose a canonical set of patches. About the only thing I
> install, and only on very high volume sites, is big-todo. Oh, and the
> rblsmtpd multiple -r option patch. Given that MAPS
And big-dns, I hope.
Regards,
bert hubert.
--
+---------------+ | http://www.rent-a-nerd.nl
| nerd for hire | |
+---------------+ | - U N I X -
| | Inspice et cautus eris - D11T'95
Does anyone have a complete list of the available qmail patches and
what they do?
Pete
Peter Cavender writes:
> Does anyone have a complete list of the available qmail patches and
> what they do?
I expect http://www.qmail.org/top.html#addons to be canonical, and I
hope everyone else does too. If I've missed anything, please remind
me of it (except the Amavis stuff, that's still pending).
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | "Ask not what your country
521 Pleasant Valley Rd. | +1 315 268 1925 voice | can force other people to
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | do for you..." -Perry M.
On Sun, Jan 02, 2000 at 11:26:45PM -0500, Russell Nelson wrote:
> Peter Cavender writes:
> > Does anyone have a complete list of the available qmail patches and
> > what they do?
>
> I expect http://www.qmail.org/top.html#addons to be canonical, and I
> hope everyone else does too. If I've missed anything, please remind
> me of it (except the Amavis stuff, that's still pending).
>
Hi,
AMaViS doesn't require qmail patches! An early version I was hacking on
did, but I never made it publicly available. Both my modified version and
the version from http://amavis.org/ do not require any patches to qmail.
Chris
I have qmail running several virtual domains (and a "real" domain) on
a server. I am trying to make it so that the operation of the
virtual domains appears independent of the master domain.
The problem is:
1) bounce messages for [EMAIL PROTECTED] come from [EMAIL PROTECTED]
2) A message delivered to [EMAIL PROTECTED] has the following at the
top of it's header:
Delivered-To: [EMAIL PROTECTED]
If this is un-fixable, just lety me know. :-)
Thus said "Mark Maggelet" on Sun, 02 Jan 2000 01:29:33 PST:
> @40000000386f36191f0ac50c tcpserver: fatal: unable to bind: address already used
> I'm getting tons of these lines in my logs, what would cause it?
> what port is tcpserver trying to bind to?
Did you possibly enable the smtp port in your /etc/inetd.conf file? If
you already have something running on the smtp port then tcpserver will
be unable to 'bind' to that port when it starts up.
Andy
--
+====== Andy ====== TiK: garbaglio ======+
| Linux is about freedom of choice |
+== http://www.xmission.com/~bradipo/ ===+
Thanks Martin and happy new year,
> Well, if I understand the problem correctly (your PGP program is creating
> a message with bare LFs), then you should be able to solve the problem by
> piping the output of your PGP signing/encryption process to /usr/bin/addcr
> before it's sent to your SMTP server. (addcr is included in the ucspi
> package). For kicks, try running the PGP program by itself on a text
> file, and do an "od -c ${FILENAME}" to see whether or not you have the
> required \r\n. If not, you can add them with addcr.
>
> -Martin
probably this is the point, but how can I tell a MUA to use pgp with
addcr? Is it possible to tell the sendmail replacement
/var/qmail/bin/sendmail to do this? Perhaps by replacing the sendmail
by a perl-script, that pipes the output and the options to the sendmail
with adding a \r\n to the output? This would require, that the qmail
sendmail receives the input via stdin, wouldn't it? On the other hand
could this mean, that in all cases without pgp a \r\n too much is
appended, or is this not critical?
-Eugen ([EMAIL PROTECTED])
Hello all,
I need to know where I can find info on how to solve domain relaying
(one main mail server that sends all known mail to the right host).
mail.domain.com will automatically send mail to [EMAIL PROTECTED]
to host1.domain.com and mail to [EMAIL PROTECTED] to
host2.domain.com (guess you get the picture).. and I just need to know
where there are docs on that, or just how it's done. :)
I've tried to find about it in the howto and life with qmail, but maybe
I'm mixing names or something, because all I can find is relaying for
user, not domain :/
Thanks in advance.
--
-Marthe
Ano-Tech Computers, www.atc.no
"You humans are a disease, a cancer to this planet..
you are a plague.. and we.. are the cure."
On Mon, Jan 03, 2000 at 11:02:51AM +0100, Marthe Nes�en Gangfl�t wrote:
> Hello all,
>
> I need to know where I can find info on how to solve domain relaying
> (one main mail server that sends all known mail to the right host).
>
> mail.domain.com will automatically send mail to [EMAIL PROTECTED]
> to host1.domain.com and mail to [EMAIL PROTECTED] to
> host2.domain.com (guess you get the picture).. and I just need to know
> where there are docs on that, or just how it's done. :)
>
> I've tried to find about it in the howto and life with qmail, but maybe
> I'm mixing names or something, because all I can find is relaying for
> user, not domain :/
control/smtproutes and control/rcpthosts should have all the stuff you need,
look at man qmail-control for references to the relevant manpages.
Greetz, Peter.
--
Peter van Dijk - student/sysadmin/ircoper/madly in love/pretending coder
|
| 'C makes it easy to shoot yourself in the foot;
| C++ makes it harder, but when you do it blows your whole leg off.'
| Bjarne Stroustrup, Inventor of C++
On Mon, Jan 03, 2000 at 11:04:21AM +0100, [EMAIL PROTECTED] wrote:
> On Mon, Jan 03, 2000 at 11:02:51AM +0100, Marthe Nes�en Gangfl�t wrote:
> > I need to know where I can find info on how to solve domain relaying
> > (one main mail server that sends all known mail to the right host).
>
> control/smtproutes and control/rcpthosts should have all the stuff you need,
> look at man qmail-control for references to the relevant manpages.
Great thanks :)
--
-Marthe
Ano-Tech Computers, www.atc.no
"You humans are a disease, a cancer to this planet..
you are a plague.. and we.. are the cure."
