1. 17 Jul, 2017 1 commit
  2. 15 Jul, 2017 4 commits
    • Kim Vandry's avatar
      Interpret dates in search terms in the local timezone, including DST. · 3ef02dc4
      Kim Vandry authored
      Previously, dates in search terms were interpreted in the local time
      zone, but not taking into account that the current local DST offset
      may not be the same as the DST offset on the specified date.
      This can cause certain dates to be interpreted off-by-one at certain
      times of the year in certain time zones. For example, where I am
      right now, TZ=Europe/London, and at this time of year (summer),
      dates in the winter are intrepreted incorrectly in this manner. This
      breaks the test suite.
      This patch does not completely fix date processing in mairix. There
      are three salient timezones in mairix's operation:
      1. The timezone specified in the messages (RFC 822 headers include it).
      2. The timezone mairix was running in when it built the database.
      3. The timezone that gets attached to dates in the search criteria.
      This patch fixes (3). The design intent has never been made clear, but
      I believe that midnight local time (for start dates) and 23:59:59
      local time (for end dates) in the timezone in which mairix is running
      is the most reasonable and unsurprising interpretation of those dates.
      Now, (2) should have no bearing on anything at all, but it does,
      because of the way times and timezones are ignored in rfc822.c. In other
      words, (2) matters because (1) is done improperly. This should ideally
      be fixed, but is more work, especially because doing it properly
      requires the non-portable function timegm().
      But at least with this patch the test suite now passes, in many
      different timezones that I tried (partly thanks to the fact that in
      the tests, mairix always builds the index in the same timezone as
      the search happens in).
      Fixes rc0/mairix#8
    • Benjamin Hill's avatar
    • Raphaël Hertzog's avatar
      Fix search of message id containing equal signs · 0e679bef
      Raphaël Hertzog authored
      Mairix incorrectly interprets the equal sign as a substring search
      even when the following character is not compatible with such
      a search.
      All gmail Message-ID have an equal sign so this is major problem
      when you want to lookup a specific Message-ID.
      Fixes rc0/mairix#10
    • Kim Vandry's avatar
      Merge branch 'follow_mbox_symlinks' · 98206c33
      Kim Vandry authored
  3. 12 Jul, 2017 1 commit
  4. 09 Jul, 2017 1 commit
    • Kim Vandry's avatar
      Fix string overrun bugs in nvp.c · 1305fc13
      Kim Vandry authored
      Previously, names and values that exceeded 256 bytes in length would
      smash the stack during parsing headers like Content-Foo: thing; key=val
      Now we copy these tokens after each one is collected instead of
      character-by-character as we go, so we avoid using fixed-size buffers.
      Fixes rc0/mairix#7, Fixes rc0/mairix#5, Fixes rc0/mairix#14
  5. 24 Mar, 2016 3 commits
  6. 17 Dec, 2015 1 commit
  7. 12 Sep, 2014 1 commit
  8. 05 Sep, 2014 9 commits
  9. 24 Nov, 2013 4 commits
  10. 19 Nov, 2013 1 commit
  11. 18 Mar, 2012 3 commits
  12. 29 Jul, 2011 1 commit
  13. 10 Feb, 2011 1 commit
  14. 13 Dec, 2010 1 commit
  15. 07 Dec, 2010 1 commit
  16. 21 Oct, 2010 1 commit
    • Peter Jeremy's avatar
      Fix SEGV if mbox shrinks · 66d1467a
      Peter Jeremy authored
      If you build the database using mbox files and then shrink one of the files (eg
      delete a message out of it) then mairix will SEGV if it tries to search that
  17. 30 Aug, 2010 1 commit
  18. 29 Jul, 2010 1 commit
    • Jonathan Kamens's avatar
      Fix faultly mbox message separators · 7cdd0712
      Jonathan Kamens authored
      Jonathan writes:
      I noticed an issue with mairix today when doing a search with output into an
      mbox file.
      Technically, the message separator for mbox files is “\n\nFrom “, i.e., there’s
      always supposed to be a blank line before the “From “ line, but the mbox being
      generated by mairix search is missing the blank line at the end of some
      messages, with the result that some programs that parse mbox files were missing
      some message breaks and glomming messages together.
      The attached patch fixes this by ensuring that there’s a blank line at the end
      of every message in the mbox.
  19. 05 Jul, 2010 4 commits