I like that you quoted "feature", like it's a euphemism for something dirty. I'm easily amused, sorry. :)
When a message is delivered to a "stock" qmail server, there are a number of processes that handle delivery. First qmail-smtpd runs and actually receives the message from the network interface. During its run, qmail-smtpd will check (among others) /var/qmail/control/rcpthosts and /var/qmail/control/morercpthosts, rejecting the message if the recipient's domain is not listed in one of those two files and the remote server is not allowed to relay. If it accepts the message, qmail-smtpd uses qmail-queue to write the message to the queue and exits. Some time later, qmail-send scans the queue and reads the message. qmail-send uses /var/qmail/control/me, /var/qmail/control/locals and /var/qmail/control/virtualdomains to decide if the recipient is local (the mailbox is stored on this server) remote (the message should be forwarded to another server). If the recipient is remote, qmail-send invokes qmail-rspawn which invokes qmail-remote to perform the delivery. qmail-remote uses /var/qmail/control/smtproutes for instructions. qmail-remote will generate a bounce message if the remote server refuses delivery for any reason (backscatter spam). If the recipient is local, qmail-send invokes qmail-lspawn which invokes qmail-local to start processing. qmail-local consults /var/qmail/control/percenthack and modifies the recipient address if necessary. If the recipient's domain is not found in /var/qmail/control/locals, it searches /var/qmail/control/virtualdomains and modifies the recipient address with the entry found there (or generates a bounce message otherwise). If the recipient address doesn't have a domain (a bare username), qmail-send uses /var/qmail/control/envathost and /var/qmail/control/me to append a domain. At this point, it uses /var/qmail/users/assign to discover the recipient's home directory within the server's filesystem. If a user can't be found in that file, /etc/passwd is incrementally searched by repeatedly shortening the recipient's username at any dashes. If no match is found, the user "alias" is used. If "alias" doesn't exist, the message is bounced (backscatter spam). Once a home directory has been identified, qmail-local uses a bunch of voodoo to search for a ".qmail" file that (somehow) matches the username. If no file is found, /var/qmail/control/defaultdelivery is used instead. If a file is found, being group- or world-writable triggers a bounce (backscatter spam). If the file specifies that the message should be sent to a program, that program can return a code that will trigger a bounce (backscatter spam). The file can also contain directives to write the message to a file or forward to another user. In the case of a forward, the message is reinjected into the queue using qmail-queue and the whole process starts over from the beginning. I hope that makes some kind of sense... the point is that it's extremely complicated and very fragile. Successfully delivering a message requires at least 7 processes and more than a dozen configuration files. What I've implemented is just a filter that can be enabled or disabled like any other filter. If it's enabled, it will run whenever the remote server sends a recipient address. At that point, it will follow the above procedure to determine if the message will eventually bounce. If it can't tell (e.g. because the .qmail file specifies a program that may or may not generate a bounce), the recipient will be accepted. If a bounce is definitely going to occur, the recipient address is rejected immediately. Because vpopmail works by adding entries to qmail's /var/qmail/control/virtualdomains file (as opposed to patching qmail), it integrates seamlessly into the above procedure. spamdyke will be able to check vpopmail domains without any additional work. I've never used chkusr but I can tell you it has one big advantage -- it's already available. Whether you're willing to wait for the next version of spamdyke is a decision only you can make. -- Sam Clippinger Michael Colvin wrote: > In regards to this "Feature", Sam, can you give a brief overview of how you > implemented it? Is it similar to the CHKUSR patch that queries VPOPMAIL, or > ? I'm trying to decide if I want to wait for it to be included in Spamdyke, > or implement to patch to Qmail and not utilize it when it's available in > Spamdyke. > > Of course, if there's a benefit to doing the check in Spamdyke instead of in > Qmail, then that might influence my decision too... > > Thanks! > > Mike > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Sam Clippinger > Sent: Monday, April 27, 2009 3:59 PM > To: spamdyke users > Subject: Re: [spamdyke-users] recipient check > > Yes, this suggestion has come up many times. I'm mostly done with > implementing this feature now (though not exactly as you describe it). I > have to fix some remaining bugs and finish testing, then it'll be available. > > -- Sam Clippinger > > Otto Berger wrote: > >> Hi all, >> >> the discussion about this is quite as old as spamdyke. But is there >> anything new on this? >> >> is it maybe a way to provide a simple hook to spamdyke so it can run an >> external check-programm or script? That programm could check via a >> ENV-vars the recipient-address an return true or false or something. >> >> recipient-blacklist-plugin=/bin/check_for_invalid_recipient.sh >> recipient-whitelist-plugin=/bin/check_for_valid_recipient.sh >> >> i know its not the best and high performance solution, but maybe >> (relative) easy to implement an i think there will be soon much >> "plugins" to check valid recipients against databases, files etc... >> >> Otto >> _______________________________________________ >> spamdyke-users mailing list >> [email protected] >> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >> >> > _______________________________________________ > spamdyke-users mailing list > [email protected] > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > > _______________________________________________ > spamdyke-users mailing list > [email protected] > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
