Re: [spamdyke-users] Spamdyke on submission port for access control

[Sam Clippinger]

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
>>> spamdyke-users@spamdyke.org
>>> 
>>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users
>> 
>> 
>> 
>> ___

Re: [spamdyke-users] Spamdyke on submission port for access control

[Eric Shubert]

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
>> spamdyke-users@spamdyke.org
>> 
>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users
>
>
>
> ___
> spamdyke-users mailing list
> spamdyke-users@spamdyke.org
> http://www.spamdyke.org/mailman/listinfo/spamdyke-users


___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Re: [spamdyke-users] Spamdyke on submission port for access control

[Sam Clippinger]

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
> spamdyke-users@spamdyke.org
> http://www.spamdyke.org/mailman/listinfo/spamdyke-users

___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Re: [spamdyke-users] Spamdyke on submission port for access control

[Eric Shubert]

On 05/02/2012 08:34 AM, Faris Raouf wrote:
> One of the vital features missing from Plesk is the ability to control
> who can use the hosting server’s authenticated smtp facilities.

I must be missing something here. To begin with, I'm not familiar with 
Plesk (I use QMailToaster).

It seems to me that authentication is what controls the submission port. 
In QMT, use of the submission port requires authentication. This 
capability is provided courtesy of Jean-Paul van de Plasse's 
REQUIRE_AUTH Patch.

Does Plesk not have this capability?

-- 
-Eric 'shubes'

___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

[spamdyke-users] Spamdyke on submission port for access control

[Faris Raouf]

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
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users