Thanks for the insight, Sam. Perhaps eMPF is what Faris is looking for. (?) http://www.inter7.com/?page=empf-install
(FWIW, eMPF is baked in with QMT) -- -Eric 'shubes' On 05/02/2012 09:29 AM, Sam Clippinger wrote: > So you have many users on your Plesk server, but you only want some of > them to be able to authenticate? I'm not sure I understand the purpose > of that -- are you trying to limit the remaining users to only sending > to recipients hosted on the same server? I've never heard of anyone > wanting to restrict authentication this way. > > As it exists today, I can't think of a way to make spamdyke do that for > you. I didn't follow all of your logic about whitelists and blacklists > being checked in a specific order but none of that is actually correct. > Although there is a specific order spamdyke uses for processing > whitelists and blacklists internally, there is no difference from a > functional standpoint. In other words, spamdyke may check a blacklist > before it checks a whitelist, but it won't reject the connection until > it's checked them both and it's sure the whitelist doesn't match. So > whitelisting some sender addresses while blacklisting their IPs won't > work -- anyone sending with a whitelisted address will be allowed, > regardless of their IP (this is why sender whitelists are usually a bad > idea). Authentication works like a whitelist anyway; once a user has > authenticated, they'll never be blocked no matter what blacklists are used. > > If I'm understanding your goal correctly, I don't think spamdyke is the > right place to do this anyway. spamdyke just collects the > username/password and sends them through to the program specified on the > command line for processing (the one just after > /var/qmail/bin/qmail-smtpd). It doesn't do anything itself to check the > username or password that were provided. If the program returns a > success code, authentication was successful. If not, authentication > failed. I think the correct solution is actually to replace the Plesk > program that processes authentication (/var/qmail/bin/smtp_auth) with a > custom one. Your new binary could check the incoming username against a > defined list, then call the original Plesk binary for processing if the > username is allowed. > > -- Sam Clippinger > > > > > On May 2, 2012, at 10:34 AM, Faris Raouf wrote: > >> Dear all, >> >> I’ve been using spamdyke (in conjunction with qmail-scanner/sa/clamav) >> with various version of Plesk for years now. Thanks again to Sam for >> such a fantastic project. >> >> One of the vital features missing from Plesk is the ability to control >> who can use the hosting server’s authenticated smtp facilities. >> >> It suddenly occurred to me today that it might be possible to use >> spamdyke to provide this very feature. Or at least I thought so at first. >> >> My idea was to completely disable relaying on port 25 and spamdyke to >> the /etc/xinetd.d/submission_psa config file (i.e. for the submission >> port on 587) pointing to a special spamdyke-for-submission.conf with a >> sender-whitelist containing a list of only those users (email >> addresses) who are allowed to Relay (as long as they also then >> authenticate, so forged email addresses would not be a problem). >> >> Where my grand plan falls down is related to how to blacklist everyone >> else - I just can’t see an easy way to do this. >> >> One idea I had was to use a dnsbl (I have rbldnsd running locally) >> configured to provide a positive response for every query using some >> kind of wildcard entry. Because whitelists are looked at before >> blacklists, this should work. But that seems like a waste of resources >> if there’s an easier way. >> >> Another idea I had was to process /var/qmail/control/rcpthosts, add an >> @ before each entry and copy it to a file specified by >> sender-blacklist-file. I think that would work again because >> whitelists are processed before blacklists, but it isn’t ideal. >> >> Any better suggestions? I’ve looked at the relaying and smtp-auth >> configuration options already in spamdyke but they didn’t seem to fit >> what I needed, which is specifically to allow qmail/Plesk to worry >> about authentication usernames/passwords while only allowing specific >> users to actually relay. >> >> Faris. >> >> _______________________________________________ >> spamdyke-users mailing list >> [email protected] >> <mailto:[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
