Another non-standard search/sort field :)

[Vladislav Bogdanov]

Hi Ellie,

Unfortunately, I'm not able to say anything valuable about that license 
compatibility hell. That's why no answer from me on that.

After some digging I found that function in question was added in 
http://svn.apache.org/viewvc/spamassassin/trunk/spamc/libspamc.c?revision=5092&view=markup 
and then fixed in 
http://svn.apache.org/viewvc/spamassassin/trunk/spamc/libspamc.c?revision=5099&view=markup

Both that revisions state "It is licensed under the same license as Perl 
itself".

Perl package on my system (Fedora 21) is Licensed under "License: (GPL+ 
or Artistic) and (GPLv2+ or Artistic) and Copyright Only and HSRL and 
MIT and Public Domain and TTWL and UCD".

Can that help?

Best,
Vladislav

31.05.2016 05:24, ellie timoney via Cyrus-devel wrote:
> Hi Vladislav,
>
> As I recall, the patch contained code from spamassassin (a version of
> strtod that always expects "." as decimal separator regardless of locale
> -- good!) and I wasn't sure about license compatibility.  I emailed
> cyrus-devel, looked around a bit for alternative implementations, and
> investigated reimplementing the function myself.  But there wasn't any
> response/interest from anyone, and I had other stuff to work on, so I
> set it aside, and here we are.
>
> I would link to the mailing list web archives but the site seems to be
> down at the moment, but I assume you have my more recent emails since
> you're able to send to the list?
>
> Cheers,
>
> ellie
>
> On Fri, May 27, 2016, at 06:35 PM, Vladislav Bogdanov via Cyrus-devel
> wrote:
>> 14.09.2015 03:49, ellie timoney wrote:
>>> Hi Vladislav,
>>>
>>> Thanks for the patch.  I'll try to get it merged this week.
>>
>> ping?
>>
>>>
>>> ellie
>>>
>>> On Sat, Sep 12, 2015, at 10:06 AM, Bron Gondwana wrote:
>>>> On Fri, Sep 11, 2015, at 23:19, Vladislav Bogdanov wrote:
>>>>> 11.09.2015 14:49, Bron Gondwana wrote:
>>>>>> On Fri, Sep 11, 2015, at 20:00, Vladislav Bogdanov wrote:
>>>>>>> 11.09.2015 12:01, Bron Gondwana wrote:
>>>>>>>> On Fri, Sep 11, 2015, at 16:48, Vladislav Bogdanov wrote:
>>>>>>>>> 11.09.2015 03:52, Bron Gondwana wrote:
>>>>>>>>>> sort: spamscore search: spamabove / spambelow
>>>>>>>>>>
>>>>>>>>>> These use the X-Spam-score header which is a floating point number
>>>>>>>>>> with a single decimal place usually, i.e. 5.0, 17.3.  spamabove is GE
>>>>>>>>>> and spambelow is LT.
>>>>>>>>>>
>>>>>>>>>> I'm going to push this back, because it doesn't clash with anything.
>>>>>>>>>> It's kinda nice to be able to sort by spamscore to quickly put the
>>>>>>>>>> focus on the most likely to be be wrongly classified messages, and
>>>>>>>>>> we're going to support that in our interface at some stage.
>>>>>>>>>>
>>>>>>>>>> Bron.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ah, I have a nice patch for spamtest extension against 2.4.17.
>>>>>>>>>
>>>>>>>>> It connects to spamd itself from lmtpd, checks the message and sets
>>>>>>>>> additional headers. Sieve integration is done too.
>>>>>>>>>
>>>>>>>>> Need to send it here.
>>>>>>>>
>>>>>>>> That would be great.
>>>>>>>
>>>>>>> Attached. Just found that it inconsistently uses tabs/spaces. I hope
>>>>>>> that is not an issue at least for initial review.
>>>>>>
>>>>>> Initial impressions:
>>>>>>
>>>>>> I would rename 's' to 'fd'.  Everyone knows what 'fd' does, s could be anything,
>>>>>> and being an int, it's totally un-typesafe.
>>>>>
>>>>> It was initially written against newly-released 2.3.8. That time socket
>>>>> fd was usually named 's' or 'sock'. 's' is shorter ;) Did that change?
>>>>
>>>> Fair enough :)  I haven't dealt with that area of the code quite so much,
>>>> more the index and database filehandles.
>>>>
>>>>> Yep, that never resulted in lost messages for last N+1 years in quite
>>>>> busy setups (not as fastmail, but anyways...).
>>>>>
>>>>> So, yes, that "works for me" and such change would be really cosmetic.
>>>>>
>>>>> I just ported it to 2.4.17 recently without even looking much at the
>>>>> code (but yes, that is tested on newer setups right from the patch date).
>>>>>
>>>>> I can send previous revision (against 2.3.13) as well.
>>>>
>>>> No, that's fine.  We can work with this.
>>>>
>>>>>> I've got a sneaking feeling that your entire spamtest_parse_hosts could be
>>>>>> turned into a tight little piece of code based on strarray_split() - but it looks fine.
>>>>>
>>>>> No opinion. It was not available in 2.3.x. IMHO spamtest_parse_hosts is
>>>>> very straight-forward.
>>>>>
>>>>> And, that _may_ conflict with the line in TODO list (which I probably
>>>>> will never do anyways because I have no idea how to make that fair
>>>>> enough without initial lookups):
>>>>> * Make load-balancing work if hostname that resolve to multiple A
>>>>> records is used in "spamtest_spamd_hosts".
>>>>
>>>> One interesting possibility (more for spam than virus checking) is to
>>>> send requests
>>>> for the same user to the same host always, which would require some form
>>>> of
>>>> consistent hashing.  We do that with nginx at FastMail for web requests:
>>>>
>>>> upstream internalbackend {
>>>>     server web1.nyi.internal:8080;
>>>>     server web2.nyi.internal:8080;
>>>>     server web3.nyi.internal:8080 down;
>>>>     server web4.nyi.internal:8080;
>>>>     server web5.nyi.internal:8080;
>>>>     server web6.nyi.internal:8080;
>>>> }
>>>>
>>>> So it knows web3 is down and hashes elsewhere, but when it comes back up,
>>>> the
>>>> same users will move back.
>>>>
>>>> We do the same for postfix lmtp delivery with some magic code in a thing
>>>> called lmtpforwardd,
>>>> which just listens on localhost and forwards to the correct server based
>>>> on the list of up spam
>>>> scan machines.
>>>>
>>>>>> All the code looks like it works (which is not a surprise, because it's been used).
>>>>>> My main concerns would be around signal safety in the file IO syscalls.
>>>>>
>>>>> Feel free to convert them to prot ones, but I do not feel it is strictly
>>>>> required.
>>>>
>>>> Sure thing :)
>>>>
>>>> Bron.
>>>>
>>>> --
>>>>     Bron Gondwana
>>>>     brong at fastmail.fm
>>