Hi, As i'm using qmail-1.03-r15 from Gentoo, i watch the qmail-maillist. Yesterday there was a mail (with recommendations) about the need of all patches included in Gentoo-ebuild. i'll include it below: ...BEGIN... Casey Allen Shobe <lists@seattleserver.com> wrote: > > I've been using qmail for a long time, and love it. However I've got some > mixed feelings about how to move forward with things such as SMTP Auth. > > I wrote an email to the author a couple months ago inquiring about the > future of Qmail but never received an answer, I guess I'm not important > enough! That's not the reason. If you have a good, answerable question, he generally responds within a few days. I've had responses from him within hours on occasion. However, his standards for "good" questions are quite high, and if you don't meet them, you won't get a response at all. He doesn't bother to write back to try to elicit further details, or tell you where you can find the answer on the 'net, or anything like that. Since he's publicly stated he's working on qmail v.2, any question remotely like "When will it be done?" is /not/ a good question, since the only possible answer is "when its done". > These days I'm using Gentoo, and it applies the following enourmous > list of patches: Okay. The problem there is that Gentoo's qmail package is a hodgepodge of unnecessary and buggy patches -- if you look in the archives of this list, you'll find plenty of users complaining about weird problems that turn out to be caused by one or more of the patches they include, and everything starts working if they just revert to installing via "Life with qmail". > http://gentoo.chem.wisc.edu/gentoo/distfiles/qmailqueue-patch This is small, of general use, and can't break anything. That may be why it's also the only non-bugfix patch we included in netqmail. > http://qmail.null.dk/big-todo.103.patch Of some limited use in some situations. > http://www.jedi.claranet.fr/qmail-link-sync.patch Not the cleanest way to solve the Linux fsync bug. I prefer Bruce Guenter's solution, which requires no change to the qmail code. > http://gentoo.chem.wisc.edu/gentoo/distfiles/big-concurrency.patch Of no use to 99.9999% of qmail sites. Not necessary. > http://www.suspectclass.com/~sgifford/qmail/qmail-1.03-0.0.0.0-0.2.patch An excellent patch, and included in netqmail. > http://david.acz.org/software/sendmail-flagf.patch An excellent patch, and included in netqmail. > http://gentoo.chem.wisc.edu/gentoo/distfiles/qmail-1.03-qmtpc.patch Not necessary for 99.9999% of qmail sites. > http://gentoo.chem.wisc.edu/gentoo/distfiles/qmail-smtpd-relay-reject While this patch has some limited use, it will break certain otherwise valid email addresses containing rare characters, so it should be applied by admins who know they need it, not as a general case. > http://gentoo.chem.wisc.edu/gentoo/distfiles/qmail-local-tabs.patch An excellent patch, and included in netqmail. > http://www.shupp.org/patches/qmail-maildir++.patch Not necessary. > ftp://ftp.pipeline.com.au/pipeint/sources/linux/WebMail/qmail-date-localtime.patch.txt A bad idea, and should not be included. > ftp://ftp.pipeline.com.au/pipeint/sources/linux/WebMail/qmail-limit-bounce-size.patch.txt A bad idea, and should probably not be included. > http://www.ckdhr.com/ckd/qmail-103.patch This is the 64kb DNS patch. > http://www.arda.homeunix.net/store/old_software/qregex-starttls-2way-auth.patch >From that patch's header: ... this patch is not type-safe ... made qmail-smtpd crash frequently on [64-bit platform] ... Not a good idea. > http://www.soffian.org/downloads/qmail/qmail-remote-auth-patch-doc.txt client SMTP AUTH for qmail-remote. Mostly not necessary. > http://gentoo.chem.wisc.edu/gentoo/distfiles/qmail-gentoo-1.03-r12-badrcptto-morebadrcptto-accdias.diff.bz2 Of no use, unless you want to have a "badrcptto" list that's thousands of addresses long. > http://www.dataloss.nl/software/patches/qmail-popupnofd2close.patch I've not seen a particular reason to do this, but obviously someone wanted to add logging to qmail-pop3d. > http://js.hu/package/qmail/qmail-1.03-reread-concurrency.2.patch Pointless -- admins shouldn't need to change their concurrency settings so often that they have to worry about the overhead of re-starting qmail-send. > http://www.mcmilk.de/qmail/dl/djb-qmail/patches/08-capa.diff No idea why anyone would need this. POP3 clients just try TOP/UIDL/LAST and can handle servers that don't support them. > http://www.leverton.org/qmail-hold-1.03.pat.gz Pointless. Change local/remote concurrency to 0, restart qmail-send. No patch necessary. > http://gentoo.chem.wisc.edu/gentoo/distfiles/netscape-progress.patch Obsolete and pointless. > http://www-dt.e-technik.uni-dortmund.de/~ma/djb/qmail/sendmail-ignore-N.patch Minimal impact. > http://gentoo.chem.wisc.edu/gentoo/distfiles/qmail-1.03-moreipme-0.6pre1-gentoo.patch Useful for some installations -- but this includes the 0.0.0.0 functionality. WTF is the above 0.0.0.0 patch also doing in here? > http://hansmi.ch/download/qmail/qmail-relaymxlookup-0.3.diff Holy @$#%$@#, this patch is a security hole. All I need to do to relay through your server is list your server as an MX for my domain, and you'll now relay to me. For bonus points, here's a simple denial-of-service attack against you: I list you as an MX for my domain, and then cause qmail-smtpd to issue 4xx errors to any client connecting from your network. Now I start relaying 5MB or 10MB messages through you, until your queue disk fills up and you can't accept other mail for a week. Many clients will give up on delivering their messages to you and bounce them in less than a week -- you've now lost messages. You probably want to report this as a security hole to the Gentoo folks. But it nicely illustrates that the Gentoo qmail package maintainer doesn't have a clue and shouldn't be responsible for maintaining any software packages. > So what I'm wondering is, is it possible (and sane) to use a > vanilla, unpatched qmail, along with tools like mailfront Yes. Basically, netqmail includes a few small patches which have been considered generally useful to most qmail users by those who put it together, mostly fixing generally-acknowledged bugs. Run netqmail and almost everything else you want to do can be done with add-on packages that don't require patching qmail. Charles -- ...END... Don't wanna begin a 'flame war' (i use and like the Gentoo way of qmail). Just maybe due to the enormous number of qmail-patches >20 (which sometimes *may* overlap in functionality) think that this could be usefull for someone here. Also post this as it comes from a respected person (on qmail-list) and even more he also points (can't confirm) to a security related patch, see above. Thanks. Rumen Reproducible: Always Steps to Reproduce: 1. 2. 3.
(In reply to comment #0) > Okay. The problem there is that Gentoo's qmail package is a hodgepodge of > unnecessary and buggy patches I though this was a definition of qmail, you blame Gentoo for this? What about asking the author to change the obnoxious license instead? ;p OK, qmail herd, enjoy this bug. :)
I've been wondering how long it would take for this bug (have read the e-mail on the ML already). About the relaymxlookup-patch: I know it's not perfect. But it's not a security hole, more like a potential DoS. I wrote the patch because I've needed some secondary server to accept e-mails for all domains on the main server. Its functionality isn't enabled until you create control/relaymxlookup. So, as long as you know what you're doing, it isn't so much of a problem. Beside of that, how can Exim contain such a feature and not be yelled at "Insecure! Insecure!"? Or at least, I haven't ever read something like that. The webpage for the patch (might interest you and Charles Cazabon) is http://hansmi.ch/software/qmail. I'm interested in discussing this issue, especially if you've a better idea to make sure the secondary MX knows all rcpt-to-domains. And why did you not try qmail-1.03-r16? It contains alot of updated patches and fixes. See bug 40486 and bug 29485 and their associated bugs.
Hi, First to say i like the way Gentoo does it's ebuild for qmail and can't critisize it in any way. Even think not all said things are 100% *true*. Now some thoughts: 1.Evidently the qmail license won't change anytime soon so this is the reality, people need/(will need) patches to achieve their goals; 2.Also think that the available USE-flags are quite enough as otherwise there will be more than a dozen. IMHO this patches just are applied to do their job, three can be disabled (SSL,CRAM,TLS before AUTH) + 2 more for qmail-1.03-r-16; 3.Had an idea but that only after posting the BUG - why not have a new package: mail-mta/netmail-1.05 with the corresponding patches - like a alt-qmail ;) 4.Some problems with current ebuild state could be the difficulty to make a custom-patched qmail-install (copy to overlay disable patches etc.); 5.Personally i only use qmail as my home-mail-server and don't need all the things, but like to play with it though ;). So in no need, but will try out the testing version (-r16). Had that running before (reinstall). Realize that it's getting quite difficult to work with such a mess (restrictive license, quite old initial code, too many patches, two or three for a function). But also had (bugs filed) compile problems with some of the accompaning packages Not complaining in any way, just wanna make things better,easier. PS: feel free to close this Bug as you wish, nothing critical IMO. Thanks. Rumen
netqmail is in portage since months
