Re: Spam Buttons - bounce and useSendmail

>>>>>>As I'm trying to implement Spam buttons, and have some trouble with
>>>>>> it's
>>>>>>functionality (specially with bounce_send.php), it seems my best
>>>>>>approach is to to a forward as attachment as it will provide the best
>>>>>>unmodifiied message down the road - this is to be procmailed
>>>>>> processed
>>>>>>and fed to sa-learn (on another host)
>>>>>>
>>>>>
>>>>>Have you done any of the tests I suggested in my last email?
>>>>>Does it now appear true that forwarding works as expected even when
>>>>> you
>>>>>leave that file alone?
>>>>>
>>>>
>>>>Yes.  Unless I uncomment the lines in bounce_send.php, bounces go back
>>>>to the original sender and not to the defined recepient.  Further, it
>>>>ignores the settings on how to send the message out.  That is, SM is
>>>>configured to send messages via sendmail, but spam_buttons is
>>>> configured
>>>>to go to a particular server/port, and instead the message is sent out
>>>>via sendmail.
>>>>
>>>>If I specify forward as attachment, it goes to the newly defined email
>>>>address, but again, the settings on how to forward the message are
>>>> ignored.
>>>>
>>>
>>>Can you do any debugging?  The attachment code DOES NOT USE the file
>>>bounce_send.php, so I don't know what relationship the two would have.
>>>Using the bounce functionality, I can see that maybe Sendmail is trying
>>>to outsmart you by redirecting the message, although it is odd that it's
>>>not even using the right SMTP/Sendmail server either - again, those
>>>lines should not have a heck of a lot to do with what server it uses!!
>>>This sounds very anomalous to me from here, so if you can, try echoing
>>>the $useSendmail variable at strategic points as well as echoing and
>>>diffing the message source as detailed in my previous message.
>>>
>>>Also, can you test with all other plugins turned off?
>>>
>>
>> Some progress...  The problem seems to be with useSendmail.  When
>> useSendmail is set from the main config, it is ignored by the plugin and
>> then somehow the other settings (in particular the new recepient
>> address) are ignored and the message is bounced to the original
>
> I am still of the mind that this is two problems:
>
>   - PHP problem overriding $useSendmail
>   - Sendmail attempting to outsmart you; resends the mail as is when it
> sees the same message ID or similar
>
> Can you possibly watch your sendmail logs when you are testing?
>
>> recepient.  Enabling the 'resent-' headers send the message to the new
>> recepient, but the useSendmail in the plugin's config is still ignored
>> and the message still uses the default settings
>
> Thus the first problem I noted above is probably correct.  Just have to
> find it.  It would help if you can echo $useSendmail in places like line
>  317 of functions.php (immediately before the bounce_send file is
> "required") and line 202 of bounce_send, immediately before it is used
> (the only place it is used) in that file and anywhere else along the
> execution path - perhaps also both before and after it is overridden
> back at the top of the report_by_email() function in functions.php.
> Also, please specify exactly WHAT useSendmail is set to in your main
> config.php, TRUE I suspect?  Things go better when it is FALSE?
>
>> But when useSendmail is set to false, it  works as expected.  The
>> message is bounced to the correct recipient and using the specified smtp
>> host by the plugin.
>
> Ah, OK
>
>> On funcitons.php you test for spam_report_useSendmail is not null, if
>> so, then copy whatever I set it into useSendmail.  I set
>> spam_report_useSendmail to 'false'
>
> Boolean values should never have quotes around them.  "false" or 'false'
> is NOT a boolean false.  Those are strings, whose contents happen to
> contain the letters f-a-l-s-e, but all strings, no matter their
> contents, evaluate to true in boolean context.  As mentioned in the
> plugin config file, the empty string settings are needed to let the
> plugin obey main SM config values, but if you change them, you need to
> follow the same syntax used in the main SM config file.  Can you please
> try without the quotes and see what happens?
>
>> But then further down, tests are done as if (!$useSendmail ...  which
>> would test to see if it's null ?  Or in php if the contents is 'false'
>> that would make that condition true ?  Same thing is tested on
>> bounce_send.php.
>
> See above.  Since I can see this will continue to be a potential
> problem, find the lines that override $useSendmail at the top of the
> report_by_email() function in functions.php, near line 285:
>
>    if ($spam_report_useSendmail !== '')
>       $useSendmail = $spam_report_useSendmail;
>
> Now replace them with this:
>
>    if ($spam_report_useSendmail !== '')
>       if (strtolower($spam_report_useSendmail) === 'false')
>          $useSendmail = FALSE;
>       else
>          $useSendmail = $spam_report_useSendmail;
>
> Now 'false' should work for your config override.
>
>> BTW, sing attachments might not be a good idea since if the user selects
>> multiple ones, it seems only the first one selected gets sent and not
>> the other ones.
>
> Upon what do you base that?  I know of no such bug.
>
>> Finally, the bounced message gets the original 'Received' headers
>> changed to 'X-Received' and new ones are added due to the forwarding.  I
>> assume SA is smart enough to recognized this ?
>
> It also appears that an extra Recieved header is being added (by looking
> at the code), just above where it is changing all the others to
> X-Received (line 121 of bounce_send.php).  I don't know the answer to
> your question; it would be an excellent thing to ask on the SpamAssassin
> list, but my inclination would be to try to preserve the message as
> close to the original as possible.  You can thus put block comments
> around that whole sequence of code, line 120 should get a
>
> /*
>
> And line 150 should get a
>
> */
>
> For reference line 121 is:
>
> if (!isset($skip_SM_header) || !$skip_SM_header) {
>
> And line 149 is the last closing curly brace after the foreach ($hdr as
> $line) loop.
>
> After that (line 151/152-ish), insert this:
>
> foreach ($hdr as $line) $header[] = $line;
>
> But sendmail might very well choke on some of this.  For instance, there
> are comments in the code that make it sound like any "Message" headers
> will cause prolems.
>
>> Oh, one more... Should bounce be discarded if the message is too big
>> (say bigger than 50k) ?
>
> Dunno.