schleuder issueshttps://0xacab.org/schleuder/schleuder/-/issues2020-01-04T12:25:52Zhttps://0xacab.org/schleuder/schleuder/-/issues/412Implement 2 factor authentication2020-01-04T12:25:52ZgagzImplement 2 factor authenticationAfter some discussion on how to strength login security of schleuder-web, here is a ticket!
Ideas:
- 2FA standard implementation
- Kinda 2FA where a token would be send (encrypted) to the email corresponding to the account after success...After some discussion on how to strength login security of schleuder-web, here is a ticket!
Ideas:
- 2FA standard implementation
- Kinda 2FA where a token would be send (encrypted) to the email corresponding to the account after successful login, and the user would have to enter this token to login
thanks!Futurehttps://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/403Document API2019-02-02T17:07:35ZpazDocument APIPeople should be able to use the API for third party applications. We should document the development principles and technical details to support that:
* Semantic versioning (API will break only in major releases)
* Show happy paths for...People should be able to use the API for third party applications. We should document the development principles and technical details to support that:
* Semantic versioning (API will break only in major releases)
* Show happy paths for endpoints, authorization, etc.Next Big Thinghttps://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/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/391Adapt keywords_admin_notify to activities/actions2019-04-09T11:01:41ZpazAdapt keywords_admin_notify to activities/actionsThe point is to notify admins about certain activities. It should be irrelevant if e.g. a key was added using a keyword or using an API-client. Thus the notifications should be supervised by the resource-controllers and should be renamed...The point is to notify admins about certain activities. It should be irrelevant if e.g. a key was added using a keyword or using an API-client. Thus the notifications should be supervised by the resource-controllers and should be renamed to reflect that.
How about `actions_admin_notify`?Next Big Thinghttps://0xacab.org/schleuder/schleuder/-/issues/389Introduce tokens2021-06-06T14:48:16ZpazIntroduce tokensWe need tokens to verify control over email addresses (see #388).
They should
* be tied to an email-address (or account?),
* be hard to guess,
* have a lifetime,
* have a date (in order to prevent too many repeated requests per time sl...We need tokens to verify control over email addresses (see #388).
They should
* be tied to an email-address (or account?),
* be hard to guess,
* have a lifetime,
* have a date (in order to prevent too many repeated requests per time slot).
Open questions:
* Do we need a keyword to request tokens?
* Do we need the possibility to generate tokens for email addresses that are not subscribed at all? (Could make sense if we would also provide the option to upload a key to an account, so admins can "pluck" a key from the account if they subscribed the email address.)Next Big Thingpazpazhttps://0xacab.org/schleuder/schleuder/-/issues/388API: Provide endpoint(s) to request password-token2021-06-06T14:48:09ZpazAPI: Provide endpoint(s) to request password-tokenHTTP-Clients (schleuder-cli, schleuder-web) must be able to request a token for setting a new password. The API must provide an endpoint to do that.
The workflow shall be this:
1. A person that wants an account enters their email-addre...HTTP-Clients (schleuder-cli, schleuder-web) must be able to request a token for setting a new password. The API must provide an endpoint to do that.
The workflow shall be this:
1. A person that wants an account enters their email-address in a form and clicks a button.
2. The web-interface sends the request unauthenticated (because there's no account yet) to the API.
3. The API uses the sent email-address to look up a subscription with a usable key.
4. *If* it finds a key, it generates a token (or a link?) and sends that in an encrypted email to the email-address. It returns an positive response to the web interface.
4. *If* it doesn't find a subscription for the email-address at all it returns an error to the web interface.
5. *If* it finds a subscription but none with a usable key it returns a different error to the web interface (so the web interface can display a helpful message).
5. The person receives and decrypts the email, copies the token into the web interface (or clicks the link).
6. The web interfaces validates the token at the API.
7. *If* that is successful, it presents the person a form to enter and save a new password.
7. *Or* should the person receive a second email, which contains the new password as it was set by schleuder?
* The tokens should be valid only for a given time span (15 minutes?).
* Admins must be able to request a token for a different email-address than their own. List-admins must only be allowed to request a token for email-addresses that are subscribed to one of their admin-lists.
* Should admins receive the token (or link) via HTTP instead of via encrypted email? The request from the web interface to the API is authenticated with their admin-credentials, thus we don't need the proof that they can decrypt a message.
* How to protect against SPAM/DOS-attacks through repeated requests for new tokens against the API? We can't authenticate those requests because there's no account yet.Next Big Thingpazpazhttps://0xacab.org/schleuder/schleuder/-/issues/384Improve key-related keyword vocabulary2021-06-09T14:29:49ZpazImprove key-related keyword vocabularySome key-related keywords are ambigiously named:
* `x-send-key` sends a key from schleuder to the sender.
* `x-get-key` also sends a key from schleuder to the sender.
* `x-fetch-key` makes schleuder get a key from the internet, though.
...Some key-related keywords are ambigiously named:
* `x-send-key` sends a key from schleuder to the sender.
* `x-get-key` also sends a key from schleuder to the sender.
* `x-fetch-key` makes schleuder get a key from the internet, though.
Without studying documentation the difference between these is not comprehensible. Unfortunately I don't have a good proposal for this problem.
Other keywords are clearer named regarding their action (`x-list-keys`, `x-delete-key`), but they suffer from singularized/pluralized mismatches. It *is* possible to list only one key (`x-list-key`?), and it is also possible to delete multiple keys (`x-delete-keys`?). We should harmonize that, or introduce the respective pluralized and singularized aliases.Next Big Thinghttps://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/376Harmonize output of keywords that deal with keys2020-01-04T12:51:37ZgeorgHarmonize output of keywords that deal with keysI've used `x-fetch-key` with a capitalized fingerprint argument, and got, in return a message containing the lowercased fingerprint. We should probably harmonize this, so the output matches the input.
Not sure, but maybe this applies to...I've used `x-fetch-key` with a capitalized fingerprint argument, and got, in return a message containing the lowercased fingerprint. We should probably harmonize this, so the output matches the input.
Not sure, but maybe this applies to spaces, too.
Any opinions?Futurehttps://0xacab.org/schleuder/schleuder/-/issues/375Handle space-separated fingerprints for all relevant keywords2020-01-04T12:51:15ZgeorgHandle space-separated fingerprints for all relevant keywordsIn version `3.2.0`, we introduced spaces-separated fingerprint support for `x-subscribe`.
We should probably revisit this for the other relevant keywords, too. I just did `x-fetch-key` with such a fingerprint, and got, in return, ten ti...In version `3.2.0`, we introduced spaces-separated fingerprint support for `x-subscribe`.
We should probably revisit this for the other relevant keywords, too. I just did `x-fetch-key` with such a fingerprint, and got, in return, ten times the message: `Invalid input. Allowed are: URLs, OpenPGP-fingerprints, or email-addresses.`. I'm not sure, and didn't checked, if this is an issue for other keywords too, but I guess so.
OTOH, as we spoke about "being implicit", I wonder if parsing fingerprints with spaces is maybe error prone?
Still, if we do, we should be consistent. Tagging this for `4.0` for now, and labeling as `bug`.
Any opinions?Futurehttps://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/364Admin will self-unsubscribe with accidental line-break in x-unsubscribe:-command2020-01-02T22:30:45Zinit voidAdmin will self-unsubscribe with accidental line-break in x-unsubscribe:-commandOne of our list-**admins** send the following request:
```
x-list-name: some-list@listserver.net
x-unsubscribe:
mail@example.net
```
I don't know, why he added a line break? Users to these things.
**Admin** was removed. List stoped wor...One of our list-**admins** send the following request:
```
x-list-name: some-list@listserver.net
x-unsubscribe:
mail@example.net
```
I don't know, why he added a line break? Users to these things.
**Admin** was removed. List stoped working immediately, due to missing admin. Admin had to be restored by schleuder-cli.
## Expected Behavior
The command should complain that the subscription-e-mail is missing.
or
The admin should get a warning, that he is about to unsubscribe himself and some confirmation like `force` is required.
## Actual Behavior
Since the command does not get an e-mail-address on the same line, it assumes that the sender wants to unsubscribe himself.
## Steps to Reproduce the Problem
1. Be Admin
2. Try to unsubscribe a list member
3. Add a line-break between x-unsubscribe: and the e-mail-address.
## Specifications
- Version: 3.2.2-1~bpo9+1
- Installation method: deb
- Mail client version: any
## Other information
I see, why the current behavior is useful. A person that want's to get off the list just sends `x-unsubscribe:` . Done.
But I'm filing this issue anyway because we had the problem with an actual admin. The list shutting down because of the unsubscribed admin caused some stress for the group using the list.
So, the command behaves as intended.
But this intended behavior bares some danger for clumsy admins.
Maybe you cannot prevent clumsy ppl from shooting themselves in the foot sometimes. It's not too hard to write a command and an e-mail-address on one line. I just wanted to let you know, that one of our list-admins managed to pull that of.Next Big Thinghttps://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-01https://0xacab.org/schleuder/schleuder/-/issues/355An email with multiple signatures throws an error2019-01-20T19:58:41ZngAn email with multiple signatures throws an errorIf somebody signs their email with multiple keys, schleuder is at the moment not able to handle the multiple signaures and will just throw an error:
https://0xacab.org/schleuder/schleuder/blob/master/lib/schleuder/mail/message.rb#L145
...If somebody signs their email with multiple keys, schleuder is at the moment not able to handle the multiple signaures and will just throw an error:
https://0xacab.org/schleuder/schleuder/blob/master/lib/schleuder/mail/message.rb#L145
Such an email will be bounced. We had someone who (accidentally) signed their message with 2 keys and wasn't able to send mails to any schleuder.
The major issue with it, is that bouncing the mail is technicall (as we are throwing an error) the right thing to happen. However, it is not very userfriendly and requires involvment of a superadmin to interprete the thrown error message. At least this should have a much better message for users to be able to detect what went wrong.
Additionally, we should probably discuss if throwing an error is the right thing to do. While I can think of reasons why an error should be raised - e.g. as the multiple signatures were for different parts - I still think we can do better. Also I think, we actually slightly changed how we work now and the double signatures should be less of a problem, since we merged
!172
We should make sure, that we only verify signatures around the whole message (or only treat correctly signed parts of the message as trusted), but still allow for multiple signatures on them. We should still be able to match for the right signature, while making sure you cannot craft messages to inject content that we trust to be signed properly, although the signature was for a different part.
While the reason for this report was an accident, I still think there is someone out there who has legitimate reasons to sign an email with 2 keys.https://0xacab.org/schleuder/schleuder/-/issues/353Send whole Keyring at once (worked in schleuder2)2020-11-12T16:28:16Zinit voidSend whole Keyring at once (worked in schleuder2)Feedback from one of our users:
> in der vorherigen Schleuder-Version war es möglich, sich mittels des Befehls `X-GET-KEY: . ` den gesamten Keyring (Schlüsselbund) einer verschlüsselten E-Mail-Verteilerliste zusenden zu lassen.
> So is...Feedback from one of our users:
> in der vorherigen Schleuder-Version war es möglich, sich mittels des Befehls `X-GET-KEY: . ` den gesamten Keyring (Schlüsselbund) einer verschlüsselten E-Mail-Verteilerliste zusenden zu lassen.
> So ist funktioniert das nun leider nicht mehr. Gibt es einen neuen Befehl hierfür?
The described behavior sounds more like a "hack" that like an intended Feature to me. Yet it might be a useful option to export all keys in one go.
Just leaving this here so the users input is not lost.Futurepazpaz