qmail Digest 18 Mar 1999 11:00:01 -0000 Issue 583
Topics (messages 23053 through 23093):
NIS and qmail
23053 by: [EMAIL PROTECTED]
23068 by: Mark Delany <[EMAIL PROTECTED]>
probleet with qmail and defunc processes
23054 by: Franky Van Liedekerke <[EMAIL PROTECTED]>
23055 by: Harald Hanche-Olsen <[EMAIL PROTECTED]>
Relaying problem (kind of)
23056 by: torben fjerdingstad <[EMAIL PROTECTED]>
23058 by: Anand Buddhdev <[EMAIL PROTECTED]>
23060 by: torben fjerdingstad <[EMAIL PROTECTED]>
again NIS and qmail: refined question
23057 by: [EMAIL PROTECTED]
23090 by: Peter van Dijk <[EMAIL PROTECTED]>
keeping users from running shells
23059 by: Jeff Hayward <[EMAIL PROTECTED]>
23066 by: Mark Delany <[EMAIL PROTECTED]>
Virtual Domains.
23061 by: "Daniel V. Pedersen" <[EMAIL PROTECTED]>
23069 by: Mark Delany <[EMAIL PROTECTED]>
delivery errors?
23062 by: Samuel Dries-Daffner <[EMAIL PROTECTED]>
23063 by: "Sam" <[EMAIL PROTECTED]>
23064 by: Samuel Dries-Daffner <[EMAIL PROTECTED]>
23065 by: Mark Delany <[EMAIL PROTECTED]>
23067 by: "Wil Boucher" <[EMAIL PROTECTED]>
23070 by: Mark Delany <[EMAIL PROTECTED]>
ETRN, qmail-1.03 and etrn patch v0.1f
23071 by: Andrew Spencer <[EMAIL PROTECTED]>
23073 by: Andrew Spencer <[EMAIL PROTECTED]>
23093 by: Van Liedekerke Franky <[EMAIL PROTECTED]>
e-mail hanging ... at 12:00 - 1:30
23072 by: "t" <[EMAIL PROTECTED]>
Problems starting qmail
23074 by: Ernesto Miranda <[EMAIL PROTECTED]>
23075 by: Peter van Dijk <[EMAIL PROTECTED]>
Rcpthosts
23076 by: Michael Bryan <[EMAIL PROTECTED]>
23077 by: "Sam" <[EMAIL PROTECTED]>
23078 by: Michael Bryan <[EMAIL PROTECTED]>
23079 by: "Sam" <[EMAIL PROTECTED]>
Unusual Delivery Problem
23080 by: "Aaron L. Meehan" <[EMAIL PROTECTED]>
ezmlm and "delay notifies" (was: Re: mini-bounce)
23081 by: Tim Pierce <[EMAIL PROTECTED]>
23082 by: "Greg Owen {gowen}" <[EMAIL PROTECTED]>
splogger replacement?
23083 by: John Conover <[EMAIL PROTECTED]>
23085 by: Stefan Paletta <[EMAIL PROTECTED]>
Mails that refused to be dequeued
23084 by: Operations <[EMAIL PROTECTED]>
qmail, DNS, and relaying for a hidden host
23086 by: "Greg Owen {gowen}" <[EMAIL PROTECTED]>
23087 by: "Greg Owen {gowen}" <[EMAIL PROTECTED]>
23089 by: "Timothy L. Mayo" <[EMAIL PROTECTED]>
23092 by: Robin Bowes <[EMAIL PROTECTED]>
Bounces off of incorrect smtproutes
23088 by: "Greg Owen {gowen}" <[EMAIL PROTECTED]>
dot-qmail security
23091 by: Joel Eriksson <[EMAIL PROTECTED]>
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]
----------------------------------------------------------------------
Hi, I can`t make qmail deliver mail on a box that is NIS base (users have only pop3 accounts there and no homedirs) qmail keeps loggin infamous #5.1.1 mistake ... any ideas about what I could have messed up? Pashah -- http://www.spb.sitek.net/~pashah/public-key-0x97739141.pgp
At 02:15 PM 3/17/99 +0300, [EMAIL PROTECTED] wrote: >Hi, >I can`t make qmail deliver mail on a box that is NIS base (users have only >pop3 accounts there and no homedirs) >qmail keeps loggin infamous #5.1.1 mistake ... Might be helpful if you actually give us the full log extracts rather than paraphrasing them... On what basis did you set up these "pop3 accounts" within NIS+ and on what basis have you got qmail set up to find these mailboxes? Regards.
Hi, I'm seeing a lot of zombies in my process list (qmail 1.03 with anti spam from Sam). Is this a known problem or do I need some patch? Or do they time out? 8 Z qmailq 549 546 0 0 0:00 <defunct> 8 Z qmailq 2288 2284 0 0 0:00 <defunct> 8 Z qmailq 28210 28207 0 0 0:00 <defunct> 8 Z qmailq 2473 2469 0 0 0:00 <defunct> 8 Z qmailq 27260 27256 0 0 0:00 <defunct> 8 Z qmailq 26578 26574 0 0 0:00 <defunct> 8 Z qmailq 852 849 0 0 0:00 <defunct>
- Franky Van Liedekerke <[EMAIL PROTECTED]>: | I'm seeing a lot of zombies in my process list (qmail 1.03 with anti | spam from Sam). Is this a known problem or do I need some patch? Or do | they time out? Zombies are processes whose parents have not waited for them. They never time out. The stay until the parent wait()s, or the parent exits without waiting, in which case the init process takes over parenthood and takes care of the wait so the process is removed from the process table. In other words, you need to look at the parent processes to get some idea what is going on. - Harald
Things do not work quite as I expect. Say I am MX for domain inside.dk (this is not a real name). So, I put two lines into rcpthosts and HUP qmail-smtpd: .inside.dk inside.dk Right? Now mail to @inside.dk bounces: <[EMAIL PROTECTED]>: 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) Then I put an entry into smtproutes, like: inside.dk:mailhost.inside.dk, and now it works. I don't understand why I need to do that too. -- Med venlig hilsen / Regards Netdriftgruppen / Network Management Group UNI-C Tlf./Phone +45 35 87 89 41 Mail: UNI-C Fax. +45 35 87 89 90 Bygning 304 E-mail: [EMAIL PROTECTED] DK-2800 Lyngby
On Wed, Mar 17, 1999 at 02:06:27PM +0100, torben fjerdingstad wrote: > Things do not work quite as I expect. > > Say I am MX for domain inside.dk (this is not a real name). > So, I put two lines into rcpthosts and HUP qmail-smtpd: There's no qmail-smtpd to HUP. It is started each time a connection comes in, and it reads the control/rcpthosts file every time. > .inside.dk > inside.dk > > Right? Right. > Now mail to @inside.dk bounces: > <[EMAIL PROTECTED]>: > 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) That's the problem. You are are the best preference MX for inside.dk, and so you must arrange for local delivery of the mail on this machine. Add inside.dk to the control/locals file, and you should be OK. Remember to HUP qmail-send after changing the locals file. > Then I put an entry into smtproutes, like: > inside.dk:mailhost.inside.dk, and now it works. This will work, because mail for inside.dk is being treated as remote mail, and you are artificially routing it to mailhost.inside.dk. You will not need this entry after you add your domain to the locals file. -- System Administrator See complete headers for address, homepage and phone numbers
On Wed, Mar 17, 1999 at 05:14:20PM +0300, Anand Buddhdev wrote: > On Wed, Mar 17, 1999 at 02:06:27PM +0100, torben fjerdingstad wrote: > > > Things do not work quite as I expect. > > > > Say I am MX for domain inside.dk (this is not a real name). > > So, I put two lines into rcpthosts and HUP qmail-smtpd: > > Now mail to @inside.dk bounces: > > <[EMAIL PROTECTED]>: > > 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) > > That's the problem. You are are the best preference MX for inside.dk, and so > you must arrange for local delivery of the mail on this machine. Add > inside.dk to the control/locals file, and you should be OK. Remember to HUP > qmail-send after changing the locals file. But, if I did that, I would expect "user" to be treated as a local user on my mail relay which he is not. I cannot make that out of the FAQ. I thought control/locals was for aliases for the local host. I am sure you are right. Thanks very much. -- Med venlig hilsen / Regards Netdriftgruppen / Network Management Group UNI-C Tlf./Phone +45 35 87 89 41 Mail: UNI-C Fax. +45 35 87 89 90 Bygning 304 E-mail: [EMAIL PROTECTED] DK-2800 Lyngby
Hi, I`ve find out the problem, that made deliveries of local messages impossible - since all the users has the ~ set as /tmp (they have only vsm pop3 accounts) qmail refuses to deliver messages ... the [Q] is where do I tweak qmail sources for it to be more tolerant about this matter? I`ve checked conf-patrn ... my attempts to change bits in it didn`t work out ... Would some [c|qmail] gurus help me (: ? thanx in advance, Pashah -- http://www.spb.sitek.net/~pashah/public-key-0x97739141.pgp
On Wed, Mar 17, 1999 at 04:29:21PM +0300, [EMAIL PROTECTED] wrote: > Hi, I`ve find out the problem, that made deliveries of local messages > impossible - since all the users has the ~ set as /tmp (they have only vsm pop3 > accounts) qmail refuses to deliver messages ... > the [Q] is where do I tweak qmail sources for it to be more tolerant about this > matter? > I`ve checked conf-patrn ... my attempts to change bits in it didn`t work out > ... > Would some [c|qmail] gurus help me (: ? Read FAQ 4.9 Greetz, Peter. -- .| Peter van Dijk | <mo|VERWEG> stoned worden of coden .| [EMAIL PROTECTED] | <mo|VERWEG> dat is de levensvraag | <mo|VERWEG> coden of stoned worden | <mo|VERWEG> stonend worden En coden | <mo|VERWEG> hmm | <mo|VERWEG> dan maar stoned worden en slashdot lezen:)
On Tue, 16 Mar 1999, Adam D. McKenna wrote: # groupadd shellusr # vi /etc/group # chown root.shellusr /bin/csh [...] etc.. Of course you need to be careful when doing this and make sure every user that could possibly need shell access is included (including any users that have cron jobs running under their UID).. etc.. but this is possible without modifying qmail (and taking out a very important feature). This may work but remember that qmail-lspawn does not set up any supplemental groups before running qmail-local, so you'd have to rely on the user's primary group to give them "|" capability in .qmail files. -- Jeff Hayward
At 08:43 AM 3/17/99 -0600, Jeff Hayward wrote: >On Tue, 16 Mar 1999, Adam D. McKenna wrote: > > # groupadd shellusr > # vi /etc/group > # chown root.shellusr /bin/csh > [...] > > etc.. Of course you need to be careful when doing this and make sure every > user that could possibly need shell access is included (including any users > that have cron jobs running under their UID).. etc.. but this is possible > without modifying qmail (and taking out a very important feature). > >This may work but remember that qmail-lspawn does not set up any >supplemental groups before running qmail-local, so you'd have to >rely on the user's primary group to give them "|" capability in >.qmail files. As usual Jeff makes a very good point. I'd like to look at the obverse side though. That the .qmail shell is invoked without supplemental groups means that you can use supplemental groups to allow that user different access when they access the system via means other than local delivery. One way? When users are created, their primary group is used to provide the most minimal file system access (which of course includes executables) that any user is allowed in any form and they are added to supplemental groups for access by other means, such as SMB, ftp, login, etc. Regards.
Hi, this is maybe not the place to ask, bnut here goes :)I'm running a Sun Sparc server w. solaris and qmail 1.03 - this machine will host multiple domains, now..how do i setup qmail to deliver mail for each domains in specefic folders etc - meaning that mail for [EMAIL PROTECTED] foes into /domains/domain1.com/bob and mail for [EMAIL PROTECTED] goes into /domains/domain2.co...and if anyone know's how to setup Imapd 4-5 from WU to to something similar that would be great :)again, sorry if this is the wrong place to ask - if anyone know of the right place / faq (and i don't think that the one one fra ftp://koobera.math.uic.edu/ is very explenatory :))#Daniel.
At 04:57 PM 3/17/99 +0100, Daniel V. Pedersen wrote:
Hi, this is maybe not the place to ask, bnut here goes :)
�
I'm running a Sun Sparc server w. solaris and qmail 1.03 - this machine will host multiple domains, now..
�
how do i setup qmail to deliver mail for each domains in specefic folders etc - meaning that mail for [EMAIL PROTECTED] foes into /domains/domain1.com/bob and mail for [EMAIL PROTECTED] goes into /domains/domain2.co...
I'd be inclined to read the file called FAQ that comes with the source
bundle. Specifically, items 3.2 and 3.3 talk about virtual domains.
Regards.
Any ideas what cause these types of errors? from maillog: Mar 17 07:31:09 1C:ella ipop3d[1417154]: Retrying after disk error user=spertus host=UNKNOWN mbx=/acct/faculty/spertus/mbox: Invalid argument from syslog.critical Mar 16 23:57:57 1C:ella ipop3d[1417154]: Retrying after disk error user=spertus host=206.111.145.243 mbx=/acct/faculty/spertus/mbox: Error 0
Samuel Dries-Daffner writes: > > Any ideas what cause these types of errors? > > from maillog: > > Mar 17 07:31:09 1C:ella ipop3d[1417154]: Retrying after disk error > user=spertus host=UNKNOWN mbx=/acct/faculty/spertus/mbox: Invalid argument > > > from syslog.critical > > Mar 16 23:57:57 1C:ella ipop3d[1417154]: Retrying after disk error > user=spertus host=206.111.145.243 mbx=/acct/faculty/spertus/mbox: Error 0 My guess would be a disk error, just what it says. Exactly why do you suspect some other reason? -- Sam
On Wed, 17 Mar 1999, Sam wrote: > > Mar 17 07:31:09 1C:ella ipop3d[1417154]: Retrying after disk error > > user=spertus host=UNKNOWN mbx=/acct/faculty/spertus/mbox: Invalid argument > > Mar 16 23:57:57 1C:ella ipop3d[1417154]: Retrying after disk error > > user=spertus host=206.111.145.243 mbx=/acct/faculty/spertus/mbox: Error 0 > > My guess would be a disk error, just what it says. Exactly why do you > suspect some other reason? Well, just that incoming mail for this user writes to /var/mail/spertus. I can't see why (or how) her POP client would be trying to write to /acct/faculty/spertus/mbox . Perhaps I am missing the obvious ;> Samuel
At 09:52 AM 3/17/99 -0800, Samuel Dries-Daffner wrote: > >On Wed, 17 Mar 1999, Sam wrote: > >> > Mar 17 07:31:09 1C:ella ipop3d[1417154]: Retrying after disk error >> > user=spertus host=UNKNOWN mbx=/acct/faculty/spertus/mbox: Invalid argument >> > Mar 16 23:57:57 1C:ella ipop3d[1417154]: Retrying after disk error >> > user=spertus host=206.111.145.243 mbx=/acct/faculty/spertus/mbox: Error 0 >> >> My guess would be a disk error, just what it says. Exactly why do you >> suspect some other reason? > >Well, just that incoming mail for this user writes to /var/mail/spertus. I >can't see why (or how) her POP client would be trying to write to >/acct/faculty/spertus/mbox . Perhaps I am missing the obvious ;> It might be more useful if you asked about ipop3d (whatever that is) on a list devoted to ipop3d. Call me dumb, but I'm not sure which part of qmail you think is relevant to an unrelated program complaining about "Invalid argument". Regards.
This error is generated by the popd daemon, I have seen it before and it took me FOREVER to track it down, I have no idea how they came up with the 'disk error' eroor message but what the problem actually is, is a lock fle in the users home directory. go into there directory, remove the lock file (I believe it is mbox.lock) and the problem should go away. It is afe to say that there isn't a problem with your hard-drive... Wil Boucher > -----Original Message----- > From: Mark Delany [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 17, 1999 11:57 AM > To: [EMAIL PROTECTED] > Subject: Re: delivery errors? > > > At 09:52 AM 3/17/99 -0800, Samuel Dries-Daffner wrote: > > > >On Wed, 17 Mar 1999, Sam wrote: > > > >> > Mar 17 07:31:09 1C:ella ipop3d[1417154]: Retrying after disk error > >> > user=spertus host=UNKNOWN mbx=/acct/faculty/spertus/mbox: Invalid > argument > >> > Mar 16 23:57:57 1C:ella ipop3d[1417154]: Retrying after disk error > >> > user=spertus host=206.111.145.243 > mbx=/acct/faculty/spertus/mbox: Error 0 > >> > >> My guess would be a disk error, just what it says. Exactly why do you > >> suspect some other reason? > > > >Well, just that incoming mail for this user writes to > /var/mail/spertus. I > >can't see why (or how) her POP client would be trying to write to > >/acct/faculty/spertus/mbox . Perhaps I am missing the obvious ;> > > It might be more useful if you asked about ipop3d (whatever that is) on a > list devoted to ipop3d. Call me dumb, but I'm not sure which part > of qmail > you think is relevant to an unrelated program complaining about "Invalid > argument". > > > Regards. >
At 12:14 PM 3/17/99 -0800, Wil Boucher wrote: >This error is generated by the popd daemon, I have seen it before and it >took me FOREVER to track it down, I have no idea how they came up with the >'disk error' eroor message but what the problem actually is, is a lock fle >in the users home directory. go into there directory, remove the lock file >(I believe it is mbox.lock) and the problem should go away. > >It is afe to say that there isn't a problem with your hard-drive... Nor qmail as it never uses lock files. Regards.
This is the first time I've posted to the list, so if I've missed something, kindly let me know... I checked the FAQ but didn't find anything... This is concerning the etrn solution I found at this URL: http://www.cqc.com/~pacman/projects/qmail-etrn/ I am currently using a P90/Redhat 5.2 test station using qmail-1.03 installed via the memphis rpm's. (qmail-1.03-11ucspi.i386.rpm, based on a src rpm) I then compiled the qmail-1.03, patched with etrn diff v0.1f on another test station also running Redhat 5.2 and the memphis 1.03 rpm. (only have a limited HD on the testing station) Compared the binaries from my existing /var/qmail/bin to qmail-1.03/ and moved in the changed binaries... Restarted... Took a bit to get the permissions on etrntrigger and /var/qmail/queue/lock/tcpto but it appears to be working... The etrn command is received and says ok.... But I'm not seeing an "instantaneous" outflow of held mail... I use qmHandle -l to see what's sitting in the queue, and I have the test mx10 go offline, watch the mail pool by watching for deferrals in the wmail log, and then I bring it back online and issue the etrn command via port 25... 250 ok... But no outgoing mail traffic... In amount 5-10minutes it will starting spooling out and everything is fine... The only thing I can think of is the patch isn't quite right... I have noticed that nothing shows up in qmail-tcpto but I've gotten varied results in regenerating qmail-tcpto tables for specific IP address on "unmodified" qmail installs... I can see healthy qmail-tcpto responses on our outgoing mail server, but everytime I trick it into holding email a specific IP using static mail routes I don't see it show up in the qmail-tcpto tables... Is 5-10 minutes response from an ETRN, in this configuration normal or? Any checks I can make to make sure that tcpto "tables"(?) are working ok... I have attempted to find other ETRN solutions, and have found mention of AutoTRN(?) but can't find anything concrete on it.... If you have URLs or leads on an ETRN package you can email me directly... Any input would be greatly appreciated... Andrew Spencer Qmail Admin / RMCI [EMAIL PROTECTED]
Disregard... UNIX 101: Don't bypass make install lightly... :) -Andrew Andrew Spencer wrote: > This is the first time I've posted to the list, so if I've missed > something, kindly let me know... > I checked the FAQ but didn't find anything... > > This is concerning the etrn solution I found at this URL: > http://www.cqc.com/~pacman/projects/qmail-etrn/ > > I am currently using a P90/Redhat 5.2 test station using qmail-1.03 > installed via the memphis rpm's. > (qmail-1.03-11ucspi.i386.rpm, based on a src rpm) > > I then compiled the qmail-1.03, patched with etrn diff v0.1f on another > test station also running Redhat 5.2 and the memphis 1.03 rpm. > (only have a limited HD on the testing station) > Compared the binaries from my existing /var/qmail/bin to qmail-1.03/ and > > moved in the changed binaries... > > Restarted... > > Took a bit to get the permissions on etrntrigger and > /var/qmail/queue/lock/tcpto but it appears to be working... > > The etrn command is received and says ok.... > > But I'm not seeing an "instantaneous" outflow of held mail... I use > qmHandle -l to see what's sitting in the queue, and I have the test mx10 > > go offline, watch the mail pool by watching for deferrals in the wmail > log, and then I bring it back online and issue the etrn command via port > > 25... 250 ok... > > But no outgoing mail traffic... In amount 5-10minutes it will starting > spooling out and everything is fine... > > The only thing I can think of is the patch isn't quite right... I have > noticed that nothing shows up in qmail-tcpto but I've gotten varied > results in regenerating qmail-tcpto tables for specific IP address on > "unmodified" qmail installs... I can see healthy qmail-tcpto responses > on our outgoing mail server, but everytime I trick it into holding email > > a specific IP using static mail routes I don't see it show up in the > qmail-tcpto tables... > > Is 5-10 minutes response from an ETRN, in this configuration normal or? > Any checks I can make to make sure that tcpto "tables"(?) are working > ok... > > I have attempted to find other ETRN solutions, and have found mention of > AutoTRN(?) but can't find anything concrete on it.... > If you have URLs or leads on an ETRN package you can email me > directly... > > Any input would be greatly appreciated... > > Andrew Spencer > Qmail Admin / RMCI > [EMAIL PROTECTED]
I've read the page about etrn, and I think the author made some mistakes (at least on his first page, I'm saying anything about the code). Maildir2smtp does NOT require a seperate queue to be created: you just let the mail be delivered at a normal mailbox, and when the person connects using POP3, maildir2smtp starts delivering mail to that ip address. This is a great advantage for when you're using dynamic ip addresses: you don't always know which ip address a client gets. This solution of etrn relies on the fact that all mail should stay in a queue. But why? In a maildir, you've much more control about the size (quota) and all, which I think is a feature many people appreciate. When mails stay in the queue, it can grow beyond your control and crash your own machine. So to summarize: use maildir2smtp, not etrn. > ---------- > From: Andrew Spencer[SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, March 17, 1999 9:44 PM > To: [EMAIL PROTECTED] > Subject: ETRN, qmail-1.03 and etrn patch v0.1f > > This is the first time I've posted to the list, so if I've missed > something, kindly let me know... > I checked the FAQ but didn't find anything... > > This is concerning the etrn solution I found at this URL: > http://www.cqc.com/~pacman/projects/qmail-etrn/ > > I am currently using a P90/Redhat 5.2 test station using qmail-1.03 > installed via the memphis rpm's. > (qmail-1.03-11ucspi.i386.rpm, based on a src rpm) > > > I then compiled the qmail-1.03, patched with etrn diff v0.1f on another > test station also running Redhat 5.2 and the memphis 1.03 rpm. > (only have a limited HD on the testing station) > Compared the binaries from my existing /var/qmail/bin to qmail-1.03/ and > > moved in the changed binaries... > > Restarted... > > Took a bit to get the permissions on etrntrigger and > /var/qmail/queue/lock/tcpto but it appears to be working... > > The etrn command is received and says ok.... > > But I'm not seeing an "instantaneous" outflow of held mail... I use > qmHandle -l to see what's sitting in the queue, and I have the test mx10 > > go offline, watch the mail pool by watching for deferrals in the wmail > log, and then I bring it back online and issue the etrn command via port > > 25... 250 ok... > > But no outgoing mail traffic... In amount 5-10minutes it will starting > spooling out and everything is fine... > > The only thing I can think of is the patch isn't quite right... I have > noticed that nothing shows up in qmail-tcpto but I've gotten varied > results in regenerating qmail-tcpto tables for specific IP address on > "unmodified" qmail installs... I can see healthy qmail-tcpto responses > on our outgoing mail server, but everytime I trick it into holding email > > a specific IP using static mail routes I don't see it show up in the > qmail-tcpto tables... > > Is 5-10 minutes response from an ETRN, in this configuration normal or? > Any checks I can make to make sure that tcpto "tables"(?) are working > ok... > > I have attempted to find other ETRN solutions, and have found mention of > AutoTRN(?) but can't find anything concrete on it.... > If you have URLs or leads on an ETRN package you can email me > directly... > > Any input would be greatly appreciated... > > > Andrew Spencer > Qmail Admin / RMCI > [EMAIL PROTECTED] >
Hello all and thanks in advance. Heres my problem. Mail seems to hang on all the clients sometime between lunch and 1:30. It happens everyday. And it only seems to be e-mail. I can telnet to the port locally and it seems fine. But from a remote system, no go. Any suggestions? I have checked everything I can think of. Is there someway to increase the debugging info? I dont see anything in the logs that shows a problem. Thanks Again Todd
Hi, please, help me. When I start qmail, this not run and in the /var/log/maillog apper this message: Mar 17 15:56:07 pegasus qmail: 921700567.838979 alert: cannot start: unable to switch to queue directory Because appear this message?.
On Thu, Mar 18, 1999 at 12:18:32AM +0000, Ernesto Miranda wrote: > Hi, please, help me. When I start qmail, this not run and in the > /var/log/maillog apper this message: > Mar 17 15:56:07 pegasus qmail: 921700567.838979 alert: cannot start: > unable to switch to queue directory > > Because appear this message?. Hmm.. nothing a good 'make setup check' can't fix I guess :) Greetz, Peter. -- .| Peter van Dijk | <mo|VERWEG> stoned worden of coden .| [EMAIL PROTECTED] | <mo|VERWEG> dat is de levensvraag | <mo|VERWEG> coden of stoned worden | <mo|VERWEG> stonend worden En coden | <mo|VERWEG> hmm | <mo|VERWEG> dan maar stoned worden en slashdot lezen:)
Hey Guys, This is just driving me crazy and I've tried everything I know. I'm getting Qmail setup on a new network. I've always used Qmail on the same as my machine nameserver. This network, however, has a dedicated name server and a dedicated mail machine. I get the standard error: <[EMAIL PROTECTED]>: 208.15.106.2 does not like recipient. Remote host said: 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1) Giving up on 208.15.106.2. All the tcp stuff is correct. And, I can actually send mail to virtual addresses from that machine (via pine, or Web-Based Programs) So where do I look? rcpthosts,virtualdomains,locals all look good. Thanks, MB -- Michael Bryan The Radio Cafe, LLC http://www.radiocafe.com
Michael Bryan writes: > <[EMAIL PROTECTED]>: > 208.15.106.2 does not like recipient. > Remote host said: 553 sorry, that domain isn't in my list of allowed > rcpthosts (#5.7.1) > Giving up on 208.15.106.2. > > All the tcp stuff is correct. And, I can actually send mail to virtual > addresses from that machine (via pine, or Web-Based Programs) > > So where do I look? rcpthosts,virtualdomains,locals all look good. You look into the manual page for qmail-smtpd, which explains how qmail-smtpd uses rcpthosts, and how it uses the RELAYCLIENT environment variable. Together with the knowledge of what your IP addresses are, this information is sufficient to be able to set up controlled relaying in your domain. -- Sam
Sam wrote: > > Michael Bryan writes: > > > <[EMAIL PROTECTED]>: > > 208.15.106.2 does not like recipient. > > Remote host said: 553 sorry, that domain isn't in my list of allowed > > rcpthosts (#5.7.1) > > Giving up on 208.15.106.2. > > > > All the tcp stuff is correct. And, I can actually send mail to virtual > > addresses from that machine (via pine, or Web-Based Programs) > > > > So where do I look? rcpthosts,virtualdomains,locals all look good. > > You look into the manual page for qmail-smtpd, which explains how > qmail-smtpd uses rcpthosts, and how it uses the RELAYCLIENT environment > variable. Together with the knowledge of what your IP addresses are, this > information is sufficient to be able to set up controlled relaying in your > domain. > > -- > Sam What I'm saying is that I've looked and looked and looked and can't see why it's not working. I've got Qmail running fine on other machines on different networks with virtual domains and correct relaying. What are things that I can check? I'd be happy to paste the contents of certain files. MB -- Michael Bryan The Radio Cafe, LLC http://www.radiocafe.com
Michael Bryan writes: > Sam wrote: > > > > Michael Bryan writes: > > > > > <[EMAIL PROTECTED]>: > > > 208.15.106.2 does not like recipient. > > > Remote host said: 553 sorry, that domain isn't in my list of allowed > > > rcpthosts (#5.7.1) > > > Giving up on 208.15.106.2. > > > > > > All the tcp stuff is correct. And, I can actually send mail to virtual > > > addresses from that machine (via pine, or Web-Based Programs) > > > > > > So where do I look? rcpthosts,virtualdomains,locals all look good. > > > > You look into the manual page for qmail-smtpd, which explains how > > qmail-smtpd uses rcpthosts, and how it uses the RELAYCLIENT environment > > variable. Together with the knowledge of what your IP addresses are, this > > information is sufficient to be able to set up controlled relaying in your > > domain. > > > > -- > > Sam > > What I'm saying is that I've looked and looked and looked and can't see > why it's not working. I've got Qmail running fine on other machines on > different networks with virtual domains and correct relaying. > > What are things that I can check? I'd be happy to paste the contents of > certain files. You check: A) The set of IP addresses that you're sending the mail from. B) The contents of control/rcpthosts. C) The mechanism by which you're setting the contents of the RELAYCLIENT environment variable, whether it's accomplished via tcpserver, a shell script, or by some other means. Those are the only three factors which affect whether an arbitrary recipient is accepted by qmail-smtpd. In each case, you declare not only what you THINK each item of information should be, but also provide some kind of an independent confirmation -- that you're verifying the contents of control/rcpthosts on the right machine; by running a trace to yourself to verify your actual IP address; by temporarily implementing some debugging code that accurately logs the contents of the environment just prior to qmail-smtpd being invoked, etc... -- Sam
Well, I successfully sent a message to an invalid address to eagle.co.nz. I'd guess it was a wierd patch, too. 921720265.618007 delivery 147849: failure: 202.36.45.1_does_not_like_recipient. /Remote_host_said:_550_<[EMAIL PROTECTED]>_user_unknown/Giving_up_on_202.36.45.1./ Aaron Quoting Harald Hanche-Olsen ([EMAIL PROTECTED]): > | At Mon Mar 15 18:22:27 1999 > | call from renaissance.co.nz/203.97.88.2 > | 220-relay ESMTP SMTP/smap Ready. > | 220 ESMTP tried here > | HELO renaissance.co.nz > | 250 (renaissance.co.nz) pleased to meet you. > | QUIT > | 221 Closing connection > | > | It looks as if the Qmail machine is connecting, passing a HELO > | command and then just QUITing. Can anyone explain to me what is > | going on here? > > As far as I can tell, this falls into the ``this cannot happen'' > category. I contacted the SMTP port on relay.eagle.co.nz myself, it > responds exactly as shown above, with each line CRLF terminated and no > fuzz about it. It looks like qmail-remote has stopped reading the > response after the first line (the one with the hyphen), leaving the > second line to be interpreted as the response to the HELO command. > But, as far as I can read the source in qmail-remote.c (the first few > lines in smtp() and all of smtpcode(), only ~20 lines in all) there is > no way this can happen. So unless this is a patched version of qmail, > I can see no rational explanation for this.
On Tue, Mar 16, 1999 at 10:08:27AM -0600, Bruno Wolff III wrote: > On Mon, Mar 15, 1999 at 06:13:15PM -0500, > Scott Schwartz <[EMAIL PROTECTED]> wrote: > > Peter van Dijk <[EMAIL PROTECTED]> writes: > > | But yes, it would consider these warnings as bounces. > > > > It also considers vacation messages to be bounces. :-( > > Vacation programs shouldn't be replying to lists. Lists should also identify themselves as lists so vacation programs don't reply to them. On this list in particular, when you subscribe, the ezmlm confirmation message doesn't include any of the magic cookies traditionally associated with daemon messages (such as "Precedence: junk" or "qmail-request"). My vacation program replied, and apparently that was enough to confirm my subscription. The confirmation process is a sham if it can be fooled so easily by vacation programs and autoresponders. -- Regards, Tim Pierce RootsWeb Genealogical Data Cooperative system obfuscator and hack-of-all-trades
>Lists should also identify themselves as lists so vacation programs >don't reply to them. > >On this list in particular, when you subscribe, the ezmlm confirmation >message doesn't include any of the magic cookies traditionally >associated with daemon messages (such as "Precedence: junk" or I see a "Precedence: bulk", which I seem to remember was the key for most vacation programs not responding. Or am I misremembering this? -- gowen -- Greg Owen -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] Please note my new [EMAIL PROTECTED] address which will become my default address in March, and which works now.
The syslog on my machine takes more resources than qmail in: exec env - PATH="/var/qmail/bin:$PATH" qmail-start ./Mailbox splogger qmail Is there a replacement for splogger that will log qmail's activity into its own log so that I won't have to use syslog? I also use tcpserver instead of inetd, and would like to log activity on those ports, too. Thanks, John -- John Conover, 631 Lamont Ct., Campbell, CA., 95008, USA. VOX 408.370.2688, FAX 408.379.9602 [EMAIL PROTECTED], http://www2.inow.com/~conover/john.html
John Conover wrote/schrieb/scribsit: > Is there a replacement for splogger that will log qmail's activity into > its own log so that I won't have to use syslog? > I also use tcpserver instead of inetd, and would like to log activity > on those ports, too. Use cyclog from djb's daemontools: http://pobox.com/~djb/daemontools.html Stefan
Hi Apology if this question has been asked a thousand time over. We have been seeing that certain of our client using us as their secondary mail server having problem dequeueing SOME mails. It is just SOME and NOT all mails for those particular domains that refuse to go down to them. It stays with us while the rest goes on fine with the dequeue. We have been observing this pattern for some months since we implemented in Qmail in Dec 98. Any one having this problem? Thanks in advance. EZWang
I'm quoting Timothy Mayo from his March 2 message titled "Re: DNS & /etc/hosts" >No, qmail does NOT use the resolver. Yes it makes direct DNS requests. ... >qmail NEVER uses /etc/hosts, period. It only uses DNS, regardless of how >you have set up your resolver. The only way to override the use of DNS is >by using /var/qmail/control/smtproutes. How does Qmail act as an outbound relay for a host who is not listed in DNS? I'm setting up a network which has two Qmail mail relays on the DMZ, and the mail server (mail store) on the internal network. The firewall allows the mail store to talk to the mail relays (and vice versa), and the mail relays to talk to the Internet (and vice versa). The mail relays are in DNS with MX values of 10 and 20. The mail store is not listed in Internet-accessible DNS, a standard security precaution. The mail relays use our ISP's DNS servers for all their resolution. Our ISP hosts our primary and secondary DNS servers as far as the Internet is concerned; our internal network has its own "primary" and "secondary" which provide DNS for internal hosts and which slave to the ISP's DNS servers for all else (as allowed by the firewall). When the internal host tried to send out via the relay (Yes, I've got RELAYCLIENT set via tcpserver), the relay complained that it couldn't find the mail store in DNS and therefore wouldn't accept the mail (I don't have a copy of the exact error message, but can get it if that makes a difference). Adding the internal mail store machine to /etc/hosts didn't help (as Timothy's message above would indicate). So what's the solution for this? 1) Add the mail store to Internet-available DNS? Security guidelines say not to do this, in order to deny information to attackers, but that's always seemed a pretty weak argument to me (once someone is in a position to use the information, they're in a position to gather the information pretty easily). 2) Set the firewall to allow the mail relays to query the INTERNAL DNS servers, which will know about this host and will forward other requests back out the firewall to the ISP's DNS server? Seems inefficient, and presumably is as bad or worse than #1 security wise (cracker need only break DMZ to get all DNS info, as opposed to breaking onto the internal network). 3) Set up a forwarding DNS server on the DMZ which knows about the internal mail store, but doesn't pass that info on to the Internet? 4) Entering an [dotted quad] into smtproutes fixes this on the inbound relay case. Is there a similar fax for the outbound relay case? 5) Everything else I haven't thought of ;> Surely I can't be the only one who's tried this. How do the rest of you handle this? Any help you can give is appreciated. I've got two weeks or more before this system needs to go live, so I can take the time to do the "right" solution rather than the expedient solution. -- gowen -- Greg Owen -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] Please note my new [EMAIL PROTECTED] address which will become my default address in March, and which works now.
> How does Qmail act as an outbound relay for a host who is not listed in >DNS? Ah, I think I just found my answer, on the qmail home page. "Dan Bernstein noted that qmail will skip dns queries for incoming mail with tcpserver -Hl your.host.name; and you can skip them for outgoing mail with control/smtproutes." I'll go check the tcpserver documentation, and if that doesn't clear it up I'll post any further questions. Sorry about that -- I searched the mailing list and the FAQ before posting, but didn't check the front qmail page. Maybe this should be in the FAQ? -- gowen -- Greg Owen -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] Please note my new [EMAIL PROTECTED] address which will become my default address in March, and which works now.
How are you starting qmail-smtpd? Are you using tcpserver or inetd? What is the command syntax you user for what you use? One possible solution, set up an outbound only relay machine in the DMZ that only accepts SMTP connections from your mail store machine and does not perform any DNS lookups on the IP connection. This can be done with tcpserver quite easily. On Wed, 17 Mar 1999, Greg Owen {gowen} wrote: > I'm quoting Timothy Mayo from his March 2 message titled "Re: DNS & > /etc/hosts" > > >No, qmail does NOT use the resolver. Yes it makes direct DNS requests. > ... > >qmail NEVER uses /etc/hosts, period. It only uses DNS, regardless of how > >you have set up your resolver. The only way to override the use of DNS is > >by using /var/qmail/control/smtproutes. > > How does Qmail act as an outbound relay for a host who is not listed in > DNS? > > I'm setting up a network which has two Qmail mail relays on the DMZ, and > the mail server (mail store) on the internal network. The firewall allows > the mail store to talk to the mail relays (and vice versa), and the mail > relays to talk to the Internet (and vice versa). > > The mail relays are in DNS with MX values of 10 and 20. > > The mail store is not listed in Internet-accessible DNS, a standard > security precaution. The mail relays use our ISP's DNS servers for all > their resolution. Our ISP hosts our primary and secondary DNS servers as > far as the Internet is concerned; our internal network has its own "primary" > and "secondary" which provide DNS for internal hosts and which slave to the > ISP's DNS servers for all else (as allowed by the firewall). > > When the internal host tried to send out via the relay (Yes, I've got > RELAYCLIENT set via tcpserver), the relay complained that it couldn't find > the mail store in DNS and therefore wouldn't accept the mail (I don't have a > copy of the exact error message, but can get it if that makes a difference). > Adding the internal mail store machine to /etc/hosts didn't help (as > Timothy's message above would indicate). > > So what's the solution for this? > > 1) Add the mail store to Internet-available DNS? Security guidelines > say not to do this, in order to deny information to attackers, but that's > always seemed a pretty weak argument to me (once someone is in a position to > use the information, they're in a position to gather the information pretty > easily). > > 2) Set the firewall to allow the mail relays to query the INTERNAL DNS > servers, which will know about this host and will forward other requests > back out the firewall to the ISP's DNS server? Seems inefficient, and > presumably is as bad or worse than #1 security wise (cracker need only break > DMZ to get all DNS info, as opposed to breaking onto the internal network). > > 3) Set up a forwarding DNS server on the DMZ which knows about the > internal mail store, but doesn't pass that info on to the Internet? > > 4) Entering an [dotted quad] into smtproutes fixes this on the inbound > relay case. Is there a similar fax for the outbound relay case? > > 5) Everything else I haven't thought of ;> > > > Surely I can't be the only one who's tried this. How do the rest of you > handle this? > > Any help you can give is appreciated. I've got two weeks or more before > this system needs to go live, so I can take the time to do the "right" > solution rather than the expedient solution. > > -- > gowen -- Greg Owen -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] > > Please note my new [EMAIL PROTECTED] address which will > become my default address in March, and which works now. > > --------------------------------- 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
Greg Owen {gowen} wrote: > How does Qmail act as an outbound relay for a host who is not listed in > DNS? > > I'm setting up a network which has two Qmail mail relays on the DMZ, and > the mail server (mail store) on the internal network. The firewall allows > the mail store to talk to the mail relays (and vice versa), and the mail > relays to talk to the Internet (and vice versa). Greg, Check out the O'Reilly book "Building Internet Firewalls" (? may be slightly wrong title). It has a lot of useful suggestions which may help you. I have a similar setup, ie mail is received by a "bastion host" on our perimeter network (DMZ) and forwarded to the internal mail host on our internal network through a router doing address translation, ie the internal network uses 172.16.x. I acually use QMQP to transfer mail from the bastion host to the internal mail host. The bastion host runs qmail-smtpd to receive incoming mail, and uses qmail-qmqpc to send it all through the firewall to the internal mail host. No mail is delivered locally on the bastion host; all locally generated system mail is delivered to the internal mail host. I don't bother using the bastion host as an outgoing relay; I send all mail direct from the internal mail host. There's not really much more of a security rick since you only have to open up the router for outgoing packets (from what I can gather). Though it wouldn't be too much trouble allowing the internal machine to use the bastion host as an outgoing relay as the bastion host uses the "internal" DNS ie as specified in resolv.conf. > 1) Add the mail store to Internet-available DNS? Security guidelines > say not to do this, in order to deny information to attackers, but that's > always seemed a pretty weak argument to me (once someone is in a position to > use the information, they're in a position to gather the information pretty > easily). Nope. > > 2) Set the firewall to allow the mail relays to query the INTERNAL DNS > servers, which will know about this host and will forward other requests > back out the firewall to the ISP's DNS server? Seems inefficient, and > presumably is as bad or worse than #1 security wise (cracker need only break > DMZ to get all DNS info, as opposed to breaking onto the internal network). This is what I do. > > 3) Set up a forwarding DNS server on the DMZ which knows about the > internal mail store, but doesn't pass that info on to the Internet? Nope. You seem to be confusing DNS server and DNS client. You can specify that the bastion host uses the internal DNS to resolve names for its own processes and run a DNS server on the same box containing completely different information. > 4) Entering an [dotted quad] into smtproutes fixes this on the inbound > relay case. Is there a similar fax for the outbound relay case? Why not send outgoing mail directly? R. -- Two rules to success in life: 1. Don't tell people everything you know. -- Sassan Tat
Short summary: I screwed something up and bounced a lot of mail. It seems to me that the mistake I made could be handled differently, and I'd just like to explore it as an idea, see if it makes sense to anyone else. I'm not blaming qmail or saying "qmail should definitely do this." I'm just exploring an idea. I have 2 qmail mail relays. Currently, they forward all mail to a Xerox mail relay, which then relays it through the Xerox firewall to the (ex-)Xerox company where I work. We are migrating to our own network, and yesterday we installed the firewall and planned to go live. (We didn't go live because of other problems that cropped up). As part of the attempted switch, I took down the internal mail server to transfer its files to the new mail server (the old one will remain up as a Xerox host for a while). Since I expected the new mail server would be accepting mail by the end of the day, I stopped the mail relays from passing mail onto the Xerox relay. I did this by configuring smtproutes to route to an (unreachable) internal network address. We spent the entire day setting up the firewall and running tests on a small test network. Several tests failed, so at 4:30 we gave up on the plan to switch users over and re-enabled the old (Xerox) internal mail server. Then I reconfigured the external mail relays to relay through Xerox again. Unfortunately, after a long day of intensive work with 5 subnets and 2 domain names, I messed up and reset the smtproutes file on the main relay to "mailer-east.scansoft.com" instead of "mailer-east.xerox.com," the Xerox relay. Of course, "mailer-east.scansoft.com" doesn't exist. Qmail looked it up in DNS, found it didn't exist, and bounced the 300 or so messages in its queue back to their senders. I didn't think that was a lot of mail, but the VP of Sales sure did ;>. Now, it seems to me that a case where the smtproutes - an internal control file set by the mail administrator - is wrong like that, might be treated differently. Perhaps rather than bouncing the (innocent ;>) mail messages, they could remain queued, and mail be sent to the postmaster. Of course, if the postmaster is relayed to that smtproute, he wouldn't get it, but presumably he'd notice sooner or later that a) he wasn't getting mail from that system he just modified and b) the disks on it were filling up. Again presumably, he'd check the logs, see the error messages that clue him in to his internal mistake, and let him fix it without losing mail. Obviously, qmail requires almost everything to be kosher DNS wise for security and spam reasons. But it seems to me an invalid smtproute is pretty clearly an administrator error as opposed to an attempt to spoof, overload, enter, or otherwise attack the server. So, what do you think of the following ideas? 1) qmail could treat unresolvable hosts in its control files as operator errors and leave affected mail in the queue rather than bouncing, and also try to notify the operator. 2) Perhaps changes to control files could somehow require something like qmail-lint that checks stuff like this? (I note qmail-lint doesn't check smtproutes). But the key would be requiring a check made before changes would take affect. The key to this question is, it seems to me that some changes (like smtproutes) take affect immediately, and that limits checkability. Or maybe I'm misunderstanding... 3) get a smarter and more careful sysadmin. For the obvious reasons, I heartily disapprove of this option. Any thoughts on all this? -- gowen -- Greg Owen -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] Please note my new [EMAIL PROTECTED] address which will become my default address in March, and which works now.
On Tue, 16 Mar 1999, Dave Sill wrote: > >> Brad Shelton <[EMAIL PROTECTED]> wrote: > >> > > >> >All you have to do is create it as root and make it readable by the mail > >> >process for the user. They can read it, but they can't replace it. > >> > >> Not true. If the user can write the directory, they can replace it. > > > >They can _read_ it, but not write to it at all. :-) Maildir and other > >files / directories must be made by root and chown'ed to the user. > > I didn't say "write", I said "replace". E.g.: > > Script started on Tue Mar 16 15:39:17 1999 > sh-2.00$ ls -la > total 40 > drwxr-xr-x 2 de5 user 40 Mar 16 15:39 . > drwxr-xr-x 54 de5 user 20480 Mar 16 15:37 .. > -r--r--r-- 1 root sys 0 Mar 16 15:38 bar > -rw-r--r-- 1 de5 user 0 Mar 16 15:39 typescript > sh-2.00$ cat bar > sh-2.00$ echo foo>bar > sh: bar: Permission denied > sh-2.00$ rm bar > bar: 444 mode. Remove ? (yes/no)[no] : y > sh-2.00$ ls -la > total 40 > drwxr-xr-x 2 de5 user 28 Mar 16 15:39 . > drwxr-xr-x 54 de5 user 20480 Mar 16 15:37 .. > -rw-r--r-- 1 de5 user 0 Mar 16 15:39 typescript > sh-2.00$ exit > > script done on Tue Mar 16 15:39:53 1999 I know my UNIX quite well, thank you.. It's obvious that you can remove directory-entries owned by anyone, in a directory owned by you. That has nothing to do with the suggestion though, that the _home-directory_ of the user should be owned by root. Perhaps you thought it was Maildir which should be owned by root?.. > -Dave
