qmail Digest 2 Oct 1999 10:00:01 -0000 Issue 777

Topics (messages 31121 through 31160):

Aack child crashed on Solaris
        31121 by:  Fred Backman

Autoresponder Written by Eric Huss
        31122 by:  Tony Wade
        31125 by:  Dave Sill

sorted (Re: Aack child crashed on Solaris)
        31123 by:  Fred Backman

qmHandle and supervise
        31124 by:  Mirko Zeibig

Re: 2) Triple Bounce
        31126 by:  Dave Sill

Problems with bulletins (popbull)
        31127 by:  Zbigniew Baniewski
        31128 by:  Stephen C. Comoletti

Re: How good is RBL at filtering spam?
        31129 by:  Peter Green
        31131 by:  Alex Rubenstein

Why "virtual"domains?
        31130 by:  Dave Kitabjian
        31140 by:  phil.ipal.net

Is inetd really unreliable?
        31132 by:  Fred Backman
        31133 by:  Bruce Guenter
        31134 by:  Markus Stumpf
        31135 by:  Johannes Erdfelt
        31136 by:  Bruce Guenter
        31138 by:  Johannes Erdfelt
        31139 by:  David Harris
        31141 by:  Racer X
        31142 by:  Johannes Erdfelt
        31143 by:  Bruce Guenter
        31145 by:  Adam D . McKenna
        31146 by:  James J. Lippard
        31147 by:  Markus Stumpf
        31148 by:  David Harris

Using form to send through qmail
        31137 by:  Darren Foo
        31155 by:  Sam

Bad return-path header, majordomo-inject, and rabid monkeys
        31144 by:  Chris Hardie
        31153 by:  Giles Lean

Auth. SMTP-after-POP
        31149 by:  Andreas Fiedler
        31150 by:  Eric Dahnke
        31159 by:  Paul Gilmore
        31160 by:  Roger Wrethman

the ERROR: "SMTP Connection closed by foreign host."
        31151 by:  Ed Weinberg
        31152 by:  Timothy L. Mayo

Qmail permissions
        31154 by:  Darren Foo
        31156 by:  Scott Schwartz
        31157 by:  Darren Foo

Blocking large mails
        31158 by:  Diego Puertas

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]


----------------------------------------------------------------------


I've got another problem on my Solaris machine (5.7), and this time I get a "Aack child crashed" when I try to send to local users. Below is the trace output (truss) of qmail-lspawn. Please can anyone advice what this might be? There is no .qmail file so that can't be it.
 
officesun2{root}# truss -p 28661
poll(0xFFBEFCA8, 1, -1)         (sleeping...)
poll(0xFFBEFCA8, 1, -1)                         = 1
sigprocmask(SIG_SETMASK, 0xFFBEFCB8, 0x00000000) = 0
read(0, "\0 9 / 4 5 4 3 4\0 r o o".., 1024)     = 71
open("9/45434", O_RDONLY|O_NDELAY)              = 2
fstat(2, 0xFFBEFBA8)                            = 0
pipe()                                          = 3 [4]
fcntl(3, F_SETFD, 0x00000001)                   = 0
fork()                                          = 45
close(2)                                        = 0
fcntl(4, F_SETFD, 0x00000001)                   = 0
sigprocmask(SIG_SETMASK, 0xFFBEFCB8, 0x00000000) = 0
    Received signal #18, SIGCLD, in poll() [caught]
      siginfo: SIGCLD CLD_EXITED pid=45 status=0x006F
poll(0xFFBEFC90, 2, -1)                         Err#4 EINTR
waitid(P_ALL, 0, 0xFFBEF748, WEXITED|WTRAPPED|WNOHANG) = 0
close(4)                                        = 0
waitid(P_ALL, 0, 0xFFBEF748, WEXITED|WTRAPPED|WNOHANG) Err#10 ECHILD
setcontext(0xFFBEF978)
sigprocmask(SIG_SETMASK, 0xFFBEFCB8, 0x00000000) = 0
sigprocmask(SIG_SETMASK, 0xFFBEFCB8, 0x00000000) = 0
poll(0xFFBEFC90, 2, -1)                         = 1
sigprocmask(SIG_SETMASK, 0xFFBEFCB8, 0x00000000) = 0
read(3, " A a c k ,   c h i l d  ".., 128)      = 30
sigprocmask(SIG_SETMASK, 0xFFBEFCB8, 0x00000000) = 0
poll(0xFFBEFC90, 2, -1)                         = 1
sigprocmask(SIG_SETMASK, 0xFFBEFCB8, 0x00000000) = 0
read(3, 0x00029398, 128)                        = 0
write(1, "\0 Z A a c k ,   c h i l".., 33)      = 33
close(3)                                        = 0
sigprocmask(SIG_SETMASK, 0xFFBEFCB8, 0x00000000) = 0
poll(0xFFBEFCA8, 1, -1)         (sleeping...)




Hi all 


I have downloaded the Autoresponder and seem to be having a spot of trouble
with it. 

my Qmail lives in /var/qmail/

I compiled the autoresponder on a RedHat 6 server and then copied it to a
Jurix Server. 

My alias file looks like this

|autorespond 10000 5 /var/qmail/alias/AUTORESPOND/MAJORDOMO/majordomo
/var/qmail/alias/AUTORESPOND/MAJORDOMO
&[EMAIL PROTECTED]


When i attempt to send a message to the alias, i get the following. 

Oct  1 12:56:30 thanatos qmail: 938775390.570015 status: local 2/10 remote
0/20
Oct  1 12:56:30 thanatos qmail: 938775390.588017 delivery 69: deferral:
/bin/sh:_/bin/autorespond:_No_such_file_or_directory/
Oct  1 12:56:30 thanatos qmail: 938775390.588177 status: local 1/10 remote
0/20
Oct  1 12:56:30 thanatos qmail: 938775390.595656 delivery 68: deferral:
/bin/sh:_/bin/autorespond:_No_such_file_or_directory/
Oct  1 12:56:30 thanatos qmail: 938775390.595750 status: local 0/10 remote
0/20

Any Idea where i have gone wrong ? 

the autorespond binary is in /bin/ and in /usr/local/bin/

Any help appreciated. 

Tony Wade
The Internet Solution
Tel:    (+27 11) 283 5483
Fax:    (+27 11) 283 5401
E-mail: [EMAIL PROTECTED] 
Web:    http://www.is.co.za
#include <std/disclaimer.h>
Life would be so much easier if we could just look at the source code.
        -- Dave Olson





Tony Wade <[EMAIL PROTECTED]> wrote:

>Oct  1 12:56:30 thanatos qmail: 938775390.588017 delivery 69: deferral:
>/bin/sh:_/bin/autorespond:_No_such_file_or_directory/
>
>Any Idea where i have gone wrong ? 

Is /bin/autorespond a script? If so, what does the first line say?
Apparently it points to the wrong place on your system, or you don't
have the interpreter it requires installed.

-Dave




I have sorted the problem myself now. Sorry for being too eager sending this post.
(The problem turned out to be non-qmail).




Hello I am using qmHandle and Mate's old RPMs. To delete messages I now stop
qmail and restart it after deletion.
Would it be sufficient to pause (STOP) qmail instead and send an CONT
afterwards?

Regards
Mirko

-- 
mailto:   [EMAIL PROTECTED]
privat:   http://sites.inka.de/picard
commerce: http://www.webideal.de
qmail, ldap, serialfax, rh-isdn: http://www.webideal.de/#downloads




"jarrid jeeby" <[EMAIL PROTECTED]> wrote:

>2. Correct a problem I have with local to local deliveries where the rcpt 
>to: field is only a the account name.  ie. Mail to "joe" gets delivered as 
>"[EMAIL PROTECTED]".  I'd like it to be delivered to "[EMAIL PROTECTED]", 
>else fix my setup to allow "host.domain.com" to work.

control/envnoathost should do the trick.

See:

    http://Web.InfoAve.Net/~dsill/lwq.html#envnoathost

-Dave




I'm using the "popbull" extension, and I'm having some problems - for no
apparent reason the bulletin, send to all users, can be read only by
several users, and not by all. I cannot find any difference between the
accounts, that are receiving the bulletins, and the ones, that are
ignoring them. Popbull is called in following way:
-------------------------------------------------------------------
/usr/local/bin/tcpserver -t3 -Hl pirx.ispid.com.pl 0 pop3 \
/var/qmail/bin/qmail-popup pirx.ispid.com.pl /bin/checkpassword \
/var/qmail/bin/qmail-popbull /var/spool/bulletins \
/var/qmail/bin/qmail-pop3d Maildir &
-------------------------------------------------------------------

Perhaps somebody noticed such problem?

                                pozdrawiam / regards

                                                Zbigniew Baniewski





Another odd problem I just noticed..MS Outlook users do not receive
bulletins. Netscape/pine(pop3 enabled)/Eudora all receive them fine.

--
Stephen Comoletti
Systems Administrator
Delanet, Inc.  http://www.delanet.com
ph: (302) 326-5800 fax: (302) 326-5802

Zbigniew Baniewski wrote:

> I'm using the "popbull" extension, and I'm having some problems - for no
> apparent reason the bulletin, send to all users, can be read only by
> several users, and not by all. I cannot find any difference between the
> accounts, that are receiving the bulletins, and the ones, that are
> ignoring them. Popbull is called in following way:
> -------------------------------------------------------------------
> /usr/local/bin/tcpserver -t3 -Hl pirx.ispid.com.pl 0 pop3 \
> /var/qmail/bin/qmail-popup pirx.ispid.com.pl /bin/checkpassword \
> /var/qmail/bin/qmail-popbull /var/spool/bulletins \
> /var/qmail/bin/qmail-pop3d Maildir &
> -------------------------------------------------------------------
>
> Perhaps somebody noticed such problem?
>
>                                 pozdrawiam / regards
>
>                                                 Zbigniew Baniewski







On Fri, 1 Oct 1999, Markus Stumpf wrote:

> On Mon, Sep 20, 1999 at 04:24:06PM -0400, David Harris wrote:
> > > I'll run this for a few days and let the list know what I find.
> 
> While we're on some statistics:

I'll throw mine in, especially since I'm really happy with RBL:

  day       tcpcontrol ok   RBL rejects
1999/09/25     13726            871
1999/09/26     14506           1099
1999/09/27     31952           1112
1999/09/28     28585           1524
1999/09/29     42701            947
1999/09/30     60224           1103

/pg
-- 
Peter Green
Gospel Communications Network, SysAdmin
[EMAIL PROTECTED]







Fyi, from mail.nac.net:

tempest:/var/log/mail$ zcat maillog.0.gz |grep smtpd | grep " ok " | wc -l
  111001

tempest:/var/log/mail$ zcat maillog.0.gz | grep smtpd | grep "BOUNCEMAIL" | wc -l
     100


You must be aimed at for spam more often then we are.








On Fri, 1 Oct 1999, Peter Green wrote:

> On Fri, 1 Oct 1999, Markus Stumpf wrote:
> 
> > On Mon, Sep 20, 1999 at 04:24:06PM -0400, David Harris wrote:
> > > > I'll run this for a few days and let the list know what I find.
> > 
> > While we're on some statistics:
> 
> I'll throw mine in, especially since I'm really happy with RBL:
> 
>   day       tcpcontrol ok   RBL rejects
> 1999/09/25     13726            871
> 1999/09/26     14506           1099
> 1999/09/27     31952           1112
> 1999/09/28     28585           1524
> 1999/09/29     42701            947
> 1999/09/30     60224           1103
> 
> /pg
> -- 
> Peter Green
> Gospel Communications Network, SysAdmin
> [EMAIL PROTECTED]
> 
> 






Please pardon my ignorance just for a moment, and permit a question that 
may have a very simple answer...

What is "virtual" about a "virtualdomain"?

We host many domains on a single qmail POP server, and they are all very 
real. Their MX records all point to that server and for all intents and 
purposes, that is "home" for them.

To me, "virtualdomains" are equivalent to, simply, domains. The prepend 
feature of "virtualdomains" is the only mechanism I know of in qmail to 
isolate the user namespace of one domain from each other domain, so that 
there can be a [EMAIL PROTECTED] and a [EMAIL PROTECTED] with no ambiguity 
or contention. That way qmail can handle multiple domains seamlessly in a 
single "assign" file.

Please educate me... :)

Dave





Dave Kitabjian wrote:

> Please pardon my ignorance just for a moment, and permit a question that 
> may have a very simple answer...
> 
> What is "virtual" about a "virtualdomain"?
> 
> We host many domains on a single qmail POP server, and they are all very 
> real. Their MX records all point to that server and for all intents and 
> purposes, that is "home" for them.
> 
> To me, "virtualdomains" are equivalent to, simply, domains. The prepend 
> feature of "virtualdomains" is the only mechanism I know of in qmail to 
> isolate the user namespace of one domain from each other domain, so that 
> there can be a [EMAIL PROTECTED] and a [EMAIL PROTECTED] with no ambiguity 
> or contention. That way qmail can handle multiple domains seamlessly in a 
> single "assign" file.
> 
> Please educate me... :)

Generally, a host machine has a domain of its own.  If it serves for other
domains, the concept as been equated to virtual memory technology.  That
kind of memory is very real, when swapped in, at least to the process that
is working with it.

So if the domain is different than the host machine, but the host machine
is doing more than just relaying or queueing for the host, such as local
delivery or even address translation and subsequent delivery, then we call
that virtual when the domain name (it doesn't have to just be a different
2nd level; it can be a different 3rd level, or 4th level, etc.) is not the
same as the host machine.

Would you have another more meaningful term to suggest that properly
differentiates between mail addressed to [EMAIL PROTECTED] and mail
addressed to [EMAIL PROTECTED] yet is delivered on "the.host"?

-- 
Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
  phil      | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
      at    | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
  ipal      | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
     dot    | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
  net       | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]




I'm reading the web page about ucspi-tcp and see the last three lines which
say:

* inetd is unreliable under high loads. It cuts off service for 10 minutes
if it receives ``too many'' connections in 1 minute.
* inetd does not provide effective resource management. It will happily use
up all your memory if you are running a popular service.
* inetd has trouble with sudden bursts of activity. Its listen() backlog is
typically only 5 or 10 and cannot be raised.

Where can I find further documentation and proof or witnesses of this
actually being true?

TIA
Fred





On Fri, Oct 01, 1999 at 05:26:38PM +0100, Fred Backman wrote:
> I'm reading the web page about ucspi-tcp and see the last three lines which
> say:
> 
> * inetd is unreliable under high loads. It cuts off service for 10 minutes
> if it receives ``too many'' connections in 1 minute.

In its default configuration, connect and disconnect from a service 50
times in one minute.  inetd will now turn that service off for the next
10 minutes.  This is how inetd is designed.

> * inetd does not provide effective resource management. It will happily use
> up all your memory if you are running a popular service.

Over the course of a long period of time, open up one connection to a
service per minute, and keep them all open.  inetd will not limit the
number of connections and cause far too many (for example) POP3 servers
to be started.  This is well known.

> * inetd has trouble with sudden bursts of activity. Its listen() backlog is
> typically only 5 or 10 and cannot be raised.

Try to simultaneously open 20 connections to a service and see how many
of them succeed, without the service being turned off.  This is a little
more difficult, as those 20 really have to be nearly simultaneous to
trigger the problem.

> Where can I find further documentation and proof or witnesses of this
> actually being true?

I couldn't point you at specific attributions right now, but these are
well known problems, some of which are documented by the way inetd is
configured.
-- 
Bruce Guenter, QCC Communications Corp.  EMail: [EMAIL PROTECTED]
Phone: (306)249-0220               WWW: http://www.qcc.sk.ca/~bguenter/




On Fri, Oct 01, 1999 at 05:26:38PM +0100, Fred Backman wrote:
> * inetd is unreliable under high loads. It cuts off service for 10 minutes
> if it receives ``too many'' connections in 1 minute.
> * inetd does not provide effective resource management. It will happily use
> up all your memory if you are running a popular service.
> * inetd has trouble with sudden bursts of activity. Its listen() backlog is
> typically only 5 or 10 and cannot be raised.
> 
> Where can I find further documentation and proof or witnesses of this
> actually being true?

How about
  $ man inetd

On my FreeBSD system I find:
        -R rate
             Specify the maximum number of times a service can
             be invoked in one minute; the default is 256.
However this can only be done "globally" for all services and you cannot
say "use 255 for smtp and 5 for all other services".

If you use ulimit (or whatever it's called in various shells) before you
start inetd you can set certain limits, but they apply for all services.
You cannot specify selective limits for individual services.

For the listen() backlog you probably have to consult the source code of
inetd for your system.

With tcpserver you can fine tune each parameter for each service
individually. For most services started from inetd this may not be needed,
for some it may be essential (smtp is a good candidate) and then tcpserver
is your friend.

        \Maex

-- 
SpaceNet GmbH             |   http://www.Space.Net/   | Yeah, yo mama dresses
Research & Development    | mailto:[EMAIL PROTECTED] | you funny and you need
Joseph-Dollinger-Bogen 14 |  Tel: +49 (89) 32356-0    | a mouse to delete files
D-80807 Muenchen          |  Fax: +49 (89) 32356-299  |




On Fri, Oct 01, 1999, Markus Stumpf <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 01, 1999 at 05:26:38PM +0100, Fred Backman wrote:
> > * inetd is unreliable under high loads. It cuts off service for 10 minutes
> > if it receives ``too many'' connections in 1 minute.
> > * inetd does not provide effective resource management. It will happily use
> > up all your memory if you are running a popular service.
> > * inetd has trouble with sudden bursts of activity. Its listen() backlog is
> > typically only 5 or 10 and cannot be raised.
> > 
> > Where can I find further documentation and proof or witnesses of this
> > actually being true?
> 
> How about
>   $ man inetd
> 
> On my FreeBSD system I find:
>         -R rate
>            Specify the maximum number of times a service can
>            be invoked in one minute; the default is 256.
> However this can only be done "globally" for all services and you cannot
> say "use 255 for smtp and 5 for all other services".
> 
> If you use ulimit (or whatever it's called in various shells) before you
> start inetd you can set certain limits, but they apply for all services.
> You cannot specify selective limits for individual services.
> 
> For the listen() backlog you probably have to consult the source code of
> inetd for your system.
> 
> With tcpserver you can fine tune each parameter for each service
> individually. For most services started from inetd this may not be needed,
> for some it may be essential (smtp is a good candidate) and then tcpserver
> is your friend.

Atleast with Linux's inetd:

     -q queuelength
             Sets the size of the socket listen queue to the specified value.
             Default is 128.

[...]

The optional ``max'' suffix (separated from
``wait'' or ``nowait'' by a dot) specifies the maximum number of server
instances that may be spawned from inetd within an interval of 60 sec-
onds. When omitted, ``max'' defaults to 40.

Both work for me fine. I dunno what people's big gripes against inetd
are. It works damn well for almost every service that doesn't have high
loads. In 99% of people's cases who use mail, then won't get more than
40 hits a second, and if they do, increase it. I run it with a 10000 hit
maximum on a relatively busy mail server (close to 100,000 incoming messages
a day)

The only thing it can't do is set environment variables based on
source IP address (like tcpserver), but I don't allow relaying through
that machine anyway so I don't need it.

JE





On Fri, Oct 01, 1999 at 11:09:10AM -0700, Johannes Erdfelt wrote:
> Both work for me fine. I dunno what people's big gripes against inetd
> are. It works damn well for almost every service that doesn't have high
> loads. In 99% of people's cases who use mail, then won't get more than
> 40 hits a second, and if they do, increase it. I run it with a 10000 hit
> maximum on a relatively busy mail server (close to 100,000 incoming messages
> a day)

And what happens when somebody tries to actively attack your system?
With these limits, I expect that a remote user could make your system
run out of FDs in a few minutes, not to mention memory.  With a limit of
10000, I could probably open up a thousand or so connections a minute
without triggering any of inetd's limits, and leave them open.

inetd protects against one thing: rapid attacks.  It does not offer any
protection against total amount of resources used (in the form of number
of connections).  I have never run into a situation where rate
protection is needed, and have only rarely heard of such situations.
However, resource starvation is common.

> The only thing it can't do is set environment variables based on
> source IP address (like tcpserver), but I don't allow relaying through
> that machine anyway so I don't need it.

-- 
Bruce Guenter, QCC Communications Corp.  EMail: [EMAIL PROTECTED]
Phone: (306)249-0220               WWW: http://www.qcc.sk.ca/~bguenter/




On Fri, Oct 01, 1999, Bruce Guenter <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 01, 1999 at 11:09:10AM -0700, Johannes Erdfelt wrote:
> > Both work for me fine. I dunno what people's big gripes against inetd
> > are. It works damn well for almost every service that doesn't have high
> > loads. In 99% of people's cases who use mail, then won't get more than
> > 40 hits a second, and if they do, increase it. I run it with a 10000 hit
> > maximum on a relatively busy mail server (close to 100,000 incoming messages
> > a day)
> 
> And what happens when somebody tries to actively attack your system?
> With these limits, I expect that a remote user could make your system
> run out of FDs in a few minutes, not to mention memory.  With a limit of
> 10000, I could probably open up a thousand or so connections a minute
> without triggering any of inetd's limits, and leave them open.
> 
> inetd protects against one thing: rapid attacks.  It does not offer any
> protection against total amount of resources used (in the form of number
> of connections).  I have never run into a situation where rate
> protection is needed, and have only rarely heard of such situations.
> However, resource starvation is common.

I'm not personally worried about it. There are so many effective Denial
of Service attacks on the Internet (smurfs, etc) that stopping one
easily traceable one does me little good.

Also, the fact qmail's binaries are so light weight, it would take ALOT
of connections to effectively do that. They'd probably run out of port
space on the IP they're attacking from before it really started to
seriously affect my machine.

But yes, octopus like attacks can be a problem, but for the majority of
users, it's not a problem. The wasted memory by another daemon running
is probably more a worry than a DoS attack on a very low profile low
traffic mail server.

JE






Bruce Guenter [mailto:[EMAIL PROTECTED]] write:
> And what happens when somebody tries to actively attack your system?
> With these limits, I expect that a remote user could make your system
> run out of FDs in a few minutes, not to mention memory.  With a limit of
> 10000, I could probably open up a thousand or so connections a minute
> without triggering any of inetd's limits, and leave them open.
>
> inetd protects against one thing: rapid attacks.  It does not offer any
> protection against total amount of resources used (in the form of number
> of connections).  I have never run into a situation where rate
> protection is needed, and have only rarely heard of such situations.
> However, resource starvation is common.

I use tcpserver for qmail - that only makes sense to me because of the load
issues.

But about the other services? I'd perhaps like to use tcpserver for them too..
and I've heard that others have had success with this. But I don't like the
idea of a whole bunch of programs all configured with command line directives
running in the background just for these rarely used services.

Why doesn't somebody patch tcpserver so that one daemon can handle multiple
services and read the configuration all out of one file. That would be really
neat, IMO.

Also, when you tcpserver devotees start railing about how the system can be
attacked with inetd, it rings hollow to me because an attacker could use any
service to attack, right? So if I have inetd in my system I'm vulnerable
whether I used it for qmail or not. Wouldn't it be cooler if you could show the
user how to easily replace inetd with tcpserver all together?

 - David






> But about the other services? I'd perhaps like to use tcpserver for them
too..
> and I've heard that others have had success with this. But I don't like
the
> idea of a whole bunch of programs all configured with command line
directives
> running in the background just for these rarely used services.

what exactly is a rarely used service?  also, what's the problem with
programs running in the background?  if they're so rarely used, they'll be
the first things paged out of memory if your system needs it.

> Why doesn't somebody patch tcpserver so that one daemon can handle
multiple
> services and read the configuration all out of one file. That would be
really
> neat, IMO.

there's already a program written just like that, it's called "inetd."  as
was mentioned in a previous exchange, one of the problems of inetd is that
you can't limit each service's resources separately.  programs such as
xinetd or some enhanced inetd might support this, but tcpserver has an
advantage in that each service is compartmented and running by itself.

> Also, when you tcpserver devotees start railing about how the system can
be
> attacked with inetd, it rings hollow to me because an attacker could use
any
> service to attack, right? So if I have inetd in my system I'm vulnerable
> whether I used it for qmail or not. Wouldn't it be cooler if you could
show the
> user how to easily replace inetd with tcpserver all together?

why DO you have inetd in your system?  there's only one or two things i can
think of that people leave inetd on for: telnet, ftp, finger maybe.  unless
you really really need telnet, you'd be better off with ssh.  finger is so
widely disabled that i don't even bother with it anymore.  that leaves only
ftp to run from inetd.  every other major service (http, smtp, etc) has its
own service control program.

replacing each service with tcpserver is pretty straight forward.  figure
out who the service needs to run as, how many concurrent connections you'll
allow, and rtfm for tcpserver.  shouldn't take more than a few minutes.
note that you probably won't be able to run certain things like
named/apache/sshd from tcpserver, but each of those have similar
functionality built in and can be limited similarly to tcpserver.

shag





On Fri, Oct 01, 1999, David Harris <[EMAIL PROTECTED]> wrote:
> 
> Bruce Guenter [mailto:[EMAIL PROTECTED]] write:
> > And what happens when somebody tries to actively attack your system?
> > With these limits, I expect that a remote user could make your system
> > run out of FDs in a few minutes, not to mention memory.  With a limit of
> > 10000, I could probably open up a thousand or so connections a minute
> > without triggering any of inetd's limits, and leave them open.
> >
> > inetd protects against one thing: rapid attacks.  It does not offer any
> > protection against total amount of resources used (in the form of number
> > of connections).  I have never run into a situation where rate
> > protection is needed, and have only rarely heard of such situations.
> > However, resource starvation is common.
> 
> I use tcpserver for qmail - that only makes sense to me because of the load
> issues.
> 
> But about the other services? I'd perhaps like to use tcpserver for them too..
> and I've heard that others have had success with this. But I don't like the
> idea of a whole bunch of programs all configured with command line directives
> running in the background just for these rarely used services.
> 
> Why doesn't somebody patch tcpserver so that one daemon can handle multiple
> services and read the configuration all out of one file. That would be really
> neat, IMO.
> 
> Also, when you tcpserver devotees start railing about how the system can be
> attacked with inetd, it rings hollow to me because an attacker could use any
> service to attack, right? So if I have inetd in my system I'm vulnerable
> whether I used it for qmail or not. Wouldn't it be cooler if you could show the
> user how to easily replace inetd with tcpserver all together?

Umm, you mostly reinvented inetd. Why not add the features you want to
inetd instead of reimplenting inetd in tcpserver?

Seriously, there's reasons for using either program. The point I'm
trying to make is, for 90% of the people out there, inetd is good
enough.

inetd works fine for spawning qmail-smtpd.

JE





On Fri, Oct 01, 1999 at 02:39:44PM -0400, David Harris wrote:
> I use tcpserver for qmail - that only makes sense to me because of the load
> issues.
> 
> But about the other services? I'd perhaps like to use tcpserver for them too..
> and I've heard that others have had success with this. But I don't like the
> idea of a whole bunch of programs all configured with command line directives
> running in the background just for these rarely used services.

Have you actually profiled the impact of doing such a thing?  Modern
UNIX is designed to deal with many tasks, and this one would have only a
few pages per process that weren't shared.

> Why doesn't somebody patch tcpserver so that one daemon can handle multiple
> services and read the configuration all out of one file. That would be really
> neat, IMO.

Because it is unnecessary.  tcpserver is so light that multiple
tcpservers don't hurt system resources significantly, especially if
they're not used and swapped out.  In fact, I would go so far as to say
it's bad.  Anything that reads configuration regarding multiple services
out of a single file is bad.  How do you add or remove a service
safely?

It also goes against "the UNIX way" -- each task does one small and
easily definable task.  Why else have programs like "sort" or "uniq"?
Why not build those into "ls" as well?  Oh, and "cat".  Oh, and "more".
What DJB has done is to build a set of programs that each do a single
task -- svscan handles starting a series of supervise tasks; supervise
handles (re)starting and stoping a single task; tcpserver handles
incoming connections; qmail-smtpd handles ths SMTP protocol; and so on.

> Also, when you tcpserver devotees start railing about how the system can be
> attacked with inetd, it rings hollow to me because an attacker could use any
> service to attack, right? So if I have inetd in my system I'm vulnerable
> whether I used it for qmail or not.

Right on both points.

> Wouldn't it be cooler if you could show the
> user how to easily replace inetd with tcpserver all together?

I have seen a script that converts a inetd.conf file into a series of
"supervise tcpserver" commands.  It can't get much simpler than that.
-- 
Bruce Guenter <[EMAIL PROTECTED]>                       http://em.ca/~bruceg/




On Fri, Oct 01, 1999 at 11:54:25AM -0700, Johannes Erdfelt wrote:
> Umm, you mostly reinvented inetd. Why not add the features you want to
> inetd instead of reimplenting inetd in tcpserver?
> 
> Seriously, there's reasons for using either program. The point I'm
> trying to make is, for 90% of the people out there, inetd is good
> enough.

I'd be willing to wager that a good portion of the people reading this list
do not use inetd at all.  I replace it with xinetd on the systems that I
administer.  A lot of people ditch it altogether and just run everything
under tcpserver.

As far as a "single file" where you can put your "tcpserver configuration",
what's wrong with /etc/init.d/tcpserver?

--Adam




On Fri, 1 Oct 1999 12:58:15 -0600 in <[EMAIL PROTECTED]> Bruce Guenter 
<[EMAIL PROTECTED]> wrote:
> It also goes against "the UNIX way" -- each task does one small and
> easily definable task.  Why else have programs like "sort" or "uniq"?
> Why not build those into "ls" as well?  Oh, and "cat".  Oh, and "more".
> What DJB has done is to build a set of programs that each do a single
> task -- svscan handles starting a series of supervise tasks; supervise
> handles (re)starting and stoping a single task; tcpserver handles
> incoming connections; qmail-smtpd handles ths SMTP protocol; and so on.

This is by contrast with "the Multics way", which is to build powerful
subroutines (programs not intended to be called except by other programs)
to do things like date conversions, sorting, pattern matching, argument
processing, file manipulation, etc., so that any given command can easily
be as powerful as necessary, and be completely consistent with all other
commands in its interface.  Perl developers often seem to have a fairly
similar philosophy.  See http://www.best.com/~thvv/multics.html

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 Fri, Oct 01, 1999 at 11:39:06AM -0700, Johannes Erdfelt wrote:
> Also, the fact qmail's binaries are so light weight, it would take ALOT
> of connections to effectively do that. They'd probably run out of port
> space on the IP they're attacking from before it really started to
> seriously affect my machine.
> 
> But yes, octopus like attacks can be a problem, but for the majority of
> users, it's not a problem. The wasted memory by another daemon running
> is probably more a worry than a DoS attack on a very low profile low
> traffic mail server.

May I refer to a message I posted earlier this week?
Someone forged one of the domains hosted on one of our mailservers
and injected tons of email via a few open relays.
We were hit with all the failure messages coming in at high rate from
thousands (yes really) of remote systems.

With tcpserver I had at least *some* control, with inetd I am rather
sure we'd been lost.

A small, unrecognized, smoothly running system can mutate really fast.

        \Maex

-- 
SpaceNet GmbH             |   http://www.Space.Net/   | Yeah, yo mama dresses
Research & Development    | mailto:[EMAIL PROTECTED] | you funny and you need
Joseph-Dollinger-Bogen 14 |  Tel: +49 (89) 32356-0    | a mouse to delete files
D-80807 Muenchen          |  Fax: +49 (89) 32356-299  |





I didn't think I'd evoke such a response. Here goes...

I'm happy with my inetd service and tcpserver for my qmail-smtp. I'm running a
few low-load services through inetd and it's doing fine. Perhaps if pop3 or
imap become a larger load when I deploy web based email, I'll run them with
tcpserver too.

I was just mainly trying to point out the hole in the
You-Must-Use-Tcpserver-Because-Inetd-Is-A-DoS-Risk argument - that you can
simply attack a different service.

 - David Harris
   Principal Engineer, DRH Internet Services







        I assume /var/qmail/bin/sendmail the same as qmail-inject. Everytime I
try to send from my forms I the the following error. I've tried to read
the error report mail but I don't receive any.

qmail-inject: fatal: read error qmail-inject:
                     fatal: read error ions have
                     been mailed to you.
-- 
Darren Foo
===========================
WebCT Canada
Information and Communication Systems




On Fri, 1 Oct 1999, Darren Foo wrote:

>       I assume /var/qmail/bin/sendmail the same as qmail-inject. Everytime I

No, they're slightly different.  I haven't yet been buggered enough to be
motivated into looking what the differences are, but there are some
differences in addition to different command line options.






Hi.  We're having some problems with qmail and majordomo.  I've read the
FAQs on using the two together, the docs on majordomo-inject, the man
pages for qmail-inject and qmail-header, and I still don't quite know what
to do.

The problem occurs when a message sent to a mailing list bounces on one
or more of the mailing list addresses.  The return path included in the
message to the list is always invalid, often in the form:

Return-Path: <[EMAIL PROTECTED]>

Summersault.com is our domain, the rest of that is related to the invalid
mailing list address.

The result, as you can imagine, is that the bounce bounces, and everything
ends up getting dumped to postmaster.  I'm looking for A) someone to tell
me which piece of software is writing that bad return-path header and why,
and B) how to fix things so the the return path is properly set to the
owner of the list.

I know this has probably been discussed/answered before, but in reading
all of the related docs I've become more confused rather than get closer
to a solution, so I'd appreciate your help.

I've included a sample bounced message below for your examination. System
specs: qmail 1.03, majordomo 1.94.4, majordomo-inject.

Thanks in advance!
Chris


-------- Original Message --------
Return-Path: <#@[]>
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 18102 invoked by alias); 1 Oct 1999 12:31:22 -0000
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 18099 invoked by alias); 1 Oct 1999 12:31:22 -0000
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 18094 invoked for bounce); 1 Oct 1999 12:31:21 -0000
Date: 1 Oct 1999 12:31:21 -0000
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: failure notice

Hi. This is the qmail-send program at summersault.com.
I tried to deliver a bounce message to this address, but the bounce bounced!

<[EMAIL PROTECTED]>:
Sorry, no mailbox here by that name. (#5.1.1)

--- Below this line is the original bounce.

Return-Path: <>
Received: (qmail 18090 invoked from network); 1 Oct 1999 12:31:21 -0000
Received: from mail11.lax.netzero.net (209.247.162.44)
  by nollie.summersault.com with SMTP; 1 Oct 1999 12:31:21 -0000
Received: (qmail 26871 invoked for bounce); 1 Oct 1999 12:31:09 -0000
Date: 1 Oct 1999 12:31:09 -0000
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: failure notice

Hi. This is the NetZero mail server.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<[EMAIL PROTECTED]>:
Sorry, no mailbox here by that name. (#5.1.1)

--- Below this line is a copy of the message.

Return-Path: <[EMAIL PROTECTED]>
Received: (qmail 26846 invoked by uid 0); 1 Oct 1999 12:31:09 -0000
Received: from nollie.summersault.com (HELO summersault.com) (199.120.185.41)
  by mail11.lax.netzero.net with SMTP; 1 Oct 1999 12:31:09 -0000
Received: (qmail 17847 invoked by uid 54); 1 Oct 1999 12:30:38 -0000
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 17840 invoked from network); 1 Oct 1999 12:30:35 -0000
Received: from f318.hotmail.com (HELO hotmail.com) (207.82.250.238)
  by nollie.summersault.com with SMTP; 1 Oct 1999 12:30:35 -0000
Received: (qmail 14000 invoked by uid 0); 1 Oct 1999 12:28:46 -0000
Message-ID: <[EMAIL PROTECTED]>
Received: from 63.24.87.146 by www.hotmail.com with HTTP;
        Fri, 01 Oct 1999 05:28:45 PDT
X-Originating-IP: [63.24.87.146]
From: "T. Eric Monroe" <[EMAIL PROTECTED]>
To:
Subject: NYC (9/26) results/ USA regionals and championship
Date: Fri, 01 Oct 1999 05:28:45 PDT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Sender: [EMAIL PROTECTED]
Precedence: bulk

<original message to mailing list was here>







On Fri, 1 Oct 1999 14:01:16 -0500 (EST)  Chris Hardie wrote:

> Hi.  We're having some problems with qmail and majordomo.  I've read the
> FAQs on using the two together, the docs on majordomo-inject, the man
> pages for qmail-inject and qmail-header, and I still don't quite know what
> to do.

Hmm ... I had an old script called majordomo-inject.  It did VERP
correctly but inefficiently, and overlapped Russ Allbery's "mjinject"
script.  I think it is a couple of years since I merged VERP
functionality into Russ's script and he continues to distribute it.

Please search the www.qmail.org web page for "mjinject" and check
Russ's FAQ and documentation.  My web pages are guaranteed out of
date. :-(

> The problem occurs when a message sent to a mailing list bounces on one
> or more of the mailing list addresses.  The return path included in the
> message to the list is always invalid, often in the form:
> 
> Return-Path: <[EMAIL PROTECTED]>
> 
> Summersault.com is our domain, the rest of that is related to the invalid
> mailing list address.

As it is supposed to be, so that you know which address bounced.

You need to set qmail up on your system so that mail to 411-owner-* is
handled by a person or better still by a script, so that these failing
addresses can be removed from your list.  I'll refer you to the
doucmentation for this -- I've not administered a mailing list in a
couple of years.

Regards,

Giles




Hi,

I have a problem with sending mail (of course :-)

My new provider uses SMTP-after-POP. This means I have to receive Mail via POP
before I can send outgoing mail. The provider uses it to reduce spammers.

Is there any way I can realize that with Qmail/serialmail? I didn't find a
authentication like that in the serialmail docs...

Thanks in advance!

Andreas


PS.:  The Qmail/serialmail lists seem like dead..  I didn't get mails for 
      days.. only low traffic or is there something up?





Sure just put fetchmail or your pop application before serialmail in
your ppp/ip-up scripts.

- Eric

Andreas Fiedler escribió:
> 
> Hi,
> 
> I have a problem with sending mail (of course :-)
> 
> My new provider uses SMTP-after-POP. This means I have to receive Mail via POP
> before I can send outgoing mail. The provider uses it to reduce spammers.
> 
> Is there any way I can realize that with Qmail/serialmail? I didn't find a
> authentication like that in the serialmail docs...
> 
> Thanks in advance!
> 
> Andreas
> 
> PS.:  The Qmail/serialmail lists seem like dead..  I didn't get mails for
>       days.. only low traffic or is there something up?

-- 
+ + + + + + + + + + + + + + + + + + + +
Spark Sistemas
   - presentado por IWCC Argentina S.A.
   Tel: 4702-1958
   e-mail: [EMAIL PROTECTED]
+ + + + + + + + + + + + + + + + + + + +




Of course you might have to send _yourself_ a message so that you are
guaranteed to always have mail to receive. *wink*

----- Original Message -----
>From: Eric Dahnke <[EMAIL PROTECTED]>
>
> Sure just put fetchmail or your pop application before serialmail in
> your ppp/ip-up scripts.
>
> - Eric
>
> Andreas Fiedler escribió:
> >
> > Hi,
> >
> > I have a problem with sending mail (of course :-)
> >
> > My new provider uses SMTP-after-POP. This means I have to receive Mail
via POP
> > before I can send outgoing mail. The provider uses it to reduce
spammers.
> >
>





not at all.

You just want to check for mail, before you send mail.

-----Original Message-----
From: Paul Gilmore [mailto:[EMAIL PROTECTED]]
Sent: Saturday, October 02, 1999 5:33 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Auth. SMTP-after-POP


Of course you might have to send _yourself_ a message so that you are
guaranteed to always have mail to receive. *wink*

----- Original Message -----
>From: Eric Dahnke <[EMAIL PROTECTED]>
>
> Sure just put fetchmail or your pop application before serialmail in
> your ppp/ip-up scripts.
>
> - Eric
>
> Andreas Fiedler escribió:
> >
> > Hi,
> >
> > I have a problem with sending mail (of course :-)
> >
> > My new provider uses SMTP-after-POP. This means I have to receive Mail
via POP
> > before I can send outgoing mail. The provider uses it to reduce
spammers.
> >
>






I am trying to run qmail on my firewall.  Until now we were picking up
the mail by pop using fetchmail.  

qmail on the sending machine tells me that the firewall started to
respond, then dropped.  When I telnet from inside the firewall to port
25 it works fine.

When I telnet to port 25 from outside the firewall I get:

Trying x.x.x.x...
Connected to [servername].
Escape character is '^]'.
Connection closed by foreign host.

Here is how tcpserver and qmail are started:
        /usr/local/bin/tcpserver \
           -x /etc/tcp.smtp.cdb \
           -u 91 -g 90 0 smtp \
           /var/qmail/bin/qmail-smtpd &

I know we should be using private ip addresses inside, but we are not
(blame it on the previous administration), and this should not cause
this problem.  We want people on the inside (the 100 network) to be
able to use the firewall as a relay...and that works.
Here is the content of tcp.smtp which holds the rules compiled to
tcp.smtp.cdb:
:deny
127.0.0.1:allow,RELAYCLIENT=""
100.0.:allow,RELAYCLIENT=""

I have the domain I am accepting mail for in locals.
I have the domain I am accepting mail for in rcpthosts.
I do not think that my ipfwadm commands are stopping it.

Am I missing something?

If you need the machine name to look at it from the outside let me
know.

Thanks.
  --  Ed Weinberg,
      Detel, Inc., An Internet Presence Provider
      [EMAIL PROTECTED]




The problem is your first line in tcp.smtp.cdb.  Remove the :deny.  You
want to allow the connections but NOT set the RELAYCLIENT environment
variable which is the default behaviour.

On Fri, 1 Oct 1999, Ed Weinberg wrote:

> I am trying to run qmail on my firewall.  Until now we were picking up
> the mail by pop using fetchmail.  
> 
> qmail on the sending machine tells me that the firewall started to
> respond, then dropped.  When I telnet from inside the firewall to port
> 25 it works fine.
> 
> When I telnet to port 25 from outside the firewall I get:
> 
> Trying x.x.x.x...
> Connected to [servername].
> Escape character is '^]'.
> Connection closed by foreign host.
> 
> Here is how tcpserver and qmail are started:
>         /usr/local/bin/tcpserver \
>            -x /etc/tcp.smtp.cdb \
>            -u 91 -g 90 0 smtp \
>            /var/qmail/bin/qmail-smtpd &
> 
> I know we should be using private ip addresses inside, but we are not
> (blame it on the previous administration), and this should not cause
> this problem.  We want people on the inside (the 100 network) to be
> able to use the firewall as a relay...and that works.
> Here is the content of tcp.smtp which holds the rules compiled to
> tcp.smtp.cdb:
> :deny
> 127.0.0.1:allow,RELAYCLIENT=""
> 100.0.:allow,RELAYCLIENT=""
> 
> I have the domain I am accepting mail for in locals.
> I have the domain I am accepting mail for in rcpthosts.
> I do not think that my ipfwadm commands are stopping it.
> 
> Am I missing something?
> 
> If you need the machine name to look at it from the outside let me
> know.
> 
> Thanks.
>   --  Ed Weinberg,
>       Detel, Inc., An Internet Presence Provider
>       [EMAIL PROTECTED]
> 

---------------------------------
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 running qmail on a solaris box. For some reason users other than
root can't send mail. I followed the INSTALL.ids file but to no avail.
Also, I've setup qmail twice on FreeBSD boxes with no problems at all.
The only thing I noticed that was weird was that the solaris box doesn't
have a A Name record to it. It's listed in the SOA record as domain.net
without a hostname. I thought that mail servers require canonical name
records but qmail will send only as root. Does anyone know what I'm
doing wrong? I get this error: qmail-inject: fatal: read error. Also,
Most programs automatically goto /usr/lib/sendmail or /usr/sbin/sendmail
which is why we link them to /var/qmail/bin/sendmail. But how come I
can't send mail from this binary?



-- 
Darren Foo




Darren Foo <[EMAIL PROTECTED]> writes:
| I get this error: qmail-inject: fatal: read error. 

It's too bad that it doesn't print useful context with error messages,
but you can probably find out where it is failing by running
qmail-inject and /usr/lib/sendmail under ``truss -f''.





Oct  2 00:52:18 ult qmail: 938825538.614975 delivery 13: deferral:
Unable_to_open_.qmail:_access_denied._(#4.3.0)/
Oct  2 00:52:18 ult qmail: 938825538.615167 status: local 0/10 remote
0/20

        This is what I get in my logs. Is 4.3.0 error a read execution
permission error?


Scott Schwartz wrote:
> 
> Darren Foo <[EMAIL PROTECTED]> writes:
> | I get this error: qmail-inject: fatal: read error.
> 
> It's too bad that it doesn't print useful context with error messages,
> but you can probably find out where it is failing by running
> qmail-inject and /usr/lib/sendmail under ``truss -f''.

-- 
Darren Foo
===========================
WebCT Canada
Information and Communication Systems




Greetings to everyone

How can I make qmail stop receiving  large mails.

Thanks



Reply via email to