That looks like it would work, but I've never tried patching and recompiling qmail on Plesk. I would expect wild variations on mileage.
Also, a patched qmail would be replaced/broken the next time any Plesk updates are applied. -- Sam Clippinger On May 2, 2012, at 11:50 AM, Eric Shubert wrote: > 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 _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
