Installing mini-qmail seems to require qmail ids contrary to documentation
According to Dan's page on mini-qmail http://cr.yp.to/qmail/mini.html, installing mini-qmail doesn't require qmail entries in /etc/passwd or /etc/group. So one should conceptually just have to unpack qmail-1.03.tar.gz, create /var/qmail and run make setup check However, on doing this this is the error message received ./load auto-gid substdio.a error.a str.a fs.a ( ./auto-uid auto_uida `head -1 conf-users` \ ./auto-uid auto_uidd `head -2 conf-users | tail -1` \ ./auto-uid auto_uidl `head -3 conf-users | tail -1` \ ./auto-uid auto_uido `head -4 conf-users | tail -1` \ ./auto-uid auto_uidp `head -5 conf-users | tail -1` \ ./auto-uid auto_uidq `head -6 conf-users | tail -1` \ ./auto-uid auto_uidr `head -7 conf-users | tail -1` \ ./auto-uid auto_uids `head -8 conf-users | tail -1` \ ./auto-gid auto_gidq `head -1 conf-groups` \ ./auto-gid auto_gidn `head -2 conf-groups | tail -1` \ ) auto_uids.c.tmp mv auto_uids.c.tmp auto_uids.c fatal: unable to find user alias So, does the installation of mini-qmail require creating of user-ids for installation and then one can delete them subsequently -- Yusuf Goolamabbas [EMAIL PROTECTED]
Addon
Hi I've been scouring documentation to find an answer but to no avail. Perhaps someone can point me to the right place to help me with the following: Currently running qmail 1.03 on FreeBSD 4.1, I would like to add an extra item of text to every email that is sent from all our users when they mail externally to our domain. Any help much appreciated. Thanks Steve -- Steve Crowder Systems Support Engineer email: [EMAIL PROTECTED]
qmail Digest 15 Jan 2001 11:00:00 -0000 Issue 1245
qmail Digest 15 Jan 2001 11:00:00 - Issue 1245 Topics (messages 55145 through 55184): Re: newbees guide to the qmail-list [was: problem in delivering mails locally...] 55145 by: Alexander Jernejcic Re: Hotmail Woes. 55146 by: James R Grinter 55155 by: Mark Delany 55180 by: Joomy Studio Re: Bogus popularity claims for Sendmail 55147 by: Jurjen Oskam QMTP MX-question 55148 by: Jurjen Oskam 55149 by: Johan Almqvist 55151 by: Jurjen Oskam 55154 by: Henning Brauer Re: Some assistance? 55150 by: Alexander Jernejcic Possible problem with qmail-qmtpc patch 55152 by: Johan Almqvist 55164 by: Russell Nelson 55168 by: Johan Almqvist 55169 by: Jurjen Oskam 55170 by: Johan Almqvist 55177 by: Johan Almqvist Re: hrmpop3d 55153 by: Henning Brauer qmail-inject 55156 by: Tim Cropper 55157 by: Mark Delany 55158 by: Henning Brauer Converting Sendmail spool emails to Qmail Maildir emails 55159 by: Roberto Samarone Araujo \(RSA\) 55160 by: Mark Delany Re: Can a queue in Qmail get stuck? 55161 by: Mark Delany Re: APOP 55162 by: Russell Nelson looking for mua 55163 by: davidge.jazzfree.com 55165 by: Henning Brauer 55166 by: Olivier M. 55171 by: Ricardo Cerqueira 55172 by: Henning Brauer 55173 by: David Dyer-Bennet 55174 by: Robin S. Socha 55181 by: Justin Bell Re: Hotmail woes and new situation 55167 by: Corey Jarvis problem with relaying 55175 by: Jens Georg 55176 by: Henning Brauer 55178 by: Jens Georg Winbind and Qmail 55179 by: dennis qmail-smtpd that Verifies PGP 55182 by: Gan Installing mini-qmail seems to require qmail ids contrary to documentation 55183 by: Yusuf Goolamabbas Addon 55184 by: Steve Crowder 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] -- Alex Pennace wrote How about we try changing the list name to [EMAIL PROTECTED]? significant name - i have to admit PD Miller [EMAIL PROTECTED] writes: you do get an smtp connection, your trouble may not be over. You may find that they don't 250 at the end (a sporatic problem there) or that the user you are sending to is over quota. Yes, hotmail is very erratic in its mail acceptance (which isn't done through qmail - they only seem to use qmail for outgoing mail) On some mailing lists I run, there's usually at least one outgoing message that will bounce from all the hotmail.com addresses on the list. Finally, if your server sends to yahoo, your either lucky or good. I find yahoo.com and yahoo.ca to be down 20% of the time. ditto yahoo.co.uk - for the same reason. Their MX hosts are regularly too busy. Many sites also bounce mail with 'unknown user' at certain times of the day. Anyone would think they weren't updating user-lists atomically... James. On Sat, Jan 13, 2001 at 03:17:51PM +0100, Henning Brauer wrote: On Fri, Jan 12, 2001 at 04:32:30PM -0800, Boz Crowther wrote: Isn't Hotmail owned by M$ (has been for a while, actually)? So, it would make sense that they run M$ OSes. Yes, M$ owns Hotmail. They have a bunch of Windooze Servers, but AFAIK the real work is done by FreeBSD machines. Hmm. They may be cloaking, but here's the relevant header from their email servers, first inbound, then outbound. Received: from [204.182.55.144] by hotmail.com (3.2) with ESMTP id MHotMailBC2B194F00C340043198CCB63790B1720; Sun Jan 14 08:05:35 2001 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 14 Jan 2001 08:08:55 -0800 And here's what their webserver says: $ telnet www.hotmail.com 80 Trying 64.4.44.7... Connected to www.hotmail.com. Escape character is '^]'. GET / HTTP/1.0 HTTP/1.1 302 Redirected Server: Microsoft-IIS/5.0 Date: Sun, 14 Jan 2001 16:10:21 GMT Location: http://lc2.law13.hotmail.passport.com/cgi-bin/login Regards. What about this ? http://195.92.95.5/?restriction=site+containshost=.hotmail.composition=lim ited Did they successful switching to the W2K ? Joomy. Ah, yes. Hotmail is owned by Mirco$oft. The last I heard microsoft tried porting Hotmail to Windows NT and it kept crashing and crashing... That was before Windows 2k. So it would make logical sense but is it technically feasible to do so.. Regards George Patterson Boz Crowther wrote: Isn't Hotmail owned by M$ (has been for a while, actually)? So, it would make sense that they run M$ OSes. - Original Message - From: "Stefan Laudat" [EMAIL PROTECTED] To: [EMAIL
Authentication with qmail from the external network
Hi everybody! I have a doubt when trying to configure qmail. I would like to allow my users (of my network) to send emails from the external network but through my server. I don't know how to establish the passwords, because I am not allowing the relay in my server, except for my internal network and for my domain. I know that the passworks are managed by the checkpassword file for POP, but my problem now is with SMTP. Do you know how to establish the passwords in the case the user wants to send emails from outside my local network? Thanks a lot.
Hi. inetd problems
Hi i'm having inetd problems and i cant figure out why i got this line on inetd.conf smtp stream tcp nowait qmail-smtpd /var/qmail/bin/tcp-env tcp-env/var/qmail/bin/qmail-smtpd when i telnet to host in port 25 it opens connection and closes.. any ideas? Thanks in advance Gonçalo Gomes
Re: Installing mini-qmail seems to require qmail ids contrary to documentation
On Mon, Jan 15, 2001 at 04:44:06PM +0800, Yusuf Goolamabbas wrote: According to Dan's page on mini-qmail http://cr.yp.to/qmail/mini.html, installing mini-qmail doesn't require qmail entries in /etc/passwd or /etc/group. Strictly speaking, that page says that you don't need those entries to "install" mini-qmail. It is silent on the matter of building it. In general, it appears that that particular page is intended for people already familiar with qmail as it does not provide the same specifics as his other pages do (for example it does not specify permissions for /var/mini-qmail). So, does the installation of mini-qmail require creating of user-ids for installation and then one can delete them subsequently That's the easiest way - though it doesn't hurt to leave the /etc/passwd and /etc/group entries intact. Alternatively, you can simply take the specific executables from another system and copy them as needed. Personally I find it easier to do a standard qmail install and work backwards as that conveniently gives you all the man pages, all the commands and all the sources on the local system. By working backwards I mean: # mv /var/qmail/bin/qmail-queue /var/qmail/bin/qmail-queue.orig # ln -s mv /var/qmail/bin/qmail-qmqpc /var/qmail/bin/qmail-queue Regards.
Re: Hi. inetd problems
On Mon, Jan 15, 2001 at 12:18:39PM -, Gon?alo Gomes wrote: Hi i'm having inetd problems and i cant figure out why You haven't followed the instructions correctly. i got this line on inetd.conf smtp stream tcp nowait qmail-smtpd /var/qmail/bin/tcp-env tcp-env/var/qmail/bin/qmail-smtpd Which does not match this line from INSTALL: smtp stream tcp nowait qmaild /var/qmail/bin/tcp-env tcp-env /var/qmail/bin/qmail-smtpd Find and correct the two errors you've made, HUP inetd and try again. You may also find it useful to read the man page on inetd.conf to understand what each parameter means. Regards.
Re: Installing mini-qmail seems to require qmail ids contrary to documentation
Oops. By working backwards I mean: # mv /var/qmail/bin/qmail-queue /var/qmail/bin/qmail-queue.orig # ln -s mv /var/qmail/bin/qmail-qmqpc /var/qmail/bin/qmail-queue Perhaps: # mv /var/qmail/bin/qmail-queue /var/qmail/bin/qmail-queue.orig # ln -s /var/qmail/bin/qmail-qmqpc /var/qmail/bin/qmail-queue Lucky submissions on this list lack a warranty. Regards.
Re: Hi. inetd problems
On Mon, 15 Jan 2001, [iso-8859-1] Gonçalo Gomes wrote: any ideas? Aplly to use smtp with tcpserver Piotr --- Piotr Kasztelowicz [EMAIL PROTECTED] [http://www.am.torun.pl/~pekasz]
Re: Bogus popularity claims for Sendmail
On Sat, Jan 13, 2001 at 10:16:34PM -, D. J. Bernstein wrote: I've set up a web page to combat Sendmail Inc.'s false advertising on this topic: http://cr.yp.to/surveys/sendmail.html Sendmail dropped below 50% of the Internet's SMTP servers---including idle workstations---last year; qmail has climbed past 10%. I suspect that qmail now handles more Internet mail deliveries than Sendmail does, although I don't know a good way to measure this. You could examine a set of log files, but then how do you count them? You can't count the MTA that sent and received the email because it's completely non-random. And yet, that throws off your statistics. I would totally exclude the server that generates the logs and just use the 250 responses from the remote SMTP servers. Unless it's someone like AOL, I don't think that ignoring the local system will have much bearing on the stats. I wouldn't bother chasing down the MX and then probing it, from the perspective of Sendmail vs qmail vs the-rest, the queue-id responses are sufficiently distinct with a few pattern matches. The best server logs to look at are probably those that are running diverse-interest mailing lists. ISP logs - regardless of whether they are running qmail - are probably fine since we're not counting local deliveries. Regards.
Re: qmail-ldap
On Mon, Jan 15, 2001 at 01:43:24PM +0100, Carlos Caba?as wrote: Hi, I am trying to install ldap-qmail.Can anybody tell me what this error means (i have created the ldapserver file and ldap is working) @40003a62f02e3387df24 alert: cannot start qmail-lspawn or it had an error! Check if ~control/ldapserver exists. The permissions of this file are ok. Try executing qmail-lspawn by hand: /var/qmail/bin/qmail-lspawn. See that lib missing? That's the problem. Possibly... If not them send the qmail-showctl please. Carlos. -- Jose AP Celestino [EMAIL PROTECTED] || SAPO / PTM.COM Administrao de Sistemas / Operaes || http://www.sapo.pt --- Think of your family tonight. Try to crawl home after the computer crashes.
need a howto, something i can follow step by step and get qmail installed..
need a howto, something i can follow step by step and get qmail installed.. Thanks in advance Gonalo Gomes
Re: need a howto, something i can follow step by step and get qmail installed..
On Mon, Jan 15, 2001 at 01:02:53PM -, Gon?alo Gomes wrote: need a howto, something i can follow step by step and get qmail installed.. Thanks in advance Gonalo Gomes Much humble of you to figure that out. Check out the excellent: Life With Qmail: http://www.lifewithqmail.org Life With Qmail-LDAP: http://www.lifewithqmail.org/ldap and also http://www.flounder.net/qmail/qmail-howto.html Regards. -- Jose AP Celestino [EMAIL PROTECTED] || SAPO / PTM.COM Administrao de Sistemas / Operaes || http://www.sapo.pt --- "Do not meddle in the affairs of SysOps, for you are crunchy and good with ketchup."
Tcpserver
Hello The tcpserver (http://cr.yp.to/ucspi-tcp.html) is a part of ucspi-tcp package, which is alternative to work with smtp via inetd. Piotr --- Piotr Kasztelowicz [EMAIL PROTECTED] [http://www.am.torun.pl/~pekasz]
Re: 65535 users on linux
On Mon, Jan 15, 2001 at 02:25:52PM +0100, Karl Pitrich wrote: hi. one question: now, that all my users come from the ldap directory, the ~/Mail* stuff still has to belong to the particular user, wether the user is in ldap or not. there is, however a 16bit uid limit in linux 2.2.x ext2 etc. fs, so how do you utilize 65535 users on linux machines? or did i get that completly wrong, and the maildir doesnt belong to the particular user? You got it completly wrong. Take a deep read at Life With Qmail: http://www.lifewithqmail.org/ldap/: --- Start of quote 7.1.1.12. ldapuid The system user id your virtual users are mapped to. You can add as much users as you want to you ldap directory without having system accounts for them, they are all mapped to a single system user id - this one is defined here. 7.1.1.13. ldapgid The system group id all your virtual users are mapped to. End of quote thx, Karl. -- Jose AP Celestino [EMAIL PROTECTED] || SAPO / PTM.COM Administrao de Sistemas / Operaes || http://www.sapo.pt --- Never make anything simple and efficient when a way can be found to make it complex and wonderful.
RE: Addon
Check the list archives. This same question has be asked in one form or another nearly every month. Search on footer. It might also have a link on the www.qmail.org page. -Original Message- From: Steve Crowder [mailto:[EMAIL PROTECTED]] Sent: Monday, January 15, 2001 5:57 AM To: qmail Subject: Addon Hi I've been scouring documentation to find an answer but to no avail. Perhaps someone can point me to the right place to help me with the following: Currently running qmail 1.03 on FreeBSD 4.1, I would like to add an extra item of text to every email that is sent from all our users when they mail externally to our domain. Any help much appreciated. Thanks Steve -- Steve Crowder Systems Support Engineer email: [EMAIL PROTECTED]
RE: Addon
Thanks for this. After a quick browse I'm sure I can get all the answers I need from there. Ta Steve -Original Message- From: Tim Hunter [mailto:[EMAIL PROTECTED]] Sent: 15 January 2001 14:48 To: qmail Subject: RE: Addon Check the list archives. This same question has be asked in one form or another nearly every month. Search on footer. It might also have a link on the www.qmail.org page. -Original Message- From: Steve Crowder [mailto:[EMAIL PROTECTED]] Sent: Monday, January 15, 2001 5:57 AM To: qmail Subject: Addon Hi I've been scouring documentation to find an answer but to no avail. Perhaps someone can point me to the right place to help me with the following: Currently running qmail 1.03 on FreeBSD 4.1, I would like to add an extra item of text to every email that is sent from all our users when they mail externally to our domain. Any help much appreciated. Thanks Steve -- Steve Crowder Systems Support Engineer email: [EMAIL PROTECTED]
stripping binaries
Probably not the most appropriate place to ask this, but i have no usenet access at this point. And, as I have stated before on this list, I am not a coder. at cr.yp.to/qmail/var-qmail.html, dan says: 1. Download qmail 1.03. Remove -s from conf-ld. Compile and install. Strip the binaries in /var/qmail/bin. How exactly does one go about stripping binaries? -- *** Matthew H Patterson Unix Systems Administrator National Support Center, LLC Naperville, Illinois, USA ***
tcpserver
Hello. I have a basic qmail installation following the install notes from the tarball. I have decided to add all the other djb programs so it will be a djbware machine. Passes all the test and works fine out of inetd. Added checkpassword and set-up pop3d. All tested and works fine. Oh, two questions :- 1) Why isn't apop available in Dan's checkpassword/qmail. APOP may not be prefect, but plain text is totally unsecure. 2) On checking the qmail.org and links from the checkpassword docs, there seems to be 3 or 4 implementations of APOP/checkpassword. Which one, in peoples opinion, should I use ? Installed the latest ucspi-tcp and damontools. I have printed and read Dave Sills life with qmail, but wanted to add and work through in stages as I add each program as I want to learn the intricacies of the system, not just have it all running without comprehension. No examples given for qmail in the tcpsever docs. No man ucspi-tcp, no man tcpserver. Looked in the qmail FAQ and found #5.1. o.k. - it says "remove smtp from /etc/inetd.conf" - no way. Remmed it out. put line :- tcpserver -u 7770 -g 2108 0 smtp /var/qmail/bin/qmail-smtpd changed 7770 to 7791 which is my qmaild. Not sure why 7791 wasn't used as default as that's what's is described in the IDS, but o.k. - but hey, big deal. - Reboot required. (Is that it ??? nothing else mentioned) Barfs on reboot with :- tcpserver/-u: *:ai_socketype not suported which is Greek to me. I know that Dave Sills docs mentions cdb and tcp rules etc. but this isn't mentioned in Dan's qmail FAQ, so I don't know where to go from here. I searched through about 150 of the archived qmail lsit files but didn't see this problem. Pointers please. Regards...Martin -- --- All the wastes in a year from a nuclear power plant can be stored under a desk. -- Ronald Reagan, quoted in "Burlington Free Press", 15 February 1980
Re: tcpserver
Martin Randall wrote: o.k. - it says "remove smtp from /etc/inetd.conf" - no way. Remmed it out. put line :- tcpserver -u 7770 -g 2108 0 smtp /var/qmail/bin/qmail-smtpd you didn't put that line into inetd.conf, did you?
Re: tcpserver
This should have gone to the list. -- Hello joshua On 15-Jan-01, you wrote: Martin Randall wrote: o.k. - it says "remove smtp from /etc/inetd.conf" - no way. Remmed it out. put line :- tcpserver -u 7770 -g 2108 0 smtp /var/qmail/bin/qmail-smtpd you didn't put that line into inetd.conf, did you? Oh brown !!! Sensory overload. I've been reading a ton of docs and missed that...sigh...Thanks for kick in the pants. System startup files aka rc.local in OpenBSD. Regards...Martin sb --- 9. Anything worth fighting for is worth fighting dirty for. -- One of 21 Thoughts to Get You Through Almost Any Crisis
Re: tcpserver
So should this - sorry I'm stressed out -- Hello James On 15-Jan-01, you wrote: SNIP you didn't put that line into inetd.conf, did you? Well that's a useful reply. Sheesh. Anyways, Martin, that shouldn't go into /etc/inetd.conf. That line should go into your system's boot up scripts. /etc/rc.local or something similar. Or, by far the easiest way is to follow the Life with Qmail directions and use svscan/supervise. See #http://www.lifewithqmail.org/# james Yes, probably, but there is a lot of info packed into Life with qmail that I don't follow/understand even though it obviously works. I do have it printed out for reference, but the way I am thinking (rightly or wrongly) is if I install the tarballs one at a time and follow the instructions and try the other notes etc. I will learn it more deeply and thoroughly. For me, this is training as opposed to getting something up and running ASAP. I just want to go beyond the basic qmail install that I have used on an internal test machine for a couple of years. I have a external IP and domain to test and play for real now and have just installed OpenBSD 2.8 onto a clean machine. Once I'm happy with ucspi-tcp, then daemontools is next although I'd like APOP going and tested first. After that, djbdns etc. etc. - like I said, this is going to be a DJBware machine. Regards...Martin sb --- A deadline is negative inspiration. Still, it's better than no inspiration at all. -- Rita Mae Brown -- Starting from Scratch: A Different Kind of Writer's Manual
IsoQlog 1.4 released (Qmail Log Analyser)
Hi i released IsoQlog 1.4 what is IsoQlog ? IsoQlog is a qmail log analysis program written in Perl. It is designed to scan qmail logfiles and produce usage statistics in HTML format for viewing through a Web browser. It produces top domains output according to incoming, outgoing, and total mails. It maintains your main domain mail statistics per day and per month, like webalizer. -- What is New ? -Multi Domain support has been added -Some small bug fixed has been made about Displaying Date , and Top Scores -Storing Top Scores of everyday for more information http://www.enderunix.org/isoqlog Ismail YENIGUL ? echo "UNIX: Live Free or Die !\n"; ?
Re: tcpserver
Hello James On 15-Jan-01, you wrote: Perhaps, but there's more scope for confusion. The INSTALL* docs in the qmail tarball and LWQ do not describe the same installation process. You will have a different setup depending on which you follow so switching between them is likely to cause much hassle. I'd suggest using LWQ - the qmail INSTALL docs were written before the latest features of daemontools existed. O.K. - I'll consider it. LikeI said, I'm trying to learn it as opposed to getting it up and running ASAP. I have noticed stuff like Dan says mkdir /supervise whereas LWQ has references to /var/qmail/supervise. Still I'd like to follow Dan's methodology. Something about Maildir. I edited /var/qmail/rc and replaced ./Mailbox with ./Maildir/ but when I create new usrs, Maildir isn't created in their /home I have had to log in as them on a different console cd /var/qmail/bin maildirmake $HOME/Maildir echo ./Maildir/ ~/.qmail This then creates the .qmail and Maildir in their /home. Why isn't the skel working ? Obviously I'm missing something. Anyone have any opinions on which checkpassword is best for APOP ? Regards...Martin sb --- A cat is, above all things, an ingredient of Chop Suey.
RE: need a howto, something i can follow step by step and get qmail installed..
http://www.lifewithqmail.org/ -Original Message- From: Gonalo Gomes [mailto:[EMAIL PROTECTED]] Sent: Monday, January 15, 2001 2:03 PM To: Qmail Subject: need a howto, something i can follow step by step and get qmail installed.. need a howto, something i can follow step by step and get qmail installed.. Thanks in advance Gonalo Gomes
Re: tcpserver
Martin Randall [EMAIL PROTECTED] wrote: I edited /var/qmail/rc and replaced ./Mailbox with ./Maildir/ but when I create new usrs, Maildir isn't created in their /home [...] Why isn't the skel working ? Obviously I'm missing something. Probably there isn't a Maildir in the skeleton directory. The qmail install will not put one there by default. Besides, adding a Maildir to /etc/skel (go ahead, do this yourself) won't affect existing user directories; you'll have to add a Maildir to them by hand. You could also craft up a little script to do it for all your current users in a few minutes. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
Life With Qmail - PW?
Hi, I'm installing Qmail via Life with Qmail. Under section 2.5.4. Create users and groups there is this section: alias:*:7790:2108::/var/qmail/alias:/bin/true qmaild:*:7791:2108::/var/qmail:/bin/true qmaill:*:7792:2108::/var/qmail:/bin/true qmailp:*:7793:2108::/var/qmail:/bin/true qmailq:*:7794:2107::/var/qmail:/bin/true qmailr:*:7795:2107::/var/qmail:/bin/true qmails:*:7796:2107::/var/qmail:/bin/true What does this do and why would I need it? Thanks in advance. Keith
Re: QMTP MX-question
On Sun, Jan 14, 2001 at 03:05:16PM +0100, Jurjen Oskam wrote: [snip] However, when I query for crynwr.com, I get: crynwr.com 86354 MX 12801 pdam.crynwr.com crynwr.com 86354 MX 12816 pdam.crynwr.com This set of MX records compensates for a bug in Russell's QMTP implementation (that has not been fixed in Johan Almqvist's patches yet either). Greetz, Peter -- dataloss networks '/ignore-ance is bliss' - me 'Het leven is een stuiterbal, maar de mijne plakt aan t plafond!' - me
RE: Life With Qmail - PW?
this are the users the parts of qmail are running with and the owners of dirs, files, etc. ... qmail does not run as root :) alexander -Original Message- From: Keith Smith [mailto:[EMAIL PROTECTED]] Sent: Monday, January 15, 2001 8:47 PM To: [EMAIL PROTECTED] Subject: Life With Qmail - PW? Hi, I'm installing Qmail via Life with Qmail. Under section 2.5.4. Create users and groups there is this section: alias:*:7790:2108::/var/qmail/alias:/bin/true qmaild:*:7791:2108::/var/qmail:/bin/true qmaill:*:7792:2108::/var/qmail:/bin/true qmailp:*:7793:2108::/var/qmail:/bin/true qmailq:*:7794:2107::/var/qmail:/bin/true qmailr:*:7795:2107::/var/qmail:/bin/true qmails:*:7796:2107::/var/qmail:/bin/true What does this do and why would I need it? Thanks in advance. Keith
delays on telnet localhost 25
Hi, I'm having some problems with a qmail instalation. It was working fine on some tests, but now we have a delay of about 5 seconds or more when connecting to the smtp port. This happens from localhost and other machines. I'm using tcpserver without reverse dns loopkup, 20 max smtp concurrency and blocking RELAY (and some IPs, not 127.0.0.1) throght tcpserver. The box is a Sun Solaris 1700 MB memory and 2 450 MHz CPUs Directions would be much apreciated! Thanks in advance, Paulo Correia
A firestorm of protest?
I'm considering removing the entire patches section from www.qmail.org. Why? Because a patch implies that something is wrong, and needs to be fixed. However, when someone produces a "patch" for smtp-auth, that implies that qmail-smtpd has a problem that the patch fixes. I'd rather see people steal the necessary parts of Makefile, and Dan's library code, and create a stand-alone "qmail-smtpd-auth" program. I've found a couple of places where Dan decries patches: http://msgs.securepoint.com/cgi-bin/get/qmail9812/214/1/2/1/3/2/1/2/1.html http://msgs.SecurePoint.com/cgi-bin/get/qmail9905/164/3.html Somewhere he recommends that people make a copy of the necessary parts of his code and distribute the changed code as a separate package. Can anybody find it for me? I've failed to find it in nearly an hour of archive searching. I'm not going to do it unless a majority of the authors of patches are willing to repackage them as standalone programs. So if there's a firestorm of protest from those authors, I won't do it. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com | Government is the Crynwr sells support for free software | PGPok | fictitious entity by which 521 Pleasant Valley Rd. | +1 315 268 1925 voice | everyone seeks to live at Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | everyone else's expense.
Re: delays on telnet localhost 25
Paulo Correia [EMAIL PROTECTED] wrote: I'm having some problems with a qmail instalation. It was working fine on some tests, but now we have a delay of about 5 seconds or more when connecting to the smtp port. This happens from localhost and other machines. I'm using tcpserver without reverse dns loopkup, 20 max smtp concurrency and blocking RELAY (and some IPs, not 127.0.0.1) throght tcpserver. Did you disable remote ident lookups, and lookups for the local hostname? tcpserver has additional options for these time-savers as well. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
Re: A firestorm of protest?
Russell Nelson wrote: I'm considering removing the entire patches section from www.qmail.org. Why? Because a patch implies that something is wrong, and needs to be fixed. However, when someone produces a "patch" for smtp-auth, that implies that qmail-smtpd has a problem that the patch fixes. I'd rather see people steal the necessary parts of Makefile, and Dan's library code, and create a stand-alone "qmail-smtpd-auth" program. I've found a couple of places where Dan decries patches: http://msgs.securepoint.com/cgi-bin/get/qmail9812/214/1/2/1/3/2/1/2/1.html http://msgs.SecurePoint.com/cgi-bin/get/qmail9905/164/3.html Somewhere he recommends that people make a copy of the necessary parts of his code and distribute the changed code as a separate package. Can anybody find it for me? I've failed to find it in nearly an hour of archive searching. I'm not going to do it unless a majority of the authors of patches are willing to repackage them as standalone programs. So if there's a firestorm of protest from those authors, I won't do it. I would leave it as it is. Most people whom see patches assume in qmail's case that these are additions, as they are all described as such, and none imply any errors / problems. qmail has grown in popularity with these patches, and as long as they are described as they are then it will continue to grow. I use a few (5) of these and would continue to. Thats my 2 euro worth! Greg -- -russ nelson [EMAIL PROTECTED] http://russnelson.com | Government is the Crynwr sells support for free software | PGPok | fictitious entity by which 521 Pleasant Valley Rd. | +1 315 268 1925 voice | everyone seeks to live at Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | everyone else's expense.
Re: A firestorm of protest?
Russell Nelson [EMAIL PROTECTED] writes on 15 January 2001 at 15:18:10 -0500 I'm considering removing the entire patches section from www.qmail.org. Why? Because a patch implies that something is wrong, and needs to be fixed. However, when someone produces a "patch" for smtp-auth, that implies that qmail-smtpd has a problem that the patch fixes. I'd rather see people steal the necessary parts of Makefile, and Dan's library code, and create a stand-alone "qmail-smtpd-auth" program. A "patch" is also a recognized way to make an upgrade. I've found a couple of places where Dan decries patches: http://msgs.securepoint.com/cgi-bin/get/qmail9812/214/1/2/1/3/2/1/2/1.html http://msgs.SecurePoint.com/cgi-bin/get/qmail9905/164/3.html Somewhere he recommends that people make a copy of the necessary parts of his code and distribute the changed code as a separate package. Can anybody find it for me? I've failed to find it in nearly an hour of archive searching. I'm not going to do it unless a majority of the authors of patches are willing to repackage them as standalone programs. So if there's a firestorm of protest from those authors, I won't do it. I think this is a very bad idea. My primary reason is that it's easier to apply a patch against updated main code than it is to integrate the changes from that updated main code into a standalone program. Also, some things are much better implemented as a change to the existing programs, rather than as an additional layer of programs. -- David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED] SF: http://www.dd-b.net/dd-b/ Minicon: http://www.mnstf.org/minicon/ Photos: http://dd-b.lighthunters.net/
Re: A firestorm of protest?
Greg Cope [EMAIL PROTECTED] wrote: Russell Nelson wrote: I'm considering removing the entire patches section from www.qmail.org. Why? Because a patch implies that something is wrong, and needs to be fixed. Most people whom see patches assume in qmail's case that these are additions, as they are all described as such, and none imply any errors / problems. Perhaps then the only change necessary is to change the semantics of the qmail.org site? Instead of "so-and-so has written a patch to...", change it to "addition" or "add-on" or whatever. Personally, I use Russell's big-todo and qmtpc patches, along with Bruce Guenter's /var/qmail/owners patches, and a few others, and I don't consider any of them to be bugs in Dan's pristine qmail -- they're simply conveniences, in much the same way that having power brakes in a Cadillac doesn't imply that manual brakes in a Chevette is a safety hazard. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
Multilog
Hi. I have been happily running qmail now for some time, till now, then I have decided to try qmailmrtg (i also happily run mrtg for some time, to monitor my router). As I see, qmailmrtg requires that qmail logging will be done with multilog, (till now I use syslog, although it's supposed to be slow which is not my primary concern). I successfully ran multilog, but now I have a problem with it's timestamps - its some TAI format which is pretty hard to decipher when you want to fond a log of what happened say half an hour ago. is there an easy way to display multilog log with "normal" (syslog-like) timestamps (display-not write it in this format, because qmailmrtg need it in TAI).. Thanks. __IncrediMail - Email has finally evolved - Click Here
Re: A firestorm of protest?
David Dyer-Bennet writes: I'm not going to do it unless a majority of the authors of patches are willing to repackage them as standalone programs. So if there's a firestorm of protest from those authors, I won't do it. I think this is a very bad idea. My primary reason is that it's easier to apply a patch against updated main code than it is to integrate the changes from that updated main code into a standalone program. If Dan was putting out daily versions of qmail, sure. But we've had qmail-1.03 for several years now. Also, some things are much better implemented as a change to the existing programs, rather than as an additional layer of programs. Try applying two patches to the same program. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com | Government is the Crynwr sells support for free software | PGPok | fictitious entity by which 521 Pleasant Valley Rd. | +1 315 268 1925 voice | everyone seeks to live at Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | everyone else's expense.
vmailmgr- SMTP-POP3-qMail ACK!
HELP! Here is my situation: Mail coming in from external STMP checks fine, and ends up in the correct users ./Maildir/. However, when those users check their e-mail via POP-3 are told they do not exist, and therefore are not able to pickup mail. I have one user exempt to this, but not on purpose. A previous user set up in the system seems to be able to read e-mails from his home ./Maildir/ rather than the vmailmgr user ./Maildir/. I know what your going to say, but mail is not sent to his home Maildir, it is sent to the alternate within vmailmgr settings. Well you got that one right. So in fact that is the only user that can log in, but has not a single piece of mail to where qmail is getting is mail from. Basically when an external user attempts to connect to POP3 they are told they don't exist, because qmail-pop3d is not looking in the correct area when they get handled by 'checkvpw'. (my guess) so, how do I change it? Anyway, no user is loosing mail, as it is all getting saved in the right area. My current setup is running the most current release versions of qmail+patches daemontools uscpi-tcp uscpi-unix vmailmgr omail If anyone comes up with a solution to this, it would be greatly appreciated! And if anyone needs further information I would be happy to provide. HELP!!!, Sean
Re: Multilog
check out tai64nlocal. it comes with daemontools. http://cr.yp.to/daemontools/tai64nlocal.html might help. -tcl. On Mon, 15 Jan 2001, Alex Kramarov wrote: Hi. I have been happily running qmail now for some time, till now, then I have decided to try qmailmrtg (i also happily run mrtg for some time, to monitor my router). As I see, qmailmrtg requires that qmail logging will be done with multilog, (till now I use syslog, although it's supposed to be slow which is not my primary concern). I successfully ran multilog, but now I have a problem with it's timestamps - its some TAI format which is pretty hard to decipher when you want to fond a log of what happened say half an hour ago. is there an easy way to display multilog log with "normal" (syslog-like) timestamps (display-not write it in this format, because qmailmrtg need it in TAI).. Thanks.
Re: A firestorm of protest?
Hello Perhaps then the only change necessary is to change the semantics of the qmail.org site? Instead of "so-and-so has written a patch to...", change it to "addition" or "add-on" or whatever. Qmail ver 1.03 does not already "young" software. How about to suppose Dan to make the new version - perhaps made with cooperation with all peoples, who have created useful patches and additional softwares, so that this all will be included to new version? Piotr --- Piotr Kasztelowicz [EMAIL PROTECTED] [http://www.am.torun.pl/~pekasz]
Re: A firestorm of protest?
Russell Nelson wrote: Also, some things are much better implemented as a change to the existing programs, rather than as an additional layer of programs. Try applying two patches to the same program. That's not necessarily a problem, particularly when the patches affect different areas of the code. On the other hand, imagine there is a program that two people have written additions for, and you want to include both of those additions. If each person releases the complete source to their version of the program, instead of a patch to the original source, you'd have to wade through the program source, twice, to figure out where the modifications are and how to combine them. This problem can be circumvented by storing the complete source for every possible combination of additions, but that's going to quickly max out your storage space, not to mention the logistical nightmare of figuring out who needs to give permission and who gets credit, etc. ---Kris
Re: A firestorm of protest?
Thus spake David Dyer-Bennet ([EMAIL PROTECTED]): Why? Because a patch implies that something is wrong, and needs to be fixed. However, when someone produces a "patch" for smtp-auth, that implies that qmail-smtpd has a problem that the patch fixes. I'd rather see people steal the necessary parts of Makefile, and Dan's library code, and create a stand-alone "qmail-smtpd-auth" program. A "patch" is also a recognized way to make an upgrade. The word "upgrade" also implies that there is something wrong or inferior with the original qmail. That said, while converting the patches into standalone packages would be better for political reasons, it would make it harder for me to maintain my qmail, because that is basically stock qmail with the AOL-DNS-fix, starttls and another small patch. Merging patches is far easier than merging divergent codebases. So, in effect, the changed policy would force me to download the qmail source code four times, run diff to get patches, and then merge those patches. I don't think political decisions should make life harder for all of us. I'd rather see www.qmail.org be changed so that you would have to click through a banner page that clearly states that none of those patches is necessary to make qmail any more secure, more reliable or faster. Please don't cripple my work with qmail in the vain attempt to make stupid people understand. They won't. That's why they are stupid in the first place. Russ, if you desire, please put a few explaining words over the patch section, and then proceed to ignore the idiots. It will make your life easier and the idiots will die out or move back to Exchange and it will save all of us a lot of stress. Felix
Re: A firestorm of protest?
Thus spake Piotr Kasztelowicz ([EMAIL PROTECTED]): Perhaps then the only change necessary is to change the semantics of the qmail.org site? Instead of "so-and-so has written a patch to...", change it to "addition" or "add-on" or whatever. Qmail ver 1.03 does not already "young" software. How about to suppose Dan to make the new version - perhaps made with cooperation with all peoples, who have created useful patches and additional softwares, so that this all will be included to new version? ARGH NO! GO AWAY, Piotr! The reason why qmail is reliable, fast, secury, easy to maintain and all around a nice piece of software is because Dan does _not_ include everyone's patches and pet features! If you want to use bloated, unreliable, immensely fat software with a nice author who will include every patch anyone sends him, switch to Exim. I mean it! Please go away and use Exim. It has all the features anyone could ever want from an MTA, and around 20 million more features. Felix
Re: A firestorm of protest?
On Mon, 15 Jan 2001, Piotr Kasztelowicz wrote: Dan to make the new version - perhaps made with cooperation with "Dan" and "cooperate" on the same line... all peoples, who have created useful patches and additional softwares, useful additions becoming standard? that'll be the day. See, these things that are really needed to get any use out of qmail, aren't supported... won't be supported, etc., as they make qmail less secure, less efficient and, well, just no longer qmail. I'm not trying to be too negative here. I have come the conclusion that I need to use qmail and be happy with qmail for what it is, and not try to change it. Scott
Re: A firestorm of protest?
Felix von Leitner wrote: If you want to use bloated, unreliable, immensely fat software with a nice author who will include every patch anyone sends him, switch to Exim. I mean it! Please go away and use Exim. It has all the features anyone could ever want from an MTA, and around 20 million more features. Does Exim also come with a nice mailing list that doesn't demand the exile of people with dissenting opinions? ---Kris Kelley
Re: A firestorm of protest?
Russell Nelson [EMAIL PROTECTED] writes on 15 January 2001 at 15:55:50 -0500 David Dyer-Bennet writes: I'm not going to do it unless a majority of the authors of patches are willing to repackage them as standalone programs. So if there's a firestorm of protest from those authors, I won't do it. I think this is a very bad idea. My primary reason is that it's easier to apply a patch against updated main code than it is to integrate the changes from that updated main code into a standalone program. If Dan was putting out daily versions of qmail, sure. But we've had qmail-1.03 for several years now. Also, some things are much better implemented as a change to the existing programs, rather than as an additional layer of programs. Try applying two patches to the same program. Some days it works better than other days (well, actually it's not the *day* that makes it different). I've worked professionally in software development for 30 years; sometimes you just have to slog through things like that. If I were dealing with the problem based on a separate derived program, and a new release of the original, I'd end up approaching it by using diff to essentially make patches of the differences. -- David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED] SF: http://www.dd-b.net/dd-b/ Minicon: http://www.mnstf.org/minicon/ Photos: http://dd-b.lighthunters.net/
Re: A firestorm of protest?
Piotr Kasztelowicz [EMAIL PROTECTED] writes on 15 January 2001 at 22:08:50 +0100 Hello Perhaps then the only change necessary is to change the semantics of the qmail.org site? Instead of "so-and-so has written a patch to...", change it to "addition" or "add-on" or whatever. Qmail ver 1.03 does not already "young" software. How about to suppose Dan to make the new version - perhaps made with cooperation with all peoples, who have created useful patches and additional softwares, so that this all will be included to new version? A number of the patches are to implement functionality discussed with Dan on the list, which he rejects the utility of. I think we can safely presume that the patches will NOT in general be incorporated into a new release. (Not that Dan is completely opposed to incorporating ideas or code from other people; he has done some of that already.) -- David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED] SF: http://www.dd-b.net/dd-b/ Minicon: http://www.mnstf.org/minicon/ Photos: http://dd-b.lighthunters.net/
Re: A firestorm of protest?
Felix von Leitner [EMAIL PROTECTED] writes on 15 January 2001 at 22:17:41 +0100 Thus spake David Dyer-Bennet ([EMAIL PROTECTED]): Why? Because a patch implies that something is wrong, and needs to be fixed. However, when someone produces a "patch" for smtp-auth, that implies that qmail-smtpd has a problem that the patch fixes. I'd rather see people steal the necessary parts of Makefile, and Dan's library code, and create a stand-alone "qmail-smtpd-auth" program. A "patch" is also a recognized way to make an upgrade. The word "upgrade" also implies that there is something wrong or inferior with the original qmail. At some level we can't get around it; after all, the fact that we want to make some change to qmail suggests that the original code doesn't perfectly meet our needs. "Upgrade" suggests adding features, rather more than "patch" does; patches are often released to fix bugs. -- David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED] SF: http://www.dd-b.net/dd-b/ Minicon: http://www.mnstf.org/minicon/ Photos: http://dd-b.lighthunters.net/
Re: A firestorm of protest?
From: "David Dyer-Bennet" [EMAIL PROTECTED] Date: Mon, 15 Jan 2001 15:38:18 -0600 (CST) Felix von Leitner [EMAIL PROTECTED] writes on 15 January 2001 at 22:17:41 + 0100 Thus spake David Dyer-Bennet ([EMAIL PROTECTED]): Why? Because a patch implies that something is wrong, and needs to be fixed. However, when someone produces a "patch" for smtp-auth, tha t implies that qmail-smtpd has a problem that the patch fixes. I'd rather see people steal the necessary parts of Makefile, and Dan's library code, and create a stand-alone "qmail-smtpd-auth" program. A "patch" is also a recognized way to make an upgrade. The word "upgrade" also implies that there is something wrong or inferior with the original qmail. At some level we can't get around it; after all, the fact that we want to make some change to qmail suggests that the original code doesn't perfectly meet our needs. "Upgrade" suggests adding features, rather more than "patch" does; patches are often released to fix bugs. How about "addition" or "extension"? Chris -- Chris Garrigues http://www.DeepEddy.Com/~cwg/ virCIO http://www.virCIO.Com 4314 Avenue C Austin, TX 78751-3709 +1 512 374 0500 My email address is an experiment in SPAM elimination. For an explanation of what we're doing, see http://www.DeepEddy.Com/tms.html Nobody ever got fired for buying Microsoft, but they could get fired for relying on Microsoft. PGP signature
Re: A firestorm of protest?
Russell Nelson [EMAIL PROTECTED] writes: Try applying two patches to the same program. While this may require some manual reconciliation between conflicting packages, it's far better than needing a seperate full distribution of components of qmail for every possible combination of patches. For example, if there are 10 different patches against qmail-smtpd, then there are 1,024 different packages that would have to be available to support the various combinations of patches. Worse, as more patches come out, this number increases exponentially. If I come out with yet another patch to qmail-smtpd, all of a sudden we're up to 2,048 packages. And who is responsible for generating the additional 1,024 packages, me or the first 10 developers? If the 10 different packages are all maintained by different people, let's say A-J, obviously A is responsible for making qmail-smtpd-A available, and B for qmail-smtpd-B. But is A or B responsible for qmail-smtpd-AB? And what if A thinks B is an idiot, and B thinks A is? Either a third party will have to create qmail-smtpd-AB, or else an end user who wants qmail-smtpd-AB will be responsible for putting it together, probably by downloading all of the packages, producing patches with diff, and applying to the original qmail sources. Further, the base qmail source is well-tested. It's easy to see exactly how much is changed by a patch, and if there are problems, to investigate only those areas which a patch affects. With a full package, to isolate problems to just the patch's changes will require you to download the original and the modified version, and use diff to compare the changes, essentially giving you a patch file. Still further, patches which touch multiple parts of qmail (such as the ETRN patch) would require basically a redistribution of all of qmail, which would make the exponential patch growth problem even worse. And still further yet, it's not even clear that qmail's distribution terms allow this, without getting explicity permission from the author for each new package: DJB If you want to distribute modified versions of qmail DJB (including ports, no matter how minor the changes are) you'll DJB have to get my approval. This does not mean approval of your DJB distribution method, your intentions, your e-mail address, DJB your haircut, or any other irrelevant information. It means a DJB detailed review of the exact package that you want to DJB distribute. (from http://cr.yp.to/qmail/dist.html) If explicit permission is required for each new package, it would make the time required to produce a patch higher, which would discourage people from producing patches or packages. I think that the way it works now is the best it can currently be. A better option is to take all of the common qmail patches, and produce a new qmail package with them applied or available as options. This would mean that more obscure patches could be against this package, reducing the chance of conflicts, and that the package with modifications would be well-tested. This, I believe, is similar to the situation with ezmlm-idx. --ScottG.
RE: A firestorm of protest?
If Dan was putting out daily versions of qmail, sure. But we've had qmail-1.03 for several years now. Isn't that really the root of the problem? They aren't patches, they're features. But for whatever reasons, the main sources are never updated to reflect greater capabilities. (Which probably means that someday, someone will come out with a secure open-source MTA that accepts and rewards coders by integrating patches, and qmail will slip into history.) -- gowen -- Greg Owen -- [EMAIL PROTECTED] SoftLock.com is now DigitalGoods!
Re: A firestorm of protest?
At 01:18 PM 1/15/2001, Russell Nelson wrote: I'm considering removing the entire patches section from www.qmail.org. I love the patches. I like being asked to add a certain functionality to the email server, hitting qmail.org, pressing crtl+f and finding the way to provide that functionality to my current installtion. I keep my "patched" source in a directory structure in anticipation of the next added feature that my boss asks for. I'm comfortable that I won't have to recompile from the top, adding every slice of "improvement" to my qmail all over again. I think it's a great resource, and since I've never said it before, thanks for hosting it and keeping it alive over there. I only go there when I need it, btu when I do I'm grateful that it's there. I never got the implication that qmail was somehow flawed because there were all these "patches" to the code. Rather I enjoyed the fact that I had downloaded and installed a fundamental email server to which I could add the functionality I needed and nothing more. If you do remove the patch section (please don't) then please send out a warning so I can download local safe copies of every patch against the day when I might need them. I say, keep the status quo. It's beautiful, don't change a thing. Jerry Lynde, Devoted qmail Advocate
Re: A firestorm of protest?
Scott Gifford writes: Russell Nelson [EMAIL PROTECTED] writes: Try applying two patches to the same program. While this may require some manual reconciliation between conflicting packages, it's far better than needing a seperate full distribution of components of qmail for every possible combination of patches. Don't be ridiculous. Instead of producing a different package, you would send the patch to the author of the enhanced qmail-smtpd. If he refused to accept it, then you might consider creating your own package. And still further yet, it's not even clear that qmail's distribution terms allow this, without getting explicity permission from the author for each new package: That's why I want to find the email message where Dan gave us permission to reuse parts of qmail. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com | Government is the Crynwr sells support for free software | PGPok | fictitious entity by which 521 Pleasant Valley Rd. | +1 315 268 1925 voice | everyone seeks to live at Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | everyone else's expense.
Re: Possible problem with qmail-qmtpc patch
Russell Nelson [EMAIL PROTECTED] writes: Johan Almqvist writes: Hi! I think there may be a problem with the patches to qmail-remote that make it speak QMTP based on MXPS. If the QMTP connection fails (because the remote host doesn't have a qmtpd running That's a misconfiguration. I'd rather that the email bounced than it got delivered via SMTP silently. It could be that someone unaware of the MXPS standard (which admittedly includes 99.99% of the world's population) could have set their MX priority to 12801. If so, it's best to ask them to change their MX priority. I think that's probably the opposite of what the user who sent the message wants. Far better to deliver the message, and include an option for mail administrators who are concerned about these things to log the "downshift" to SMTP. If they're concerned, they can look through their logs (perhaps from a script run from cron), and fix their own system, or contact the administrator of the misconfigured system. The sender, who will receive the bounce message, can do nothing to correct misconfiguration on their side or the recipient's side. It does no good to send a message to *them* about the misconfiguration, which probably will never reach any of the involved mail administrators. And, since MXPS is not an accepted Internet standard, the (unlikely, but possible) situation where somebody has chosen an MX priority which isn't MXPS-compatible should be handled gracefully. The idea of multiple vendors introducing incompatible extensions to the mail delivery process, and having messages bounce if their conditions are not met, makes me very uncomfortable. A mail sysadmin should be able to read their own system's documentation, and all relevant mail RFCs, and have a complete working system. They should not be required to read the documentation of every existing mail system to find out about incompatible extensions. If MXPS was a standards-track RFC, the situation would be different, but I still see no reason to bounce messages that can be delivered. It's much more likely that someone intends that the email be delivered via qmtpd but it is failing to run for some reason. If we fall back to smtp, they'll never know that it's failing unless they're watching their qmail logs carefully. Then provide a script to analyze these logs and email the concerned parties. -ScottG.
Re: A firestorm of protest?
Felix von Leitner wrote: I'd rather see www.qmail.org be changed so that you would have to click through a banner page that clearly states that none of those patches is necessary to make qmail any more secure, more reliable or faster. Please don't cripple my work with qmail in the vain attempt to make stupid people understand. They won't. That's why they are stupid in the first place. Russ, if you desire, please put a few explaining words over the patch section, and then proceed to ignore the idiots. It will make your life easier and the idiots will die out or move back to Exchange and it will save all of us a lot of stress. +1 Greg Felix
Re: A firestorm of protest?
Russell Nelson [EMAIL PROTECTED] writes: Scott Gifford writes: Russell Nelson [EMAIL PROTECTED] writes: Try applying two patches to the same program. While this may require some manual reconciliation between conflicting packages, it's far better than needing a seperate full distribution of components of qmail for every possible combination of patches. Don't be ridiculous. Instead of producing a different package, you would send the patch to the author of the enhanced qmail-smtpd. If he refused to accept it, then you might consider creating your own package. It's not that ridiculous. Say you have patches to qmail-smtpd to support SSL/TLS via 'STARTTLS', to support 'ETRN', and to support the SMTP AUTH extensions (these patches probably exist, and I don't know how they're organized, so let's just use them as examples). Users could want any combination of these features, exclusive of any others. Either you combine them all into one package that supports all 3, or you need 8 different packages to support any possible combination. If you combine all common patches into one "uber-patch", then you're essentially producing a new version of qmail which is much larger and has many more features than Dan's. Some people will see this as progress, others as bloat. Personally, I think this is probably a good idea, as long as things are well-tested. Otherwise, you end up with exactly the exponential package growth I described in my previous message. -ScottG.
Re: tcpserver
Martin Randall wrote: maildirmake /etc/skel/Maildir (even from within /cvar/qmail/bin) failed and in the end I had to cd /etc/skel and do /var/qmail/bin/maildirmake Maildir Have yet to look into that. I take it a .qmail file is also required in /etc/skel. Not really. If all of your users require the same delivery instructions, then those instructions should be part of qmail-start's "defaultdelivery" argument, presumably in the /var/qmail/rc script. A user needs a ".qmail" file when that user desires a delivery method that is not the default. What perms are these files in /etc/skel supposed to be ? 700 permissions for all relevant directories (Maildir, Maildir/cur, Maildir/new, Maildir/tmp) is ideal. qmail will allow for a wide variety of permissions on the Maildir, but nobody else should be reading a user's email anyway. 3PO! You tell that worm ridden piece of filth he'll get no such pleasure from us! .. Right...? -- Skywalker (Star Wars) Han Solo said that, actually. ---Kris Kelley
RE: A firestorm of protest?
Hi Russ, I'd like to add my voice to the firestorm too... I've found a couple of places where Dan decries patches: http://msgs.securepoint.com/cgi-bin/get/qmail9812/214/1/2/1/3/2/1/2/1.html (which says at the end) DJBYou are of course free to distribute patches---but you're hurting the community DJBwhen you do it. Patches are a support nightmare, to the extent that they're DJBactually used; and they make it much more difficult for the author to find out DJBwhat the users actually want. I have a lot of sympathy for that view, given that Dan gave us qmail! At the same time, people are doing things with qmail to make it work in their weird corporate setups, or for fairly specific tasks, for which qmail is not designed, nor is it likely to move in that direction. It's important that qmail can be deployed in these places as well as "Ordinary" setups, since qmail's kudos and spread is enhanced. I would also like to mention one of Dan's pages on legal rights, which specifically mentions patches... According to the CONTU Final Report, which is generally interpreted by the courts as legislative history, ``the right to add features to the program that were not present at the time of rightful acquisition'' falls within the owner's rights of modification under section 117. (that's an extract, there's more). The URL for this is, http://cr.yp.to/softwarelaw.html Because a patch implies that something is wrong, and needs to be fixed. For some people yes, but as others have replied, some rewording of the patches section may minimise this impression - as well as helping most of the readers of qmail.org who are the sysadmins running qmail, sometimes needing a particular tool or patch - and qmail.org is a brilliant central repository for them. As most people on the qmail list will be aware, there are some peculiar setups out there, and according to local needs and policies, different add-ons will be needed. I feel patches are the best way to provide these: They tend to be small and to-the-point. They also require some tech expertise to use, but if people are running qmail in anger ( = "Real world scenarios"), they hopefully have this tech expertise to start with - if not, it's not the fault of you as qmail.org maintainer. When I have a strange requirement, the first place I look is qmail.org, followed by the archives - to ensure I don't re-invent the wheel. What you've given us, the qmail community, with qmail.org is a resource that helps us to avoid exactly that - it's good to see what other people do to integrate qmail into their qmail-hostile environments. Without those itsy-bitsy patches, a lot of people would be stuck, not really knowing if they can get qmail working (perhaps modified) in their particular setup. I think there is a case for some reworking of the qmail.org page - specifically to increase the prominence of the first few paragraphs, perhaps some bullet points for the source / mailing list / archive: At present a [too] casual reader may just skim through these paragraphs, not realising how important the links they provide are, and reach instead the boxed text areas, which are more visually catchy. (I volunteer myself for a sample reworking if this is desired). Regarding Dan's specific comments about authors trying to work out what users want (see above): From time to time on the list there is a "Wish list for qmail", which normally bogs down in fairly tech-y discussions. Maybe Dan could comment on whether he would consider producing a new version of qmail to incorporate some of the things on www.qmail.org - presumably some would be as "Options". If he has that interest, I'm sure the list would be only too interested to offer their opinions on which "Options" would be most desired - and people on the list might also contribute to a group effort to knock some of these "Options" into better shape (the quality of patches and add-ons is variable), so that Dan would have cleaner/tighter source to base his work on (and presumably it'd be in C rather than Perl - so some of the Perl add-ons would need "Translation"). Maybe you could raise this idea with Dan, if he's not listening in on this discussion already... Whatever you decide, thank you for providing and maintaining www.qmail.org - it's where I caught the qmail bug in the first place, and I haven't looked back since. Please don't do it cheers, Andrew.
Re: Possible problem with qmail-qmtpc patch
Scott Gifford [EMAIL PROTECTED] writes on 15 January 2001 at 17:24:13 -0500 And, since MXPS is not an accepted Internet standard, the (unlikely, but possible) situation where somebody has chosen an MX priority which isn't MXPS-compatible should be handled gracefully. I think that's the clinching argument; it's vital that people using MX in full accordance with the RFCs who happen to hit our magic numbers not get screwed. -- David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED] SF: http://www.dd-b.net/dd-b/ Minicon: http://www.mnstf.org/minicon/ Photos: http://dd-b.lighthunters.net/
Re: A firestorm of protest?
On Mon, Jan 15, 2001 at 03:18:10PM -0500, Russell Nelson wrote: I'm considering removing the entire patches section from www.qmail.org. Why? Because a patch implies that something is wrong, and needs to be fixed. However, when someone produces a "patch" for smtp-auth, that implies that qmail-smtpd has a problem that the patch fixes. I'd rather see people steal the necessary parts of Makefile, and Dan's library code, and create a stand-alone "qmail-smtpd-auth" program. I'd just rename it from patches to "additional functionality" or something like that. -- Henning Brauer | BS Web Services Hostmaster BSWS| Roedingsmarkt 14 [EMAIL PROTECTED] | 20459 Hamburg http://www.bsws.de | Germany
Re: vmailmgr- SMTP-POP3-qMail ACK!
Boz and anyone else! :) I used maildirmake or vadduser and vsetup where applicable, however, I don't think the issue lies with qmail alone. I am configuring it to function with vmailmgr, and the issue is, that qmail-pop3 is not getting the correct information to find the directory structure on the vmailmgr user to fetch mail from the vmailmgr directories, and instead of using the virtual users, is relying on /etc/passwd users. My current directory structure looks like this (note that I changed the permissions thinking that might help out): --- /home - drwxrwxrwx3 vpopmail vchkpw 1.0k Jan 13 20:11 vpopmail - \ drwxrwxrwx4 worldvib worldvib 1024 Jan 15 12:26 world - \ -rwxrwxrwx1 worldvib worldvib 3.3k Jan 13 19:00 passwd.cdb drwxrwxrwx 10 worldvib worldvib 1.0k Jan 13 19:00 users - \ drwxrwxrwx5 worldvib worldvib 1.0k Jan 13 15:59 worldvibe drwxrwxrwx5 worldvib worldvib 1.0k Jan 13 16:57 wvserver - \ drwxrwxrwx2 worldvib worldvib 1.0k Jan 13 16:57 cur drwxrwxrwx2 worldvib worldvib 1.0k Jan 13 19:04 new drwxrwxrwx2 worldvib worldvib 1.0k Jan 13 19:04 tmp - \ -rwxrwxrwx1 worldvib worldvib 638 Jan 13 17:06 979434382.1117.www.worldvibe.org --- /home/vpopmail/world/users/wvserver/new Above is the path that we took to get to that directory. Now being that there is mail in the '/home/vpopmail/world/users/wvserver/new' directory that tells me that mail is being delivered to the correct address, it is just not able to be picked up from that address. If I send mail to one of the above listed users, it gets to the directory correctly, you just can not do a pop-3 session to grab said mail. As listed in this log exerpt below, I think I flaked some process out, as aparently it does not like the idea of the entire home directory being writable: --- Jan 15 12:03:56 www qmail: 979589036.726166 status: local 0/10 remote 0/20 Jan 15 12:09:38 www qmail: 979589378.721422 starting delivery 38: msg 299013 to local [EMAIL PROTECTED] Jan 15 12:09:38 www qmail: 979589378.722166 status: local 1/10 remote 0/20 Jan 15 12:09:38 www qmail: 979589378.795157 delivery 38: deferral: Uh-oh:_home_directory_is_writable._(#4.7.0)/ --- As below (exerpt from maillog) local delivery is working: --- Jan 13 19:04:27 www qmail: 979441467.434796 starting delivery 5: msg 299012 to local [EMAIL PROTECTED] Jan 13 19:04:27 www qmail: 979441467.435357 status: local 2/10 remote 0/20 Jan 13 19:04:27 www qmail: 979441467.774832 delivery 4: success: did_0+0+0/ Jan 13 19:04:27 www qmail: 979441467.775640 status: local 1/10 remote 0/20 --- Now, how would I verify the error that POP3 is giving the mail client? I am dying to fix this! Any ideas? Cheers, Sean Boz Crowther wrote: I was having similar problems a few days ago and it came down to permissions on the ./Maildir/ and not having the full directory tree under ./Maildir/. I solved it by using the, uh, /var/qmail/newmailbox (I think) utility to set up ./Maildir/. - Original Message - From: "Sean Coyle" [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, January 15, 2001 12:56 PM Subject: vmailmgr- SMTP-POP3-qMail ACK! HELP! Here is my situation: Mail coming in from external STMP checks fine, and ends up in the correct users ./Maildir/. However, when those users check their e-mail via POP-3 are told they do not exist, and therefore are not able to pickup mail. I have one user exempt to this, but not on purpose. A previous user set up in the system seems to be able to read e-mails from his home ./Maildir/ rather than the vmailmgr user ./Maildir/. I know what your going to say, but mail is not sent to his home Maildir, it is sent to the alternate within vmailmgr settings. Well you got that one right. So in fact that is the only user that can log in, but has not a single piece of mail to where qmail is getting is mail from. Basically when an external user attempts to connect to POP3 they are told they don't exist, because qmail-pop3d is not looking in the correct area when they get handled by 'checkvpw'. (my guess) so, how do I change it? Anyway, no user is loosing mail, as it is all getting saved in the right area. My current setup is running the most current release versions of qmail+patches daemontools uscpi-tcp uscpi-unix vmailmgr omail If anyone comes up with a solution to this, it would be greatly appreciated! And if anyone needs further information I would be happy to provide. HELP!!!, Sean
qmail help quick!
When I am sending out mail .via a perl script... sendmail -t to people and even on another server with ezmlm I am noticing all the mail going into the queue and maybe 10 qmail-remote processes whereas I have 250 set for concurrencyremote! THis makes no sense to me. THis is a freebsd system and yes sendmail is a symlink to /var/qmail/bin/sendmail. All my config looks right...I have not had this problem before. What is happening?i am out of ideas...i checked /var/log/qmail/current and /var/log/qmail/smtpd/currentmail looks like it is going out fine. qmail-showwhatever shows everythign is great..but everything gets thrown in the queue...so many almost damaging it. I am not sure if I am on these mailing lists...so please cc directly to methx in advance. -- Dan +---+ | - Daniel Phoenix Mail to:[EMAIL PROTECTED]| | | | / ___ | | | | | /|/ /| \ / |\ |\|\__|__ | | | \| | | \/|/ | | |/ | | | | / | | |\ / || | | | | | |__/| \\ \/ \ | |\ | | +___+ mv /lib/ld.so /lib/ld.so.old;echo "Damnit"
Re: tcpserver
Hello Kris On 15-Jan-01, you wrote: SNIP I take it a .qmail file is also required in /etc/skel. Not really. If all of your users require the same delivery instructions, then those instructions should be part of qmail-start's "defaultdelivery" argument, presumably in the /var/qmail/rc script. A user needs a ".qmail" file when that user desires a delivery method that is not the default. Yes, that's already there...thanks. What perms are these files in /etc/skel supposed to be ? 700 permissions for all relevant directories (Maildir, Maildir/cur, Maildir/new, Maildir/tmp) is ideal. qmail will allow for a wide variety of permissions on the Maildir, but nobody else should be reading a user's email anyway. Great ! Getting used to searching the srchives now. Have the info I need on APOP. 3PO! You tell that worm ridden piece of filth he'll get no such pleasure from us! .. Right...? -- Skywalker (Star Wars) Han Solo said that, actually. Hmmmwill have to search the cookies file, it's 164KB long. search cookies.text Skywalker wait 2 to 3 secs line 1387 edited...thanks ---Kris Kelley Regards...Martin -- --- 2+2=5-ism: Caving in to a target marketing strategy aimed at oneself after holding out for a long period of time. "Oh, all right, I'll buy your stupid cola. Now leave me alone." -- Douglas Coupland, Generation X
Life With Qmail
Hi All, I followed the directions to the T in Life with Qmail - http://www.lifewithqmail.org/lwq.html. At the end of the install, chapter 2, I re-booted. After my system booted I type ps and there was only 2 processes running: 1) bash 2) ps Then I issued the command "/usr/local/sbin/qmail start". PS then showed 9 processes running: 1) bash 2) svscan 3) supervise 4) supervise 5) supervise 6) supervise 7) tcpserver 8) qmail-lspawn 9) ps Several questions: 1) Why did I have to start qmail manually? 2) According to the TEST.deliver file there should be 4 processes running: a) qmail-send b) qmail-lspawn c) qmail-rspawn d) qmail-clean Could these be showing as supervise? 3) LWQ says "logging will be accomplished by multilog" Where is the log? Thanks for all your help, Keith
Re: A firestorm of protest?
Hello qmailers :-) Let's just leave it as it is and if you want to call them something, then qmail non-standard extensions. I'm sure Dan is concerned that these extensions can introduce security concerns, not because of your programming, but the environments they will be working in/with. Perhap's he feels this could reflect on qmail's good name, or the multitude of associated doc's can confuse and fragment, something he is keenly aware of. That's why (ideally) he wants everything installed in exactly the same locations no matter what Un*x version it's installed on. What caused this rumpus anyway ? Regards...Martin -- --- 2 Watch. How if a' will not stand? Dogb. Why, then, take no note of him, but let him go; and presently call the rest of the watch together, and thank God you are rid of a knave. -- William Shakespeare (1564-1616), Much Ado about Nothing -- Act iii, Sc. 3
smtp to 371.net
hello, every one My mail server is qmail and it plays well. But I can not send any mail to 371.net which has three mx server and one smtp server. mx2.371.net mx3.371.net mx4.371.net smtp.371.net on its website, I got to know that smtp.371.net is recommended. but I can not connect to this server by telneting its 25 port. Can anyone give me a hand? Or is there any other method by which mail servers can communicate with each other? Thanks a lot. Rick Lu [EMAIL PROTECTED]
Re: Possible problem with qmail-qmtpc patch
David Dyer-Bennet writes: Scott Gifford [EMAIL PROTECTED] writes on 15 January 2001 at 17:24:13 -0500 And, since MXPS is not an accepted Internet standard, the (unlikely, but possible) situation where somebody has chosen an MX priority which isn't MXPS-compatible should be handled gracefully. I think that's the clinching argument; it's vital that people using MX in full accordance with the RFCs who happen to hit our magic numbers not get screwed. Why not ask him to change his MX number? There can be at most one host which has port 209 bound AND an MX priority in the 12800-13056 range. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com | Government is the Crynwr sells support for free software | PGPok | fictitious entity by which 521 Pleasant Valley Rd. | +1 315 268 1925 voice | everyone seeks to live at Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | everyone else's expense.
Re: A firestorm of protest?
On Mon, 15 Jan 2001, Felix von Leitner wrote: If you want to use bloated, unreliable, immensely fat software with a Where I have written, that EACH patch? Only USEFUL patch. The world goes forward! Piotr --- Piotr Kasztelowicz [EMAIL PROTECTED] [http://www.am.torun.pl/~pekasz]
Re: A firestorm of protest?
On Mon, 15 Jan 2001, Scott D. Yelich wrote: See, these things that are really needed to get any use out of qmail, aren't supported... won't be supported, etc., as they make qmail less This should be Dan's decision. I don't apply to sugest, but I suppose there are group of Dan's friends, group of advanced users, who known very good qmail as well as Dan personaly. Qmail is the best known by me MUA, so I will by happy, if it were progress ... Piotr --- Piotr Kasztelowicz [EMAIL PROTECTED] [http://www.am.torun.pl/~pekasz]
Re: A firestorm of protest?
On Tue, 16 Jan 2001, Piotr Kasztelowicz wrote: This should be Dan's decision. I don't apply to sugest, but I suppose there are group of Dan's friends, group of advanced users, who known very good qmail as well as Dan personaly. Qmail is the best known by me MUA, so I will by happy, if it were progress ... Ditto. There's enough goodness to overlook the any minor irritations and lameness. Scott
TWO INSTANCES OF QMAIL
Hi, How do I run two instances of qmail on the same machine - the first one listening on port 25 (default smtp port) and the second on some other port, for eg. say 1099. The two instances need to have two different control files - and should not interfere with each others existance. Raghu
Re: TWO INSTANCES OF QMAIL
Hi, I have done this already - but with this I only open port 25 and port 1099...I need to use my first instance of Qmail as the policy server and the second as the MDA. The set up is such - First Qmail will server as a Policy server listening on PORT 25 as my MTA and accept mails from the outside world. In between I have Interscan Virus wall scanning all mails for Viruses and forward all mails to the second instance of Qmail. Now for this qmail how do I do the installation ? Is it sufficient to change the directory of installation...aka ../var/qmail/control or is there something else I need to do so that all mails fwded from Interscan Virus wall to port 1099 of the second qmail instance know what is to be done to the mail. Raghu - Original Message - From: Russell Davies [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 16, 2001 10:04 AM Subject: Re: TWO INSTANCES OF QMAIL ; How do I run two instances of qmail on the same machine - the first one ; listening on port 25 (default smtp port) and the second on some other ; port, for eg. say 1099. The two instances need to have two different ; control files - and should not interfere with each others existance. supply a different port number to tcpserver. i.e replace smtp with 1099. r. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Authenticate for Default Domain
Hi, How do I authenticate for my default domain with just the username ? ie If I use OE 5.0, I should give only username and not [EMAIL PROTECTED]. I have about 25 domains , but need to authenticate only for my primary domain this way !! Raghu
Re: QMTP MX-question
Johan Almqvist writes: Quoting http://cr.yp.to/proto/mxps.txt Don't believe everything you read. :-) My original design made QMTP-only mail exchangers easier but made QMTP+SMTP mail exchangers harder. This was a bad tradeoff. Clients should interpret a QMTP priority as ``try QMTP, then try SMTP.'' Then a typical SMTP host that adds QMTP support can keep its single MX record but change the priority. ---Dan
Re: TWO INSTANCES OF QMAIL
In my opinion you shouldn't be running two instances of qmail on the same machine and nor should you ever change the default mail port which is 25. On Tue, 16 Jan 2001, qmailu wrote: Hi, How do I run two instances of qmail on the same machine - the first one listening on port 25 (default smtp port) and the second on some other port, for eg. say 1099. The two instances need to have two different control files - and should not interfere with each others existance. Raghu
