- 12 Feb, 2021 1 commit
-
-
paz authored
This changes the way we block gpg from asking interactively for a passphrase, ever. It's also a less hacky way to force this. This works with gpg-2.0.26+gpgme-1.5.1, gpg-2.1.18+gpgme-1.8.0, gpg-2.2.27+gpgme-1.14.0, and gpg-2.2.27+gpgme-1.15.1, which makes me optimistic that it's universally working. The previous solution brought problems for some platforms and specific combinations of gnupg with gpgme (resulting in "GPGME::Error no such file or directory").
-
- 11 Feb, 2021 1 commit
-
-
paz authored
-
- 07 Feb, 2021 1 commit
-
-
georg authored
-
- 02 Feb, 2021 3 commits
- 01 Feb, 2021 1 commit
-
- 19 Jan, 2021 1 commit
-
-
ng authored
-
- 13 Jun, 2020 1 commit
-
-
georg authored
-
- 12 Jun, 2020 1 commit
-
-
georg authored
Do not rely on '127.0.0.1', but on 'localhost'. dirmngr receives some extra care, so it's able to cope with it. gpgconf --kill might hang indefinitely, therefore, rely on pkill. Relax the expected output of gpg if refreshing keys without a keyserver being available, as gpg might report various errors in such a situation. The dependency on dirmngr will be dropped soon, anyway, so I deem this acceptable as a workaround, for now. Closes #472
-
- 09 Jun, 2020 2 commits
- 19 May, 2020 1 commit
-
- 04 May, 2020 1 commit
-
-
georg authored
-
- 15 Apr, 2020 2 commits
- 13 Apr, 2020 1 commit
-
- 30 Mar, 2020 1 commit
-
-
georg authored
-
- 25 Mar, 2020 1 commit
-
-
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.
-
- 22 Mar, 2020 1 commit
-
-
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 parts. 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.
-
- 28 Jan, 2020 4 commits
-
-
ng authored
When we are unable to resend to one of the addresses in resend-cc-encrypted-only we are not sending the email of the batch to any of the addreses. Adding an additional info makes this more clear and visible to users.
-
ng authored
Make it more clear what happens when resending an encrypted email fails (due to missing or too many matching keys), but falling back to unencrypted resend is allowed.
-
ng authored
-
ng authored
-
- 23 Jan, 2020 1 commit
-
-
paz authored
-
- 22 Jan, 2020 1 commit
-
-
paz authored
-
- 20 Jan, 2020 1 commit
-
-
Michał "rysiek" Woźniak authored
Relevant ticket: #365
-
- 07 Jan, 2020 1 commit
-
-
georg authored
This should help with filtering such messages, which is currently not easy to do in a reliable way.
-
- 05 Jan, 2020 3 commits
-
-
georg authored
Handle incoming mails encrypted to an absent key, using symmetric encryption or containing PGP-garbage in a more graceful manner: Don't throw an exception, don't notify (and annoy) the admins, instead inform the sender of the mail how to do better. Closes #337
-
ng authored
this should ensure we are able to parse most incoming plain text mails in different charsets. See: * schleuder/schleuder#409 * schleuder/schleuder!301 * https://ruby-doc.org/core-2.6.5/Encoding.html#class-Encoding-label-External+encoding Especially: * schleuder/schleuder#409 (comment 176612) * https://idiosyncratic-ruby.com/56-us-ascii-8bit.html * https://github.com/mikel/mail/issues/1294#issuecomment-460855599
-
paz authored
-
- 04 Jan, 2020 4 commits
- 16 Sep, 2019 1 commit
-
-
georg authored
-
- 07 Sep, 2019 1 commit
-
- 22 Aug, 2019 2 commits
- 17 Jun, 2019 1 commit
-
-
ng authored
Although mutt now supports protected headers, the content of a message compiled by mutt is just a plain body, without wrapped into further mime parts (contrary to other mailers). Also the message does not contain a special marked protected headers mime part.
-