qmail Digest 16 Sep 2001 10:00:01 -0000 Issue 1489
Topics (messages 69505 through 69520):
qmail-pop3d finds no maildir
69505 by: Ruprecht Helms
69506 by: speedboy
69507 by: Henning Brauer
ezmlm-clean error
69508 by: Mark
Re: Accounting eMail
69509 by: Lordy
69510 by: Alex Stevens
qmail-inject fatal error program.
69511 by: doph
69512 by: Scott Gifford
pref_ambigmx() and friends
69513 by: Stevie O
69514 by: Scott Gifford
69515 by: richard.illuin.org
69516 by: Greg White
69517 by: Stevie O
69518 by: Adrian Ho
69519 by: Scott Gifford
qmail moreipme patch
69520 by: Scott Gifford
Administrivia:
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To bug my human owner, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
Hi,
why can not the POP3-Daemon Maildirs in the homedirs. I've installed the patch
for qmail-pop3, but it fails when I try to make a telnet localhost pop3 with
the message
can't find maildir in $HOME/Maildir
It answer that also when a Maildir exists in the homedirectory of the user.
The rights are set so that others can write in the three subdirs of the
maildirectory.
Regards,
Ruprecht
> but it fails when I try to make a telnet localhost pop3 with
> the message can't find maildir in $HOME/Maildir
>
> It answer that also when a Maildir exists in the homedirectory of the user.
> The rights are set so that others can write in the three subdirs of the
> maildirectory.
I had this on friday. A client had over 1000 messages in Maildir/cur, I set
Outlook Express to _not_ leave a copy on the server, it removed them and
it worked fine again. I tryed stracing the process but I couldn't see why
it was not working, I'm not a C programmer.
Any other ideas from the author, programmers?
Thanks crew.
On Sat, Sep 15, 2001 at 09:07:00PM +1000, speedboy wrote:
> I had this on friday. A client had over 1000 messages in Maildir/cur, I set
> Outlook Express to _not_ leave a copy on the server, it removed them and
> it worked fine again. I tryed stracing the process but I couldn't see why
> it was not working, I'm not a C programmer.
>
> Any other ideas from the author, programmers?
ressource limits. It's in the archives.
--
* Henning Brauer, [EMAIL PROTECTED], http://www.bsws.de *
* BS Web Services, Roedingsmarkt 14, 20459 Hamburg, Germany *
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)
when running ezmlm-test
ezmlm-clean fails.
removed mod queue entry 3 that wasn't due
now if I bypass this test it fails again later on in the second
set of ezmlm-clean tests.
I am running qmail-1.03, ezmlm-0.53 with id-0.40 on
a slackware 8 box
-
Hello everybody,
I'm a more or less advanced qmail-user and therefore I'm always
trying new things with qmail. Now that I make use of iptables under
Linux (2.4.9) I thought about doing traffic accounting for qmail on my
RH 7.1 box.
As I first thought about it, it seemed rather simple but as I try to
realize this it gets complicated.
As I want to account incoming as well as outgoing traffic I defined four
rules for iptables:
1.) Incoming packets going to port 25/tcp (ACCEPT)
2.) Incoming packets going to port 110/tcp (ACCEPT)
3.) Outgoing packets going to port 25/tcp (ACCEPT)
4.) Outgoing packets comming from port 25/tcp (ACCEPT)
I know that this does not yet achive what I am trying to do but this is as
far as I have come.
I know that due to TCP mechanism and the local port allocation this might
not be working at all but I thought I ask some of our pro's on the list :-)
Regards,
Lordy
On Sat, Sep 15, 2001 at 08:45:03PM +0200, Lordy wrote:
> Hello everybody,
>
> I'm a more or less advanced qmail-user and therefore I'm always
> trying new things with qmail. Now that I make use of iptables under
> Linux (2.4.9) I thought about doing traffic accounting for qmail on my
> RH 7.1 box.
Does this really belong on the qmail list?
>
> As I first thought about it, it seemed rather simple but as I try to
> realize this it gets complicated.
um. yes.
>
> As I want to account incoming as well as outgoing traffic I defined four
> rules for iptables:
>
> 1.) Incoming packets going to port 25/tcp (ACCEPT)
> 2.) Incoming packets going to port 110/tcp (ACCEPT)
> 3.) Outgoing packets going to port 25/tcp (ACCEPT)
> 4.) Outgoing packets comming from port 25/tcp (ACCEPT)
FORWARD??? As in, -i and -o?
I'd suggest you try the netfilter ML, either developers or the general list (the
latter seems mostly noise these days).
Check the netfilter archives. Have you looked at Netramet, Argus, ipac, et al?
-Alex
--
__________________
[EMAIL PROTECTED]
------------------
"Yeah, I'm drunk all right, and you're crazy. Tomorrow I'll
be sober, but you'll still be crazy for the rest of your life."
-W.C. Fields
qmail,
can someone please help me with something that I didn't find in the
documentation: my hoster changed sendmail to qmail and told me that
now I should use qmail-inject.
Well, I thought cool, I can use it, it's cool. So I telnet to the host,
man qmail-inject, read it and then do:
%/var/qmail/bin/qmail-inject -a -f [EMAIL PROTECTED] [EMAIL PROTECTED]
qmail-inject: fatal: read error
I do: hmmm...
and then read /var/qmail/docs/TEST.deliver and do:
%echo to: [EMAIL PROTECTED] |/var/qmail/bin/qmail-inject
qmail-inject: fatal: read error
so, what is wrong? I guess it's about permissions since my hoster does
the same and it sends the letter. but where is the prob?
thanks a lot.
Alexander / doph.
IT WORKS! group.
doph <[EMAIL PROTECTED]> writes:
[...]
> Well, I thought cool, I can use it, it's cool. So I telnet to the host,
> man qmail-inject, read it and then do:
> %/var/qmail/bin/qmail-inject -a -f [EMAIL PROTECTED] [EMAIL PROTECTED]
> qmail-inject: fatal: read error
[...]
> so, what is wrong? I guess it's about permissions since my hoster does
> the same and it sends the letter. but where is the prob?
Your command looks fine. You probably want to talk to your provider,
perhaps using strace or truss to find out where it's failing and help
them fix the problem.
----ScottG.
When the NYC disaster took out the route to my box, whisper.qrpff.net, I
asked my friend on the west coast to setup his machine, zlotnik.oilcan.org,
as a backup mx for qrpff.net. The problem: Mail kept bouncing with messages
stating that there were too many hops. zlotnik's syslog clearly indicated
that qmail was delivering mail to itself, which is obviously a dumb thing
to do. The thing was, I was fairly certain that qmail was guarded against
that. It wasn't until just now that I figured out the problem.
backup mx for qrpff.net: 65.85.11.85
zlotnik.oilcan.org ip: 192.168.1.105
Zlotnik's IP address is really a private one, because it's located behind a
NAT firewall. 65.85.11.85 traffic is routed to it.
Thus, when qmail-send sees that the primary mx is down, and 65.85.11.85 a
2ndary mx, it routes
the e-mail to 65.85.11.85, which is routed to (what else?) itself by the frw.
I'm not familiar enough with qmail or patching in general to trust myself
to make a decent patch for qmail, so what I'm thinking of is something
along the lines
/var/qmail/control/ipequiv:
65.85.11.85:192.168.1.105
i.e. packets for 65.85.11.85 will end up going to 192.168.1.105.
Questions? Comments? Money?
--
Stevie-O
Real programmers use COPY CON PROGRAM.EXE
Stevie O <[EMAIL PROTECTED]> writes:
> When the NYC disaster took out the route to my box, whisper.qrpff.net,
> I asked my friend on the west coast to setup his machine,
> zlotnik.oilcan.org, as a backup mx for qrpff.net. The problem: Mail
> kept bouncing with messages stating that there were too many
> hops. zlotnik's syslog clearly indicated that qmail was delivering
> mail to itself, which is obviously a dumb thing to do. The thing was,
> I was fairly certain that qmail was guarded against that. It wasn't
> until just now that I figured out the problem.
>
> backup mx for qrpff.net: 65.85.11.85
> zlotnik.oilcan.org ip: 192.168.1.105
>
> Zlotnik's IP address is really a private one, because it's located
> behind a NAT firewall. 65.85.11.85 traffic is routed to it.
>
> Thus, when qmail-send sees that the primary mx is down, and
> 65.85.11.85 a 2ndary mx, it routes
> the e-mail to 65.85.11.85, which is routed to (what else?) itself by the frw.
[...]
I've encountered this problem before. I've got a patch I've been
preparing for public consumption which does essentially what you
suggest; it's been in production for over a year with great success,
and is very simple.
-----ScottG.
On Sat, 15 Sep 2001, Stevie O wrote:
> When the NYC disaster took out the route to my box, whisper.qrpff.net, I
> asked my friend on the west coast to setup his machine, zlotnik.oilcan.org,
> as a backup mx for qrpff.net. The problem: Mail kept bouncing with messages
> stating that there were too many hops. zlotnik's syslog clearly indicated
> that qmail was delivering mail to itself, which is obviously a dumb thing
> to do. The thing was, I was fairly certain that qmail was guarded against
> that. It wasn't until just now that I figured out the problem.
>
> backup mx for qrpff.net: 65.85.11.85
> zlotnik.oilcan.org ip: 192.168.1.105
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Zlotnik's IP address is really a private one, because it's located behind a
> NAT firewall. 65.85.11.85 traffic is routed to it.
okay, so out onf the BBI I see...
so? mail.illuin.org is behind a NAT firewall, but you can't tell that --
its supposed to be transparent.
you need entries in the DNS zone for qpff.net like this:
whisper.qpff.net IN MX 10 whisper.qpff.net.
IN MX 20 zlotnik.oilcan.org.
IN A whatever.its.ip-address.is
and add whisper.qpff.net to rcpthosts on zlotnik.oilcan.org
now, we'll try to connect to whisper, discover its not there and send mail
to oilcan. oilcal will accept it and try to forward it to whisper.
oilcan removes itself and any higher preference MX hosts from the list of
machine it will try to forward mail to.
it won't try to deliver locally because whisper isn't in its locals.
note the complete lack of IP addresses on the MX lines: that is a BAD
IDEA.
now, split DNS is a different matter and needs to be discussed elsewhere,
since that allows you to get
answer: illuin.org 86400 MX 12801 illuin.illuin.org
additional: illuin.illuin.org 86400 A 216.30.73.135
and me to get
answer: illuin.org 86400 MX 12801 illuin.illuin.org.
additional: illuin.illuin.org 86400 A 192.168.0.135
RjL
==================================================================
You know that. I know that. But when || Austin, Texas
you talk to a monkey you have to || Email: [EMAIL PROTECTED]
grunt and wave your arms -ck ||
On Sat, Sep 15, 2001 at 10:41:55PM -0400, Stevie O wrote:
> When the NYC disaster took out the route to my box, whisper.qrpff.net, I
> asked my friend on the west coast to setup his machine, zlotnik.oilcan.org,
> as a backup mx for qrpff.net. The problem: Mail kept bouncing with messages
> stating that there were too many hops. zlotnik's syslog clearly indicated
> that qmail was delivering mail to itself, which is obviously a dumb thing
> to do. The thing was, I was fairly certain that qmail was guarded against
> that. It wasn't until just now that I figured out the problem.
>
> backup mx for qrpff.net: 65.85.11.85
> zlotnik.oilcan.org ip: 192.168.1.105
>
> Zlotnik's IP address is really a private one, because it's located behind a
> NAT firewall. 65.85.11.85 traffic is routed to it.
>
> Thus, when qmail-send sees that the primary mx is down, and 65.85.11.85 a
> 2ndary mx, it routes
> the e-mail to 65.85.11.85, which is routed to (what else?) itself by the frw.
Since it's just a secondary, why not just drop qrpff.net in smtproutes?
Good general solution that avoids this problem, without patching. Any
reason not to do it that way?
> Real programmers use COPY CON PROGRAM.EXE
No, they don't. They might use 'cat' though. :)
--
Greg White
At 10:26 PM 9/15/2001 -0500, [EMAIL PROTECTED] wrote:
>On Sat, 15 Sep 2001, Stevie O wrote:
>
> > When the NYC disaster took out the route to my box, whisper.qrpff.net, I
> > asked my friend on the west coast to setup his machine,
> zlotnik.oilcan.org,
> > as a backup mx for qrpff.net. The problem: Mail kept bouncing with
> messages
> > stating that there were too many hops. zlotnik's syslog clearly indicated
> > that qmail was delivering mail to itself, which is obviously a dumb thing
> > to do. The thing was, I was fairly certain that qmail was guarded against
> > that. It wasn't until just now that I figured out the problem.
> >
> > backup mx for qrpff.net: 65.85.11.85
> > zlotnik.oilcan.org ip: 192.168.1.105
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> >
> > Zlotnik's IP address is really a private one, because it's located
> behind a
> > NAT firewall. 65.85.11.85 traffic is routed to it.
>
>okay, so out onf the BBI I see...
>
>
>so? mail.illuin.org is behind a NAT firewall, but you can't tell that --
>its supposed to be transparent.
NAT is only transparent until protocols start involving IP addresses.
>you need entries in the DNS zone for qpff.net like this:
>
>
>whisper.qpff.net IN MX 10 whisper.qpff.net.
> IN MX 20 zlotnik.oilcan.org.
> IN A whatever.its.ip-address.is
Wtf is this? tinydns doesn't have anything like this.
>and add whisper.qpff.net to rcpthosts on zlotnik.oilcan.org
That's been done.
>now, we'll try to connect to whisper, discover its not there and send mail
>to oilcan. oilcal will accept it and try to forward it to whisper.
>oilcan removes itself and any higher preference MX hosts from the list of
>machine it will try to forward mail to.
zlotnik ("oilcan") doesn't remove itself from the list, because zlotnik is
192.168.1.105,
which isn't anywhere on the mx list.
--
Stevie-O
Real programmers use COPY CON PROGRAM.EXE
On Sat, Sep 15, 2001 at 11:00:08PM -0400, Scott Gifford wrote:
> Stevie O <[EMAIL PROTECTED]> writes:
>
> > When the NYC disaster took out the route to my box, whisper.qrpff.net,
> > I asked my friend on the west coast to setup his machine,
> > zlotnik.oilcan.org, as a backup mx for qrpff.net.
> [...]
> I've encountered this problem before. I've got a patch I've been
> preparing for public consumption which does essentially what you
> suggest; it's been in production for over a year with great success,
> and is very simple.
As simple as doing:
echo "qrpff.net:whisper.qrpff.net" > /var/qmail/control/smtproutes
on zlotnik.oilcan.org?
--
Adrian Ho Tinker, Drifter, Fixer, Bum [EMAIL PROTECTED]
ListArchive: <http://marc.theaimsgroup.com/?l=qmail>
Useful URLs: <http://cr.yp.to/qmail.html> <http://www.qmail.org>
<http://www.lifewithqmail.org/> <http://qmail.faqts.com/>
Adrian Ho <[EMAIL PROTECTED]> writes:
> On Sat, Sep 15, 2001 at 11:00:08PM -0400, Scott Gifford wrote:
> > Stevie O <[EMAIL PROTECTED]> writes:
> >
> > > When the NYC disaster took out the route to my box, whisper.qrpff.net,
> > > I asked my friend on the west coast to setup his machine,
> > > zlotnik.oilcan.org, as a backup mx for qrpff.net.
> > [...]
> > I've encountered this problem before. I've got a patch I've been
> > preparing for public consumption which does essentially what you
> > suggest; it's been in production for over a year with great success,
> > and is very simple.
>
> As simple as doing:
>
> echo "qrpff.net:whisper.qrpff.net" > /var/qmail/control/smtproutes
>
> on zlotnik.oilcan.org?
Not as simple, but a more general solution to the problem of qmail not
knowing what IP addresses are local to it, and misbehaving when it
doesn't know. Hang on, I'll post the patch in a minute...
-----ScottG.
Here's a patch I used on a qmail system I used to run which ran behind
a NAT load balancer. It solves a problem qmail has when it doesn't
know all of the IP addresses that connect to it. If you run qmail on
a server behind any kind of network address translator, if you have
any other machines that forward their SMTP port to your SMTP port, or
if you have machines which listen on SMTP and unconditionally forward
mail to your qmail server, take a look at this patch and see if it
prevents a potential problem.
Here's a brief README and the patch itself. It doesn't have a
permanent home yet (I'm moving my Web page; if anybody has suggestions
for a good, inexpensive Web hosting service for personal pages that
doesn't have ads or stupid restrictions, please email me off-list),
but I'll post the URL when it finds one.
Comments are welcome.
-----ScottG.
This patch may be necessary in some configurations that involve network
address translation or port forwarding. It prevents a problem caused
by an MX or other mail routing directive instructing qmail to connect to
itself without realizing it's connecting to itself. When this happens,
it accepts the message, finds out where to deliver it to (itself), and
promptly reconnects to itself to deliver the message. Eventually, when
it has done this 20 or 30 times, it will give up and bounce the message,
but not before sucking up all of your CPU while it's happening.
Normally, qmail can detect what IP addresses refer to itself by getting
a list of all network interfaces with IP addresses from the operating
system. It uses this list to determine whether connecting to an address
will cause it to connect to itself, and avoid the situation (it calls
the perm_ambigmx() function, which prints the message:
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)
But in situations where the OS is not aware of all IP addresses that
connect back to itself, this detection fails, causing the CPU-sucking
phenomenon described above. This can happen if there is a network
address translation device in front of the qmail server, such as a
load-balancer or a router which allows you to share one IP address among
several machines; if there is a port forwarder forwarding connections
from some other machine to the SMTP server on the qmail server; or in
configurations where a "dumb" mailserver is configured to use your qmail
server as a "smarthost", delivering all mail to it without inspection.
To solve this, other IP addresses which will ultimately connect back to
your machine can be added to the file "control/moreipme", one per line.
qmail will treat all addresses in this file exactly as if they were
local, and if it finds an MX record or other mail routing information
which would cause it to connect to any of these addresses, it will call
perm_ambigmx(), and print the above error message.
You can cd into your qmail directory (normally /var/qmail) and run the
program "ipmeprint" from the source directory to see what interfaces
qmail is detecting or finds in moreipme.
This patch also incorporates the "0.0.0.0" patch, which causes qmail
to recognize the IP address 0.0.0.0 as a local address. See:
http://www.tir.com/~sgifford/qmail/qmail-0.0.0.0.README
for more information, and
http://www.tir.com/~sgifford/qmail/qmail-0.0.0.0.patch
for a copy of the patch.
diff -ur qmail-1.03/Makefile qmail-1.03-sg2/Makefile
--- qmail-1.03/Makefile Mon Jun 15 06:53:16 1998
+++ qmail-1.03-sg2/Makefile Sun Sep 16 04:01:13 2001
@@ -787,9 +787,9 @@
./compile ipme.c
ipmeprint: \
-load ipmeprint.o ipme.o ip.o ipalloc.o stralloc.a alloc.a substdio.a \
+load ipmeprint.o ipme.o ip.o ipalloc.o open.a getln.a stralloc.a alloc.a substdio.a \
error.a str.a fs.a socket.lib
- ./load ipmeprint ipme.o ip.o ipalloc.o stralloc.a alloc.a \
+ ./load ipmeprint ipme.o ip.o ipalloc.o open.a getln.a stralloc.a alloc.a \
substdio.a error.a str.a fs.a `cat socket.lib`
ipmeprint.o: \
diff -ur qmail-1.03/ipme.c qmail-1.03-sg2/ipme.c
--- qmail-1.03/ipme.c Mon Jun 15 06:53:16 1998
+++ qmail-1.03-sg2/ipme.c Sun Sep 16 04:07:09 2001
@@ -5,6 +5,7 @@
#include <sys/socket.h>
#include <net/if.h>
#include <netinet/in.h>
+#include <unistd.h>
#ifndef SIOCGIFCONF /* whatever works */
#include <sys/sockio.h>
#endif
@@ -14,6 +15,7 @@
#include "ipalloc.h"
#include "stralloc.h"
#include "ipme.h"
+#include "substdio.h"
static int ipmeok = 0;
ipalloc ipme = {0};
@@ -40,12 +42,19 @@
int len;
int s;
struct ip_mx ix;
+ int moreipme_fd;
if (ipmeok) return 1;
if (!ipalloc_readyplus(&ipme,0)) return 0;
ipme.len = 0;
ix.pref = 0;
+ /* 0.0.0.0 is a special address which always refers to
+ * "this host, this network", according to RFC 1122, Sec. 3.2.1.3a.
+ */
+ byte_copy(&ix.ip,4,"\0\0\0\0");
+ if (!ipalloc_append(&ipme,&ix)) { return 0; }
+
if ((s = socket(AF_INET,SOCK_STREAM,0)) == -1) return -1;
len = 256;
@@ -90,6 +99,34 @@
x += len;
}
close(s);
+
+ /* Now see if there are any supplemental IPs */
+ if ( (moreipme_fd = open_read("control/moreipme")) != -1)
+ {
+ char inbuf[1024];
+ substdio ss;
+ stralloc l = {0};
+ int match;
+
+ substdio_fdbuf(&ss, read, moreipme_fd, inbuf, sizeof(inbuf));
+ while (1)
+ {
+ if (getln(&ss, &l, &match, '\n') == -1)
+ {
+ break;
+ }
+ if (!match && !l.len)
+ {
+ break;
+ }
+ l.len--;
+ if (!stralloc_0(&l)) { close(moreipme_fd); return 0; }
+ if (!ip_scan(l.s, &ix.ip)) { continue; }
+ if (!ipalloc_append(&ipme,&ix)) { close(moreipme_fd); return 0; }
+ }
+ }
+ close(moreipme_fd);
+
ipmeok = 1;
return 1;
}
