pleroma issueshttps://git.pleroma.social/pleroma/pleroma/-/issues2023-05-08T00:37:06Zhttps://git.pleroma.social/pleroma/pleroma/-/issues/3048Instance Ban2023-05-08T00:37:06ZtusooaInstance BanCurrently there is no such thing in Pleroma as instance ban.
Every user from a banned instance should behave as if they are deactivated individually. MRF Simple only deals with future posts, and everything before the Reject is still in ...Currently there is no such thing in Pleroma as instance ban.
Every user from a banned instance should behave as if they are deactivated individually. MRF Simple only deals with future posts, and everything before the Reject is still in place, available for display, which can be really annoying.https://git.pleroma.social/pleroma/pleroma/-/issues/3047Relayed Creates rejected with "Invalid HTTP Signature"2023-05-08T00:40:01ZthefloweringashRelayed Creates rejected with "Invalid HTTP Signature"<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been ...<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been reported before. If the bug has not been addressed after 2 weeks, it's fine to bump it.
* Try to ensure that the bug is actually related to the Pleroma backend. For example, if a bug happens in Pleroma-FE but not in Mastodon-FE or mobile clients, it's likely that the bug should be filed in [Pleroma-FE](https://git.pleroma.social/pleroma/pleroma-fe/issues/new) repository.
-->
### Environment
* Installation type (OTP or From Source): from source(?) via nixpkgs
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.5.0
* Elixir version (`elixir -v` for from source installations, N/A for OTP): 1.13.4
* Operating system: NixOS 22.11
* PostgreSQL version (`psql -V`): 14.6
### Bug description
Relayed Create messages posted to /inbox are rejected with "Invalid HTTP Signature" after 23e91ec8ddb143353b5f685feec33c64370d13c6, which changed the fallback logic for invalid signatures.
The "valid_signature=false" assign has two meanings:
- signature was not valid
- signature key id does not match author (MappedSignatureToIdentityPlug, "payload actor mismatch")
The second meaning applies to relayed Create requests.
Prior to 23e91ec8ddb143353b5f685feec33c64370d13c6, requests with invalid signatures would hit the ActivityPubController inbox handler that (possibly) called `post_inbox_relayed_create`. After the change, they are rejected eagerly with the "Invalid HTTP Signature" error.https://git.pleroma.social/pleroma/pleroma/-/issues/3046[error] Elixir.Pleroma.Web.MastodonAPI.WebsocketHandler received frame: {:pin...2023-05-08T00:40:17Ztusooa[error] Elixir.Pleroma.Web.MastodonAPI.WebsocketHandler received frame: {:ping, "PING"}
log: `[error] Elixir.Pleroma.Web.MastodonAPI.WebsocketHandler received frame: {:ping, "PING"}`
code:
```
def websocket_handle(:ping, state), do: {:ok, state}
```
~~Maybe websockex is different from our original implementation?~~ that...
log: `[error] Elixir.Pleroma.Web.MastodonAPI.WebsocketHandler received frame: {:ping, "PING"}`
code:
```
def websocket_handle(:ping, state), do: {:ok, state}
```
~~Maybe websockex is different from our original implementation?~~ that's unrelevant, websockex is the client implementation, not serverhttps://git.pleroma.social/pleroma/pleroma/-/issues/3044Import following not working as expected on new instance2023-02-19T06:58:01ZVD-15Import following not working as expected on new instance<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been ...<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been reported before. If the bug has not been addressed after 2 weeks, it's fine to bump it.
* Try to ensure that the bug is actually related to the Pleroma backend. For example, if a bug happens in Pleroma-FE but not in Mastodon-FE or mobile clients, it's likely that the bug should be filed in [Pleroma-FE](https://git.pleroma.social/pleroma/pleroma-fe/issues/new) repository.
-->
### Environment
* Installation type (OTP or From Source): From Source
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.5.0
* Elixir version (`elixir -v` for from source installations, N/A for OTP): Elixir 1.12.2 (compiled with Erlang/OTP 24)
* Operating system: Ubuntu 22.04 jammy
* PostgreSQL version (`psql -V`): psql (PostgreSQL) 14.5 (Ubuntu 14.5-0ubuntu0.22.04.1)
### Bug description
I recently set up a new instance following the [instructions](https://docs-develop.pleroma.social/backend/installation/debian_based_en/) for my distribution in the Pleroma docs, but I've found myself unable to import my `friends.csv` from my main account.
I follow about 200 people on my main, but when importing the follows via pleroma-FE, the importing process only appeared to follow a single user from the list. I'm aware this process can take a while, so I left it overnight but no progress had been made the following morning. I tried importing the list a few more times, and each time I uploaded the file, it would follow exactly one more user from the list and stop. Eventually it stopped following users altogether and the new account currently sits following 15 people, a handful of which were followed manually.
This is odd to me, because I was able to import almost the exact same follow list on a new Akkoma instance the week prior. That account now follows 134 people. I assume this number is lower than my main because I follow a lot of usernames from dead instances.
I've restarted Pleroma and the server it's running on several times and even re-compiled pleroma and its dependencies just to be sure. I don't think it's a federation issue as I can see posts from the few users I do follow just fine and the import process follows some users from specific instances, but not others on those same instances. Perhaps worth mentioning is that I've configured the instance with an abnormally low upload limit of ~64kB and a character limit of ~1000 characters. I don't know if that would somehow affect the importing process. I can't see any relevant errors in pleroma's logs when running the import process. I did have one error in the logs relating to a user I had followed whose instance had since shut down. While removing that user's handle from `friends.csv` did remove the error, it did not fix the import process.https://git.pleroma.social/pleroma/pleroma/-/issues/3043Re-following bot accounts on non-Pleroma seems to be forbidden2023-05-08T00:35:42ZDohyeon JeonRe-following bot accounts on non-Pleroma seems to be forbidden<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been ...<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been reported before. If the bug has not been addressed after 2 weeks, it's fine to bump it.
* Try to ensure that the bug is actually related to the Pleroma backend. For example, if a bug happens in Pleroma-FE but not in Mastodon-FE or mobile clients, it's likely that the bug should be filed in [Pleroma-FE](https://git.pleroma.social/pleroma/pleroma-fe/issues/new) repository.
-->
### Environment
* Installation type (OTP or From Source): Not a Pleroma environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): Not a Pleroma environment
* Elixir version (`elixir -v` for from source installations, N/A for OTP): Not a Pleroma environment
* Operating system: Not a Pleroma environment
* PostgreSQL version (`psql -V`): Not a Pleroma environment
#### Remote Environment
> NOTE: This bug has arisen between Pleroma and remote (non-Pleroma environment), and I'm at the remote.
* Remote instance 1
* Instance Type: Misskey
* Instance version: [Misskey 13.0.0-beta.30+paring-b25ac66](https://github.com/pikokr/misskey/tree/master)
* Operating system: Alpine Linux v3.17 (Linux kernel 5.15.74-0-lts) on Backend, Data, and Media (Single system hosted)
* Remote instance 2
* Instance Type: Mastodon
* Instance version: [v4.0.2](https://github.com/mastodon/mastodon/releases/tag/v4.0.2)
* Operating System: Could not check
* Bug arisen on (1): [Udongein](https://udongein.xyz)
* Pleroma version: Backend 2.5.0; Frontend 3a507ba9b
* Installation type: Could not check
* Elixir version: Could not check
* Operating system: Could not check
* PostgreSQL version: Could not check
* Bug arisen on (2): [blobcat](https://blob.cat)
* Pleroma version: Backend 2.2.50-745-g0ad6ea20-develop; Frontend 39f85871
* Installation type: Could not check
* Elixir version: Could not check
* Operating system: Could not check
* PostgreSQL version: Could not check
### Bug description
When you followed a bot user and unfollowed, you can never re-follow again but it just says "Follow request pending".
#### Reproduce steps
1. Follow a bot user of Pleroma on non-Pleroma remote.
2. Unfollow them.
3. Try follow them again.https://git.pleroma.social/pleroma/pleroma/-/issues/3042Periodic job for pruning old content2023-09-17T21:42:51ZpiggoPeriodic job for pruning old contentI fixed my issues with incredibly slow timelines and query timeouts by deleting disabled users, old activities and objects (older than Jan 1 2021), then vacuum full. How about this were a built-in job that runs every X days or something,...I fixed my issues with incredibly slow timelines and query timeouts by deleting disabled users, old activities and objects (older than Jan 1 2021), then vacuum full. How about this were a built-in job that runs every X days or something, configurable of course?
It could also be limited to remote only and posts the local users never interacted with, but that makes the query more complicated.
Deleting old stuff also solves the issue of ever growing storage requirements. This almost halved my postgres folder in size.
In my case this deleted about 3 millions of activities and couple hundred thousand objects
This change was needed to delete objects - the constraint prevented anything being deleted:
```
ALTER TABLE deliveries DROP CONSTRAINT "deliveries_object_id_fkey", ADD CONSTRAINT "deliveries_object_id_fkey" FOREIGN KEY (object_id) REFERENCES objects(id) ON DELETE CASCADE;
```
Deleting users needed a new index, but I forgot what it was - it shows up when running explain (timing) when deleting a single user.https://git.pleroma.social/pleroma/pleroma/-/issues/3039MRF SimplePolicy: `check_ftl_removal` only supports tuples as configuration, ...2023-05-08T00:36:22ZpiggoMRF SimplePolicy: `check_ftl_removal` only supports tuples as configuration, no single string (legacy)```
pleroma | 10:32:21.655 [info] POST /api/v1/statuses
pleroma |
pleroma | 10:32:21.660 request_id=FzXaMT1xvIFX2yUAAD8h [error] Internal server error: %FunctionClauseError{args: nil, arity: 1, clauses: nil, functio...```
pleroma | 10:32:21.655 [info] POST /api/v1/statuses
pleroma |
pleroma | 10:32:21.660 request_id=FzXaMT1xvIFX2yUAAD8h [error] Internal server error: %FunctionClauseError{args: nil, arity: 1, clauses: nil, function: :"-instance_list_from_tuples/1-fun-0-", kind: nil, module: Pleroma.Web.ActivityPub.MRF}
pleroma |
pleroma | 10:32:21.661 request_id=FzXaMT1xvIFX2yUAAD8h [info] Sent 500 in 5ms
pleroma |
pleroma | 10:32:21.661 [error] #PID<0.4543.0> running Pleroma.Web.Endpoint (connection #PID<0.4135.0>, stream id 20) terminated
pleroma | Server: piggo.space:80 (http)
pleroma | Request: POST /api/v1/statuses
pleroma | ** (exit) an exception was raised:
pleroma | ** (FunctionClauseError) no function clause matching in anonymous fn/1 in Pleroma.Web.ActivityPub.MRF.instance_list_from_tuples/1
pleroma | (pleroma 2.5.0) anonymous fn("botsin.space") in Pleroma.Web.ActivityPub.MRF.instance_list_from_tuples/1
pleroma | (elixir 1.12.2) lib/enum.ex:1582: Enum."-map/2-lists^map/1-0-"/2
pleroma | (pleroma 2.5.0) lib/pleroma/web/activity_pub/mrf/simple_policy.ex:89: Pleroma.Web.ActivityPub.MRF.SimplePolicy.check_ftl_removal/2
pleroma | (pleroma 2.5.0) lib/pleroma/web/activity_pub/mrf/simple_policy.ex:217: Pleroma.Web.ActivityPub.MRF.SimplePolicy.filter/1
pleroma | (elixir 1.12.2) lib/enum.ex:2385: Enum."-reduce/3-lists^foldl/2-0-"/3
pleroma | (pleroma 2.5.0) lib/pleroma/web/activity_pub/activity_pub.ex:130: Pleroma.Web.ActivityPub.ActivityPub.insert/4
pleroma | (pleroma 2.5.0) lib/pleroma/web/activity_pub/activity_pub.ex:299: Pleroma.Web.ActivityPub.ActivityPub.do_create/2
pleroma | (ecto_sql 3.9.0) lib/ecto/adapters/sql.ex:1190: anonymous fn/3 in Ecto.Adapters.SQL.checkout_or_transaction/4
pleroma |
pleroma | 10:32:21.697 [info] GET /api/v1/timelines/home
```https://git.pleroma.social/pleroma/pleroma/-/issues/3036Suggestion: add email_whitelist option to Pleroma.User config2023-05-08T00:42:01Zl mSuggestion: add email_whitelist option to Pleroma.User config- only allow users with allowed email domains to register
- has no effect when empty list, which is the default option
- if given domain is in both email_blacklist and email_whitelist, blacklist has priority- only allow users with allowed email domains to register
- has no effect when empty list, which is the default option
- if given domain is in both email_blacklist and email_whitelist, blacklist has priorityhttps://git.pleroma.social/pleroma/pleroma/-/issues/3034Emails not being sent2023-05-08T00:41:12ZWyatt ParkerEmails not being sentSo I have Pleroma with Soapbox and I'm trying to figure out how come no emails are being sent. I've check/tested 465/587 with telnet and can telnet just fine to my google workspace.
I've even tested with SendMail API/AmazonSES both API a...So I have Pleroma with Soapbox and I'm trying to figure out how come no emails are being sent. I've check/tested 465/587 with telnet and can telnet just fine to my google workspace.
I've even tested with SendMail API/AmazonSES both API and SMTP credentials on these ports through Pleroma and no emails, but again, Telnet is successful.
Port 25 is not an option as DigitalOcean is blocking it. I've tried to reach out to Pleroma through their IRC and no response for 2 days. Was hoping someone could shed some light on how come registration emails are not going through.
Thanks in advance.https://git.pleroma.social/pleroma/pleroma/-/issues/3032Non-breaking migration process2023-05-08T00:43:30ZtusooaNon-breaking migration processWe should set up a non-breaking migration process.
This means we should strive to minimize the downtime for the migrations.
Preferably, the process should behave as follows:
0. Run the migrations that will not break old code
1. Swap o...We should set up a non-breaking migration process.
This means we should strive to minimize the downtime for the migrations.
Preferably, the process should behave as follows:
0. Run the migrations that will not break old code
1. Swap old code with new code
2. Run migrations that will not break current code, while new code is runninghttps://git.pleroma.social/pleroma/pleroma/-/issues/3028search only finds users who start with the search term2023-05-08T00:45:35Zrobinsearch only finds users who start with the search termWhen you search for a user, it only finds results that start with your search term; it would be much more useful (at least to me) if it found results that contain the term.
The specific example that inspired me to open an issue was sear...When you search for a user, it only finds results that start with your search term; it would be much more useful (at least to me) if it found results that contain the term.
The specific example that inspired me to open an issue was searching for an account I'd just added to the instance I use to mirror Twitter accounts so they can be followed from the fediverse (https://twitter.oksocial.net); the account is "PlayARKMobile", but all I could remember was that it was related to Ark.
Searching for "ark" on that instance finds no users, but searching for "play" does find it.
(I had to look back at the the mirror config for the username. :-)https://git.pleroma.social/pleroma/pleroma/-/issues/3025Not getting all emoji when downloading pack from remote instance2023-05-08T00:46:46ZHJNot getting all emoji when downloading pack from remote instanceImporting remote emoji pack seem to download first 30 of the pack and fails the rest, emoji are still created but have no files for them.Importing remote emoji pack seem to download first 30 of the pack and fails the rest, emoji are still created but have no files for them.https://git.pleroma.social/pleroma/pleroma/-/issues/3016Infinite app registration2023-05-08T00:52:25ZRenat EskeninInfinite app registrationHi, all. I read Pleroma use Mastodon API contract. So, may be it be interested for developers
https://github.com/mastodon/mastodon/issues/21991
I can fill my instance postgres by unconfirmed accounts and spam by confirmation emails. An...Hi, all. I read Pleroma use Mastodon API contract. So, may be it be interested for developers
https://github.com/mastodon/mastodon/issues/21991
I can fill my instance postgres by unconfirmed accounts and spam by confirmation emails. And can fill postgres by creating registered applications (1.5kk apps on mastodon.social now). I didn't find methods to purge this spam from db for Mastodon or any retention policy, but this API has rate limit.https://git.pleroma.social/pleroma/pleroma/-/issues/3014Jsonrs issues2023-06-07T15:26:27ZZeroJsonrs issues### Environment
* Installation type: Source
* Pleroma version: 2.4.5 stable
* Elixir version: Elixir 1.13.0 (compiled with Erlang/OTP 24)
* Operating system: Ubuntu
* PostgreSQL version: 12.12
### Bug description
So I was looking for...### Environment
* Installation type: Source
* Pleroma version: 2.4.5 stable
* Elixir version: Elixir 1.13.0 (compiled with Erlang/OTP 24)
* Operating system: Ubuntu
* PostgreSQL version: 12.12
### Bug description
So I was looking for ways to speed up Pleroma, and I found [Jsonrs](https://hexdocs.pm/jsonrs/readme.html), the authors claim it to be much faster than Jason and even Jiffy, you can see the graphs in their page.
So anyway, I added it to mix.exs and used the following in my config:
```
config :phoenix, :format_encoders, json: Jsonrs, "activity+json": Jsonrs
config :phoenix, :json_library, Jsonrs
config :postgrex, :json_library, Jsonrs
```
To my surprise, everything seemed to work or so I thought, later I found out anything under the "Settings" menu for admin-fe doesn't seem to work properly when using Jsonrs.
I _think_ I traced the issue to Phoenix not being able to decode the JSON for the settings' descriptions Pleroma sends to it when using Jsonrs, but thats as far I was able to go on my own.
I managed to get a full log of the error by adding `config :logger, truncate: :infinity` to my config, as it was too long and got truncated otherwise.
The log file was upload [here](https://git.pleroma.social/-/snippets/7642/raw/main/jsonrs.log) as it would probably be too long to include in the post.
So what I'm asking is if someone knows how to solve or even work around this issue, because if this Json library is that much faster, it could benefit everyone using Pleroma.https://git.pleroma.social/pleroma/pleroma/-/issues/3012Upgrade Swoosh dependency2022-12-31T06:04:26ZZhuoyun WeiUpgrade Swoosh dependencyNewer version of Swoosh ships a useful adapter [ExAwsAmazonSES](https://hexdocs.pm/swoosh/Swoosh.Adapters.ExAwsAmazonSES.html), which wraps AmazonSES to use dynamic credentials fetched from IAM role. This is particular useful if Pleroma ...Newer version of Swoosh ships a useful adapter [ExAwsAmazonSES](https://hexdocs.pm/swoosh/Swoosh.Adapters.ExAwsAmazonSES.html), which wraps AmazonSES to use dynamic credentials fetched from IAM role. This is particular useful if Pleroma is running in an AWS environment.
Currently the OTP release of Pleroma ships Swoosh 1.3.11, which does not include this adapter. Please consider upgrading Swoosh to a newer version.https://git.pleroma.social/pleroma/pleroma/-/issues/3004Turn emoji react to mention when reacting to a Mastodon post2023-05-08T00:52:48ZpiggoTurn emoji react to mention when reacting to a Mastodon postProvided pleroma knows what server it's federating to and that server is running a software known to not support emoji reacts, how about the react was turned either into a favourite, or to a mention with just the emoji as text?
now you'...Provided pleroma knows what server it's federating to and that server is running a software known to not support emoji reacts, how about the react was turned either into a favourite, or to a mention with just the emoji as text?
now you'd have to check who is running what before reacting
this could be an optional MRF or somethinghttps://git.pleroma.social/pleroma/pleroma/-/issues/3002full_nickname does not respect webfinger domain setting2023-05-08T00:53:27ZStephen Weberfull_nickname does not respect webfinger domain settingWhen a different webfinger domain is set than the web host, https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/user.ex#L2230 still generates nicknames using the ap_id which uses the web host, so UI shows the wrong addr...When a different webfinger domain is set than the web host, https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/user.ex#L2230 still generates nicknames using the ap_id which uses the web host, so UI shows the wrong address.https://git.pleroma.social/pleroma/pleroma/-/issues/3000Suggestion: clarify visibility expectations in https://api.pleroma.social/#op...2023-05-08T00:53:21ZJames CridlandSuggestion: clarify visibility expectations in https://api.pleroma.social/#operation/StatusController.createIn https://api.pleroma.social/#operation/StatusController.create there is a note reading:
> Visibility of the posted status. Besides standard MastoAPI values (`direct`, `private`, `unlisted` or `public`) it can be used to address a List...In https://api.pleroma.social/#operation/StatusController.create there is a note reading:
> Visibility of the posted status. Besides standard MastoAPI values (`direct`, `private`, `unlisted` or `public`) it can be used to address a List by setting it to `list:LIST_ID`
It would be beneficial to developers were this to also include expectations of how this is used; I'd suggest...
> Visibility of the posted status. Besides standard MastoAPI values (`direct`, `private`, `unlisted` or `public`) it can be used to address a List by setting it to `list:LIST_ID`. Bots posting automated statuses are generally expected by the community to be `unlisted`.
This would help new-to-the-fediverse developers like me to, at least, understand the community expectation here, and not put a big foot in it.
I'd make a pull request, but I don't actually know where the documentation lives.https://git.pleroma.social/pleroma/pleroma/-/issues/2997Inform users who are following someone who just got defederated2023-05-08T00:54:32ZJeff CliffInform users who are following someone who just got defederatedhttps://bae.st/objects/4fbd5aea-eb73-48e4-8edd-0117b7f3f496
at least with pleroma-pleroma federation, users should see a message that tells them that the lines of communication between them and the person they think they are following h...https://bae.st/objects/4fbd5aea-eb73-48e4-8edd-0117b7f3f496
at least with pleroma-pleroma federation, users should see a message that tells them that the lines of communication between them and the person they think they are following has snappedhttps://git.pleroma.social/pleroma/pleroma/-/issues/2996LDAP auth saying invald credentals2023-05-08T12:36:50Znoidea manLDAP auth saying invald credentalsI have a config similar to #1646
### environment
* Installation type:
* self build docker image from https://github.com/angristan/docker-pleroma
* ldap authentication
```
import Config
config :pleroma, :instance,
registrations_o...I have a config similar to #1646
### environment
* Installation type:
* self build docker image from https://github.com/angristan/docker-pleroma
* ldap authentication
```
import Config
config :pleroma, :instance,
registrations_open: false
config :pleroma, Pleroma.Web.Auth.PleromaAuthenticator, Pleroma.Web.Auth.LDAPAuthenticator
config :pleroma, :ldap,
enabled: true,
host: "host",
port: 389,
ssl: false,
tls: false,
base: "cn=users,cn=accounts,dc=server,dc=com",
uid: "uid"
```
loging into the webui returns invalid credentials
trying the command listed in the previous issue ends with
```
mix pleroma.user new user user@server.com
Compiling 22 files (.ex)
== Compilation error in file lib/phoenix-1.5.9/priv/templates/phx.gen.channel/channel.ex ==
** (SyntaxError) lib/phoenix-1.5.9/priv/templates/phx.gen.channel/channel.ex:1:13: syntax error before: '='
(elixir 1.11.4) lib/kernel/parallel_compiler.ex:314: anonymous fn/4 in Kernel.ParallelCompiler.spawn_workers/7
```
I went to a remote device to see if the mail attribute shows when not authenticating against freeipa's ldap
```
ldapsearch -x -b "cn=users,cn=accounts,dc=server,dc=com" -H ldap://host
```
and it does not show the mail attribute. After allowing anonymous read access it does show
```
ipa permission-add 'Mail readable by anon' --type=user --attrs=mail --bindtype=anonymous --permissions=read
```
But account creation/login still fails