Another non-standard search/sort field :)

[ellie timoney]

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
>