Patches says it all virusscan on smtpd for microsoft virus http://qmail.serve-you.net/qmail-smtpd-viruscan-1.3.patch Ipv6 is gonna be added back at this point as well I have the patch rediffed already but gotta work out compilation errors. Sorry for the delay. If you feel a patch is missing that would benefit the majority of users post as soon as possible or you will have to wait till -r18 A freeze is in place now for all patches for -r16. This could change only if patch that is needed is concidered a security patch.
I really need the functionality the chkusr 1.0 patch added to qmail or better yet the new chkuser 2.0 binaries/hooks made by the same author. Gentoo's solution so far has been to use the included qmail-spp patch and get plugins. So far I have tried 4 different chkusr type scripts and not one of them has been reliable and bug free. The best script I've found is a bash shell script and it seems to catch everything but ezmlm mailing lists. This is because the script can't have access to /var/vpopmail/domains directory to check if a mailing list ".qmail-??? file" exists. Thus all posts to mailing lists are seen as posts to invalid accounts and rejected. Supposedly the chkuser 2.0 patch has been made almost entirely into separate binaries only requiring minor hooks into qmail-smtpd, making it easier to patch a patched qmail and then you simply upgrade the chkuser binaries when new updates are released and you can just leave qmail-smtpd as it is. Seeing this chkuser 2.0 is already binary files with just hooks into qmail-smtpd perhaps someone could convert this to use the hooks from the qmail-spp patch to keep things easier to manage. Then it could be made into a separate package such as "qmail-spp-chkuser" or put with a group of plugins/libraries (SPF, chkuser, etc) as package "qmail-spp-plugins". This capability of blocking smtpd connections to accounts that do not exist is very important to me. The majority of my mailserver bandwidth is usedon emails sent to accounts (of my domains) that do not exist (and most have never existed). This problem of serious wasted resources can completely go away with this patch. This patch to me makes a lot more sense than some already existing patches (like badmailto).
Jason: I use the lucheck-spp plugin and it works great with for everything. Regular users, vpopmail users, and ezmlm lists. I'll even consider a package for some spp plugins if there is demand.
The lucheck-spp plugin has not worked for us. It accepts everything even email for accounts that do not exist. I tried it again in case this was a newer version and still no go. My qmail-smtpd logs show an error that the LUCHECK_ALIAS variable was not set. The instructions make no mention of this (only required variable is LUCHECK_ALIASDIR). I didn't see a reference to LUCHECK_ALIASDIR anywhere in the lucheck-spp.c code (but I'm not a C programmer so I could of missed it) thus I assumed it was a typo in the docs and instead set the variable LUCHECK_ALIAS instead of LUCHECH_ALIASDIR and now I get no messages in the log. I've tried turing on the verbose and debugging flags as well and still see nothing in the logs though I can see the lucheck-spp binary as an active process on an smtp connection. Maybe I'm missing something but not according to how I'm reading the documentation. I would love to see this as a simple emerge to enable this plugin properly.
do you have a ~alias/.qmail-default file? This would cause accceptance of all mail. the documentation for lucheck-spp is out of data compared to the code, it's LUCHECK_ALIAS, not LUCHECK_ALIASDIR. It's the default alias homedir anyway, /var/qmail/alias so you shouldn't need to set it at all. how did you turn on the debugging/verbose? You should have put them in your smtp tcprules and rebuilt the smtp tcprules database. Anyway, enable debugging and verbose, and post up some logs that show why the emails are being accepted/rejected.
Thanks Robin for the response. I enabled verbose and debug as the docs said, by putting them in the script that tcpserver starts with (same place I defined LUCHECK_ALIAS). It sounds like the docs are wrong on that too. I'm not sure how I would define these in the smtp tcprules file though...
look in /etc/tcprules.d/tcp.qmail-smtp. you have a line that should be: :allow,... (where ... is some other stuff). at the end of that line, add: ,LUCHECK_DEBUG="1",LUCHECK_VERBOSE="1" and rebuild the tcprules cdb. (if you have an other more specific rules, you might need to edit those for testing instead).
Thanks (I wasn't sure if they just needed to be defined, or set to yes. Setting them to "1" worked...well at least I'm getting better log messages). I can still send to non existant accounts. here is a snippet from my logs (I changed the domain name to keep this address from harvesters). @4000000042e9673e0822cd44 plugins/lucheck-spp: Started for 'bc23@mydomain.com' @4000000042e9673e0828ef94 plugins/lucheck-spp: 'bc23@mydomain.com' is virtual - exiting. That is what is shown whether it was directed to a legit email or a fake one. Do I need to have LUCHECK_FFDB defined as well to correctly detect vpopmail accounts? If so is there documentation on how that should be defined? Thanks
do you have .qmail-default files for the domain? /var/vpopmail/domains/$DOMAIN/.qmail-default should NOT exist. if it does, move it out of the way.
I had a .qmail-default file (set by qmailadmin to bounce-no-mailbox) but even after removing it lucheck still accepted emails for non-existant accounts with the same message appearing in the logs as I mentioned before. Even if that did solve the problem that does not take into account that qmailadmin creates that file when you use it (gives you three options: bounce, drop, forward). The lucheck-spp plugin would need to read this file rather than only looking for it's existance because many use the qmailadmin package and we can't expect administrators to be deleting this file everytime a client uses the qmailadmin utitily. On a side note the chkuser patch looks at the content of the .qmail-default file already, rather than just for its existance. It also uses one db connection per email but it appears lucheck-spp uses one db connection for every address in the email headers, thus a lot more DB overhead per email message. So I'm curious as to why the spp is the focused solution for this problem and we wouldn't focus on the better performing chkusr or chkuser patch? I already mentioned this blocking capability is very important to my business. I looked at my logs and calculated that last month alone if I had this patch in place I would of saved close to 20GB of bandwidth and eliminated over 90% of my mailserver's load. I was flooded with millions of emails going to "name" dictionary lists (like andrew,ann,anne,annie,annette,etc...) for many of my mail servers domains. If someone is really worried about this suggested "fix" making it so spammers could just probe for valid accounts there is the option of also having a tarpit patch detect these probes and slow or block connections from that IP address making it much more difficult and costly for spammers than their current methods for harvesting legit emails.
Ok, looking at the lucheck-spp source code, I can see the problem. In the case of a virtual domain, the code is broken, it only checks for the virtual domain, and doesn't check anything beyond that. If somebody can produce a chkuser binary that can be used by the SPP framework, I'd gladly accept it. The entire reasoning behind the SPP framework is that it means less patches to put on the qmail codebase directly, and easier maintanance (not having to recompile qmail everything you need to change something is an advantage). Tarpitting can be done in the SPP framework easily, just modify lucheck-spp to sleep on failure, or put a wrapper around it that sleeps on failure.
I've written my own script to check RCPT TO. I don't know exactly why I wrote my own, but if I remember correctly, it was because the already available program only checked wether the domain is in control/virtualdomains. This script, however, checks for ~user/.qmail-files. It's available at http://dev.gentoo.org/~hansmi/misc/rcpt-to-check.pl -- feel free to use/abuse/whatever it.
After googling a bit for a mail relaying problem I was having (the first MX server was bad), http://www-dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html at section 3.2 talks about how qmail is breaking RFC 2821 by not trying other servers if the first server doesn't response by a 220 greeting. A patch is linked from the article: http://www-dt.e-technik.uni-dortmund.de/~ma/qmail/patch-qmail-1.03-rfc2821.diff The patch wouldn't apply cleanly to qmail-1.03-r16 It will also try on a 5xx greeting instead of bouncing for true rfc 2821 compliance. I'm not sure how to keep comments in patch so refer to the linked one above for license and stuff. I have added TLS support to the patch. I will be attaching a patch that applies cleanly.
Created attachment 69319 [details, diff] My version of the rfc2821 compliance patch for Gentoo
This patch would be nice, however it conflicts with the other outgoing ip patch. This allows someone to set the outgoing ip of qmail using a control file called outgoingip. I am aware that there is one that will set it to whatever the DNS for the domain is, but it doesn't allow to easily change the outgoing ip for qmail on a global basis. I am also unsure of how to apply a patch of this format. http://www.qmail.org/outgoingip.patch A use flag to toggle between outgoing patches would be nice.
Another interesting patch would be the qmtproutes patch which is the qmtp equivalent of the smtproutes control. With the patch, QMTP has preseance over SMTP for hosts listed in qmtproutes. Patch is available there http://www.skarnet.org/software/qmail-qmtproutes/qmail-1.03-qmtproutes.patch I haven't had a chance to try it, but I am definitely going to go ahead with qmtp as a transport between trusted boxes on a vpn.
After qmail-1.03-r16 has gone stable, we'll start working on the next revision. As far as I've planned, it'll be based on netqmail and be a complete restart. The current ebuild contains just too many patches. We've been thinking about creating our own patchset, so we don't need to rediff so many patches so often, also more USE flags to control the behaviour of qmail should get considered.
Please please please yes, remove the patches, that would be great. I'm so sick of all the patches in qmail, and a buggy qmail build, I've dumped the ebuild entirely since problems introduced in -r16. qmail doesn't need 23906723096 patches, it works fine as it is. When no use flags are used, it should not have any patches that are not absolutely required (some of the patches are only applicable to desktop users (i.e. qmail-remote_authenticated_smtp), some are patched in but then disabled by default (i.e. qmail-bounce-encap), most are to suite some niche needs and are counterproductive for the rest of us (i.e. big-concurrency), others fix the problem the wrong way (i.e. big-dns versus any-to-cname), some are obsoleted (i.e. nullenvsender-recipcount), others workaround limitations of filesystems most of us don't use anymore (i.e. big-concurrency), some are overzealous and patch things already patched in by another patch (i.e. moreipme includes a 0.0.0.0 fix too), some add useless features that don't offer any advantages (pop3d-capa), and yet more fix bugs introduced by aforementioned useless patches (qmail-pop3d-capa-outputfix). Oh, and then some include horrendous gaping security holes that allow anybody to relay through my server (i.e. qmail-relaymxlookup). Then, to make matters even worse, there are negative USE flags (bad in general) to disable problems introduced by the patches (i.e. notlsbeforeauth). ARGH!!!
Just a few random comments. (In reply to comment #17) > I'm so sick of all the patches in qmail, and a buggy qmail build, I've dumped > the ebuild entirely since problems introduced in -r16. Have I missed your bug report or is there none? > Oh, and then some include horrendous > gaping security holes that allow anybody to relay through my server (i.e. > qmail-relaymxlookup). a) It's disabled by default. b) Have you a better way to do it? No, giving root access to strangers is not something I want to do. With that patch they can configure their MXes and it's fine. You only route back to their servers. Well, yes, it can be abused, but that outweights the disadvantages (for me).
(In reply to comment #18) > > I'm so sick of all the patches in qmail, and a buggy qmail build, I've dumped > > the ebuild entirely since problems introduced in -r16. > > Have I missed your bug report or is there none? No. There are no bugs in r16, only "required mistakes" ... > > Oh, and then some include horrendous > > gaping security holes that allow anybody to relay through my server (i.e. > > qmail-relaymxlookup). > > a) It's disabled by default. Yes, but is *installed* by default. Why you permitted to choose to install TLS support (use tls) and not your dangerous patch? May be 80% of mail servers ars TLS-enabled; only you gives relay access to your server for free. > b) Have you a better way to do it? Algorithm: - on third party relay attempt, check dns; - if mx isn't set, "550 relay denied"; - if mx is set, "451 relay delayed" and write a message to the log Then, you can collect relay attempts and decide who can be inserted in (more)rcpthosts and who is abusing your server. > No, giving root access to strangers is not something I want to do. chmod 644 /var/qmail/control/rcpthosts chown guest /var/qmail/control/rcpthosts ln /var/qmail/control/rcpthosts /home/guest/rcpthosts (IMHO, better security than your method; this way only your customer know the "guest" password ...) > With that patch they can configure their MXes and it's fine. You only > route back to their servers. Well, yes, it can be abused, but that > outweights the disadvantages (for me). USE='relaymx' emerge qmail is better (for me).
There's an experimental netqmail ebuild in portage since about a week, mail-mta/netqmail.
Created attachment 102149 [details, diff] For relaying outgoing mail to a smarthost which requires authentication. "Add SMTP authentication support (AUTH LOGIN) to qmail-remote. This is useful for relaying outgoing mail to a smarthost which requires authentication." Resource: http://tomclegg.net/qmail/#qmail-remote-auth
We won't add custom patches to mail-mta/netqmail. Please use QMAIL_PATCH_DIR.
