The first one is correct.  spamdyke sets RELAYCLIENT, then starts 
qmail-smtpd, then starts filtering the mail connection.  That way, the 
remote mail server thinks its talking to qmail directly and spamdyke 
remains invisible (unless a filter is triggered).  Because qmail-smtpd 
is started as soon as the connection begins, RELAYCLIENT can't be changed.

-- Sam Clippinger

On 12/2/10 11:34 AM, Bgs wrote:
>    HI Sam,
>
> As I told you I never thought about unsetting anything, only about
> setting something just the same way as you set RC now...
>
> I haven't checked the code but the crucial question is (and you can
> probably answer instantly):
>
> Do you set RC, start qmail-smtpd and then filter or block
>
>    or
>
> Do you filter/block, set RC and then start qmail-smtpd?
>
> If it's the first one, then env vars are indeed no solution to this
> problem. If the later, it works.
>
> Regards
> Bgs
>
> On 11/26/2010 07:48 PM, Sam Clippinger wrote:
>    
>> That sounds like a great idea, but unfortunately it just can't be done.
>> Environment variables can't be changed once the program is running.
>> That's why spamdyke can't turn RELAYCLIENT on/off as appropriate -- it
>> can't turn any other environment variables on/off either.  qmail-smtpd
>> is started by spamdyke at the very beginning, so its environment is set
>> at that time and can't be altered based on authentication or anything else.
>>
>> Communicating with qmail-scanner using environment variables is just the
>> wrong answer.  I think the right answer is for qmail-scanner to only
>> scan certain recipient addresses (based on a list, regexs or something
>> similar).  Since modifying qmail-scanner this way is probably not
>> something you're interested in undertaking, would it be possible to get
>> your authenticated users to deliver their email on a different port
>> (like 587)?  Then you could use a different configuration on that port
>> to skip the SA scanning for those users.
>>
>> -- Sam Clippinger
>>
>> On 11/26/10 3:32 AM, Bgs wrote:
>>      
>>> No, you misunderstood. I'm not asking about removing RC anytime later. I
>>> want to disable SA for authenticated users only.
>>> The problem is that both of you (spamdyke/spamassassin) have you own
>>> logic that works well alone, but do not work well together.
>>> The solution could be some way of communication between the two that can
>>> override the default behaviours. This is why I thought about adding
>>> another env var (the main way of communication) that could relay the
>>> information.
>>>
>>> So:
>>>
>>> Spamdyke sets RC for all mail it thinks by its rules, that must be
>>> handled and overrides qmail.
>>> qmail-scanner only filters mail that's not local and RC is not set.
>>> This way I'm forced to override qmail-scanner by setting QS_SPAMASSASSIN
>>> from my smtp.conf and by this scanning authenticated mail as well.
>>>
>>> A possible solution is to add a logic to spamdyke which is able to set a
>>> new env var and also add a logic to qmail-scanner takes it into
>>> consideration when scanning mail. This needs only minor changes in both
>>> software and enables them to peacefully coexist.
>>>
>>> The logic I was thinking of:
>>>
>>> - spamdyke acts as normal with average config
>>> - Add and env var SCAN_SPAM which can be set to 'on' or 'off'
>>> - qmail-scanner acts as normal without the env var (or wrongly set)
>>> - qmail-scanner overrides spam scanning rules if the env var tells it
>>> explicitly to set it on/off
>>>
>>> - Add a rule to spamdyke's config: external-spam-scan-on-auth which
>>> takes on or off as arguments and sets the env var to that.
>>>
>>> The same could be used for other spam scan disable/enable scenarios not
>>> just authentication and as a plain env var, other downstream scanning
>>> modules can utilize it, not just qmail-scanner.
>>>
>>> What to you think Sam?
>>>
>>> Regards
>>> Bgs
>>>
>>>
>>> On 11/25/2010 06:10 PM, Sam Clippinger wrote:
>>>
>>>        
>>>> I'm not sure this can be resolved.  Environment variables can't be
>>>> altered once the qmail-smtpd process has been started:
>>>>          http://www.spamdyke.org/documentation/FAQ.html#SUGGESTION7
>>>>
>>>> spamdyke always sets the RELAYCLIENT variable because it needs to
>>>> override qmail's filters when a client meets spamdyke's criteria for
>>>> relaying.  Specifically, if a client authenticates or matches a
>>>> whitelist, spamdyke needs to prevent qmail from blocking the message
>>>> later.  I suppose I could change spamdyke to not set the RELAYCLIENT
>>>> variable if authentication is turned off and no whitelists are
>>>> enabled... but the method to trigger/stop the variable would be so
>>>> complex I think it would cause more confusion than it's worth.
>>>>
>>>> What does the rest of your spamdyke configuration look like?  Could you
>>>> use it with no whitelists, no configuration directories and "smtp-auth"
>>>> set to "none" or "observe"?
>>>>
>>>> -- Sam Clippinger
>>>>
>>>> On 11/23/10 3:01 PM, Bgs wrote:
>>>>
>>>>          
>>>>> Trying again, it didn't show up on the list...
>>>>>
>>>>> -------- Original Message --------
>>>>> Subject:  RELAYCLIENT setting when spamdyke is authenticating
>>>>> Date:     Sun, 21 Nov 2010 14:52:14 +0100
>>>>> From:     Bgs<[email protected]>
>>>>> To:       spamdyke users<[email protected]>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>      Hi,
>>>>>
>>>>> I might be the one misinterpreting the docs, but something is strange
>>>>> for me.
>>>>>
>>>>> The setup:
>>>>>
>>>>> spamdyke with auth/access file + qmail-scanner with spamassassin
>>>>>
>>>>> In my access file I have localhost with RELAYCLIENT and no
>>>>> qmail-scanner, all other without RELAYCLIENT and qmail-scanner.
>>>>>
>>>>> I have relay-level set to 'normal' which according to the docs, does
>>>>> the following:
>>>>>
>>>>> |normal|: Prevent relaying unless the sender authenticates, the access
>>>>> file allows relaying or an environment variable allows relaying.
>>>>> Requires |local-domains-entry| or |local-domains-file| and |access-file|.
>>>>>
>>>>>
>>>>> So I was expecting the following:
>>>>>
>>>>>      - Normal mail arrives for relay ->     denied (does this)
>>>>>      - Normal mail arrives for domain in rcpthost ->     do NOT set
>>>>> relayclient, pass to q-s and further to qmail-smtpd which will handle
>>>>> it (it doesn't do this)
>>>>>      - Authenticated user sends mail ->     spamdyke sets RELAYCLIENT, q-s
>>>>> skips checks, qmail-smtpd processes mail
>>>>>
>>>>> The second buffles me:
>>>>>
>>>>>      - access file does not set RELAYCLIENT
>>>>>      - there is no environment variable passed to spamdyke
>>>>>      - the user does not authenticate
>>>>>
>>>>> Apparently spamdyke also sets RELAYCLIENT when the domain is in
>>>>> rcpthosts. This means that spamdyke disables spam filtering. If I
>>>>> override qmail-scanner (with explicit QS_SPAMASSASSIN environment
>>>>> variable) to check all mail, authenticated users get filtered as well
>>>>> which leads to loads of complaints.
>>>>>
>>>>> Am I getting something wrong or is this a bug?
>>>>>
>>>>> Regards
>>>>> Bgs
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>    
_______________________________________________
spamdyke-users mailing list
[email protected]
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Reply via email to