>> (...)
>> if (x > h) x = NULL [2]
>> ---------------------------
>>
>> For this last line [2], I understand that the goal is to ignore any
>> "spam-" or similar, if it is "after" a double CRLF ("empty line"), which
>> is probably intended to encode the headers/body boundary.
>>
> Wrong. The reason for checking this double CRLF or double LF is because of
> the format of the TO header.[...]
> The code checking for "\r\n\r\n" or "\n\n" is there to prevent checking
> inside the mail body. But it is not there to encode header/body boundary.
> IMHO the code should be even extended and prevent checking for
> spam/notspam in any other header than "To".
>
Sure, that's what I meant, although "encode" was the wrong word! rather
"represent" or "check for", or stg like that. Sorry, no native english...
>> I am not sure whether this is useful, as this function is called with a
>> 1-line text buffer (fetched line by line in the caller). But that's just
>> for safety, no big deal.
>>
> You miss the point that this function can be used by other applications
> that use libdspam and no one is preventing the coder using libdspam to
> call the function with: "To: [email protected]\nfrom:
> [email protected]\nsubject: [email protected] testing\n\nJust a test\n".
> So it is more then just safety.
>
Sure (too), I was thinking to "other contexts" for calling this
function, but I did not go into details of all possible calling scenarios.
>> But, due to line [1] above, if the line does not contain any
>> double-CRLF, h will be NULL when checking x > h (on line [2]) as this is
>> not protected. x > NULL will quite often be true, thus x will be reset
>> to NULL, and we will never conclude a spam-xxx was found.
>>
>> I changed line [2] to
>> if (h && x > h) x = NULL;
>>
>> And that works.
>>
> Yeah. That works. Should however be extended to prevent the code to match
> [email protected] in anything other then the "To" header.
>
Great!
Improvement idea, for... one day :-) : having spam- and notspam-
patterns overridable by config. Would be cool to allow one or several
syntax, localize it, etc..
>> I am not sure in which context this could work before, but I guess this
>> patch cannot hurt, even if one day, buf contains empty lines.
>>
>> Hope that helps, it did for me ;-) Tell me if I am wrong on stg...
>>
>>
> I am going to overwork that function when I return home from work.
>
Thanks for that! I like this implicit spam-xxx feature...
>> Regards,
>> Cyril'
>>
> Stevan
>
------------------------------------------------------------------------------
_______________________________________________
Dspam-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspam-user
