You know... I may have sub-consciously meant it that way too! :-) Not necessarily in regards to Spamdyke, but in general, I've found that most "Features" are not. In this case, I think it will be a great addition to Spamdyke.
I know the fact that chkusr is available is a plus for it, but, for me, I'd rather wait a bit more for something that's easier to implement. In the end, it's about being able to roll out a server easily, and how efficient that server is... So, what I was really after was how your user check will work versus something like chkusr (Assuming you know how chkuser works). Will one be more resource intensive than the other, or about the same? Secondly, I recently took a look at Qmail Toaster, which now includes Spamdyke as well as chkuser. I usually like building my servers by hand because I get a better grasp of how they work that way, and maybe learn something... But, they sure make it easy to get a server going, and w/Spamdyke to boot. Michael J. Colvin NorCal Internet Services www.norcalisp.com > -----Original Message----- > From: [email protected] [mailto:spamdyke-users- > [email protected]] On Behalf Of Sam Clippinger > Sent: Sunday, May 03, 2009 11:43 AM > To: spamdyke users > Subject: Re: [spamdyke-users] recipient check > > 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 _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
