qmail Digest 25 Sep 1999 10:00:00 -0000 Issue 770
Topics (messages 30815 through 30853):
Re: APOP question
30815 by: Vince Vielhaber
HELP! Spammers!
30816 by: Tero Niemi
30817 by: Van Liedekerke Franky
Re: Return Receipts
30818 by: Toni Mueller
Re: Kurt's Closet on qmail
30819 by: Toni Mueller
30823 by: Petr Novotny
Re: qmail startup
30820 by: schinder.leprss.gsfc.nasa.gov
30826 by: Dave Sill
ALRM and ongoing deliveries?
30821 by: Toni Mueller
30838 by: Racer X
30839 by: Dave Sill
Re: daemontools-0.53 not available in LWQ site
30822 by: Dave Sill
30824 by: Dave Sill
Warning message earlier than in 12 hours?
30825 by: Toni Mueller
30827 by: Eric Dahnke
High volume - help!
30828 by: Alexis S. Panagides
30840 by: Dave Sill
Re: A patched qmail-smtpd.c
30829 by: Fred Lindberg
30843 by: Roger L Soles
30844 by: Racer X
qmail source and licensing question
30830 by: Eric Dahnke
30831 by: Mullen, Patrick
30832 by: Vince Vielhaber
30833 by: Mullen, Patrick
30836 by: Russell Nelson
qmail startup errors
30834 by: Franklin A Hays
30835 by: Dave Sill
Re: cyclog and daily logs
30837 by: Russell Nelson
30841 by: thomas.erskine-dated-0e24cc34663de5b6.crc.ca
Re: When will qmail back off to the next MX?
30842 by: Ruben van der Leij
30845 by: Pavel Kankovsky
30846 by: Jon Rust
30847 by: Racer X
30851 by: phil.ipal.net
30852 by: phil.ipal.net
30853 by: phil.ipal.net
Re: Sqwebmail and IMAP
30848 by: Russell Nelson
30850 by: Sam
Re: Qmail book
30849 by: Russell Nelson
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To bug my human owner, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
On Fri, 24 Sep 1999, Ludovic Kuty wrote:
> Hello,
>
> I'd like to know if it is possible to do that:
> I have a mail server that keeps mails in /var/spool/mail.
> Clients should be able to get mails with fetchmail using the
> APOP protocol.
>
> I thought qmail could be a pop server with qmail-pop3d (with
> customized checkpassword for APOP) but it seems to work only with
> the maildir system which I want to avoid. So I turned towards qpopper
> which supports APOP. But when I launched 'configure', the script stoppped
> and said that the sendmail program cannot be located. But I want it to use
> qmail instead.
>
> So what should I do ?
Have you installed qmail? If you have, it comes with a sendmail program.
Depending on the OS you're using, make a link to it from either /usr/sbin,
/usr/lib or /usr/ucblib and rerun configure.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null
# include <std/disclaimers.h> Have you seen http://www.pop4.net?
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
I configured our mailserver not to accept mail from outside IP's,
but
spammers still get through. They send mail like
[EMAIL PROTECTED]
How to prevent these coming?
Help needed quick! I had to drive our server down till I can do
something about this...
It seems you're being an open relay, if they can get away with
[EMAIL PROTECTED]
How is your tcpserver configured? Do you have an rcpthosts control file?
> ----------
> From: Tero Niemi[SMTP:[EMAIL PROTECTED]]
> Sent: Friday, September 24, 1999 1:53 PM
> To: qmail
> Subject: HELP! Spammers!
>
> I configured our mailserver not to accept mail from outside IP's,
> but
> spammers still get through. They send mail like
> [EMAIL PROTECTED]
>
> How to prevent these coming?
>
> Help needed quick! I had to drive our server down till I can do
> something about this...
>
Hello,
On 09/14/1999 16:27 -0400, Thomas Blauvelt ([EMAIL PROTECTED]) wrote:
> On Mon, 13 Sep 1999, Anand Buddhdev wrote:
> > man qreceipt
>
> Yes, but is anyone sucessfully using this?
what is successful usage in your opinion? If the program doesn't
crash or pose similar problems, this is successful enough for me.
> Are there any mailers which use the necessary
> Notice-Requested-Upon-Delivery-To header field?
Well, I wanted an unconditional reply, w/o any special headers, to anybody
who sends me mail. So I made the following patch to qreceipt.c (qmail-1.03,
what is qmail-1.04 anyway?):
$ rcsdiff -u qreceipt.c
===================================================================
RCS file: RCS/qreceipt.c,v
retrieving revision 1.1
diff -u -r1.1 qreceipt.c
--- qreceipt.c 1999/09/24 10:51:26 1.1
+++ qreceipt.c 1999/09/24 12:15:40
@@ -111,6 +111,10 @@
if (!stralloc_copy(&messageid,h)) die_nomem();
break;
case H_NOTICEREQUESTEDUPONDELIVERYTO:
+ case H_TO:
+ case H_CC:
+ case H_BCC:
+ case H_APPARENTLYTO:
doordie(h,token822_parse(&hfin,h,&hfbuf));
doordie(h,token822_addrlist(&hfrewrite,&hfaddr,&hfin,rwnotice));
break;
This sends me a DELIVERY SUCCESS -story any time I get a mail...
I think this can be easily customized using hfield.[ch], but have
not tested this.
Regards,
Toni.
-------- NIC: TM2155
Oeko.neT Mueller & Brandt GbR sales: [EMAIL PROTECTED]
v: +49 2261 979364 f: +49 2261 979366 http://www.oeko.net
Unix, networking, administration, consulting, programming, Internet services
Hello,
while having explicit permission for item XYZ, I decided that
the following page and related pages on Dan's site should be
sufficient:
ftp://koobera.math.uic.edu/www/rights.html
On 09/15/1999 13:12 +0100, Petr Novotny ([EMAIL PROTECTED]) wrote:
> It's nice that you know the licence for qmail-1.03.tar.gz - but this
> package per se is somewhat unuseful. What's the licence for
> tcpserver?
Any comments are very welcome!
Regards,
Toni.
-------- NIC: TM2155
Oeko.neT Mueller & Brandt GbR sales: [EMAIL PROTECTED]
v: +49 2261 979364 f: +49 2261 979366 http://www.oeko.net
Unix, networking, administration, consulting, programming, Internet services
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 24 Sep 99, at 15:21, Toni Mueller wrote:
> Hello,
>
> while having explicit permission for item XYZ, I decided that
> the following page and related pages on Dan's site should be
> sufficient:
>
> ftp://koobera.math.uic.edu/www/rights.html
We're beating a dead horse; reading a document (source code if
you wish) is certainly different from compiling and running it.
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2 -- QDPGP 2.60
Comment: http://community.wow.net/grt/qdpgp.html
iQA/AwUBN+uTl1MwP8g7qbw/EQJTPACbB7oKugMQAQU0yBvWjFx2SsBpIZgAoJ/0
co2Xl4petdCuU8+7b3EhTcjH
=YkCi
-----END PGP SIGNATURE-----
--
Petr Novotny, ANTEK CS
[EMAIL PROTECTED]
http://www.antek.cz
PGP key ID: 0x3BA9BC3F
-- Don't you know there ain't no devil there's just God when he's drunk.
[Tom Waits]
On Fri, Sep 24, 1999 at 12:05:18AM -0500, Franklin A Hays wrote:
}
} i am getting closer, have some more questions for everyone (really
} appreciate the help thus far). I commented out the sendmail startup
} daemon in rc.M and then added the following to rc.local:
} if [ -x /var/qmail/rc ]; then
} echo "Starting qmail daemon ..."
} bash -r -c 'var/qmail/rc &'
You're missing a / here. /var/qmail/rc. That may be one reason.
I thought Dan said to use csh here? If you have csh, try it. bash,
especially in restricted shell mode, just may act like old Bourne sh,
and the child may get killed as soon as the parent dies. But I don't
know enough about bash to know for sure.
} fi
}
} yet when I restart I have no mail capabilities (i.e. qmail isn't working
} and sendmail is disabled). My startup script (qmail) is in /var/qmail.
} When I check syslog there are no errors (no 'status' or 'cannot start'
} from qmail-send or anything else). No errors reported in error_log
} either. there are also no qmail daemons running. when i try a
} local-local test (echo to: me | /var/qmail/bin/qmail-inject) and get no
} response in syslog or my mailbox------qmail is not running.
}
} Thus, I have qmail installed yet it is not running. i know it could be a
} million things, but what do i go now??? troubleshooting...
}
} -frank
} -------------------------------------------------------------------------------
} [EMAIL PROTECTED]
} http://spin.biochem.okstate.edu/~frank
} -------------------------------------------------------------------------------
}
}
--
Paul J. Schinder
NASA Goddard Space Flight Center
[EMAIL PROTECTED]
Franklin A Hays <[EMAIL PROTECTED]> wrote:
>i am getting closer, have some more questions for everyone (really
>appreciate the help thus far). I commented out the sendmail startup
>daemon in rc.M and then added the following to rc.local:
>if [ -x /var/qmail/rc ]; then
>echo "Starting qmail daemon ..."
>bash -r -c 'var/qmail/rc &'
>fi
That should be:
if [ -x /usr/local/sbin/qmail ]; then
echo "Starting qmail..."
/usr/local/sbin/qmail start
fi
I'll update LWQ with Slackware directions ASAP. Sorry about that.
-Dave
Hello,
the qmail-send page says that sending it an ALRM makes it re-scan the
queue. Well, somebody demanded that his qmail-send gets ALRMed every
15 minutes to minimize mail delivery time. BUT: He has a slow link
and queued some 20+ megs of mail at once, in pieces around 3-7 meg each.
His mail got NOT delivered for over a day while the link was constantly
glowing. When I stopped that cron job the mail was out in about an
hour. The exact command this cronjob executes is
/usr/local/bin/svc -a /var/qmail/run/qmail
So what gives? Did I assume correctly that sending the ALRM interrupted
the ongoing transfers and restarted them? The log file mentions
"SMTP connection died" several times... If so, how do I have the
queue run every 15 minutes w/o disturbing the deliveries already
in progress? This is qmail-1.03 with daemontools-0.53 and
ucspi-tcp-0.84.
"Stay tuned for more tuning questions" :-|
Thank you!
Regards,
Toni.
-------- NIC: TM2155
Oeko.neT Mueller & Brandt GbR sales: [EMAIL PROTECTED]
v: +49 2261 979364 f: +49 2261 979366 http://www.oeko.net
Unix, networking, administration, consulting, programming, Internet services
if he's demanding that you run the queue every 15 minutes, that would seem
to suggest that he's permanently connected, in which case i'm wondering why
the mail isn't delivered directly to his machine.
assuming that's not possible though, i'm pretty sure that if you're acting
as MX for him, your own qmail process should attempt to deliver mail
immediately after it's placed in the queue. if for some reason delivery
fails initially, qmail will retry according to its retry schedule.
or am i missing something here?
shag
=====
Judd Bourgeois | CNM Network +1 (805) 520-7170
Software Architect | 1900 Los Angeles Avenue, 2nd Floor
[EMAIL PROTECTED] | Simi Valley, CA 93065
Quidquid latine dictum sit, altum viditur.
----- Original Message -----
From: Toni Mueller <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Fri 24 Sep 1999 7.01
Subject: ALRM and ongoing deliveries?
>
>
> Hello,
>
> the qmail-send page says that sending it an ALRM makes it re-scan the
> queue. Well, somebody demanded that his qmail-send gets ALRMed every
> 15 minutes to minimize mail delivery time. BUT: He has a slow link
> and queued some 20+ megs of mail at once, in pieces around 3-7 meg each.
> His mail got NOT delivered for over a day while the link was constantly
> glowing. When I stopped that cron job the mail was out in about an
> hour. The exact command this cronjob executes is
>
> /usr/local/bin/svc -a /var/qmail/run/qmail
>
> So what gives? Did I assume correctly that sending the ALRM interrupted
> the ongoing transfers and restarted them? The log file mentions
> "SMTP connection died" several times... If so, how do I have the
> queue run every 15 minutes w/o disturbing the deliveries already
> in progress? This is qmail-1.03 with daemontools-0.53 and
> ucspi-tcp-0.84.
>
> "Stay tuned for more tuning questions" :-|
>
> Thank you!
>
>
> Regards,
>
> Toni.
>
> -------- NIC: TM2155
> Oeko.neT Mueller & Brandt GbR sales: [EMAIL PROTECTED]
> v: +49 2261 979364 f: +49 2261 979366 http://www.oeko.net
> Unix, networking, administration, consulting, programming, Internet
services
>
>
[EMAIL PROTECTED] wrote:
>the qmail-send page says that sending it an ALRM makes it re-scan the
>queue. Well, somebody demanded that his qmail-send gets ALRMed every
>15 minutes to minimize mail delivery time.
That's ignorant. qmail tries to deliver messages immediately. Messages
sitting in the queue are there for one of two reasons:
1) the previous delivery attempt failed
2) qmail hasn't had a chance to send the message yet
In the case of (1), the best policy is almost always to allow qmail to
retry the message according to its own schedule. If this user is on a
part-time connection, you should use serialmail's
maildir2smtp/AutoTURN to send the messages when the connection comes
up. In the case of (2), ALRM qmail-send won't speed anything up
because qmail is already going as fast as it can.
>BUT: He has a slow link
>and queued some 20+ megs of mail at once, in pieces around 3-7 meg each.
>His mail got NOT delivered for over a day while the link was constantly
>glowing.
No messages were delivered?
>When I stopped that cron job the mail was out in about an
>hour. The exact command this cronjob executes is
>
>/usr/local/bin/svc -a /var/qmail/run/qmail
>
>So what gives? Did I assume correctly that sending the ALRM interrupted
>the ongoing transfers and restarted them?
No.
>The log file mentions "SMTP connection died" several times...
That means the other end hung up.
>If so, how do I have the queue run every 15 minutes w/o disturbing
>the deliveries already in progress?
I think the problem is that the ALRM is causing too many qmail-remotes
to talk to the remote system at once, so it's choking.
qmail isn't designed to do deliveries on a fixed schedule. The ALRM
hack is intended for occasional use only.
-Dave
Patrick Berry <[EMAIL PROTECTED]> wrote:
>daemontools have moved up a version. Since LWQ is written for use
>with 0.53 and I found it easier to grab an rpm of daeomontools, but
>still do the regular qmail source install.
Daemontools 0.53 is still available from koobera using the link in
LWQ:
ftp://koobera.math.uic.edu/www/daemontools/daemontools-0.53.tar.gz
Daemontools 0.61 will *NOT* work with the LWQ qmail control script.
LWQ now contains the following:
-------------------------------------------------------------------------------
Note: Although the latest version of daemontools is 0.61, 0.53 is
still available and adequate for our purposes. The user interface
changed substantially in 0.60, and these instructions will only work
right with 0.53.
-------------------------------------------------------------------------------
-Dave
"Timothy L. Mayo" <[EMAIL PROTECTED]> wrote:
>It's at ftp://koobera.math.uic.edu/www/daemontools/daemontools-0.53.tar.gz
>
>You will most likely need to use an FTP tool instead of a web browser to
>see it.
No, I've downloaded it with IE 5 and Navigator 4.61. Some browsers
have trouble navigating koobera by FTP, but I haven't had any trouble
with links to partiticular files.
-Dave
Hello,
a few days ago I received a message that qmail was unable to send a
message within the last 12 hours. How do I tune this except for
patching the source code?
Thank you!
Regards,
Toni.
-------- NIC: TM2155
Oeko.neT Mueller & Brandt GbR sales: [EMAIL PROTECTED]
v: +49 2261 979364 f: +49 2261 979366 http://www.oeko.net
Unix, networking, administration, consulting, programming, Internet services
I believe that qmail does not produce such messages, rather they are
generated by a third party application running in conjunction with
qmail. I believe there are 2 such applications on the qmail site, and
both are written in perl therefore making a change to the functionality
rather simple if you know a bit of perl.
- eric
Toni Mueller escribió:
>
> Hello,
>
> a few days ago I received a message that qmail was unable to send a
> message within the last 12 hours. How do I tune this except for
> patching the source code?
>
> Thank you!
>
> Regards,
>
> Toni.
>
> -------- NIC: TM2155
> Oeko.neT Mueller & Brandt GbR sales: [EMAIL PROTECTED]
> v: +49 2261 979364 f: +49 2261 979366 http://www.oeko.net
> Unix, networking, administration, consulting, programming, Internet services
--
+ + + + + + + + + + + + + + + + + + + +
Spark Sistemas
- presentado por IWCC Argentina S.A.
Tel: 4702-1958
e-mail: [EMAIL PROTECTED]
+ + + + + + + + + + + + + + + + + + + +
Hello,
For some time we have been offering a free email redirection service. Due
to some recent press it has suddenly picked up and we are registering more
than 100 users / day. The way we have it set up is using a database lookup
of the evelope recipient and then redirecting via |/var/qmail/bin/forward
to the users real email address.
Everything was running great until a couple weeks ago. We now have around
20 thousand accounts and at times email rerouting is getting slow.
Yesterday was a good example. I noticed that the queue was getting over the
2000 mark and kept growing. When I sent email to a test account I maintain
(that delivers to the same network) my email would experience tremendous
delays (two hours) before being delivered.
My basic question is how can I increase the throughput of my Qmail 1.03
installation?
What I have done:
I have both concurrencylocal and concurrencyremote set to 120. But most of
the time qmail has around 10 qmail-remote processes going. Every now and
again I give it the ALRM signal and that shoots up the processes but then
eventually things back down to the around 10 level.
A week or so ago I added the big-todo.patch although I am not really sure
what it does. I didn't really see an improvement.
I have tcpserver at -c80 for qmail-smtpd.
One thing I find discouraging is when the queue inflates and a new email
(my test email) gets sent in there is a delay. It is as if the queue really
is a queue in the FIFO sense.
In a moment of desperation I installed zmailer to handle the outbound
transmission of new emails. That seemed to solve some queue problems but
zmailer soon brought my machine to its knees by eating all the memory,
despite resource limits in its config files.
Is there anything more than I can do or strategies I could persue?
Something I missed?
Advice would be greatly appreciated!
Many thanks,
Alex Panagides
Ceará, Brazil
PS. Platform: Debian/Linux 2.1, (2.2.10) Pentium 233, 160Mb SDRAM
"Alexis S. Panagides" <[EMAIL PROTECTED]> wrote:
>My basic question is how can I increase the throughput of my Qmail 1.03
>installation?
Easy: locate the bottleneck and remove it. :-)
>I have both concurrencylocal and concurrencyremote set to 120. But most of
>the time qmail has around 10 qmail-remote processes going.
If you only have 10 qmail-remotes running, but 2000+ queued remote
messages, something is seriously wrong. You need to open your sysadmin
toolkit and get under the hood. Are you CPU bound? Not likely. I/O
bound? Probably. N/W bound? Possibly? Run top, vmstat, iostat,
etc. until you can identify the critical resource.
>Every now and
>again I give it the ALRM signal and that shoots up the processes but then
>eventually things back down to the around 10 level.
Huh. From that, it sounds like you don't really have a problem. But
you said a test message took 2 hours, so something is definitely not
right. Did you trace your test message through the logs?
>A week or so ago I added the big-todo.patch although I am not really sure
>what it does. I didn't really see an improvement.
Oops. One shouldn't patch qmail, or any other system, for that matter,
unless one knows what the patch does.
>I have tcpserver at -c80 for qmail-smtpd.
Your problem is outgoing throughput, not incoming.
>One thing I find discouraging is when the queue inflates and a new email
>(my test email) gets sent in there is a delay. It is as if the queue really
>is a queue in the FIFO sense.
It *is* a queue. qmail-send can't do infinite work instantaneously. If
there's more work than it can handle, waiting jobs queue up.
Have you run qmailanalog?
-Dave
On Fri, 24 Sep 1999 16:48:26 +0800, Hotdog wrote:
> I have added some codes into qmail-smtpd.c, now it can do something funny:
As far as I can see, you've also added a potential buffer overflow bug
for "word". Admittedly, you need to be able to write control/badip in
order to exploit it.
-Sincerely, Fred
(Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
I can give you a good point on #2 why it should be done by QMAIL-SMTP rather
than TCPSERVER -- if you want to inhibit *all* connection from known SPAMmer
IP blocks _except_ where the sender can do SMTP-AUTH... TCPSERVER has no way
of handling this... Also, TCPSERVER doesn't provide SMTP error messages
back (you can modify it fairly easily to allow QMAIL-SMTP to send the error
message on it's behalf, and do tar pitting, etc etc etc).
And, speaking from experience, putting a patch together sounds easy, but
isn't always that simple. I run QMAIL with a fair number of changes that
are of little interest to most people; building a patch is a little more
tedious when it needs to be able to be applied to a generic QMAIL
distribution. Don't get me wrong, PATCHES are the right way -- but
sometimes providing the modified source is the most expedient to get
comments from others and allow them access to your work.
If *one* implementation of a mail program was right for everyone, we'd still
be running sendmail...
- Roger
----- Original Message -----
From: Petr Novotny <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 24, 1999 3:17 AM
Subject: Re: A patched qmail-smtpd.c
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I am not saying it's a bad idea, but a few things need to be pointed
> out:
> 1. It's usual to publish a patch, not a patched source.
> 2. The badip idea seems confusing; why shouldn't tcpserver or
> inetd take care about that? After all, qmail-smtpd might just as well
> read from the keyboard/file instead of socket.
> 3. If you're saying "no" in SMTP, it can't be with a code 221. It
> must be 4xx (temporary) or 5xx (permanent).
> 4. What's the silly idea of saying "no" to vrfy? "maybe" is much
> better.
>
> But again, I am not saying your ideas are wrong - I'm only saying I
> don't like them :-)
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 6.0.2 -- QDPGP 2.60
> Comment: http://community.wow.net/grt/qdpgp.html
>
> iQA/AwUBN+tPpFMwP8g7qbw/EQLvVgCg4VXi3cmAy/ncQ1AwhAse7XjlRSYAoL5S
> JwTC8Quy4RnLKTg9EeXvXw5p
> =W4RB
> -----END PGP SIGNATURE-----
> --
> Petr Novotny, ANTEK CS
> [EMAIL PROTECTED]
> http://www.antek.cz
> PGP key ID: 0x3BA9BC3F
> -- Don't you know there ain't no devil there's just God when he's drunk.
> [Tom Waits]
>
> I can give you a good point on #2 why it should be done by QMAIL-SMTP
rather
> than TCPSERVER -- if you want to inhibit *all* connection from known
SPAMmer
> IP blocks _except_ where the sender can do SMTP-AUTH... TCPSERVER has no
way
> of handling this... Also, TCPSERVER doesn't provide SMTP error messages
> back (you can modify it fairly easily to allow QMAIL-SMTP to send the
error
> message on it's behalf, and do tar pitting, etc etc etc).
yes, tarpitting has to be done in qmail-smtpd, but using tarpitting implies
that you're still accepting the mail. if you're not going to accept the
mail anyway, why bother allowing the connection to succeed and then closing
it? tcpserver will catch the IP blocks and just refuse the connection.
smtp-auth isn't exactly a reason to move the ip checking into qmail-smtpd.
if you're denying a net block unless they use smtp-auth, you aren't gaining
anything - anyone on that net block can spoof the connection. if you want
real security use ssh and forward ports.
> And, speaking from experience, putting a patch together sounds easy, but
> isn't always that simple. I run QMAIL with a fair number of changes that
> are of little interest to most people; building a patch is a little more
> tedious when it needs to be able to be applied to a generic QMAIL
> distribution. Don't get me wrong, PATCHES are the right way -- but
> sometimes providing the modified source is the most expedient to get
> comments from others and allow them access to your work.
bah. "man diff" - it's fairly straightforward. if you intend to distribute
your patches you should be building them and running diff's off of a
pristine qmail install. otherwise there could be hidden conflicts between
your changes and some other patch you've installed.
shag
=====
Judd Bourgeois | CNM Network +1 (805) 520-7170
Software Architect | 1900 Los Angeles Avenue, 2nd Floor
[EMAIL PROTECTED] | Simi Valley, CA 93065
Quidquid latine dictum sit, altum viditur.
Hello List,
If a one modifies any of the code associated with qmail. Are they
obligated to make available the modifications to the qmail community.
OT: Is the above true of GPL when talking about GPLd sources?
Regards - Eric
> If a one modifies any of the code associated with qmail. Are they
> obligated to make available the modifications to the qmail community.
>
Not at all, as long as you keep it to yourself.
If you modify qmail (or any GPL'd product) and
you want to distribute the results as your own
prduct, you must put the new product under the
GPL with all sources (both qmail's and your
own) available to any who request it.
That being said, if you make any improvements
upon the existing product that you feel others
may find useful, you may want to support the
spirit of Open Source and make your patches
available for others to use.
~Patrick
On Fri, 24 Sep 1999, Mullen, Patrick wrote:
> > If a one modifies any of the code associated with qmail. Are they
> > obligated to make available the modifications to the qmail community.
> >
>
> Not at all, as long as you keep it to yourself.
> If you modify qmail (or any GPL'd product) and
> you want to distribute the results as your own
> prduct, you must put the new product under the
> GPL with all sources (both qmail's and your
> own) available to any who request it.
qmail is NOT under GPL.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null
# include <std/disclaimers.h> Have you seen http://www.pop4.net?
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
> qmail is NOT under GPL.
My apologies. I had assumed Eric did his
homework and took his statement as gospel.
Well, you know what they say about when
you ass-u-me something... ;-)
~Patrick
Eric Dahnke writes:
> Hello List,
>
> If a one modifies any of the code associated with qmail. Are they
> obligated to make available the modifications to the qmail community.
No. You can distribute a patch if you want, but you are under no
obligation to. You *are* under an obligation not to distribute
modified source or binary code.
> OT: Is the above true of GPL when talking about GPLd sources?
Only if you distribute the code.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
First off, yes, the previous script was missing a '/' in front of /var,
and second, I made the changes Dave suggested to rc.local. I commented
out sendmail startup script in rc.M.
the script I now have in rc.local is as follows:
if [ -x /usr/local/sbin/qmail ]; then
echo "Starting qmail daemon ..."
/usr/local/sbin/qmail start
fi
and my startup/shutdown script, 'qmail', from lwq is in /usr/local/sbin.
Errors reported in syslog are as follows:
Sep 24 10:20:37 ultrascan afpd[311]: Can't register ultrascan:AFPServer@*
Sep 24 10:30:14 ultrascan inetd[290]: auth/tcp: bind: Address already in
use
Sep 24 10:30:14 ultrascan inetd[290]: finger/tcp: bind: Address already in
use
Sep 24 10:30:14 ultrascan inetd[290]: imap2/tcp: bind: Address already in
use
Sep 24 10:30:14 ultrascan inetd[290]: pop3/tcp: bind: Address already in
use
Sep 24 10:30:14 ultrascan inetd[290]: login/tcp: bind: Address already in
use
Sep 24 10:30:14 ultrascan inetd[290]: shell/tcp: bind: Address already in
use
Sep 24 10:30:14 ultrascan inetd[290]: telnet/tcp: bind: Address already in
use
Sep 24 10:30:14 ultrascan inetd[290]: ftp/tcp: bind: Address already in
use
Sep 24 10:30:14 ultrascan inetd[290]: time/tcp: bind: Address already in
use
and in error_log the following
httpd: [Fri Sep 24 10:13:20 1999] [notice] caught SIGTERM, shutting down
httpd: [Fri Sep 24 15:15:59 1999] [notice] Apache/1.3.4 (Unix) configured
-- resuming normal operations
(neither of which tell me much about qmail errors)
upon restart of server sendmail is no longer running, as expected, yet
qmail is NOT running yet NO qmail daemons are running either.
Suggestions?? My limited knowledge has me stuck in a corner...
-thanks
frank
-------------------------------------------------------------------------------
[EMAIL PROTECTED]
http://spin.biochem.okstate.edu/~frank
-------------------------------------------------------------------------------
Franklin A Hays <[EMAIL PROTECTED]> wrote:
>Errors reported in syslog are as follows:
None refer to qmail, sendmail, or SMTP.
>upon restart of server sendmail is no longer running, as expected, yet
>qmail is NOT running yet NO qmail daemons are running either.
>Suggestions?? My limited knowledge has me stuck in a corner...
What does "/usr/local/sbin/qmail stat" say?
-Dave
Peter Samuel writes:
> The reson I'm doing it this way is that my log files are reasonably
> large (8Mb per day) and groking a big file every 5 minutes to extract
> a small section is loading up the system a bit too much.
That's why you use lots of little files (on average the same size as
the time period you wish to analyze, so that you need only examine 2X
the amount of data).
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
On Fri, 24 Sep 1999, Russell Nelson wrote:
> Peter Samuel writes:
> > The reson I'm doing it this way is that my log files are reasonably
> > large (8Mb per day) and groking a big file every 5 minutes to extract
> > a small section is loading up the system a bit too much.
>
> That's why you use lots of little files (on average the same size as
> the time period you wish to analyze, so that you need only examine 2X
> the amount of data).
That's one of the reasons why I wrote a logfile-server for remote
monitoring. It keeps track of where it last read to and only extracts the
remaining part of the file. It's not perfect, but it works fine for my
purposes.
> --
> -russ nelson <[EMAIL PROTECTED]> http://russnelson.com
> Crynwr sells support for free software | PGPok | Government schools are so
> 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
> Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
>
--
"Life is much too important to be taken seriously."
Thomas Erskine <[EMAIL PROTECTED]> (613) 998-2836
On Thu, Sep 23, 1999 at 11:09:08PM -0400, Russell Nelson wrote:
> Because it's reasonable to expect that other MX records will work for
> 1+2, but not for 3. If the lowest priority MX record is screwed up,
> why aren't the others as well?
If one MX has a screwed up binary, it is likely that other MX's have a
corrupted binary too? I fail to see the reasoning behind that. By the way,
the *lowest* prefence is used first. If the host is down, the higher MX's
are tried.
--
Ruben
--
Eat more memory!
On Thu, 23 Sep 1999, Russell Nelson wrote:
> Because it's reasonable to expect that other MX records will work for
> 1+2, but not for 3. If the lowest priority MX record is screwed up,
> why aren't the others as well?
How does the way the 1st MX fails to accept the message affect the working
of other MXes (in a general case)?
> Essentially what we're dancing around is the issue of deliberate
> misconfiguration in an effort to save sysadmin time: "It's hard work to
> set up split DNS. Why not just have a low numbered MX record for
> internal hosts, and a higher numbered record for external hosts? It
> works for sendmail, so it should work for everything, right?"
This is irrelevant. Qmail has no problem with this particular product of
ignorancy unless it can somehow connect to the internal host and get
disconnected (or get a temporary error during the conversation).
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."
>> Essentially what we're dancing around is the issue of deliberate
>> misconfiguration in an effort to save sysadmin time: "It's hard work to
>> set up split DNS. Why not just have a low numbered MX record for
>> internal hosts, and a higher numbered record for external hosts? It
>> works for sendmail, so it should work for everything, right?"
>
>This is irrelevant. Qmail has no problem with this particular product of
>ignorancy unless it can somehow connect to the internal host and get
>disconnected (or get a temporary error during the conversation).
Agreed. In this case, all it was getting (correct me if I'm wrong)
was a TCP ack for the establishment, not an SMTP greeting. no
"conversation" ever happened. Hence qmail should not assume an SMTP
server is successfully running, and should drop back to secondary MX
record(s). If it got an SMTP greeting, maybe queuing the message
would be more correct, but it isn't.
>--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
>"Resistance is futile. Open your source code and prepare for assimilation."
Hey, cool link! (Maintained by one of my customers :-)
Jon
> How does the way the 1st MX fails to accept the message affect the working
> of other MXes (in a general case)?
if the first MX allows a connection to port 25, there is an implied
assumption that there is a program listening on port 25 that speaks SMTP.
therefore, the sender should attempt delivery.
the connection is never disconnected "immediately." assuming the connection
succeeds it must stay connected for some minimum length of time. it could
drop after 1 second with no traffic, or the SMTP transaction could get
halfway done and then the connection times out. let's say you send EHLO,
MAIL FROM, RCPT TO, and all is well, and you start your DATA but you never
get an ok from the remote. does that mean you should fall back to the next
MX?
anyway, until an RFC or something clarifies exactly different situations
should be handled i don't think it's particularly worthwhile to pick on
qmail for 1) "not doing it like sendmail does," and 2) not handling a broken
configuration in the way the breakers expect it to. say what you will about
qmail, the DNS configuration IS broken (and no i don't care how many people
do it that way - "everyone speeds" but that doesn't make it legal). until
we can agree that, yes, someone was lazy and should fix the DNS first, i
don't see the point in changing qmail's behavior.
shag
=====
Judd Bourgeois | CNM Network +1 (805) 520-7170
Software Architect | 1900 Los Angeles Avenue, 2nd Floor
[EMAIL PROTECTED] | Simi Valley, CA 93065
Quidquid latine dictum sit, altum viditur.
Racer X wrote:
> > How does the way the 1st MX fails to accept the message affect the working
> > of other MXes (in a general case)?
>
> if the first MX allows a connection to port 25, there is an implied
> assumption that there is a program listening on port 25 that speaks SMTP.
> therefore, the sender should attempt delivery.
Given that port 25 is established to be the standard port for SMTP, and is
shared for any other protocol, it is very reasonable to assume that the
protocol that should be conducted is SMTP. It would then follow that if a
connection was in fact achievable, then the destination host apparently does
intend to converse SMTP. A configuration of firewalls that causes the
connection to happen even though the destination is not willing (perhaps at
this time) to converse SMTP, is misleading at best. The firewall is
certainly badly implemented, and I would consider it to be broken.
> the connection is never disconnected "immediately." assuming the connection
> succeeds it must stay connected for some minimum length of time. it could
> drop after 1 second with no traffic, or the SMTP transaction could get
> halfway done and then the connection times out. let's say you send EHLO,
> MAIL FROM, RCPT TO, and all is well, and you start your DATA but you never
> get an ok from the remote. does that mean you should fall back to the next
> MX?
Does it mean you should not?
There are legitimate scenarios NOT involving broken firewalls, in which a
server could be trying to converse SMTP, but failing to do so for reasons
that may persist for an undetermined length of time. The internet protocols
were designed under a philosophy of making reasonable attempts to work
around failures. The host that fails to converse SMTP (despite the intent
to do so in the configuration, as view by the MX records in the DNS) is a
failure in the network.
A way to work around that failure is to try another MX host, if more than
one is present, guided by the priority information given. It may not be
mandatory to do so, but doing so is a way to work around failure. An
implementation that does not fall back to another MX is an implementation
that is not attempting to work around failure.
> anyway, until an RFC or something clarifies exactly different situations
> should be handled i don't think it's particularly worthwhile to pick on
> qmail for 1) "not doing it like sendmail does," and 2) not handling a broken
> configuration in the way the breakers expect it to. say what you will about
> qmail, the DNS configuration IS broken (and no i don't care how many people
> do it that way - "everyone speeds" but that doesn't make it legal). until
> we can agree that, yes, someone was lazy and should fix the DNS first, i
> don't see the point in changing qmail's behavior.
Doing things a certain way because sendmail does it that way is certainly
not a reasonable guide. Indeed, doing things a different way may well be
preferrable.
Which scenario are you referring to when you say "the DNS configuration IS
broken"? Are you referring to the scenario where the firewall is broken,
and just tossing this in to confuse the issue? Since when is having more
than one MX record for a host to be considered "broken" when one of the
hosts might be down?
Just because one scenario which Qmail could "work around" happens to be a
scenario which is either configured or implemented broken, does not mean
that no other scenarios can exist which would involve the same issue. Just
because one scenario represents a case which is not an interim failure does
not mean that every scenario is likewise.
Hosts do sometimes go down. They do sometimes fail. They do sometimes have
problems which, while not entirely crashing, do prevent the completion of a
protocol at ANY step along its defined path, including before and
immediately after the TCP connection is established. Even Qmail could fail
in such a way when running on a machine which has an interim problem
providing Qmail with the resources to complete execution (e.g. memory
exhausted). It's a failure. You might call it "broken" if you want. The
issue is whether or not it is worthwhile to attempt to work around the
failure.
--
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]
Jon Rust wrote:
> >> Essentially what we're dancing around is the issue of deliberate
> >> misconfiguration in an effort to save sysadmin time: "It's hard work to
> >> set up split DNS. Why not just have a low numbered MX record for
> >> internal hosts, and a higher numbered record for external hosts? It
> >> works for sendmail, so it should work for everything, right?"
> >
> >This is irrelevant. Qmail has no problem with this particular product of
> >ignorancy unless it can somehow connect to the internal host and get
> >disconnected (or get a temporary error during the conversation).
>
> Agreed. In this case, all it was getting (correct me if I'm wrong)
> was a TCP ack for the establishment, not an SMTP greeting. no
> "conversation" ever happened. Hence qmail should not assume an SMTP
> server is successfully running, and should drop back to secondary MX
> record(s). If it got an SMTP greeting, maybe queuing the message
> would be more correct, but it isn't.
Why should a failure at any point in the connection and conversation bias
the behaviour of deciding to, or not to, try another MX host? Why is that a
situation where an SMTP server is indeed running, but failure in mid course,
be any different than a connection refused, with regard to deciding if
another MX would be reasonable to attempt to communication with?
--
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]
Pavel Kankovsky wrote:
> > Because it's reasonable to expect that other MX records will work for
> > 1+2, but not for 3. If the lowest priority MX record is screwed up,
> > why aren't the others as well?
>
> How does the way the 1st MX fails to accept the message affect the working
> of other MXes (in a general case)?
I think this is a good question.
Some believe that if the 1st MX is failing, that the mail to the 2nd or 3rd
MX will not reach the destination any sooner. I believe this is due to a
mistaken belief that the 1st MX is the same as the ultimate destination host
when in fact it may not be.
> > Essentially what we're dancing around is the issue of deliberate
> > misconfiguration in an effort to save sysadmin time: "It's hard work to
> > set up split DNS. Why not just have a low numbered MX record for
> > internal hosts, and a higher numbered record for external hosts? It
> > works for sendmail, so it should work for everything, right?"
>
> This is irrelevant. Qmail has no problem with this particular product of
> ignorancy unless it can somehow connect to the internal host and get
> disconnected (or get a temporary error during the conversation).
Even if the split DNS setup were done, the situation is still problematic for
Qmail if it won't backoff to the 2nd MX. If the ultimate destination is
behind a correctly configured firewall (you can't get there directly at all)
and the DNS has no MX record pointing direct, but both the 1st and 2nd MX
hosts can get there (special tunnel), then in the case of a failure of the
1st MX host, the 2nd MX host would mean a successful delivery ... missed by
Qmail if it doesn't want to try it.
--
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]
D. J. Bernstein writes:
> Say you have a bunch of mboxes. You choose filenames for them. Of
> course, some filenames are prohibited:
>
> * You can't use the name .., because that's a directory.
> * You can't use the name /Mail, because you don't have permission.
> * You can't use the name Mailbox/2, because Mailbox is a file.
>
> But the complete list of restrictions is reasonably simple, and people
> don't seem to have much trouble dealing with a few special characters.
>
> Now change each mbox to a maildir. Whatever filenames worked with mbox
> will continue to work with maildir. You now have a bunch of maildirs.
> What exactly is the problem?
IMAP permits the name Mailbox/2. Feel free to argue that that's
stupid. It's just a drop in the bucket of stupidity which is IMAP.
Did I say stupidity? I mean another word beginning with s.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
On Fri, 24 Sep 1999, Russell Nelson wrote:
> IMAP permits the name Mailbox/2. Feel free to argue that that's
> stupid. It's just a drop in the bucket of stupidity which is IMAP.
> Did I say stupidity? I mean another word beginning with s.
IMAP may permit this name, in theory, but IMAP servers are free to reject
it.
I do believe that IMAP is an extremely moronic protocol, but for other
reasons, and this ain't it. How RFC 2060 reached the Standard status is a
complete mystery to me.
Kevin Waterson writes:
> Is there a qmail book?
Eventually there will be. Can you spell "ADD"? I knew you could, but
they don't give Ritalin to 40-year-old's.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
