Re: When will qmail back off to the next MX?
Russell Nelson wrote: [EMAIL PROTECTED] writes: Russell Nelson wrote: A host that persistently refuses to run the SMTP protocol on the SMTP port cannot be said to be running SMTP. So why not fall back to another one that does? Because you claimed that it was speaking SMTP. Upon examination, it isn't. Your MX records are false. Why should I send your server any mail at all, since it may not be the right server at all? If it isn't speaking SMTP right then, it's BROKEN right then. But that's no different than if it isn't accepting connections right then, which is also a case of it's BROKEN right then. Either way it's BROKEN right then. Now you can just requeue the mail and try again later. If you do, then you are presuming that perhaps it will be fixed later on, but before the expiration of the mail. So why not send the mail on to at least the WORKING secondary MX? That at least gets it out of your queue, putting the storage burden on whoever is supposedly doing queueing service for the crappy server. Tell them to fix their SMTP servers, don't work around their breakage. Isn't the design philosophy of the Internet supposed to be one where it is desireable to work around breakage? Nope, because if you do that, people never notice the breakage. If something is working (even if it takes special efforts to keep it working, e.g. contacting the wrong host first), they quite reasonably conclude that it isn't broken, and they don't fix it. How is it that people won't notice the breakage if the primary mail server isn't accepting mail? If the server accepts connections, and then keeps closing them, it's not going to get its mail even from then secondary MX. I think they will eventually notice they are not getting their mail if it disconnects just the same as if it was refusing connections. Doesn't this really come down to a difference between the WAY a mail server is broken? But I'm not seeing any argument about why the WAY it is broken is more important than merely the fact that it is broken. -- Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] at| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] dot| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: http://pobox.com/~djb/ezmlm.html
On Sat, Sep 18, 1999 at 01:54:40AM -0500, Mark Thomas wrote: I am trying to setup qmail for the first time. Being a newbie to Linux, I need all of the help I can get. I keep seing references to this, but I cannot see anything under pobox.com/. I even got this message after signing up to this mailing list. See http://pobox.com/~djb/qmail.html for more information about qmail. Please read http://pobox.com/~djb/qmail/faq.html before sending your question to the qmail mailing list. Just follow these instructions literally. Don't try to "see anything under pobox.com," whatever that might mean. Access the cited URLs, and there you will find the desired information. Chris
Re: http://pobox.com/~djb/ezmlm.html
On Sat, 18 Sep 1999, Mark Thomas wrote: Also Setting up User Masquerading, mentions adding statements to your environment. Is this one of the .files in my home directory? Nope. It is issuing export QMAILUSER='your_localpart_to_appear' -like commands in your profile file depending on which shell you use (eg. .bash_profile in bash) Of course it works only on locally queued messages (not on SMTP). Robert Varga
Re: US encyrption laws relaxed - way to go Dan!
http://www.wired.com/news/news/politics/story/21790.html I think that's the article forwarded to this list that I just read [...] That's what I thought when I first saw it posted, but it's a different article with a different slant. It is referenced in the one posted tho. Thanks, I just read that one! Indeed, it's the only one that forthrightly dealt with *my* big concern, which is, does this mean free software can include crypto without concern? Answer: no. (I should have realized the from the other articles, of course, but didn't really grok the gummint-review requirement as limiting free software. Mostly I was thinking about how the concern about proprietary software being wilfully broken by agreement between the vendor and the gummint to ensure back-door access would make free-software, i.e. OS, products *that* much more attractive: it's harder to hide bugs in source code, especially when anyone can read it.) tq vm, (burley)
qmail LWQ installation problem - qmail doesn't seem executable
All, So I'm installing qmail on my RedHat 6 distrubution a la the "Life with qmail" document, and its going great (I've been doing a little each day all week) until section 2.8.2 when I am suppposed to type "/usr/local/sbin/qmail cdb" Well, I do this, and I get "bash: /usr/local/sbin/qmail: No such file or directory" So I do an ls -l and see the qmail entry in /usr/local/sbin is the link to: "qmail - /etc/rc.d/init.d/qmail" and its permission is "lrwxrwxrwx" In checking /etc/rc.d/init.d/, i see that qmail is the executable script "qmail" frmom the beginning of section 2.8.2, but I can't execute it here either. It looks like: [root@lllama init.d]# qmail bash: qmail: command not found [root@lllama init.d]# ./qmail bash: ./qmail: No such file or directory [root@lllama init.d]# ls apmd functions inet linuxconf network qmail rusersd smb syslog atdgpminnd lpdnfs random rwhod snmpd xfs core halt keytable named pcmcia routed sendmail sound ypbind crond httpd killall netfs portmap rstatd singlesshd See? There is is. qmail. With -rwxr-xr-x permissions. Can anybody suggest where I should go from here? If I just pretend this step went ok and keep going, it doesn't even start up. (I'ce reboot to make sure things are clean-ish). See? [root@lllama init.d]# /usr/local/sbin/qmail start bash: /usr/local/sbin/qmail: No such file or directory Any thoughts anyone? Virtually, Warr [EMAIL PROTECTED]
Re: qmail LWQ installation problem - qmail doesn't seem executable
Warren 'Llama' Ernst wrote: All, So I'm installing qmail on my RedHat 6 distrubution a la the "Life with qmail" document, and its going great (I've been doing a little each day all week) until section 2.8.2 when I am suppposed to type "/usr/local/sbin/qmail cdb" Well, I do this, and I get "bash: /usr/local/sbin/qmail: No such file or directory" So I do an ls -l and see the qmail entry in /usr/local/sbin is the link to: "qmail - /etc/rc.d/init.d/qmail" and its permission is "lrwxrwxrwx" In checking /etc/rc.d/init.d/, i see that qmail is the executable script "qmail" frmom the beginning of section 2.8.2, but I can't execute it here either. It looks like: [root@lllama init.d]# qmail bash: qmail: command not found [root@lllama init.d]# ./qmail bash: ./qmail: No such file or directory [root@lllama init.d]# ls apmd functions inet linuxconf network qmail rusersd smb syslog atdgpminnd lpdnfs random rwhod snmpd xfs core halt keytable named pcmcia routed sendmail sound ypbind crond httpd killall netfs portmap rstatd singlesshd See? There is is. qmail. With -rwxr-xr-x permissions. Can anybody suggest where I should go from here? If I just pretend this step went ok and keep going, it doesn't even start up. (I'ce reboot to make sure things are clean-ish). See? [root@lllama init.d]# /usr/local/sbin/qmail start bash: /usr/local/sbin/qmail: No such file or directory Any thoughts anyone? Virtually, Warr [EMAIL PROTECTED] Warr, Check the top line of the qmail file. It will name a program to be run to process the qmail script. Check to make sure that this program exists on your system and is runnable. For example, if the program is named as: #!/bin/sh Make sure that /bin/bash exists and is runnable on your system. Linux will report "no such file or directory" for a script which names an interpreter which does not exist or is not runnable. It's cryptic, I know. Someone should fix it :) ... Best wishes, Bryan -- Bryan Ischo [EMAIL PROTECTED]1995 Honda VFR750 Yonkers, NY, USAhttp://www.ischo.comRedHat Linux 6.0
Re: qmail LWQ installation problem - qmail doesn't seem executable
"Bryan J. Ischo" wrote: Warr, Check the top line of the qmail file. It will name a program to be run to process the qmail script. Check to make sure that this program exists on your system and is runnable. For example, if the program is named as: #!/bin/sh Make sure that /bin/bash exists and is runnable on your system. Linux will report "no such file or directory" for a script which names an interpreter which does not exist or is not runnable. It's cryptic, I know. Someone should fix it :) ... Sorry everyone, in my haste to get the email out I made a typographical error ... it should read: For example, if the program is named as: #!/bin/sh Make sure that /bin/sh exists and is runnable on your system. On Linux it's all /bin/bash anyway. I'd be surprised if Warr's Linux box didn't have a working /bin/bash, or /bin/sh wasn't properly linked to /bin/bash, but ... it's an easy thing to check. Thanks, Bryan -- Bryan Ischo [EMAIL PROTECTED]1995 Honda VFR750 Yonkers, NY, USAhttp://www.ischo.comRedHat Linux 6.0
RE: http://pobox.com/~djb/ezmlm.html
Hold on a minute! I you said what I think you said, I have a really odd problem here. I am reading the installation documentation for Qmail 1.03. All over the document, it says to go read this or that, or download this or that from the Pobox.com address. When you double click on this address(or cut and paste it), do you get to this site, or do you get errors. Http://www.pobox.com/~djb/qmail.html Because, if you can get there, I have a real funny problem. Because I use Pobox.com for my mail redirector, and I frequent their site, I just can't get to ~djb/ under pobox.com. Please clarify,, MarkT. Thanks, -Original Message- From: Chris Johnson [mailto:[EMAIL PROTECTED]] Sent: Saturday, September 18, 1999 2:52 AM To: Mark Thomas Cc: [EMAIL PROTECTED] Subject: Re: http://pobox.com/~djb/ezmlm.html On Sat, Sep 18, 1999 at 01:54:40AM -0500, Mark Thomas wrote: I am trying to setup qmail for the first time. Being a newbie to Linux, I need all of the help I can get. I keep seing references to this, but I cannot see anything under pobox.com/. I even got this message after signing up to this mailing list. See http://pobox.com/~djb/qmail.html for more information about qmail. Please read http://pobox.com/~djb/qmail/faq.html before sending your question to the qmail mailing list. Just follow these instructions literally. Don't try to "see anything under pobox.com," whatever that might mean. Access the cited URLs, and there you will find the desired information. Chris
RE: When will qmail back off to the next MX?
On Fri, 17 Sep 1999, Greg Owen wrote: But the Xerox servers aren't accepting a connection. The apparent accepted connection is a side effect of the Raptor proxy firewall. If that firewall wasn't in the way, they'd just refuse connection and qmail would back off to the next MX immediately. What is an "apparent accepted connection?" The connection is accepted when the TCP handshake completes -- what has not happened is an SMTP session. The Raptor is then slamming the door post-connection, in the same manner as a TCP wrapper might. The correct behavior would be to return a RST rather than do the handshake at all. That the Raptor is accepting the connect for the MX's IP address is no excuse -- indeed, it's the problem. I have verified that Gauntlet does not show this behavior. It's a Raptor thing (and possibly one of other proxy firewalls that launch each proxy on all interfaces as if using inetd). Moreover, it could be looked at as a misconfigured Raptor thing, since Raptor has IP-level packet filters that could easily be used to drop the inbound packets before they reach the Raptor's listening application on the "wrong" interface, or (perhaps - I don't know how fancy that filtering is) RST on the attempted connect. The Raptor tech we talked with said one has to use the filters to prevent listening ports from being reached on untrusted interfaces. Tell them to fix their SMTP servers, don't work around their breakage. If anyone is broken here, its my firewall, not their mail setup. No one here LIKES their mail setup, but that doesn't make it broken; it conforms with all relevant RFCs that I'm aware of. Now, THAT I will agree with, mostly. What is broken is the aggregate setup - one side or the other should be adjusted. If you want an unreachable MX, then the firewall should not act like a broken mail server. OTOH, as is often done with Gauntlet, you can have the firewall accept, proxy the mail service, accept as if it were the primary MX and then move it along to the real primary. -M Michael Brian Scher (MS683/MS3213) Anthropologist, Attorney, Policy Analyst Mainlining Internet Connectivity for Fun and Profit [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Give me a compiler and a box to run it, and I can move the mail.
Re: When will qmail back off to the next MX?
Make it configurable. ok, i get the point. i would say that it IS configurable in that different MTA's can handle it however they want. making it configurable at an even lower level would seem to be a rather difficult project and not something you could do without at least patching and rebuilding. that is, i don't think you could just have a simple qmail control file that detailed MX handling unless all the policies were already built into the source anyway. i do agree that fallback MX handling is an issue of policy and not function. an RFC would be the ideal way to answer these. doing it "like everyone else does" isn't valid. doing it "the way sendmail does" is even worse. Agreed. But in some cases I have found things can work better by violating RFCs. I don't like to distribute software that violates the RFCs, unless it would do so only if the administrator gets to choose to do so, and is aware that such a choice is a violation. I have no qualms about distributing or using any software that works that way. that's fine except in this case there IS no rfc to provide a baseline. there's "the way sendmail does it", which is in a sense a de facto standard, but it's only a standard because way back when, Eric Allman made some decisions about MX handling and for better or worse we're stuck with his decisions. Sticking to standards does have an important purpose. Deviating from them should never be done lightly. But it should not be ruled out, either. In many cases, such deviations have to be done to fully evaluate a proposed change in the standards. And sometimes, old standards are not re-visited because de-factor standards born out of deviant usage have established themselves and there is no pressure to formalize them when other standards work is more pressing. qmail is deviating from the established standard and handling things its own way. is it better or right? i don't know, there really hasn't been enough discussion. There is also another saying common in computers and networking, especially in regard to conformance to standards: Be conservative in what you produce and be liberal in what you accept. I have interpreted that to mean that if something does not conform to the standard, but I also don't have to go out of my way to detect and understand what is meant, I _may_ (and some would like this to be _should_) go ahead and accept it with the obvious semantics. the first part i agree with. the second part i'm not so sure about. my take on it is that programs should be prepared to handle any input. "handle" does not mean process necessarily, it just means that for any input, the program should have defined behavior. this means that the program has a very limited set of inputs and very well defined behaviors. if the inputs are bad, the program refuses the input. i do NOT believe that "liberal" means "should attempt to rectify problems automatically." report the problem, sure, and don't crash because the input is too big or malformed, but don't attempt to fix the problem. GIGO. I don't know of any protocol that specifically says that accepting a connection and then summarily dropping it with no output has any particular meaning in that standard. But I would readily classify this as a failure not unlike a connection refusal. I recognize this because I happen to know that there are cases where this is unavoidable. One example is that the UNIX socket API is a deficient standard for lacking the ability to allow user space processes to act on an incoming connection in a way that is seen as a connection refusal. how fast does it have to be dropped to be "summarily" dropped? 1 second? 5? 30? at what point does the connection become "established, but timed out, will try later" instead of "connection refused or immediately dropped?" shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur.
Trivial Messages from Qmail
I have installed Qmail on my system and in the process for tweaking it. The TEST.deliver document says, I should expect to see the following messages in the SYSLOG. qmail: new msg 53 qmail: info msg 53: bytes 246 from me@domain qp 20345 uid 666 qmail: starting delivery 1: msg 53 to local me@domain qmail: status: local 1/10 remote 0/20 qmail: delivery 1: success: did_1+0+0/ qmail: status: local 0/10 remote 0/20 qmail: end msg 53 My SYSLOG, however, shows the following messages. Sep 18 14:27:18 myhost qmail: 937679238.126089 new msg 1756430 Sep 18 14:27:18 myhost qmail: 937679238.127301 info msg 1756430: bytes 772 from qp 8948 uid 1011 Sep 18 14:27:18 myhost qmail: 937679238.129305 starting delivery 4: msg 1756430 to local [EMAIL PROTECTED] Sep 18 14:27:18 myhost qmail: 937679238.130491 status: local 1/10 remote 0/20 Sep 18 14:27:18 myhost qmail: 937679238.357111 delivery 4: success: did_1+0+0/ Sep 18 14:27:18 myhost qmail: 937679238.358461 status: local 0/10 remote 0/20 Sep 18 14:27:18 myhost qmail: 937679238.358690 end msg 1756430 My concern is the numbers. For example 53 as opposed to 1756430. What are the number 937679238.126089? Can anyone explain this please? Thank you in advance. Subba Rao [EMAIL PROTECTED] == Disclaimer - I question and speak for myself. http://pws.prserv.net/truemax/ __
Qmail as a forwarder
Dear group, I was wondering howcan I setup Qmail so that it forwards all incoming mail to another host.. I have a firewall and it would be useful to have a non-mission-critical mail server acting as the smtp server for our domain. The other mail machine we have is an exchange box and if it were attacked we would lose the ability to communicate both internally externally.. Any ideas? Julian
setuser command not found
I am following the instruction in 10b of the FAQ. When I try the command with "supervise .." I get the message saying, bash: setuser: command not found Any idea, which package has the "setuser" command? THank you in advance for any help. Subba Rao [EMAIL PROTECTED] == Disclaimer - I question and speak for myself. http://pws.prserv.net/truemax/ __
Virtual hosts
I'm setting up a pop server for remote hosts and as I have a lot of domain names I need to use virtual hosts. What should I use for the address in the me file in /var/qmail/control? I currently have my IP only in there and my Vhosts are in rcpthosts and virtualhosts Cheers, -- Marek Narkiewicz, Webmaster Intercreations Reply to -marek @ intercreations . com- "Ticking away, the moments that make up a dull day" Pink Floyd Time
Re: setuser command not found
* Subba Rao ([EMAIL PROTECTED]) [18 Sep 1999 16:25]: I am following the instruction in 10b of the FAQ. When I try the command with "supervise .." I get the message saying, bash: setuser: command not found Any idea, which package has the "setuser" command? It is part of the daemontools 0.53 package. The newer 0.61 version is completely different and uses setuidgid. -- Quist ConsultingEmail: [EMAIL PROTECTED] 219 Donlea DriveVoice: +1.416.696.7600 Toronto ON M4G 2N1 Fax: +1.416.978.6620 CANADA WWW: http://www.quist.on.ca
Re: setuser command not found
accustamp is replaced with tai64n, and cyclog has been replaced with multilog. multilog does timestamps itself, too, so you don't actually need tai64n. Jim Lippard [EMAIL PROTECTED] http://www.discord.org/ Unsolicited bulk email charge: $500/message. Don't send me any. PGP Fingerprint: 0C1F FE18 D311 1792 5EA8 43C8 7AD2 B485 DE75 841C On Sat, 18 Sep 1999, Subba Rao wrote: What about "accustamp" and "cyclog"? I can't seem to find them. If they are under different names, what could they be. Thank you in advance. Subba Rao [EMAIL PROTECTED] == Disclaimer - I question and speak for myself. http://pws.prserv.net/truemax/ __ On Sat, 18 Sep 1999 16:35:43 -0400, Russell P. Sutherland wrote: * Subba Rao ([EMAIL PROTECTED]) [18 Sep 1999 16:25]: I am following the instruction in 10b of the FAQ. When I try the command with "supervise .." I get the message saying, bash: setuser: command not found Any idea, which package has the "setuser" command? It is part of the daemontools 0.53 package. The newer 0.61 version is completely different and uses setuidgid. -- Quist Consulting Email: [EMAIL PROTECTED] 219 Donlea Drive Voice: +1.416.696.7600 Toronto ON M4G 2N1 Fax: +1.416.978.6620 CANADA WWW: http://www.quist.on.ca
Re: setuser command not found
Thank you. The commands suggested in 10b. rblsmtpd, should they be executed as root or a qmail account (which one?)? Thank you once again. Subba Rao [EMAIL PROTECTED] == Disclaimer - I question and speak for myself. http://pws.prserv.net/truemax/ __ On Sat, 18 Sep 1999 14:00:02 -0700 (MST), James J. Lippard wrote: accustamp is replaced with tai64n, and cyclog has been replaced with multilog. multilog does timestamps itself, too, so you don't actually need tai64n. Jim Lippard [EMAIL PROTECTED] http://www.discord.org/ Unsolicited bulk email charge: $500/message. Don't send me any. PGP Fingerprint: 0C1F FE18 D311 1792 5EA8 43C8 7AD2 B485 DE75 841C On Sat, 18 Sep 1999, Subba Rao wrote: What about "accustamp" and "cyclog"? I can't seem to find them. If they are under different names, what could they be. Thank you in advance. Subba Rao [EMAIL PROTECTED] == Disclaimer - I question and speak for myself. http://pws.prserv.net/truemax/ __ On Sat, 18 Sep 1999 16:35:43 -0400, Russell P. Sutherland wrote: * Subba Rao ([EMAIL PROTECTED]) [18 Sep 1999 16:25]: I am following the instruction in 10b of the FAQ. When I try the command with "supervise .." I get the message saying, bash: setuser: command not found Any idea, which package has the "setuser" command? It is part of the daemontools 0.53 package. The newer 0.61 version is completely different and uses setuidgid. -- Quist ConsultingEmail: [EMAIL PROTECTED] 219 Donlea DriveVoice: +1.416.696.7600 Toronto ON M4G 2N1 Fax: +1.416.978.6620 CANADA WWW: http://www.quist.on.ca
Re: setuser command not found
rblsmtpd/qmail-smtpd should be run as user qmaild; that is usually done using tcpserver. Jim Lippard [EMAIL PROTECTED] http://www.discord.org/ Unsolicited bulk email charge: $500/message. Don't send me any. PGP Fingerprint: 0C1F FE18 D311 1792 5EA8 43C8 7AD2 B485 DE75 841C On Sat, 18 Sep 1999, Subba Rao wrote: Thank you. The commands suggested in 10b. rblsmtpd, should they be executed as root or a qmail account (which one?)? Thank you once again. Subba Rao [EMAIL PROTECTED] == Disclaimer - I question and speak for myself. http://pws.prserv.net/truemax/ __ On Sat, 18 Sep 1999 14:00:02 -0700 (MST), James J. Lippard wrote: accustamp is replaced with tai64n, and cyclog has been replaced with multilog. multilog does timestamps itself, too, so you don't actually need tai64n. Jim Lippard [EMAIL PROTECTED] http://www.discord.org/ Unsolicited bulk email charge: $500/message. Don't send me any. PGP Fingerprint: 0C1F FE18 D311 1792 5EA8 43C8 7AD2 B485 DE75 841C On Sat, 18 Sep 1999, Subba Rao wrote: What about "accustamp" and "cyclog"? I can't seem to find them. If they are under different names, what could they be. Thank you in advance. Subba Rao [EMAIL PROTECTED] == Disclaimer - I question and speak for myself. http://pws.prserv.net/truemax/ __ On Sat, 18 Sep 1999 16:35:43 -0400, Russell P. Sutherland wrote: * Subba Rao ([EMAIL PROTECTED]) [18 Sep 1999 16:25]: I am following the instruction in 10b of the FAQ. When I try the command with "supervise .." I get the message saying, bash: setuser: command not found Any idea, which package has the "setuser" command? It is part of the daemontools 0.53 package. The newer 0.61 version is completely different and uses setuidgid. -- Quist Consulting Email: [EMAIL PROTECTED] 219 Donlea Drive Voice: +1.416.696.7600 Toronto ON M4G 2N1 Fax: +1.416.978.6620 CANADAWWW: http://www.quist.on.ca
Re: setuser command not found
On Sat, 18 Sep 1999 14:10:21 -0700 (MST), James J. Lippard wrote: rblsmtpd/qmail-smtpd should be run as user qmaild; that is usually done using tcpserver. Jim Lippard [EMAIL PROTECTED] http://www.discord.org/ Thanks again for replying. Each time I make progress, I seem to be hitting a new road block. The following are the contents of my /var/qmail directory total 12 drwxr-xr-x 10 root qmail1024 Sep 18 17:20 ./ drwxr-xr-x 20 root root 1024 Aug 28 17:52 ../ drwxr-sr-x 2 aliasqmail1024 Aug 29 07:03 alias/ drwxr-xr-x 2 root qmail1024 Aug 28 17:59 bin/ drwxr-xr-x 2 root qmail1024 Aug 28 17:59 boot/ drwxr-xr-x 2 root qmail1024 Aug 28 18:00 control/ drwxr-xr-x 2 root qmail1024 Aug 28 17:59 doc/ -rw-r--r-- 1 root root0 Sep 18 17:20 list.txt drwxr-xr-x 10 root qmail1024 Aug 28 17:59 man/ -rwx-- 1 qmaild qmail 223 Sep 18 17:02 qt* drwxr-x--- 11 qmailq qmail1024 Aug 28 17:59 queue/ -rwxr-xr-x 1 root root 204 Aug 30 11:21 rc* drwxr-xr-x 2 root qmail1024 Aug 28 17:59 users/ Contents of rc file === #!/bin/sh # Using splogger to send the log through syslog. # Using qmail-local to deliver messages to ~/Mailbox by default. exec env - PATH="/var/qmail/bin:$PATH" \ qmail-start ./Mailbox splogger qmail Contents of qt file === supervise /var/lock/qmail-smtpd tcpserver -v -x/etc/tcp.smtp.cdb -u71 -g1001 0 25 \ rblsmtpd qmail-smtpd 21 | setuidgid qmaill multilog | \ setuidgid qmaill multilog -s500 -n5 /var/log/qmail/qmail-smtpd After switching to user qmaild, I ran the "qt" script. After a little while tinkering with other system, I executed "qt" again and got the message "/usr/local/bin/setuidgid: Permission denied" Do I need to restart the system? I have also issued the command "telnet localhost 25" and got the following response. Trying 127.0.0.1 telnet: Unabel to connect to remote host: Connection refused. I have followed line by line through the spageti documentation (more like basic programing). Please let me know where or what I am doing wrong!! Thank you in advance. Subba Rao [EMAIL PROTECTED] == Disclaimer - I question and speak for myself. http://pws.prserv.net/truemax/ __
Re: When will qmail back off to the next MX?
Racer X wrote: ok, i get the point. i would say that it IS configurable in that different MTA's can handle it however they want. making it configurable at an even lower level would seem to be a rather difficult project and not something you could do without at least patching and rebuilding. that is, i don't think you could just have a simple qmail control file that detailed MX handling unless all the policies were already built into the source anyway. It really wouldn't be that hard to implement a configurable way to fallback. One simple boolean would cover a lot of cases, that being whether or not a dropped connection is to be treated just like a connect that was not made. More involved configuration would allow choosing discrete behaviour over the different failure cases, but that may be a bit extreme. that's fine except in this case there IS no rfc to provide a baseline. there's "the way sendmail does it", which is in a sense a de facto standard, but it's only a standard because way back when, Eric Allman made some decisions about MX handling and for better or worse we're stuck with his decisions. Then Dan gets to do it however he wants, and for whatever reason he wants. Which is probably the case as it stands. It just bugs me when people say a connection refused is a broken server and a connectiond dropped is not. qmail is deviating from the established standard and handling things its own way. is it better or right? i don't know, there really hasn't been enough discussion. Well, if we do discuss it, I'd prefer to move the discussion forward to how the decision will really affect the proper delivery of mail, rather that why such and such server is a bad server. There is also another saying common in computers and networking, especially in regard to conformance to standards: Be conservative in what you produce and be liberal in what you accept. I have interpreted that to mean that if something does not conform to the standard, but I also don't have to go out of my way to detect and understand what is meant, I _may_ (and some would like this to be _should_) go ahead and accept it with the obvious semantics. the first part i agree with. the second part i'm not so sure about. my take on it is that programs should be prepared to handle any input. "handle" does not mean process necessarily, it just means that for any input, the program should have defined behavior. this means that the program has a very limited set of inputs and very well defined behaviors. if the inputs are bad, the program refuses the input. There should be a defined behaviour for different kinds of failures on the part of servers being connected to for mail delivery. Most certainly it should not crash if the connection just gets dropped. The question is what should be the reasonable range of choices for things it may do. i do NOT believe that "liberal" means "should attempt to rectify problems automatically." report the problem, sure, and don't crash because the input is too big or malformed, but don't attempt to fix the problem. GIGO. Is a connection refused a problem to be rectified? Is a connection dropped a problem to be rectified? how fast does it have to be dropped to be "summarily" dropped? 1 second? 5? 30? at what point does the connection become "established, but timed out, will try later" instead of "connection refused or immediately dropped?" What was in my mind by "summarily dropped" was the receiving server closing the TCP connection before outputting anything at all. I didn't consider time to be a factor unless the drop occurs after the point in time in which the sending server times out due to an idle connection. But the sender will be doing the connection dropping, so it won't see anything else. There are a lot of failure scenarios that can occur. Connection refused. Connection timed out. Various network failures (no route, no interface). Communications timed out. Communications severed (peer dropped, network failures, etc). In general I would tend to prefer to treat them all the same unless there is some compelling reason to do otherwise. Such reasons can be protocol standards or just a reasonable argument in favor of some other way to do it. -- Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] at| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] dot| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Installation Quesiton on Qmail. init.d directory and qmail script file.
I Have a couple of questions about the qmail install. What I have doesn't look right to me. I). I am installing qmail 1.03 from Dave Sill's "Life with Qmail" dated July 21, 1999. I am in section # 2.8.2 System Startup Files, and it says to install a script file I just created "qmail" to launch qmail at boot into my init.d directory. The document says it should be in one of the following locations: /etc/init.d /etc/rc.d/init.d /sbin/init.d I have no such directory on my system. (Slackware 3.6) It appears that Slackware uses /etc/rc.d for the initialization files. I think the qmail script file that will start qmail on boot should be located here? Can anyone verify this for me? II). Should I Chmod this file for X execute privledges? The document didn't say. III). I looked over the script and it references several files and subdirectories that don't exist. I have not received any errors in the install up to this point. I have attached the script file, and have put directories and files that don't exist here in (file/dir) (parenthesis).. case "$1" in start) echo -n "Starting qmail: qmail-send" supervise /var/(supervise)/qmail/send /var/qmail/rc |** I don't have supervise directory setuser (qmaill) cyclog /var/log/qmail ** Is qmaill a typo, or variable of somekind? echo -n " qmail-smtpd" supervise /var/supervise/qmail/smtpd tcpserver -v -x/etc/(tcp.smtp.cdb) \ ** This file doesn't exist. -u$QMAILDUID -g$NOFILESGID 0 smtp \ /var/qmail/bin/(qmail-smtpd-wrapper) 21 | setuser qmaill accustamp | \ ** I have qmail-smtpd but no wrapper. setuser qmaill cyclog /var/log/qmail/(smtpd ) *** I have a qmail-smtpd file here. I'm a bit confused here! I am running Slackware 3.6 on Kernel 2.0.35 on a 486/66Dx with 32Meg Ram. I have two NICS, both setup and working. I can ping local network and internet by name or IP address. I have the Samba Server 1.9.18p10 running. Everything working fine. I am going to continue with the install, and hope I don't hose anything, but I just don't think its going to work. ANY COMMENTS WOULD BE GREATLY APPRECIATED. TIA MarkT. qmail
Re: When will qmail back off to the next MX?
Racer X wrote: part of the problem, for me at least, is that it is impossible to guarantee that secondary MX's will, in fact, accept mail for the domain they are supposed to be MX'ing for. i'd rather hold the mail for a couple days in my queue and deliver it directly to the host than pass it off to a secondary that may or may not handle it correctly. at least if i pass it directly to the host i can guarantee that it's his fault if he loses it then, as opposed to getting a third party involved. So in all scenarios, you'd prefer to ignore all MX entries but the lowest? Wouldn't your argument apply equally to every failure scenario? I see the merit in your argument. I don't see how it distiguishes between differnet failure scenarios that need to be acted on differently. the more i think about this, the more i think that fallback MX records aren't really necessary anymore. having 3 or 4 fallback MX hosts was nice 10 years ago when mail could be passed in pony express format, eventually making its way across the country by store-and-forward, when everyone ran open relays and cooperated to help the mail get through. that really just isn't the case anymore for a large part of the world. This is a good point for most servers. Many people are still running servers on dialups that don't get connected all the time. I do MX-ing for a couple of them. When they are connected, it's for a few hours or more at a time, so they will soon get their mail. It can be argued that they should pick up their mail from my server instead. But the way it works now works just fine and is the least administrative burden (I don't have to add all their userids and worry about collisions). Probably the best counter argument is that the world should see my server for their domain as the only one, and my server should see their server as the one. It's a fair argument. I just haven't put it up like that as I am still thinking about what is the best way to manage more than one DNS server with different data for the "same" zones. there is very little reason for most MTAs to pass mail to a secondary MX host. if it can't be delivered to the primary, it's fairly likely that it can't be delivered to the secondary either. moreover, today anyway, it's likely that the secondary will be improperly configured and will refuse to accept mail for a domain it's supposed to be MX'ing for. further, it's quite possible that the secondary won't be able to deliver any sooner and may ultimately take longer to deliver. I also find it quite likely these days that the _primary_ is also misconfigured. It is a fair argument to suggest that an effort be made to ensure reliable delivery even in the face of the recipient's server's being misconfigured. I would also suggest that they should remove their secondary MX record if they don't have a procedure in place to verify that the secondary host is correctly configured. OTOH, if we always skip the primary and go only to the last secondary, then they will be forced to be sure all their servers are up to snuff. How is it that people won't notice the breakage if the primary mail server isn't accepting mail? If the server accepts connections, and then keeps closing them, it's not going to get its mail even from then secondary MX. so why even attempt to pass the mail to the secondary in that case? ignoring the firewall issue, to qmail it looks like the primary host accepted a connection and then dropped it abruptly. why should qmail think the secondary MX will have better luck? In some situations, the secondary may have a means to ensure that it can get connected. Maybe the source IP address is used by the primary to decide. In other situations, the secondary may not be able to do any better right now, but it might be able to later on at a time when you cannot even reach either (for perhaps unrelated reasons). The set of possibilities is at least large. I just tend to favor the notion of getting the mail as close to its destination as soon as possible. -- Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] at| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] dot| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
maildir structure
Hello. I have two rather stupid questions as I'm a newbie with Qmail. I've just installed Qmail and set it to use maildir-like mailboxes. The question is: Mutt ask me to specify a file to use as spool mailbox: how should I set this ? What are the function of the /tmp and /cur maildir subdirectories ? Excuse me if they're RTFM, but I didn't found the answers in the manuals... bye, Lorenzo
Re: Installation Quesiton on Qmail. init.d directory and qmail script file.
Mark Thomas [EMAIL PROTECTED] wrote: I). I am installing qmail 1.03 from Dave Sill's "Life with Qmail" dated July 21, 1999. I am in section # 2.8.2 System Startup Files, and it says to install a script file I just created "qmail" to launch qmail at boot into my init.d directory. The document says it should be in one of the following locations: /etc/init.d /etc/rc.d/init.d /sbin/init.d I have no such directory on my system. (Slackware 3.6) LWQ says "should" because it's impossible to cover every possibility. It appears that Slackware uses /etc/rc.d for the initialization files. I think the qmail script file that will start qmail on boot should be located here? Can anyone verify this for me? What's the structure of /etc/rc.d? What subdirectories does it have? II). Should I Chmod this file for X execute privledges? The document didn't say. Yes it does. It says: Make the startup script executable and link it to a directory in your path: # substitute the correct location of your rc dir on the next two lines chmod 755 /etc/init.d/qmail ln -s /etc/init.d/qmail /usr/local/sbin This is in section 2.8.2. III). I looked over the script and it references several files and subdirectories that don't exist. I have not received any errors in the install up to this point. At the completion of section 2.8.2, all necessary files and directories will be there. I have attached the script file, and have put directories and files that don't exist here in (file/dir) (parenthesis).. case "$1" in start) echo -n "Starting qmail: qmail-send" supervise /var/(supervise)/qmail/send /var/qmail/rc |** I don't have supervise directory Created later in 2.8.2. setuser (qmaill) cyclog /var/log/qmail ** Is qmaill a typo, or variable of somekind? qmaill is a user (in /etc/passwd) which you should have set up in 2.5.4. supervise /var/supervise/qmail/smtpd tcpserver -v -x/etc/(tcp.smtp.cdb) \ ** This file doesn't exist. Created later in 2.8.2. -u$QMAILDUID -g$NOFILESGID 0 smtp \ /var/qmail/bin/(qmail-smtpd-wrapper) 21 | setuser qmaill accustamp | \ ** I have qmail-smtpd but no wrapper. Created later in 2.8.2. setuser qmaill cyclog /var/log/qmail/(smtpd ) *** I have a qmail-smtpd file here. Are you sure about that? LWQ certainly doesn't create a qmail-smtpd file under /var/log/qmail. I am going to continue with the install, and hope I don't hose anything, but I just don't think its going to work. ANY COMMENTS WOULD BE GREATLY APPRECIATED. It's probably a good idea to read through the entire Installation section before attempting one's first installation. I'll add a note to that effect. -Dave
question
Hello, I use qmail and have noticed that the vast majority of spam that comes through is from Is there an a means by which I can reject mail from or is there any problems associated with this? Thank you, First Time poster / Sean
