schleuder issueshttps://0xacab.org/schleuder/schleuder/-/issues2020-03-22T11:46:09Zhttps://0xacab.org/schleuder/schleuder/-/issues/464Add keyword to configure `delivery_enabled`.2020-03-22T11:46:09ZpazAdd keyword to configure `delivery_enabled`.Currently there's no way to configure that using Email after subscribing. That should be possible.Currently there's no way to configure that using Email after subscribing. That should be possible.https://0xacab.org/schleuder/schleuder/-/issues/461Provide script to sanitize real world example mails2020-03-19T22:03:17ZgeorgProvide script to sanitize real world example mailsFeeding our issue tracker with real world example mails takes time due to doing "data hygiene". I plan to write a script, which, if given a mail file, writes out a sanitized copy. Obviously, before publishing, people should still check t...Feeding our issue tracker with real world example mails takes time due to doing "data hygiene". I plan to write a script, which, if given a mail file, writes out a sanitized copy. Obviously, before publishing, people should still check the result. Probably, this takes a bit of time to do some iterations, to make it better. Lets start?georggeorghttps://0xacab.org/schleuder/schleuder/-/issues/459Convert all text-parts to UTF-8?2020-03-22T21:57:46ZpazConvert all text-parts to UTF-8?If we would convert all incoming text-parts (or anything that has a charset) into UTF-8, we might have less trouble with the 'mail' gem. E.g. in https://github.com/mikel/mail/pull/738#issuecomment-303083226 the maintainers explain that t...If we would convert all incoming text-parts (or anything that has a charset) into UTF-8, we might have less trouble with the 'mail' gem. E.g. in https://github.com/mikel/mail/pull/738#issuecomment-303083226 the maintainers explain that they always prefer converting to UTF-8, regardless of what the original charset header says.
Actually, changing the charset-header to 'UTF-8' (instead of re-encoding the text) in [schleuder/mail/message.rb:254](https://0xacab.org/schleuder/schleuder/blob/master/lib/schleuder/mail/message.rb#L254) makes our test-suite green even with mail-gpg v.0.4.3 (see #455).
From a technical standpoint I don't see a problem changing all parts to UTF-8. I would even advocate for it, because it standardises on a modern solution.
But I can't really judge how many computers out there still don't know UTF-8 and would show broken texts.
Any opinion?https://0xacab.org/schleuder/schleuder/-/issues/456Wrong permissions after Installation from gem2020-05-26T13:25:57ZMichael WodniokWrong permissions after Installation from gem## Expected Behavior
schleuder-api-daemon runs with out errors as non-root.
## Actual Behavior
schleuder-api-daemon dies with stacktraces like in "Other information". The workaround is to run a `chmod -R a+x /var/lib/gems/2.5.0/gems/sch...## Expected Behavior
schleuder-api-daemon runs with out errors as non-root.
## Actual Behavior
schleuder-api-daemon dies with stacktraces like in "Other information". The workaround is to run a `chmod -R a+x /var/lib/gems/2.5.0/gems/schleuder-3.4.1/lib` (on Ubuntu 18.04).
## Steps to Reproduce the Problem
1. Install from gem as root on your system including `schleuder install`
2. Try to start schleuder-api-daemon as non-root
## Specifications
- Version: 3.4.1
- Installation method (package, gem...): gem
- Mail client version: non-relevant
## Other information
Stacktrace:
```
Traceback (most recent call last):
13: from /usr/local/bin/schleuder-api-daemon:23:in `<main>'
12: from /usr/local/bin/schleuder-api-daemon:23:in `load'
11: from /var/lib/gems/2.5.0/gems/schleuder-3.4.1/bin/schleuder-api-daemon:4:in `<top (required)>'
10: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
9: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
8: from /var/lib/gems/2.5.0/gems/schleuder-3.4.1/lib/schleuder-api-daemon.rb:11:in `<top (required)>'
7: from /var/lib/gems/2.5.0/gems/backports-3.16.0/lib/backports/std_lib.rb:9:in `require_with_backports'
6: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
5: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
4: from /var/lib/gems/2.5.0/gems/schleuder-3.4.1/lib/schleuder.rb:23:in `<top (required)>'
3: from /var/lib/gems/2.5.0/gems/backports-3.16.0/lib/backports/std_lib.rb:9:in `require_with_backports'
2: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:39:in `require'
1: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:135:in `rescue in require'
/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:135:in `require': cannot load such file -- schleuder/mail/parts_list.rb (LoadError)
```https://0xacab.org/schleuder/schleuder/-/issues/452Ruby-Bindings for Sequoia2021-09-03T07:04:12ZdorleRuby-Bindings for Sequoia@sssggr @paz I am working on ruby-bindings for the openpgp library sequoia and i just uploaded the current state of the ruby bindings for sequoia at:
https://gitlab.com/dorle/sequoia-ruby-ffi
Maybe you could check it out and use it as...@sssggr @paz I am working on ruby-bindings for the openpgp library sequoia and i just uploaded the current state of the ruby bindings for sequoia at:
https://gitlab.com/dorle/sequoia-ruby-ffi
Maybe you could check it out and use it as a starting point for a discussion about the interface to openpgp. On which layer of abstraction do you want to use openpgp? Which features do you need and which features do you wish for? What is akward to use now and how would it be better to use?
I would like to use the discussion to decide in which direction i am going to work further on the bindings :)https://0xacab.org/schleuder/schleuder/-/issues/444Previously expired key apparently not being updated during weekly refresh_key...2020-03-03T21:06:18ZfleishPreviously expired key apparently not being updated during weekly refresh_keys run, continues to be reported as expired by weekly check_keys runMostly SSIA. I have a list where the user's key has expired and the weekly cron runs for check_keys keeps reporting that they key is still expired based on the now passed date, despite there being an updated key available on the SKS netw...Mostly SSIA. I have a list where the user's key has expired and the weekly cron runs for check_keys keeps reporting that they key is still expired based on the now passed date, despite there being an updated key available on the SKS network with an extended expiration date set in the future.https://0xacab.org/schleuder/schleuder/-/issues/438allow encrypted resending to one specific fingerprint2019-10-16T20:50:51Zxgxwznwadxfallow encrypted resending to one specific fingerprintfrom time to time it happens, that we have to send encrypted mails to an address using a key which doesn't "match"
for example:.
* when no e-mail was given while key creation
* when collectives give out the key of the only tech-savy m...from time to time it happens, that we have to send encrypted mails to an address using a key which doesn't "match"
for example:.
* when no e-mail was given while key creation
* when collectives give out the key of the only tech-savy member (for using it with the collective e-mail-adress)
is there already a way to do this?
if not, one of this two options would be nice:
1. allow adding a key to the list and specify manually which address it belongs to
e.g. "x-add-key correspondingmailaddres"
2. allow to specify a fingerprint while using x-resend commands
e.g. "x-resend-encrypted-only: onemailadress correspondingfingerprint"https://0xacab.org/schleuder/schleuder/-/issues/437allow adding additional private keys via schleuder-cli2019-10-16T22:37:55Zxgxwznwadxfallow adding additional private keys via schleuder-cliwe had one case, when a group of people wanted to write encrypted mails and decided to set up a ordinary mailinglist (lists.riseup.net) with one shared key.
our schleuder was member of this list and at first complaining heavily, because...we had one case, when a group of people wanted to write encrypted mails and decided to set up a ordinary mailinglist (lists.riseup.net) with one shared key.
our schleuder was member of this list and at first complaining heavily, because no key to decrypt was found. i managed to deal with this by adding this private key to the lists keyring manually using gpg with --homedir, --import and --edit-key (to set owner-trust - not sure if this was necessary).
in the end it worked, but i wasn't sure, if this would be a good idea and if schleuder would accept that.
it would be nice if this could be done in a more clean (and documented) way using schleuder-cli and/or schleuder-web.
thanks!https://0xacab.org/schleuder/schleuder/-/issues/426FEATURE: domain-admin2019-04-01T20:25:00ZmalteFEATURE: domain-adminIt would be nice to have the possiblility to give users the right to become "superuser", but only for a defined set of mail-domains. Maybe invent a new role for that.It would be nice to have the possiblility to give users the right to become "superuser", but only for a defined set of mail-domains. Maybe invent a new role for that.https://0xacab.org/schleuder/schleuder/-/issues/415Add option "allow unencrypted only from non-subscribers"2020-01-05T00:52:54ZdoobryAdd option "allow unencrypted only from non-subscribers"Would be nice to have a configuration option to allow unencrypted mail from non-subscribers only. That is: reject unencrypted mail from members, but accept it from external adresses.
Here's a practical use-case: A group uses schleuder f...Would be nice to have a configuration option to allow unencrypted mail from non-subscribers only. That is: reject unencrypted mail from members, but accept it from external adresses.
Here's a practical use-case: A group uses schleuder for their internal communication. In order to train their members for send encrypted mails only, they have the list configured to "Receive {authenticated,signed} only". But now, they'd like to use the same list as public contact address (or forward all mail from a public contact address to the schleuder list automatically). For that to work, they'd have to disable the "Receive {authenticated,signed} only" settings, which would be a bad thing.https://0xacab.org/schleuder/schleuder/-/issues/414Allow lists to not be accessible via the API2020-01-02T23:33:49ZpazAllow lists to not be accessible via the APIAn idea: List-admins that don't trust username+password-based authentication might want to disallow access to their list via the API completely.
Variant: Allow access read-only.
But do people really want that?An idea: List-admins that don't trust username+password-based authentication might want to disallow access to their list via the API completely.
Variant: Allow access read-only.
But do people really want that?https://0xacab.org/schleuder/schleuder/-/issues/413List-wide limiting features available in schleuder-web2020-06-24T14:53:05ZgagzList-wide limiting features available in schleuder-webIt could be a good thing to be able to restrict schleuder-web to certain features, depending on list-config. For example, high-risk lists would have changing keys disabled.It could be a good thing to be able to restrict schleuder-web to certain features, depending on list-config. For example, high-risk lists would have changing keys disabled.https://0xacab.org/schleuder/schleuder/-/issues/408Strip inline signatures also if signing key is not present?2019-02-11T08:43:10ZpazStrip inline signatures also if signing key is not present?Schleuder (more specifically 'mail-gpg') does not strip the signature from the content of an inline-signed message body if the signature could not be verified — that case includes a missing key. That behaviour is inconsistent with other ...Schleuder (more specifically 'mail-gpg') does not strip the signature from the content of an inline-signed message body if the signature could not be verified — that case includes a missing key. That behaviour is inconsistent with other behaviour and also not helpful (in our context).
I don't think that we should much more effort in supporting PGP-inline, I'm rather posting it for the record so we don't lose it.https://0xacab.org/schleuder/schleuder/-/issues/394Automated messags are still forwarded to the list admin although list bounce/...2020-01-02T21:05:55ZngAutomated messags are still forwarded to the list admin although list bounce/drop notification disabledSchleuder 3.3.0
You can disable notifications to list admins on bounces/drops:
https://0xacab.org/schleuder/schleuder/blob/master/etc/list-defaults.yml#L91
`# Send a notice to the list-admins whenever an email is bounced or dropped?`
...Schleuder 3.3.0
You can disable notifications to list admins on bounces/drops:
https://0xacab.org/schleuder/schleuder/blob/master/etc/list-defaults.yml#L91
`# Send a notice to the list-admins whenever an email is bounced or dropped?`
But this only has an effect within the filter runner itself, but is not respected when receiving automated messages:
https://0xacab.org/schleuder/schleuder/blob/master/lib/schleuder/filters/pre_decryption/10_forward_bounce_to_admins.rb
=> Either we should also check there whether bounce notification is enabled and respect it or if the option seems not appropriate, we should add another setting, as list admins can easily be spammed through lots of automated messages.https://0xacab.org/schleuder/schleuder/-/issues/378please create a thunderbird schleuder plugin2018-11-15T14:46:57Zdkgplease create a thunderbird schleuder plugina thunderbird plugin that is designed specifically for interacting with schleuder would be a pretty sweet thing. it would:
* somehow detect that a message is going to a schleuder list
* present a pleasant gui for doing the things tha...a thunderbird plugin that is designed specifically for interacting with schleuder would be a pretty sweet thing. it would:
* somehow detect that a message is going to a schleuder list
* present a pleasant gui for doing the things that you might reasonably do
* modify the message during send to include the selected activities
I have some ideas about how each of these things would be done; hopefully they'd make the lives of people like @sajolida easier and let them be more relaxed tigers with fur that is less singed (see the comment on #373)https://0xacab.org/schleuder/schleuder/-/issues/377Feature request: select multiple keys per recipient2019-10-08T12:27:16ZUlf Buermeyerulf@freiheitsrechte.orgFeature request: select multiple keys per recipientHi, it is already possible to add as many keys as one likes to a Schleuder, but only one key can be active per recipient at any given time.
That is pretty inconvenient especially for less IT-savvy people who tend to create and use multi...Hi, it is already possible to add as many keys as one likes to a Schleuder, but only one key can be active per recipient at any given time.
That is pretty inconvenient especially for less IT-savvy people who tend to create and use multiple keys on different machines.
Therefore it would be very helpful if Schleuder could use more than one key per recipient when sending email. For example, in Schleuder-Web, we could use checkboxes in the list of available keys instead of a select-one combo box.https://0xacab.org/schleuder/schleuder/-/issues/370Issue with Receive signed only (Only accept validly signed messages) configur...2021-07-06T18:43:39ZfleishIssue with Receive signed only (Only accept validly signed messages) configuration optionI am seeing an issue in Schleuder 3.2.2-1~bpo9+1 (+ manual patches as noted in issue #331) when I set the configuration option "Receive signed only". Received messages from non-list members that are GPG signed are getting bounced with a ...I am seeing an issue in Schleuder 3.2.2-1~bpo9+1 (+ manual patches as noted in issue #331) when I set the configuration option "Receive signed only". Received messages from non-list members that are GPG signed are getting bounced with a message implying they are not signed.
Steps to reproduce:
- Create a list
- Enable "Receive signed only" configuration option (my list also has "Receive encrypted only" set, but that doesn't seem to come into play)
- Send a signed (and encrypted) message to the list by a non-member of the list
Expected behavior:
- GPG signature is validated by schleuder and message is re-sent to the list members
Actual behavior:
- Message is bounced back to sender and admins are notified
Bounce message sent to sender:
> Command died with status 1: "/usr/bin/schleuder".
>
> Command output: Error: Schleuder::Errors::MessageUnsigned Kind regards,
>
> Your Schleuder system.
Notice sent to admins:
> The attached message was bounced with the following notice:
>
> Schleuder::Errors::MessageUnsigned
>
> Kind regards,
>
> Your Schleuder system.
Debug log of one such message:
> D, [2018-09-08T00:44:39.897159 #10749] DEBUG -- : Setting GNUPGHOME to /var/lib/schleuder/lists/list.domain.com/testdl1
>
> I, [2018-09-08T00:44:39.897415 #10749] INFO -- : Parsing incoming email.
>
> D, [2018-09-08T00:44:40.089003 #10749] DEBUG -- : Calling filter forward_bounce_to_admins
>
> D, [2018-09-08T00:44:40.091492 #10749] DEBUG -- : Calling filter forward_all_incoming_to_admins
>
> D, [2018-09-08T00:44:40.091646 #10749] DEBUG -- : Calling filter send_key
>
> D, [2018-09-08T00:44:40.091754 #10749] DEBUG -- : Calling filter fix_exchange_messages!
>
> D, [2018-09-08T00:44:40.099622 #10749] DEBUG -- : Calling filter strip_html_from_alternative!
>
> D, [2018-09-08T00:44:40.211891 #10749] DEBUG -- : Calling filter request
>
> D, [2018-09-08T00:44:40.212113 #10749] DEBUG -- : Calling filter max_message_size
>
> D, [2018-09-08T00:44:40.212245 #10749] DEBUG -- : Calling filter forward_to_owner
>
> D, [2018-09-08T00:44:40.212324 #10749] DEBUG -- : Calling filter receive_admin_only
>
> D, [2018-09-08T00:44:40.212457 #10749] DEBUG -- : Calling filter receive_authenticated_only
>
> D, [2018-09-08T00:44:40.212555 #10749] DEBUG -- : Calling filter receive_signed_only
>
> I, [2018-09-08T00:44:40.212683 #10749] INFO -- : Rejecting mail as unsigned
>
> D, [2018-09-08T00:44:40.212929 #10749] DEBUG -- : Bouncing message>https://0xacab.org/schleuder/schleuder/-/issues/366`schleuder` does not make it possible to handle different errors differently2020-01-05T13:18:02ZMichał "rysiek" Woźniak`schleuder` does not make it possible to handle different errors differentlyThe `schleuder` command does not give any machine-readable hints as to the nature of the error encountered when processing e-mail. It always exists with exit code `1`, and human readable error messages are not usable in order to automati...The `schleuder` command does not give any machine-readable hints as to the nature of the error encountered when processing e-mail. It always exists with exit code `1`, and human readable error messages are not usable in order to automatically handle different kinds of errors differently.
Consider the following log. These are three completely different kinds of errors.
## 1. An internal error related to a `-request` message not being properly authenticated (with the error message sent correctly to the list admin):
```
root@30e6caa2a707:/var/schlocker/mail/.tmp/test# cat 1532175290_0.1.0c6aa2ce0ea3\,U\=167\,FMD5\=7e33429f656f1e6e9d79b29c3f82c57e\:2\, | schleuder work 'test-request@occrp.org'
Error: Schleuder::Errors::MessageUnauthenticated
Kind regards,
Your Schleuder system.
root@30e6caa2a707:/var/schlocker/mail/.tmp/test# echo $?
1
```
## 2. An error caused by the SMTP server disappearing:
```
root@30e6caa2a707:/var/schlocker/mail/.tmp/test# cat 1532175290_0.1.0c6aa2ce0ea3\,U\=167\,FMD5\=7e33429f656f1e6e9d79b29c3f82c57e\:2\, | schleuder work 'test@occrp.org'
Error: A serious, unhandleable error happened. Please contact the administrators of this system or service and provide them with the following information:
getaddrinfo: Temporary failure in name resolution
root@30e6caa2a707:/var/schlocker/mail/.tmp/test# echo $?
1
```
## 3. An error caused by a misconfiguration of the SMTP server:
```
root@30e6caa2a707:/var/schlocker/mail/.tmp/test# cat 1532175290_0.1.0c6aa2ce0ea3\,U\=167\,FMD5\=7e33429f656f1e6e9d79b29c3f82c57e\:2\, | schleuder work 'test@occrp.org'
Error: A serious, unhandleable error happened. Please contact the administrators of this system or service and provide them with the following information:
550 Invalid recipient
root@30e6caa2a707:/var/schlocker/mail/.tmp/test# echo $?
1
```
These situations need to be handled differently. It would be okay to kill the message from case `1.`, since the admins have been notified successfully; but it would *not* be okay to delete the messages from `2.` and `3.`, since this might be a temporary failure and we don't want valid e-mail to be lost.
Currently there seems to be no way to differentiate between these cases, which means either e-mail will get deleted (and lost) regardless of the kind of issue encountered, or it will remain in the queue to be handled again and again (with errors about old erroneous messages being sent and resent constantly to admins).
One simple solution would be to have different exit codes for different errors/error classes (with some documentation to boot).https://0xacab.org/schleuder/schleuder/-/issues/363Missing Feature/X-Command to enable/disable Mail delivery2018-07-21T08:43:16ZmalteMissing Feature/X-Command to enable/disable Mail deliveryOne of our users managed to subscribe members to a schleuder list in a way that mail delivery was disabled for each of them (I don't know in details how he/she managed that).
There seems to be no way to clean up this situation if your ...One of our users managed to subscribe members to a schleuder list in a way that mail delivery was disabled for each of them (I don't know in details how he/she managed that).
There seems to be no way to clean up this situation if your only access to the list config is via X-COMMANDs. Schleuder-CLI and schleuder-web allow setting this flag.
This is either a gap in the documentation or indeed a missing feature.https://0xacab.org/schleuder/schleuder/-/issues/362Feature request: Introduce list option to send all subjects encrypted2020-01-05T13:14:31ZgeorgFeature request: Introduce list option to send all subjects encryptedI've just got a feature request: The user asks for a new list option, which would allow to enable to encrypt all subjects by default.
This would extend the recently merged feature, which enabled Schleuder to "pass-on" the encrypted head...I've just got a feature request: The user asks for a new list option, which would allow to enable to encrypt all subjects by default.
This would extend the recently merged feature, which enabled Schleuder to "pass-on" the encrypted header in case it received one.
Relates: #742020-12-01