tcpserver: fatal: unable to bind: address already used

2000-01-02 Thread Mark Maggelet

@4000386f36191f0ac50c 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?

thx,
- Mark



Re: tcpserver: fatal: unable to bind: address already used

2000-01-02 Thread bert hubert

On Sun, Jan 02, 2000 at 01:29:33AM -0800, Mark Maggelet wrote:

 @4000386f36191f0ac50c 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?

Do some more work for us, we aren't clairvoyant. It appears that another
tcpserver is running already. Perhaps you invoked one by hand and then made
svscan/supervise scripts.

Try and figure out what tcpservers and running, and who's their parent.

Regards,

bert.

-- 
+---+  |  http://www.rent-a-nerd.nl
| nerd for hire |  |  
+---+  | - U N I X -
|  |  Inspice et cautus eris - D11T'95



Re: Anal-ness

2000-01-02 Thread David Cunningham

Would this license also prohibit me from modifying the source for my own
personal use (not for redistribution?)


- Original Message -
From: Russell Nelson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Saturday, January 01, 2000 11:23 PM
Subject: Re: Anal-ness


 Harald Hanche-Olsen writes:
   + "I Haddenough" [EMAIL PROTECTED]:
  
   | I mean, shit, he rattles cages with the gov't over krypto, but he
   | won't open source his code?
  
   Eh?  Qmail isn't open source?

 No.  An OSI-approved Open Source license gives recipients of the code
 the freedom to redistribute modified binaries.  Without that freedom,
 your software isn't OSI Certified Open Source.

 And RMS (Richard M. Stallman) has become much less strident over the
 years.  If asked, I'm sure he would praise Dan Bernstein for giving us
 the freedom to download the source of qmail and the freedom to
 redistribute unmodified binaries.  But he wouldn't call qmail free
 software for the same reason OSI would refuse to certify qmail as Open
 Source.

 That one essential freedom is missing.  Dan has stated his reasons for
 denying us that freedom.  I disagree with him, but as Linus Torvalds
 has said many a time, "He who writes the code picks the license."

 --
 -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.




qmail Digest 2 Jan 2000 11:00:01 -0000 Issue 868

2000-01-02 Thread qmail-digest-help


qmail Digest 2 Jan 2000 11:00:01 - Issue 868

Topics (messages 34948 through 34965):

max messages queued?
34948 by: Benjamin de los Angeles Jr .
34949 by: Russell Nelson
34953 by: Benjamin de los Angeles Jr .
34954 by: Russell Nelson

Delivery Problems
34950 by: CDR Inc
34951 by: Vince Vielhaber

Something wrong with mqil queue
34952 by: Albert Hopkins

Virtual Domains - main domain shows
34955 by: Peter Cavender

Relay management in Qmail with AtDot webmail.
34956 by: Lists

Re: max file limit
34957 by: Jim Zajkowski

Anal-ness
34958 by: I Haddenough
34959 by: John Gonzalez/netMDC admin
34960 by: Harald Hanche-Olsen
34961 by: Russell Nelson
34962 by: Russell Nelson
34965 by: David Cunningham

tcpserver: fatal: unable to bind: address already used
34963 by: Mark Maggelet
34964 by: bert hubert

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]


--



What's the maximum number of messages that can be queued in Qmail?




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.

-- 
-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 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?





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.

If you've got that much mail queued up, and the machine still has
extra resources to deliver more mail, you could run another instance
of qmail in, say, /var/qmail2.

-- 
-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.




In my quest to set up virtual domains thru QMAIL, it seems I must have
"wankified" the existing, working settings of QMAIL..

According to /var/log/maillog, mail is being received on behalf of the
various users of my domain..  The mail IS being received, but it is not
being delivered..

Here is the relevant maillog entries:

Jan  1 10:26:04 cdrinc qmail: 946740365.003803 new msg 2925
Jan  1 10:26:04 cdrinc qmail: 946740365.004089 info msg 2925: bytes 822 from
[EMAIL PROTECTED] qp 842 uid 509
Jan  1 10:26:05 cdrinc qmail: 946740365.027309 starting delivery 1: msg 2925
to local [EMAIL PROTECTED]
Jan  1 10:26:05 cdrinc qmail: 946740365.027458 status: local 1/10 remote
0/20
Jan  1 10:26:05 cdrinc qmail: 946740365.027526 starting delivery 2: msg 2925
to local [EMAIL PROTECTED]
Jan  1 10:26:05 cdrinc qmail: 946740365.027588 status: local 2/10 remote
0/20
Jan  1 10:26:05 cdrinc ipop3d[846]: port 110 service init from 205.216.79.61
Jan  1 10:26:05 cdrinc qmail: 946740365.164062 delivery 2: success:
did_1+0+0/
Jan  1 10:26:05 cdrinc 

Re: Anal-ness

2000-01-02 Thread nascheme

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



Re: Anal-ness

2000-01-02 Thread Marek Narkiewicz

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



Re: Anal-ness

2000-01-02 Thread lbudney-lists-qmail

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.



Re: Anal-ness

2000-01-02 Thread Russell Nelson

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.



Re: Anal-ness

2000-01-02 Thread Russell Nelson

[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.



q-mail relay responses (revisited)

2000-01-02 Thread Dustin Miller

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



Re: Anal-ness

2000-01-02 Thread craig

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)



Re: Anal-ness

2000-01-02 Thread Russ Allbery

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/



Re: Anal-ness

2000-01-02 Thread Russell Nelson

[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.



RE: q-mail relay responses (revisited)

2000-01-02 Thread Dustin Miller

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



Re: Anal-ness

2000-01-02 Thread listy-dyskusyjne Krzysztof Dabrowski


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



Re: Anal-ness

2000-01-02 Thread Claus Färber

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



Re: q-mail relay responses (revisited)

2000-01-02 Thread James R Grinter

"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.



Re: max messages queued?

2000-01-02 Thread Benjamin de los Angeles Jr.

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.





Re: q-mail relay responses (revisited)

2000-01-02 Thread David Cunningham

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





Re: max messages queued?

2000-01-02 Thread bert hubert

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



cgi program will not work to qmail-inject - PLEASE READ

2000-01-02 Thread Brock M. Eastman



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 
smqmaill 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 
Administrator2INTERACTIVE.COMPHONE: (530)343-0947FAX: 
1-209-844-8334




Re: q-mail relay responses (revisited)

2000-01-02 Thread John R. Levine

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



The Canonical Set of qmail Patches

2000-01-02 Thread Russell Nelson

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.



qmail patch list?

2000-01-02 Thread Peter Cavender

Does anyone have a complete list of the available qmail patches and 
what they do?

Pete



Re: qmail patch list?

2000-01-02 Thread Russell Nelson

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.



Re: qmail patch list?

2000-01-02 Thread Chris L. Mason

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



Re: The Canonical Set of qmail Patches

2000-01-02 Thread bert hubert

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



Virtual domains..?

2000-01-02 Thread Peter Cavender

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. :-)



Re: tcpserver: fatal: unable to bind: address already used

2000-01-02 Thread Andy Bradford

Thus said "Mark Maggelet" on Sun, 02 Jan 2000 01:29:33 PST:

 @4000386f36191f0ac50c 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/ ===+