1. 01 Apr, 2020 2 commits
  2. 31 Mar, 2020 4 commits
  3. 30 Mar, 2020 7 commits
  4. 29 Mar, 2020 1 commit
  5. 28 Mar, 2020 1 commit
  6. 26 Mar, 2020 1 commit
  7. 25 Mar, 2020 1 commit
    • ng's avatar
      fix #457 - ensure proper encoding if no charset is set on a part · badad300
      ng authored
      If a part did not have a charset set, we falled back to US-ASCII
      and then tried to encode the string into that. However, this only
      worked if the part had actually only ascii charcters, but as soon
      it contains non-ascii characters we failed. With this change we
      are encoding such parts as utf-8, thus adopting the future.
  8. 22 Mar, 2020 2 commits
    • georg's avatar
      fix #460 - specs: add mail to reproduce "stack level too deep" · 275d778b
      georg authored
      This triggers what we were seeing in #460 - though this got fixed
      with the previous commit.
    • ng's avatar
      fix #458 - more proper encoding handling · 39ca2227
      ng authored
      This revisits the fixes for #409 (merged in !301), as when
      trying to parse unencrypted, but signed utf-8 mails, they were
      failing to be parsed and thus generated another error. More
      in-depth later.
      With this fix we are changing the approach:
        1. We switch to UTF-8 as default input
        2. If this is not a valid encoding, we try to convert the
           input to UTF-8
        3. If we are failing to convert, we scrub the input, so that
           at least what is proper UTF-8 will be passed on.
      ASCII-8BIT is a BINARY encoding and the mail library will only
      force the mail to have CRLF if it only contains ASCII conent.
      While UTF-8 is not a BINARY encoding and thus will get CRLF if
      it is a valid encoding. Getting CRLF is important for mails such
      as the one in `signed_utf8.eml`, as otherwise the parts detection
      will fail and the whole body will end up in the prologue, with no
      Enforcing UTF-8 will still make some of our charset mails failing,
      as they are - validly - not UTF-8. By using a new dependency
      'charlock_holmes', we are able to detect the actual encoding and
      thus try to convert it to UTF-8. If everything fails, we just
      drop the invalid characters.
  9. 21 Mar, 2020 2 commits
  10. 01 Mar, 2020 1 commit
  11. 09 Feb, 2020 1 commit
  12. 28 Jan, 2020 5 commits
  13. 24 Jan, 2020 3 commits
  14. 23 Jan, 2020 3 commits
  15. 22 Jan, 2020 3 commits
  16. 20 Jan, 2020 2 commits
  17. 16 Jan, 2020 1 commit