qmail Digest 26 Jan 1999 11:00:14 -0000 Issue 532
Topics (messages 20922 through 20944):
tcpd and paranoid mode
20922 by: Cefiar <[EMAIL PROTECTED]>
Here's why mail to nonexistent users should be bounced.
20923 by: "Sam" <[EMAIL PROTECTED]>
20924 by: "Sam" <[EMAIL PROTECTED]>
Netscape and Maildir
20925 by: Peter van Dijk <[EMAIL PROTECTED]>
Why ignore virtualdomains lines w/o colon?
20926 by: "Lars Uffmann" <[EMAIL PROTECTED]>
ETRN support on Qmail
20927 by: "Matthew Schnierle" <[EMAIL PROTECTED]>
qmail-lint-0.50
20928 by: Russell Nelson <[EMAIL PROTECTED]>
configuration
20929 by: Cook <[EMAIL PROTECTED]>
QMAILQUEUE patch for qmail-1.03
20930 by: Bruce Guenter <[EMAIL PROTECTED]>
syslog.mail
20931 by: Samuel Dries-Daffner <[EMAIL PROTECTED]>
20932 by: "Sam" <[EMAIL PROTECTED]>
20933 by: Peter van Dijk <[EMAIL PROTECTED]>
20934 by: Justin Bell <[EMAIL PROTECTED]>
20935 by: Samuel Dries-Daffner <[EMAIL PROTECTED]>
20936 by: Peter van Dijk <[EMAIL PROTECTED]>
Using Example Domain Names in Exploits
20937 by: "Andrzej Kukula" <[EMAIL PROTECTED]>
getpwnam() bug in freebsd-2.2.8 affects qmail
20938 by: "Peter C. Norton" <[EMAIL PROTECTED]>
20939 by: Harald Hanche-Olsen <[EMAIL PROTECTED]>
20940 by: "Peter C. Norton" <[EMAIL PROTECTED]>
20941 by: "Paul J. Schinder" <[EMAIL PROTECTED]>
20944 by: "Peter C. Norton" <[EMAIL PROTECTED]>
zeroseek mailing list
20942 by: "D. J. Bernstein" <[EMAIL PROTECTED]>
qmail-pop3d/1.03 and RFC discrepancies
20943 by: Mark Delany <[EMAIL PROTECTED]>
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
At 02:15 25/01/99 -0800, Russ Allbery wrote:
>Stuart Young <[EMAIL PROTECTED]> writes:
>
>> Just a note that there is a CERT advisory about TCP wrappers at the
>> moment. It seems that it was replaced (trojan code) and isn't exactly
>> 'friendly' anymore.
>
>> http://www.cert.org/advisories/CA-99-01-Trojan-TCP-Wrappers.html
>
>Note that this only affects downloads from the main archive site over a
>fairly short period of time, and that all hosts downloading from that site
>over that time period have already been contacted. The canonical archive
>has also been moved to a new server.
True enough, but remember that the person asking why his system wasn't
working anymore 'since' he re-compiled his TCP Wrappers package. He didn't
mention wether it was a new version he'd just downloaded or not. I'd rather
point out a small, but possible problem like this, which could potentially
be serious, than not do and hear later that someone's system has been
compromised.
-=[ Stuart Young (Aka Cefiar) ]=--------------------------------------
| http://amarok.glasswings.com.au/ | [EMAIL PROTECTED] |
----------------------------------------------------------------------
| Hmm? What? Earth technology? Oh just thump it, that usually works. |
Peter Gradwell writes:
> At 5:57 am +0000 on 25/1/99, the great Sam wrote:
> >Instead, since I've patched it to refuse
> >E-mail to nonexistent local addresses, I'm just rejecting the RCPT TO: with
> >significant savings in bandwidth and time. I hardly need to do anything
> >about it, except watch the mail logs scroll, with some detached amusement.
>
> and what do us newbies need to do to achive this wonderful 'feature' as well?
Install my patch, you'll find a link to it on www.qmail.org.
Andy Smith writes:
> On Mon, 25 Jan 1999, Anand Buddhdev wrote:
>
> > Apply Sam's qmail-uce patches. Find them at:
> >
> > http://www.geocities.com/SiliconValley/Peaks/5799/qmail-uce.html
>
> Do the patches still allow mail to postmaster from anyone? Can't see any
> mention of it on the page, it's a feature I think I'd like.
Depends on how you set up the filters.
On Mon, Jan 25, 1999 at 04:36:23PM +0800, Steve Vertigan wrote:
> Anand Buddhdev wrote:
>
> > If the message file is owned by root, then it needs to have a minimum mode
> > of 444, ie. read access for everyone. In your case, the root-owned files
> > most likely have modes that don't allow the user to read the file. Remember
> > that qmail-pop3d runs under the permissions of the user, not root.
>
> Yes I'm aware of that and the permissions were set to readable only by owner as
> you'd expect email to be but I'm mystified that you said the user can delete message
> then that are owned by root if they own the directory. Are you saying I could've
> done a DELE on the messages even though I couldn't view them?
Yes.
Greetz, Peter.
--
<squeezer> AND I AM GONNA KILL MIKE | Peter van Dijk
<squeezer> hardbeat, als je nog nuchter bent: | [EMAIL PROTECTED]
<squeezer> @date = localtime(time); | realtime security d00d
<squeezer> $date[5] += 2000 if ($date[5] < 37); |
<squeezer> $date[5] += 1900 if ($date[5] < 99); | * blah *
On Mon, Jan 25, 1999 at 04:52:23AM -0000, Russell Nelson wrote:
> Why does qmail-send merely silently discard virtualdomains lines that
> have no colon? Isn't it likely that such a line is in error, and
> needs to be pointed out?
Due to the design of qmail-send, it's quite hard to report an error
in this case. rewrite() in qmail-send.c cannot even print a warning
to stderr. `not allowed to barf'... A possibility so, would be to
define a special address which could handle local configuration errors.
Example:
recipient address is `[EMAIL PROTECTED]'.
control/virtualdomains:
# the colon is missing, obviously a configuration error.
virtual.org
in qmail-send, rewrite the address to, hmmm, say
`[EMAIL PROTECTED]'.
Now ~alias/.qmail-trouble-virtualdomains could be used to handle the
error.
Anyway, most likely, the mail will bounce with the following error:
Sorry. Although I'm listed as a best-preference MX or A for that host,
it isn't in my control/locals file, so I don't treat it as local. (#5.4.6)
Background:
I tried to implement address rewriting in qmail-send based on an ldap
lookup, but I gave up on this because I was not able to handle errors
(and there are a plenty of possible errors that could occur during an ldap
lookup). The way it is implemented right now, does not allow any other lookup
mechanisms then in-memory based hash tables.
regards, Lars
On Mon, 25 Jan 1999, ������� ������������ wrote:
>
> Question for the experts out there:
>
> Qmail does not seem to support the ETRN function. Thus there is virtually
> no way for a remote SMTP dialup server to connect ot the net and
> emeediatelly request retrieval of the mails residing in the qmail queue for
> that server. Is there any fisible solution to the problem? Is there going to
> be ETRN support in future releases?
Two options:
There are patches for ETRN support on www.qmail.org.
Or, you can use the AUTOTURN package provided with Dan's serialmail package.
-Matthew Schnierle
[EMAIL PROTECTED]
-http://www.iup.edu/~pyld/
-Member, Programmers Local 1036--AFL-CPIO.
-Join the fight. http://www.cauce.org
I've uploaded qmail-lint-0.50 to www.qmail.org. It checks for common
problems in your qmail control files. If you try it, and it prints
something you don't understand, or you think is not a problem, send me
email. Or if it misses a known problem, I'd also to hear about that
as well.
--
-russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson
Crynwr supports Open Source(tm) Software| PGPok | There is good evidence
521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
hello...
I am running qmail 1.01. I was having all the user's email go to a single
file called Mailbox. I've switched to a Maildir format. I am using the
tcpserver package for smtp delivery. I am running qmail-pop3d.
What I have noticed is the following lines in my syslog/message files:
It looks like the server is spawing 2 processes.
Jan 25 14:36:01 ultra qmail-popup[12934]: connect from angus-proxy.ccp.com
Jan 25 14:36:01 ultra qmail-popup[12935]: connect from angus-proxy.ccp.com
-----------
I am getting this error message too. (in my syslog file)
Jan 25 13:49:46 ultra inetd[71]: pop3/tcp server failing (looping), service
terminated
------------
So to fix the above message, I did a quick fix. I am restarting inetd
every 5 minutes and I don't get the above error message.
--------
Can anyone sort this mess out? Anybody run into something like this.
Thanks for any info you can send me.
jason
Greetings.
Appended is a patch to qmail-1.03 that causes any program that would run
qmail-queue to look for an environment variable QMAILQUEUE. If it is
present, it is used in place of the string "bin/qmail-queue" when
running qmail-queue. This could be used, for example, to add a program
into the qmail-smtpd->qmail-queue pipeline that could do filtering,
rewrite broken headers, etc. (this is my planned usage for it).
This has undergone virtually no testing, but it looks so simple that it
almost has to be correct. No warranties, etc. Note that the chdir to
/var/qmail is always done before exec'ing the program.
Does this look like a reasonable thing to do?
--
Bruce Guenter, QCC Communications Corp. EMail: [EMAIL PROTECTED]
Phone: (306)249-0220 WWW: http://www.qcc.sk.ca/~bguenter/
diff -u qmail-1.03-orig/Makefile qmail-1.03/Makefile
--- qmail-1.03-orig/Makefile Mon Jun 15 04:53:16 1998
+++ qmail-1.03/Makefile Tue Jan 19 10:52:24 1999
@@ -1483,12 +1483,12 @@
trigger.o fmtqfn.o quote.o now.o readsubdir.o qmail.o date822fmt.o \
datetime.a case.a ndelay.a getln.a wait.a seek.a fd.a sig.a open.a \
lock.a stralloc.a alloc.a substdio.a error.a str.a fs.a auto_qmail.o \
-auto_split.o
+auto_split.o env.a
./load qmail-send qsutil.o control.o constmap.o newfield.o \
prioq.o trigger.o fmtqfn.o quote.o now.o readsubdir.o \
qmail.o date822fmt.o datetime.a case.a ndelay.a getln.a \
wait.a seek.a fd.a sig.a open.a lock.a stralloc.a alloc.a \
- substdio.a error.a str.a fs.a auto_qmail.o auto_split.o
+ substdio.a error.a str.a fs.a auto_qmail.o auto_split.o env.a
qmail-send.0: \
qmail-send.8
diff -u qmail-1.03-orig/qmail.c qmail-1.03/qmail.c
--- qmail-1.03-orig/qmail.c Mon Jun 15 04:53:16 1998
+++ qmail-1.03/qmail.c Tue Jan 19 09:57:36 1999
@@ -6,14 +6,25 @@
#include "fd.h"
#include "qmail.h"
#include "auto_qmail.h"
+#include "env.h"
-static char *binqqargs[2] = { "bin/qmail-queue", 0 } ;
+static char *binqqargs[2] = { 0, 0 } ;
+
+static void setup_qqargs()
+{
+ if(!binqqargs[0])
+ binqqargs[0] = env_get("QMAILQUEUE");
+ if(!binqqargs[0])
+ binqqargs[0] = "bin/qmail-queue";
+}
int qmail_open(qq)
struct qmail *qq;
{
int pim[2];
int pie[2];
+
+ setup_qqargs();
if (pipe(pim) == -1) return -1;
if (pipe(pie) == -1) { close(pim[0]); close(pim[1]); return -1; }
How can I move the syslog.mail file and make a new one safely?
The one I have is 62 MB and represents about 15% of our root partition.
Thanks in advance for any help on this :)
Samuel Daffner
Mills College ITS
Samuel Dries-Daffner writes:
> How can I move the syslog.mail file and make a new one safely?
Read the manual pages for your syslog.
On Mon, Jan 25, 1999 at 01:29:42PM -0800, Samuel Dries-Daffner wrote:
>
> How can I move the syslog.mail file and make a new one safely?
>
> The one I have is 62 MB and represents about 15% of our root partition.
>
> Thanks in advance for any help on this :)
mv syslog.mail syslog.mail.1
killall -HUP syslogd
Greetz, Peter.
--
.| Peter van Dijk
.| [EMAIL PROTECTED]
On Mon, Jan 25, 1999 at 11:23:22PM +0100, Peter van Dijk wrote:
# On Mon, Jan 25, 1999 at 01:29:42PM -0800, Samuel Dries-Daffner wrote:
# >
# > How can I move the syslog.mail file and make a new one safely?
# >
# > The one I have is 62 MB and represents about 15% of our root partition.
# >
# > Thanks in advance for any help on this :)
#
# mv syslog.mail syslog.mail.1
# killall -HUP syslogd
#
I know this is good intentions and all, but please don't advise people to use
the killall command unless you KNOW exactly what it does on their system.
here is a snippet from the man page for my killall (Solaris)
killall(1M) Maintenance Commands killall(1M)
NAME
killall - kill all active processes
SYNOPSIS
/usr/sbin/killall [ signal ]
AVAILABILITY
SUNWcsu
DESCRIPTION
killall is used by shutdown(1M) to kill all active processes
not directly related to the shutdown procedure.
killall terminates all processes with open files so that the
mounted file systems will be unbusied and can be unmounted.
killall sends signal (see kill(1)) to the active processes.
If no signal is specified, a default of 15 is used.
The killall command can be run only by the super-user.
SEE ALSO
kill(1), ps(1), fuser(1M), shutdown(1M), signal(3C)
/- [EMAIL PROTECTED] --------------- [EMAIL PROTECTED] -\
|Justin Bell NIC:JB3084| Time and rules are changing. |
|Pearson | Attention span is quickening. |
|Developer | Welcome to the Information Age. |
\-------- http://www.superlibrary.com/people/justin/ ----------/
Appreciate the concern...my system is an IRIX 6.5 and here's the snippet
from man syslogd:
To bring syslogd down, send it a terminate signal (for example,
killall -TERM syslogd).
Thanks to all who responded!
Samuel Daffner
Mills College ITS
On Mon, 25 Jan 1999, Justin Bell wrote:
> On Mon, Jan 25, 1999 at 11:23:22PM +0100, Peter van Dijk wrote:
> # On Mon, Jan 25, 1999 at 01:29:42PM -0800, Samuel Dries-Daffner wrote:
> # >
> # > How can I move the syslog.mail file and make a new one safely?
> # >
> # > The one I have is 62 MB and represents about 15% of our root partition.
> # >
> # > Thanks in advance for any help on this :)
> #
> # mv syslog.mail syslog.mail.1
> # killall -HUP syslogd
> #
>
> I know this is good intentions and all, but please don't advise people to use
> the killall command unless you KNOW exactly what it does on their system.
>
> here is a snippet from the man page for my killall (Solaris)
> killall(1M) Maintenance Commands killall(1M)
>
>
>
> NAME
> killall - kill all active processes
>
> SYNOPSIS
> /usr/sbin/killall [ signal ]
>
> AVAILABILITY
> SUNWcsu
>
> DESCRIPTION
> killall is used by shutdown(1M) to kill all active processes
> not directly related to the shutdown procedure.
>
> killall terminates all processes with open files so that the
> mounted file systems will be unbusied and can be unmounted.
>
> killall sends signal (see kill(1)) to the active processes.
> If no signal is specified, a default of 15 is used.
>
> The killall command can be run only by the super-user.
>
> SEE ALSO
> kill(1), ps(1), fuser(1M), shutdown(1M), signal(3C)
> /- [EMAIL PROTECTED] --------------- [EMAIL PROTECTED] -\
> |Justin Bell NIC:JB3084| Time and rules are changing. |
> |Pearson | Attention span is quickening. |
> |Developer | Welcome to the Information Age. |
> \-------- http://www.superlibrary.com/people/justin/ ----------/
>
On Mon, Jan 25, 1999 at 05:27:43PM -0500, Justin Bell wrote:
> On Mon, Jan 25, 1999 at 11:23:22PM +0100, Peter van Dijk wrote:
> # On Mon, Jan 25, 1999 at 01:29:42PM -0800, Samuel Dries-Daffner wrote:
> # >
> # > How can I move the syslog.mail file and make a new one safely?
> # >
> # > The one I have is 62 MB and represents about 15% of our root partition.
> # >
> # > Thanks in advance for any help on this :)
> #
> # mv syslog.mail syslog.mail.1
> # killall -HUP syslogd
> #
>
> I know this is good intentions and all, but please don't advise people to use
> the killall command unless you KNOW exactly what it does on their system.
You are SO right. I've shot myself in the foot real hard one time with that.
Greetz, Peter.
--
.| Peter van Dijk
.| [EMAIL PROTECTED]
...or in examples.
This may or may not be helpful...
Regards,
Andrzej Kukula.
------- Forwarded Message Follows -------
Date sent: Mon, 25 Jan 1999 16:25:40 -0500
Send reply to: [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
Subject: Using Example Domain Names in Exploits
Originally to: "Tabor J. Wells" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
On Sun, 24 Jan 1999 20:23:40 -0500, "Tabor J. Wells" wrote:
>On Fri, Jan 22, 1999 at 08:58:33PM -0000,
>mnemonix <[EMAIL PROTECTED]> is thought to have said:
>
(on how to exploit www.server.com)
>
>I really wish people wouldn't do this. www.server.com is a legitimate
>site (it's hosted on my network) and they certainly don't run IIS.
The domains example.com, example.org, and example.net have all been reserved
by IANA and NIC for just this purpose. Use them.
--
Bryan C. Andregg * <[EMAIL PROTECTED]> * Red Hat Software
"Gee, I'm glad you're around to tell me the almighty-truth[tm]."
-- Patrick J. Volkerding
[ I'm sending this to the qmail list because the interaction of this
bug with sub-users in qmail is especially pronounced. ]
I've been chasing down a stupid problem for a few days now, and now I
finally know why user-ext hasn't been working for one of my users on
freebsd. After figuring out the symptom (getpwnam() doesn't return
correctly in some cases), I got confirmation that getpwnam() in
freebsd-2.2.8 is broken, and it seems to me that qmail is especially
affected by it. This doesn't seem to happen in freebsd-2.2.7.
>From the freebsd-2.2.8 errata (http://www.freebsd.org/releases/2.2.8R/errata.html):
o getpwnam(3) semantics are incorrect in some cases.
Fix: If passed a string longer than the maximum allowed for a user name,
getpwnam will incorrectly return an entry for a user that matches the
initial characters in the string up to the maximum length allowed for a
user name. To correct this behaviour, libc needs to be patched and
recompiled. The appropriate patch can be obtained from:
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/gen/getpwent.c.diff?r1=1.35.2.2&r2=1.35.2.3
This means that w/ freebsd 2.2.8 if you have a user whose username is
8 characters long and they have a .qmail-ext that they want to deliver
to, qmail-getpw will never return the correct "dash" and "ext" args,
and that user is up the river.
The process of fixing seems like a real PITA to me. I think I'm just
going to change the user to having a 7 character username, or patch
qmail-getpw to check if str_len(username) > UT_NAMESIZE (currently 8).
-Peter
- "Peter C. Norton" <[EMAIL PROTECTED]>:
| [ I'm sending this to the qmail list because the interaction of this
| bug with sub-users in qmail is especially pronounced. ]
|
| I've been chasing down a stupid problem for a few days now,
You could have saved yourself a lot of trouble had you read the qmail
list traffic more. (The subject line was ".qmail file oddities.")
But I don't blame you for having missed it: There is so much traffic
on the qmail list these days, I certainly don't read all of it anymore
- and searching for pertinent information is becoming correspondingly
more difficult, even if you have a local copy of the last couple of
years' traffic as I do. Maybe we need a different mechanism for
keeping track of qmail-breaking bugs in operating systems. A simple
list, perhaps, with a prominent pointer to it to be kept at
www.qmail.org. Any ideas how to organize this, anybody?
- Harald
On Tue, Jan 26, 1999 at 01:53:16AM +0100, Harald Hanche-Olsen wrote:
> - "Peter C. Norton" <[EMAIL PROTECTED]>:
>
> | [ I'm sending this to the qmail list because the interaction of this
> | bug with sub-users in qmail is especially pronounced. ]
> |
> | I've been chasing down a stupid problem for a few days now,
>
> You could have saved yourself a lot of trouble had you read the qmail
> list traffic more. (The subject line was ".qmail file oddities.")
qmail-getpw and freebsd didn't turn up anything in the searchable
archives, except for articles relating to replacing qmail-getpw with
an ldap-capable version. Since qmail-getpw was where the symptoms
lay, and freebsd was the platform, I don't know if anyone else could
find the problem either. Hopefully my message will turn up in a
search from now on.
> But I don't blame you for having missed it: There is so much traffic
> on the qmail list these days, I certainly don't read all of it anymore
> - and searching for pertinent information is becoming correspondingly
> more difficult, even if you have a local copy of the last couple of
> years' traffic as I do. Maybe we need a different mechanism for
> keeping track of qmail-breaking bugs in operating systems. A simple
> list, perhaps, with a prominent pointer to it to be kept at
> www.qmail.org. Any ideas how to organize this, anybody?
A moderated list would be a good thing.
-Peter
At 8:18 PM -0500 1/25/99, Peter C. Norton wrote:
}
} A moderated list would be a good thing.
Moderated how? About all I can think of is that the FAQ's and complaint
about "no multiple RCPT" could be removed. That doesn't strike me as all
that much of the traffic, although I may just be fooling myself.
I agree this is getting to be a high volume list, but I think the better
solution to high volume lists is a Usenet newsgroup, where a newsreaders
filters can be brought to bear. Maybe it's finally time to start the
process?
}
} -Peter
---
Paul J. Schinder
NASA Goddard Space Flight Center
Code 693, Greenbelt, MD 20771
[EMAIL PROTECTED]
On Mon, Jan 25, 1999 at 08:24:00PM -0500, Paul J. Schinder wrote:
> At 8:18 PM -0500 1/25/99, Peter C. Norton wrote:
> } A moderated list would be a good thing.
>
> Moderated how? About all I can think of is that the FAQ's and complaint
> about "no multiple RCPT" could be removed. That doesn't strike me as all
> that much of the traffic, although I may just be fooling myself.
The purpose is to create a list that would announce qmail
show-stoppers. Someone has to decide what's worth putting on the
list, or every week the list will get messages from someone with
weitse's qmail-smtpd DoS attack. That sort of message only needs to
be seen once, and then it can become part of a FAQ.
> I agree this is getting to be a high volume list, but I think the better
> solution to high volume lists is a Usenet newsgroup, where a newsreaders
> filters can be brought to bear. Maybe it's finally time to start the
> process?
Personally I hate what usenet is now. I don't find it useful anymore.
The active abuse of newsgroups and the need to maintain outrageous
numbers of rules to filter out junk has gotten to be more then it's
worth. qmail's mailing list works just fine at its current volume -
but dedicated lists of specific qmail-related topics seems like a good
idea.
-Peter
zeroseek is the database technology that will be used to store the queue
in qmail 2. In one day it can safely write tens of millions of separate
average-size messages to a single slow disk.
I've set up a mailing list for people interested in testing zeroseek. To
join, send a message to [EMAIL PROTECTED]
---Dan
1. According to rfc1939 in the STAT command:
"Note that messages marked as deleted are not counted in either total."
But this is what I get:
$ ./qmail-pop3d MD
+OK
LAST
+OK
1 191
.
STAT
+OK 1 191
DELE 1
+OK
STAT
+OK 1 0
Note that second STAT still states '1' message. Should that say '0'?
2. The "last" variable is only updated when a message is deleted. This is
inconsisent with rfc1460 (the last POP rfc that mentions the LAST command)
which suggests that it should reflect that last message retreived. Eg:
$ ./qmail-pop3d MD
+OK
LIST
+OK
1 191
.
RETR 1
+OK
...
.
LAST
+OK 0
DELE 1
+OK
LAST
+OK 1
I sortof think that the first LAST should return '1' and the second LAST
should return '0'.
Regards.
