qmail Digest 16 Jan 2001 11:00:01 -0000 Issue 1246
Topics (messages 55185 through 55274):
Authentication with qmail from the external network
55185 by: maria.c.s.terra.es
Hi. inetd problems
55186 by: Gon�alo Gomes
55188 by: Mark Delany
55190 by: Piotr Kasztelowicz
Re: Installing mini-qmail seems to require qmail ids contrary to documentation
55187 by: Mark Delany
55189 by: Mark Delany
Re: Bogus popularity claims for Sendmail
55191 by: Mark Delany
55270 by: Gjermund Sorseth
Re: qmail-ldap
55192 by: Jose AP Celestino
need a howto, something i can follow step by step and get qmail installed..
55193 by: Gon�alo Gomes
55194 by: Jose AP Celestino
55209 by: Alexander Jernejcic
Tcpserver
55195 by: Piotr Kasztelowicz
55201 by: Martin Randall
55202 by: joshua stein
55203 by: James Raftery
55204 by: Martin Randall
55205 by: Martin Randall
55206 by: James Raftery
55208 by: Martin Randall
55210 by: Charles Cazabon
55241 by: Martin Randall
55243 by: Kris Kelley
55250 by: Martin Randall
Re: >65535 users on linux
55196 by: Jose AP Celestino
Re: Addon
55197 by: Tim Hunter
55198 by: Steve Crowder
stripping binaries
55199 by: Matthew Patterson
55200 by: joshua stein
IsoQlog 1.4 released (Qmail Log Analyser)
55207 by: Ismail YENIGUL
Life With Qmail - PW?
55211 by: Keith Smith
55213 by: Alexander Jernejcic
Re: QMTP MX-question
55212 by: Peter van Dijk
55261 by: D. J. Bernstein
55266 by: Vincent Schonau
delays on telnet localhost 25
55214 by: Paulo Correia
55216 by: Charles Cazabon
A firestorm of protest?
55215 by: Russell Nelson
55217 by: Greg Cope
55218 by: David Dyer-Bennet
55219 by: Charles Cazabon
55221 by: Russell Nelson
55224 by: Piotr Kasztelowicz
55225 by: Kris Kelley
55226 by: Felix von Leitner
55227 by: Felix von Leitner
55228 by: Scott D. Yelich
55229 by: Kris Kelley
55230 by: David Dyer-Bennet
55231 by: David Dyer-Bennet
55232 by: David Dyer-Bennet
55233 by: Chris Garrigues
55234 by: Scott Gifford
55235 by: Greg Owen
55236 by: Jerry Lynde
55237 by: Russell Nelson
55239 by: Greg Cope
55240 by: Kris Kelley
55242 by: Scott Gifford
55245 by: Andrew Richards
55247 by: Henning Brauer
55252 by: Martin Randall
55255 by: Piotr Kasztelowicz
55256 by: Piotr Kasztelowicz
55257 by: Scott D. Yelich
55265 by: Erwin Hoffmann
55267 by: Felix von Leitner
55268 by: Felix von Leitner
55271 by: Piotr Kasztelowicz
Multilog
55220 by: Alex Kramarov
55223 by: tc lewis
vmailmgr- SMTP-POP3-qMail ACK!
55222 by: Sean Coyle
55248 by: Sean Coyle
Re: Possible problem with qmail-qmtpc patch
55238 by: Scott Gifford
55244 by: Ian Lance Taylor
55246 by: David Dyer-Bennet
55254 by: Russell Nelson
55264 by: Scott Gifford
qmail help quick!
55249 by: Dan Phoenix
Life With Qmail
55251 by: Keith Smith
smtp to 371.net
55253 by: Rick Lu
TWO INSTANCES OF QMAIL
55258 by: qmailu
55259 by: qmailu
55262 by: Grant
55263 by: Marlon_Abao.support.trendmicro.com
Authenticate for Default Domain
55260 by: qmailu
55269 by: qmailu
55274 by: Andrew Richards
Documentation of qmailanalog
55272 by: piyushjain.itil.com
qmailanalog scripts
55273 by: Clemens Hermann
Administrivia:
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To bug my human owner, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
Hi 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.
On Mon, Jan 15, 2001 at 12:18:39PM -0000, 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.
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]
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.
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.
> On Sat, Jan 13, 2001 at 10:16:34PM -0000, 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.
Mark Delany write: > I would (...) just > use the 250 responses from the remote SMTP servers. > > 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. Good idea. For fun, I decided to look at the logs from our server for the last two weeks. The sample size comes to 3,016,454 messages delived to 62,786 different SMTP servers around the world. Out of these 62,786 remote SMTP servers, 16,658 are running sendmail (27%) and 5098 are running qmail (8%). (The server providing these logs belongs to an ISP and includes a good mix of private, commercial, educational and government users. The remote servers are mostly active servers at other ISP's, schools or businesses I presume, few `idle workstations') -- Gjermund Sorseth
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) > > > @400000003a62f02e3387df24 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 Administração de Sistemas / Operações || 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.. Thanks in advance Gonçalo Gomes
On Mon, Jan 15, 2001 at 01:02:53PM -0000, Gon?alo Gomes wrote: > need a howto, something i can follow step by step and get qmail installed.. > > Thanks in advance > Gonçalo 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 Administração de Sistemas / Operações || http://www.sapo.pt ----------------------------------------------------------- "Do not meddle in the affairs of SysOps, for you are crunchy and good with ketchup."
http://www.lifewithqmail.org/ > -----Original Message----- > From: Gonçalo 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 > Gonçalo Gomes > > >
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]
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
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?
On Mon, Jan 15, 2001 at 09:55:12AM -0600, joshua stein 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? 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 -- James Raftery (JBR54) "Managing 4000 customer domains with BIND has been a lot like herding cats." - Mike Batchelor, on [EMAIL PROTECTED]
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
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
On Mon, Jan 15, 2001 at 11:25:06AM -0500, Martin Randall wrote: > 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. 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. > For me, this is training as opposed to getting something up and running > ASAP. [...] > this is going to be a DJBware machine. Excellent, that earns you 10 brownie points :-) -- James Raftery (JBR54) "Managing 4000 customer domains with BIND has been a lot like herding cats." - Mike Batchelor, on [EMAIL PROTECTED]
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.
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. -----------------------------------------------------------------------
Hello Charles On 15-Jan-01, you wrote: > > 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 I did a search via the archive and found the material just before I received your note Charles, but thanks anyway. I'm having some unusual problems path related but am not sure what. 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. What perms are these files in /etc/skel supposed to be ? There was some discussion a couple of years ago on the mailing list (per archives) with two or 3 possibilities given but I didn't see the end result. An explanation why would be appropriate to round off the subject. Later... Regards...Martin -- --------------- 3PO! You tell that worm ridden piece of filth he'll get no such pleasure from us! ...... Right...? -- Skywalker (Star Wars)
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
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. > Hmmm....will 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
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 Administração de Sistemas / Operações || http://www.sapo.pt ----------------------------------------------------------- Never make anything simple and efficient when a way can be found to make it complex and wonderful.
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]
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]
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 ***********************************
Matthew Patterson wrote: > How exactly does one go about stripping binaries? strip /var/qmail/bin/*
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"; ?>
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
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 > > >
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
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
D. J. Bernstein writes: > 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. If I understand correctly, this is the way Russ has implemented it, and I think it is an important clarification of mxps.txt. Would you consider updating that document to reflect this? Also, since a number of people are now running QMTP *and* MXPS, are you going to do this for cr.yp.to as well? Thanks, Vince.
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
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. -----------------------------------------------------------------------
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.
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.
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/
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. -----------------------------------------------------------------------
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.
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]
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
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
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
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
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
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/
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/
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/
> 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
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.
> 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!
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
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.
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
Russell Nelson wrote: > 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 basically we invent a multi-layered migraine-inducing qmail bureacracy, where every programmer who thinks he has something worthwhile to contribute must talk to any or all other programmers to see who will accept his contributions. In the end, this hapless programmer may decide to create his own version of the program anyway, which puts us back to square one of trying to marry different versions of the same program to get the features we want. I see where you're coming from, but I honestly think this would cause more trouble than it is worth. Trying to make something idiot-proof will only add to the complexity, and just wait until the bigger idiots come along... ---Kris Kelley
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.
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) DJB>You are of course free to distribute patches---but you're hurting the community DJB>when you do it. Patches are a support nightmare, to the extent that they're DJB>actually used; and they make it much more difficult for the author to find out DJB>what 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.
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
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
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]
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]
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
At 23:46 15.1.2001 +0100, Henning Brauer wrote: >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. > I guess, thats the correct approach. It would be very helpful for the qmail community to "organize" the patches - or have them organized. From my point of view - actually how I organize the mails coming from this mailing list - one should differentiate between "Add-Ones" (eg. scripts working within .qmail and the brand new Log-Analyzer in perl) leaving the product unchanged and "Miscellaneous enhancements" covering the patches against the code. Both should be organized by feature and/or qmail module. This would help to keep track of the patches. When I initially created the SPAMCONTROL patch, I had the same problem like everybody has: Here and there is a useful piece of code (=patch) which I integrated into a larger set. But this is not as trivial as it seems. While qmail 1.03 is since years in the field SMTP development is going further (eg. STARTTLS and SASL) and of cause, everybody is interesting employing those features. It is necessary to integrate those enhancements (even though they are not coming from DJB and might be as complex as qmail-ldap) in order to be competitve. In addition, since qmail is prefered by ISPs, there requirements are different wrt the end user. Therefore, we have today packages like vpopmail, sqwebmail and others which enhence qmail and it's complexity significantly. Maybe it would worthwile to consider this as well as an "organizational" item for qmail.org. cheers. eh. +-----------------------------------------------------------------------+ | fff hh http://www.fehcom.de Dr. Erwin Hoffmann | | ff hh | | ff eee hhhh ccc ooo mm mm mm Wiener Weg 8 | | fff ee ee hh hh cc oo oo mmm mm mm 50858 Koeln | | ff ee eee hh hh cc oo oo mm mm mm | | ff eee hh hh cc oo oo mm mm mm Tel 0221 484 4923 | | ff eeee hh hh ccc ooo mm mm mm Fax 0221 484 4924 | +-----------------------------------------------------------------------+
Thus spake Piotr Kasztelowicz ([EMAIL PROTECTED]): > > 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! There is no objective measure for the usefulness of a patch. Thus, there will be endless fruitless discussions that make everyone feel bad, and in the end either Dan does not include the patch, which means that it was all for naught, or Dan does include the patch, and then the discussion will also have been for naught since Dan already includes patches he likes without external discussions (the pop3 daemon is based on someone else's code). Felix
Thus spake Kris Kelley ([EMAIL PROTECTED]): > > 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? Exim is luser friendly. That's why it is luser software. Felix
On Tue, 16 Jan 2001, Felix von Leitner wrote: > There is no objective measure for the usefulness of a patch. > Thus, there will be endless fruitless discussions that make everyone > feel bad ... Lets so Dan take way of further progress of qmail himself ...:-) Piotr --- Piotr Kasztelowicz <[EMAIL PROTECTED]> [http://www.am.torun.pl/~pekasz]
__________________________________________________
IncrediMail - Email has finally evolved - Click Here
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.
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
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 - drwxrwxrwx 3 vpopmail vchkpw 1.0k Jan 13 20:11 vpopmail - \ drwxrwxrwx 4 worldvib worldvib 1024 Jan 15 12:26 world - \ -rwxrwxrwx 1 worldvib worldvib 3.3k Jan 13 19:00 passwd.cdb drwxrwxrwx 10 worldvib worldvib 1.0k Jan 13 19:00 users - \ drwxrwxrwx 5 worldvib worldvib 1.0k Jan 13 15:59 worldvibe drwxrwxrwx 5 worldvib worldvib 1.0k Jan 13 16:57 wvserver - \ drwxrwxrwx 2 worldvib worldvib 1.0k Jan 13 16:57 cur drwxrwxrwx 2 worldvib worldvib 1.0k Jan 13 19:04 new drwxrwxrwx 2 worldvib worldvib 1.0k Jan 13 19:04 tmp - \ -rwxrwxrwx 1 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 >> >> >
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.999999% 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.
Johan Almqvist <[EMAIL PROTECTED]> writes: > 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) this failure will be logged as > > deferral: Connected_to_194.47.249.19_but_connection_died._(#4.4.2)/ > > which means that the message will not be retried at the next best MX but > go back to the queue. I don't see it. Russ's patch looks like this (at least, in the version I downloaded): - if (timeoutconn(smtpfd,&ip.ix[i].ip,(unsigned int) port,timeoutconnect) == 0) { + if (qmtp_priority(ip.ix[i].pref)) { + if (timeoutconn(smtpfd,&ip.ix[i].ip,(unsigned int) qmtp_port,timeoutconnect) == +0) { + tcpto_err(&ip.ix[i].ip,0); + partner = ip.ix[i].ip; + qmtp(); /* does not return */ + } + } + if (timeoutconn(smtpfd,&ip.ix[i].ip,(unsigned int) smtp_port,timeoutconnect) == +0) { In other words, if the MX priority indicates QMTP, try to make a QMTP connection. If that connection fails--if it times out, or if the remote system does not accept the connect request--timeoutconn will return -1 and qmail-remote will go on to try to make an SMTP connection. The scenario you describe should only occur if the connection to the QMTP server succeeds, implying that something is listening on port 209, but that whatever program is listening doesn't speak QMTP as expected. What am I missing? Ian
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/
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.
Russell Nelson <[EMAIL PROTECTED]> writes: > 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. Right, if they are listening on port 209, they have an MXPS MX record, and it at least vaguely seems to be speaking QMTP, I think it's a perfectly valid assumption that they're running qmail, and would like their mail delivered via QMTP. The issue I was concerned about was the situation where they had an MXPS MX record, but no QMTP listener at all. As I read your previous comment, you were advocating bouncing the message in that situation; that is what I was concerned about. I may have just misread your message. Looking back over the discussion, it looks like the topic may have been whether to bounce the message if mailroutes explicitly says to use QMTP. I agree that bouncing is appropriate in this situation. Sorry if this has all been a misunderstanding, -----ScottG.
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/current....mail 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 me....thx in advance. -- Dan +-----------------------------------------------------------------------+ | ----- Daniel Phoenix Mail to:[EMAIL PROTECTED] | | | | / ___ ____ ____ |____ ____ | | | | / |/ / | \ / | \ | \ | \ __|__ | | | \ | | | \ / |____/ | | |____/ | | | | / | | | \ / | | | | | | | |__/ | \____\ \/ \____ | | \____ | | +_______________________________________________________________________+ mv /lib/ld.so /lib/ld.so.old;echo "Damnit"
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
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]
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
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 >
Title: RE: TWO INSTANCES OF QMAILGrant,
why not? i've been running multiple instances one the same machine for some time now. each instance bound to port 25 on a separate interface.
this guy might have valid concerns, like budget or testing, to ask what he needed.
raghu,
get the source. change the directory on the "conf-qmail" file to reflect the directory you want to install the new instance on. all the users and groups are just fine.
add whatever patches you need. compile.
create a new script to start your new instance running on some other port or interface. just make sure you're using the fullpath of your new qmail installation.
-marlon
-----Original Message-----
From: Grant [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 16, 2001 1:18 PM
To: qmailu
Cc: [EMAIL PROTECTED]
Subject: 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
>
>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 !! >This is a little urgent !! Raghu, You haven't told us *anything* about your qmail setup, so how you expect us to be telpathic and work out what you've setup, I don't know. The fact that you're using multiple domains suggests you might be using, say, vpopmail or VMailMgr, but that's speculation. Possible answer to your question: Run your default domain separately (outside of virtualdomains etc; separate POP3 service). There is a mailing list for vpopmail which may be more appropriate. Andrew.
Hi there, I am searching for the Documentation of qmailanalog from last one day on net. but unable to find it.Please suggest me where i can get that or if somebody has with him pl. mail me. Thanks, Piyush Jain. [EMAIL PROTECTED]
Hi, did anyone make the attemt to get the output of qmailanalog in a webpage. I think of kind of report-page where you get a short monthly summary for each local/virtual domain (how many messages, how many Megs, etc.) If there is nothing like this around, would anyone else be interested in such a script or is it just me? bye /ch
