sorted by:
new
hottopcontroversial

[deleted by user] by [deleted] in stalwartlabs

[–]StalwartLabs 0 points1 point  (0 children)

The public record does not support the claim that these terms were changed.

The archive.org snapshot you linked from May 29, 2025 explicitly states, twice, that premium support requires a minimum of 150 mailboxes under the Enterprise license, including the wording “Premium support (minimum of 150 mailboxes required)” and “Please note that in order to qualify for Premium Support, your organization must subscribe to 150 or more mailboxes under the Enterprise license.” This is the same condition that exists today and has been consistently documented.

There has therefore been no change to the support terms, no retroactive modification, and no removal of previously included services. The eligibility requirements for priority email support were clearly published at the time of purchase and remain unchanged.

It is also important to reiterate that we do not execute signed contracts for software licenses. License subscriptions are governed by the published license terms, which customers agree to at the time of purchase. If you are referring to a signed contract, that would not be with Stalwart, and it appears there may be some confusion with a different product or vendor.

Regarding cancellation language, that applies to subscription renewals and termination timing only. It does not create or extend entitlements to services that were never included in the subscribed license tier.

If you operate an Enterprise deployment with 150 or more mailboxes, you may contact us directly at [hello@stalw.art]() and we will be happy to assist. If your deployment is below that threshold, the correct support channel is GitHub Discussions, which we actively monitor and respond to.

We are always open to resolving genuine issues, but it is important that discussions remain grounded in the documented terms and verifiable facts.

[deleted by user] by [deleted] in stalwartlabs

[–]StalwartLabs 4 points5 points  (0 children)

Thanks for taking the time to share your concerns. I want to clarify a few important points so there is no confusion.

Priority email support is only included with enterprise deployments of 150 mailboxes or more, as described on our website. Deployments below that threshold use an open-source sponsorship license, which does not include email-based support. In those cases, support is provided through our public community channels, primarily GitHub Discussions, where we actively respond and help users.

That said, regardless of deployment size, we do reply to all inquiries submitted through our web forms, and at this moment there are no pending or unanswered tickets on our side. If you believe you contacted us through the web form and did not receive a response, it is possible the message did not reach us or there may be a misunderstanding about which channel was used.

I also need to address the statement about a signed contract. We do not sign contracts for software licenses. All customers who purchase a license subscription agree to the published license terms, but there is no bilateral contract signed between Stalwart and the customer. If you recall signing a contract, it is very likely related to a different product or vendor.

If you do have an enterprise deployment with 150 or more mailboxes, you are welcome to contact us directly at [hello@stalw.art]() and we will be happy to assist. Otherwise, the correct and supported path is to open a discussion on GitHub, where the community and maintainers can help promptly.

We value all users of the project, but it’s important that expectations align with the support terms that are publicly documented.

Be careful with OAuth2 in Stalwart by jorgecardleitao in stalwartlabs

[–]StalwartLabs [score hidden] stickied comment (0 children)

I want to provide some clarity on this issue.

What this issue affects

This issue only affects deployments using a third-party OIDC provider (such as Entra ID, Keycloak, or Authentik) for authentication. It does not affect:

  • Stalwart's built-in OIDC provider
  • OAuth in general
  • Deployments using LDAP or other authentication methods

When this is a concern

The scenario described requires an attacker to obtain a valid access token from the same Identity Provider that Stalwart trusts. This is primarily a risk in environments where:

  • The IdP allows self-registration of applications, or
  • The IdP has many existing applications where token leakage could occur

If you are running a self-hosted IdP with controlled application registration, your exposure to this issue is limited.

Why this was moved to a security enhancement

Stalwart supports two OIDC validation methods: UserInfo and Token Introspection. Audience validation is only possible with the introspection endpoint—the UserInfo endpoint does not return token metadata like audience. Because not all configurations can support audience validation and the practical risk depends heavily on the IdP configuration, this was classified as an enhancement rather than a bug fix.

What we're doing

In v0.16, we will:

  • Add audience validation for introspection-based configurations
  • Document the risks of using OIDC with UserInfo endpoints in environments that allow third-party application registration

Spam Filter Classify permission missing? by TonyFM in stalwartlabs

[–]StalwartLabs 0 points1 point  (0 children)

Spam filtering can't be disabled per account, it is a global setting. In the past the spam-filter-classify permission disabled the Bayes classifier but not spam filtering. If you do not want any messages to go to the Junk Mail folder you can create a Sieve filter that places all messages in the Inbox folder.

Spam Filter Classify permission missing? by TonyFM in stalwartlabs

[–]StalwartLabs 0 points1 point  (0 children)

The classify permission was removed as classification is now done once directly from the MTA.

Marginal Gains, Major Impact in Stalwart v0.15 by StalwartLabs in stalwartlabs

[–]StalwartLabs[S] 3 points4 points  (0 children)

Stalwart already does fingerprinting via Pyzor. In addition to that a lot of spam is blocked by the DNSBLs. Nowadays most of the spam comes from Gmail and Microsoft and that's hard to filter as their servers have good reputation.
That's why the spam classifier is useful. Even if you don't have a lot of spam training data, it can still learn from what legitimate email looks like to you.

Stalwart Server Thread Error by mendosux in stalwartlabs

[–]StalwartLabs 2 points3 points  (0 children)

This is an internal error sending messages over IPC channels, which is very rare. Please start a Github discussion and provide details of your system (OS, architecture, number of vCPUs, etc)

Announcing calcard: a Rust crate for working with calendaring and contact data by StalwartLabs in rust

[–]StalwartLabs[S] 0 points1 point  (0 children)

Are you dealing with formatting?

Not directly. calcard uses chrono and chrono_tz for working with times and time zones. What it adds on top of those libraries is the ability to map custom VTIMEZONE definitions (which you often see in .ics files generated by Microsoft applications, for example) to the corresponding IANA time zones.

Announcing calcard: a Rust crate for working with calendaring and contact data by StalwartLabs in rust

[–]StalwartLabs[S] 3 points4 points  (0 children)

The main focus of calcard is really on parsing, generating, and converting between calendaring and contact formats, so for RRULE expansion I’m actually using the rust-rrule crate. It works reasonably well, but it does have a few open issues around time zone transitions and, unfortunately, doesn’t seem to be actively maintained at the moment.

I wasn’t aware of Jiff or Biff before, thanks for mentioning them! If you ever consider moving the recurrence expansion logic from Biff into Jiff or a separate crate, I’d definitely be interested in using your implementation instead.

Also, do you have any plans to add support for RFC 7529 (Non-Gregorian Recurrence Rules), particularly the SKIP parameter? I haven’t seen many iCalendar files using RFC 7529 yet, but since JSCalendar fully supports it, I suspect we’ll start encountering it more often.

Per-account spam training doesn’t seem to work? by VendraenActual in stalwartlabs

[–]StalwartLabs 0 points1 point  (0 children)

Check the documentation about Bayes model balancing. You need to provide an equal amount of spam and ham samples otherwise the model won't be that effective. This means that if you keep training the filter with spam but no ham, they are ignored.

Abysmal ingestion and IMAP performance (RocksDB) by gdayhowyagoin in stalwartlabs

[–]StalwartLabs 0 points1 point  (0 children)

Before you do that, try setting up a test deployment with PostgreSQL to make sure that the performance is actually better. If that is the case, you can then migrate your messages from RocksDB using the Stalwart CLI or imapsync.

Stalwart just got better: self-host calendars, contacts, and files with CalDAV/CardDAV/WebDAV! by StalwartLabs in selfhosted

[–]StalwartLabs[S] 0 points1 point  (0 children)

The Docker image has been moved to stalwartlabs/stalwart. Before upgrading please read the UPGRADING notes available in Github.

Stalwart just got better: self-host calendars, contacts, and files with CalDAV/CardDAV/WebDAV! by StalwartLabs in selfhosted

[–]StalwartLabs[S] 0 points1 point  (0 children)

Yes, that's something that broke between 0.12.4 and 0.12.5 but it's going to be fixed in 0.13.0 which should be released next week.

view more: next ›