[QA] Look for inbucket alternative

[amrita-shrestha]

Describe

Currently, we are using Inbucket to test email notifications. Inbucket has a limited API endpoint https://github.com/inbucket/inbucket/wiki/REST-API which is insufficient for our API test framework.

Inbucket alternatives

• maildev (https://github.com/maildev/maildev/tree/master)
• mailpit (https://github.com/axllent/mailpit https://hub.docker.com/r/axllent/mailpit)
• SymfonyMailerTesting (https://github.com/Kocal/SymfonyMailerTesting)

Feature Comparison Table

Feature	MailDev 🚀	MailPit ⚡
SMTP Server	✅ Yes (Port 1025 by default)	✅ Yes (Port 1025 by default)
Web UI	✅ Yes (Port 1080)	✅ Yes (Port 8025)
Persistent Email Storage	❌ No (Emails disappear on restart)	✅ Yes (Emails persist across restarts)
Docker Support	✅ Yes (docker run maildev/maildev)	✅ Yes (docker run axllent/mailpit)
Filtering/Search	⚠️ Basic (Only email list)	✅ Advanced search by subject, sender, content, etc.
Pause Incoming Emails	❌ No (Must stop service)	❌ No (Needs firewall workaround)
Performance	🟡 Slower with many emails	🟢 Fast, optimized for large volumes
API for Fetching Emails	✅ Yes (/email)	✅ Yes (More powerful REST API)
Message Parsing	⚠️ Basic HTML & plain text	✅ Better parsing (HTML, text, headers, attachments)
Multiple Recipients Handling	✅ Yes	✅ Yes
Attachments Support	✅ Yes	✅ Yes (Better handling)
Docs	readable(https://github.com/maildev/maildev/tree/main/docs)	Well documented (https://mailpit.axllent.org/docs/api-v1/view.html#delete-/api/v1/messages)

Maildev

docker run -p 1080:1080 -p 1025:1025 maildev/maildev

Mailpit

docker run -d --restart unless-stopped --name=mailpit -p 8025:8025 -p 1025:1025 axllent/mailpit

Ocis running command

PROXY_ENABLE_BASIC_AUTH=true \        
OCIS_ADD_RUN_SERVICES=notifications \
NOTIFICATIONS_SMTP_HOST=localhost \
NOTIFICATIONS_SMTP_PORT=1025 \
NOTIFICATIONS_SMTP_INSECURE=true \
NOTIFICATIONS_SMTP_SENDER="owncloud <[email protected]>" OCIS_INSECURE=true \
ocis/bin/ocis server

Todo

• deployment still uses inbucket
• replace api [tests-only][full-ci] Replace inbucket with mailpit #11040
• adjust docker compose file https://github.com/owncloud/ocis/blob/master/tests/acceptance/docker/src/acceptance.yml
  • [docs-only]Replace docker inbucket with mailpit #11050
• Remove tag @notification from unrelated scenarios/feature [tests-only][full-ci]Remove notification and email tag from unrelated scenario #11045

[amrita-shrestha]

@saw-jan I choose mailpit over maildev because mailpit has advance search feature and lot of message parsing options. Other feature like list, delete all mail looks same for me.

[nirajacharya2]

MailPit looks like a better alternative to me too.

[nirajacharya2]

But this could be done in a later date we could just use the @notification tag for now. We shouldn't block the notification tests. Also if you see any test that should have the notification tag please mention them in the issue.

[saw-jan]

I don't think it requires big refactoring. So, we can work on this side by side with other notification tests

[phil-davis]

Note: mailhog/MailHog#442 (comment)

We used Mailhog some years ago, and replaced it with Inbucket owncloud/core#40442

Mailhog is no longer maintained, but "Mailpit was originally inspired by MailHog". And other projects have switched from Mailhog to Mailpit. So that makes me think that switching now from Inbucket to Mailpit should be "easy".

[saw-jan]

• deployment still uses inbucket

@kobergj @2403905 do we want to change mail server used in the deployment examples? we just switched to mailpit for the tests as it provides APIs that are useful for mail cleanup.

[nirajacharya2]

• deployment still uses inbucket

do we want to change mail server used in the deployment examples? we just switched to mailpit for the tests as it provides APIs that are useful for mail cleanup.

yes, we can for being consistent. got the confirmation form the dev team

[2403905]

• deployment still uses inbucket

@kobergj @2403905 do we want to change mail server used in the deployment examples? we just switched to mailpit for the tests as it provides APIs that are useful for mail cleanup.

I'm okay with swapping the inbucket for mailpit. The only question to @kobergj @mmattel should we do it after 7.1 release?

[mmattel]

I'm okay with swapping the inbucket for mailpit. The only question to @kobergj @mmattel should we do it after 7.1 release?

Technically there is no "hard" requirement for "bundling" this with the 7.1 release though having it in place with 7.1 would be good. We can:

• change this in master only which is then also reflected in the docs next (master) version. With the upcoming major/minor release this would be part of production
• do the change in master and backport it to 7.1, a kind of "silent" upgrade

I am fine with both.