User Self-Service Access to Piler Email Archives

Feature
,
1

Background

Currently, ns8-piler lacks a way for users to access their own archived emails. @pagaille PR #77 enables persistent custom configuration for config-site.php, allowing administrators to configure IMAP or LDAP authentication for user self-service access.

According to Piler documentation, regular users should authenticate via external sources (IMAP, LDAP, AD) rather than the local database, which is reserved for special accounts like admin@local.

The Need

Enable users to:

  • Log into Piler with their email credentials

  • View their own archived emails without administrator intervention

Known Limitation

IMAP authentication only shows emails for the exact login address, not aliases.

Example: User john@example.com with alias support@example.com won’t see emails sent to the alias, even though he receives them.

Proposed Solution

  1. Short term: Accept PR #77 to enable IMAP authentication (easier to implement)

  2. Document the alias limitation clearly

  3. Long term: Consider a Mailcow-style integration (like this Piler fork) that queries the mail server API to include aliases

References

This would enable user self-service access to email archives while being transparent about the current limitations. we could also implement a toggle in the UI

cc @davidep

5 Likes
Not a bug report this time — I need you
2

It’s a nice idea that we haven’t implemented yet for the reasons above. Focusing on the long-term goal makes more sense to me.

1 Like
3

In this case, we need to make the mail server’s list-addresses action accessible from within the Piler container—most likely via a GET endpoint. Definitely a bit of a challenge :wink:

this is the intégration of the work

cat >> $etcPth/config-site.php <<EOF

// ### Begin added by Piler-Installer ###
// Mailcow API
$config[‘MAILCOW_API_KEY’] = ‘$MAILCOW_APIKEY’;
$config[‘MAILCOW_SET_REALNAME’] = true;
$config[‘CUSTOM_EMAIL_QUERY_FUNCTION’] = ‘query_mailcow_for_email_access’;
$config[‘MAILCOW_HOST’] = ‘$MAILCOW_HOST’; // default $config[‘IMAP_HOST’]
include(‘auth-mailcow.php’);
// ### end added by Piler-Installer ###
EOF

then add the phpfile.php

4

Aliases are both in Mail’s SQLite DB and LDAP (soon). Piler should get aliases from multiple sources. Is it possible?

1 Like
5

it seems it is the key, we could make a php script to query a ldap

this is the function mailpiler-mailcow-integration/auth-mailcow.php at b7156ad1ba14fc5c1090d9b1572a8ea35062a209 · patschi/mailpiler-mailcow-integration · GitHub

however the code is broken for 1.4.8

6

Yes, I’d prefer LDAP: it’s easier to query LDAP from Piler than running an agent task.

On the Mail side we could keep LDAP attributes synchronized with the aliases DB, provided we give Mail the necessary write access.

Before diving in the code, please check and provide feedback for the LDAP schema support on AD and OpenLDAP.

1 Like
7

Hi @davidep,

I tested both providers on real NS8 instances. Here are the results:

OpenLDAP

The mail attribute from inetOrgPerson is multi-valued by schema definition — no SINGLE-VALUE constraint. Multiple aliases can be stored directly on the user entry. No schema change needed.

Samba AD

mail is SINGLE-VALUE in AD schema — confirmed, ldbmodify rejects a second value. The right attribute is proxyAddresses, which is multi-valued and already part of the standard Samba schema. I tested it successfully:

proxyAddresses: SMTP:stephane@domain.com   ← primary
proxyAddresses: smtp:support@domain.com    ← alias

Next step

The question is whether ns8-mail should write these attributes directly via ldbmodify/ldapmodify, or if ns8-samba/ns8-openldap should expose a dedicated action for alias sync. What’s your preference?

How it would work end to end

1. User creates an alias in NS8 Mail UI

Admin adds support@domain.com → stephane in the Mail module. At this point, ns8-mail saves it internally as today, but also triggers a write to the account provider:

  • OpenLDAP: adds mail: support@domain.com to stephane’s entry

  • Samba AD: adds proxyAddresses: smtp:support@domain.com to stephane’s entry

2. Stephane logs into Piler

Piler authenticates him via LDAP with stephane@domain.com. Login succeeds.

3. Piler calls CUSTOM_EMAIL_QUERY_FUNCTION

Instead of just showing emails for stephane@domain.com, Piler calls our custom PHP function with the authenticated address. The function queries LDAP:

  • OpenLDAP: ldapsearch ... "(mail=stephane@domain.com)" mail → returns all mail values

  • Samba AD: ldapsearch ... "(mail=stephane@domain.com)" proxyAddresses → returns all proxyAddresses values, strips smtp: prefix

4. Piler shows everything

The function returns [stephane@domain.com, support@domain.com] to Piler. Stephane now sees archived emails sent to both addresses.

3 Likes
8

Great, guys, and thanks !

9

Is there any alternative to mail for OpenLDAP, like proxyAddresses for AD? Since the mail attribute should be user-modifiable from the user portal UI, I’d prefer to keep Mail-handled aliases in separate attributes.

Futhermore, mail could be an external mail address, like user’s home address e.g. user@gmail.com. It is important to have a separate attribute also for self-service password change and SSO validation workflows.

1 Like
10

There is no suitable standard attribute available in the loaded schemas (core, cosine, nis, inetorgperson) to store mail aliases separately from mail. The only real alternative would be labeledURI, but it’s semantically wrong.

The clean solution is to add a custom nethserverMailAlias attribute to the existing nethserver schema that ns8-openldap already ships. This requires:

Adding nethserver.ldif to server/usr/local/lib/templates/ in ns8-openldap
Including it in config.ldif

This gives a clean symmetric design with Samba AD’s proxyAddresses, keeps mail untouched for its original purpose, and the nethserverMailObject AUXILIARY class means zero impact on users without aliases.

11

please finish your PR, we will see where we go

12

Should I propose something for the documentation ? As you know I’m often annoyed by the fact that the documentation is scattered between the official doc and the GitHub readmes :slight_smile:

13

hello

I would prefer it stays under the readme, this kind of instruction is never exposed I think in the admin manual