Cloud-Integration Seafile

heiko.sass · August 24, 2026, 8:40am

Native Seafile Cloud Attachment Integration for eM Client

Document version: 1.0
Date: 23 August 2026
Target product: eM Client desktop
Reference environment: eM Client 10.4.5642, build 2a058e0
Requested provider: Seafile Server (self-hosted and hosted deployments)

1. Purpose

This document requests a native Seafile cloud attachment provider in eM Client. The integration should allow users to upload email attachments to Seafile and send controlled share links instead of embedding the complete files in an email.

The expected user experience and feature level should be comparable to the existing native Nextcloud and ownCloud cloud attachment integrations in eM Client.

The primary business goals are:

reduce message size and mail server storage consumption;
enable secure delivery of large files;
retain control over files after an email has been sent;
support self-hosted, privacy-oriented cloud infrastructure;
provide a consistent cloud attachment workflow inside the eM Client composer;
avoid separate upload tools and manual copying of links.

2. Scope

The requested integration covers:

configuration of one or more Seafile accounts;
selection and upload of local files to Seafile;
use of files located in a locally synchronized Seafile library;
creation of Seafile share links;
configuration of link expiration, password and permissions;
insertion and native representation of cloud attachments in an email;
management or revocation of links created through eM Client, where supported by the Seafile API.

The request does not require eM Client to implement Seafile synchronization. Synchronization remains the responsibility of the official Seafile Sync Client or SeaDrive Client.

3. Stakeholders and Actors

3.1 Primary user

An eM Client user who has access to a Seafile server and wants to send files as cloud links.

3.2 Recipient

An email recipient who may or may not use eM Client and may not have a Seafile account.

3.3 Administrator

An organization administrator who operates eM Client and/or a Seafile server and defines security policies, default expiration periods and permitted sharing options.

4. Functional Requirements

FR-01: Provider configuration

eM Client shall list Seafile as a cloud attachment provider under the existing cloud attachment settings.

The account configuration shall support:

a configurable HTTPS server base URL;
authentication using a Seafile account token;
authentication using a repository token for restricted deployments;
multiple Seafile accounts or server instances;
connection testing and meaningful validation errors;
selection of a default library and target directory;
removal and reauthentication of an account.

The implementation should support both authentication header formats used by deployed Seafile versions:

Authorization: Bearer <token> for current versions;
Authorization: Token <token> for older versions.

FR-02: Library and directory selection

eM Client shall retrieve and display Seafile libraries accessible to the authenticated user.

The user shall be able to:

select an owned, shared, group or organization library, subject to permissions;
browse directories within a selected library;
select and persist a default upload directory;
recognize read-only locations before starting an upload;
create a target directory if supported and permitted.

FR-03: Upload a local attachment

When a user adds a local file to an email, eM Client shall offer the option to upload it to Seafile and attach it as a cloud link.

The workflow shall support:

one or multiple files;
upload progress per file and for the complete operation;
cancellation;
Unicode file names and paths;
large files without loading the complete file into memory;
file name conflicts through a configurable replace, rename or ask policy;
clear handling of quota and server upload limits;
partial success if one of several files fails.

The existing eM Client prompt for large physical attachments should also offer Seafile when Seafile is configured as the preferred cloud provider.

FR-04: Files from synchronized Seafile locations

When a user selects or drags a file from a locally synchronized Seafile library or SeaDrive location, eM Client should recognize the configured Seafile account and offer to send a share link rather than uploading a duplicate file.

If reliable path-to-library mapping cannot be obtained from the Seafile desktop client, eM Client may request the corresponding library and remote path from the user.

FR-05: Create a share link

After a successful upload, eM Client shall create a Seafile share link for the uploaded file.

The user shall be able to configure, subject to server policy:

no expiration or a specified expiration period;
a manually entered or securely generated password;
preview and download permission;
preview-only permission;
edit and download permission where supported by the server and file type.

eM Client shall respect Seafile server policies that enforce passwords, minimum password strength or minimum/default/maximum expiration periods.

FR-06: Native cloud attachment representation

The generated Seafile link shall appear in the eM Client attachment area as a native cloud attachment, including:

original file name;
file size where available;
Seafile provider identification;
upload or error status;
share-link expiration where available;
an indication that password protection is enabled, without exposing the password.

Recipients using other email clients shall receive a standards-compatible clickable link in the message body or MIME representation. The recipient shall not require eM Client.

FR-07: Link password handling

The share-link password shall not be included in the same email by default.

eM Client should offer:

copying the password separately;
displaying a recommendation to transmit it through another channel;
an explicit opt-in option to include it in the email;
secure generation of a policy-compliant password.

The password shall not be written to diagnostic logs or retained longer than required for the operation.

FR-08: Post-upload management

For links created through eM Client, the attachment context menu should provide the actions supported by Seafile:

open the public link;
copy the public link;
copy the password during the current composition session;
change expiration or permissions where supported;
revoke the share link;
open the file or its parent directory in Seafile;
retry link creation if upload succeeded but sharing failed.

A destructive action such as revoking a link shall require confirmation.

FR-09: Error handling and recovery

The integration shall provide actionable messages for at least:

invalid or expired credentials;
insufficient library or directory permissions;
unreachable server and TLS validation errors;
upload size and quota limits;
duplicate file conflicts;
unsupported share options caused by server policy or edition;
expired one-time upload URLs;
upload success followed by share-link creation failure;
rate limiting and temporary server errors.

The integration shall avoid duplicate uploads after an ambiguous network interruption by checking the target state before retrying where practical.

FR-10: Administrative defaults

Where eM Client provides administrative configuration or policy templates, administrators should be able to define:

permitted Seafile server URLs;
a default server, library and directory;
default expiration period;
whether a password is required;
default link permission;
whether public links without expiration are permitted;
whether automatic detection of synchronized locations is enabled.

5. Non-Functional Requirements

NFR-01: Security

Only HTTPS shall be accepted for non-local Seafile servers.
Normal operating-system certificate validation shall remain enabled.
Internal certification authorities shall work through the operating-system trust store.
Tokens shall be stored using the existing secure credential mechanism of eM Client.
Tokens, link passwords and upload URLs containing temporary credentials shall be excluded from logs and crash reports.
Repository tokens with limited permissions should be supported to enable least-privilege deployments.
Redirects returned during upload shall not forward authorization credentials to an unrelated host.

NFR-02: Performance

File content shall be streamed from disk.
The integration shall not buffer a complete large attachment in memory.
The UI shall remain responsive during upload and link creation.
Multiple attachments may be processed sequentially or with bounded concurrency.
Rate limiting and Retry-After responses shall be respected.

NFR-03: Compatibility

The provider shall work with self-hosted Seafile installations whose Web API supports the required endpoints.
Server capability detection shall be preferred over assumptions based solely on an edition or version string.
Differences between legacy Token and current Bearer authentication shall be handled.
File names containing spaces, umlauts, non-Latin scripts and emoji shall be supported.

NFR-04: Accessibility and localization

All configuration, progress, error and share-option controls shall use existing eM Client accessibility and localization mechanisms.

NFR-05: Maintainability

The Seafile implementation should use eM Client’s existing cloud attachment provider abstraction. Provider-specific API data shall be isolated from general message composition and attachment logic.

6. Recommended User Flows

6.1 Upload an existing local attachment

The user adds one or more files to a message.
The user selects Upload to cloud storage → Seafile, or Seafile is chosen automatically as the preferred provider.
eM Client displays the default library, destination and sharing options.
The user confirms the operation.
eM Client uploads each file and creates a share link.
Each file is replaced by a native Seafile cloud attachment.
The message can be sent while the attachment representation remains understandable to non-eM Client recipients.

6.2 Select a file from a synchronized Seafile library

The user selects or drags a file from a recognized Seafile location.
eM Client asks whether to attach the file physically or use a Seafile link.
eM Client identifies the remote file or asks for its library/path mapping.
eM Client creates the share link without uploading a duplicate.
The file appears as a native Seafile cloud attachment.

6.3 Recover from partial failure

The file upload completes successfully.
Share-link creation fails.
eM Client retains the known remote file location.
The user can retry link creation without uploading the file again.
Alternatively, the user can open the file in Seafile or remove the incomplete attachment entry.

7. Seafile Technical Prerequisites

Seafile already provides the primary server-side functions required for a fast integration. No WebDAV emulation of Nextcloud is required or recommended. The native Seafile Web API should be used.

7.1 Required server capabilities

The Seafile server must provide:

a valid HTTPS endpoint;
Seafile Web API access;
an account token or repository token with the required permissions;
access to at least one writable library;
file upload support for that library;
public share-link creation enabled by server policy;
correct external server URLs when operating behind a reverse proxy.

7.2 Minimal API sequence

A basic upload-and-share workflow can be implemented with a small number of API calls.

List accessible libraries

GET /api2/repos/
Authorization: Bearer <account-token>

Depending on the deployment, the type query parameter can be used for owned, shared, group or organization libraries.

Browse a directory

GET /api2/repos/{repo_id}/dir/?p=/TargetDirectory
Authorization: Bearer <account-token>

Request an upload URL

GET /api2/repos/{repo_id}/upload-link/?p=/TargetDirectory
Authorization: Bearer <account-token>

The returned upload URL shall be treated as opaque. eM Client should not construct or modify its host or token components.

Upload a file

POST {upload_url}?ret-json=1
Content-Type: multipart/form-data

file=<binary stream>
parent_dir=/TargetDirectory
replace=0|1
last_modify=<optional timestamp>

The upload body can be streamed. The JSON response provides uploaded file information such as name, object ID and size.

Create a share link

POST /api/v2.1/share-links/
Authorization: Bearer <account-token>
Content-Type: application/json

{
  "repo_id": "<library-id>",
  "path": "/TargetDirectory/File.ext",
  "password": "<optional-password>",
  "expire_days": "7",
  "permissions": {
    "<capability-specific fields>": "<values>"
  }
}

For repository-token deployments, Seafile provides corresponding via-repo-token endpoints for upload-link and share-link operations.

7.3 Capability discovery and version differences

For rapid and robust implementation, eM Client should:

detect whether Bearer or legacy Token authorization is accepted;
query accessible libraries rather than assuming one fixed repository;
treat the upload URL as an opaque server response;
determine supported share permissions from server behavior or documented capability information;
tolerate deployments where password or expiration is mandatory;
handle server-defined minimum, default and maximum expiration periods;
avoid relying on WebDAV for public-link operations, because Seafile sharing uses a separate API;
use contract tests against at least one current Seafile Community Edition and one supported Professional Edition deployment.

7.4 Recommended Seafile-side preparation

To shorten development and testing, a Seafile administrator or Seafile Ltd. can provide eM Client with:

A dedicated HTTPS test server.
A non-administrative test account.
A writable, non-encrypted test library.
An account token and, separately, a write-enabled repository token.
Server policy examples for optional and mandatory link passwords.
Test cases for no expiration and bounded expiration.
Confirmation of the exact permissions request and response schema for supported server versions.
Confirmation of the endpoints for updating and revoking share links.
Representative test files including large files and Unicode names.
Contact with a Seafile API maintainer for interoperability questions.

These preparations should allow eM Client to reuse its existing cloud attachment workflow and limit provider-specific implementation primarily to authentication, library browsing, upload and share-link management.

8. Acceptance Criteria

The integration shall be considered functionally complete when all of the following are demonstrated:

A user can configure and test a Seafile account in eM Client.
eM Client lists accessible writable libraries and allows a destination to be selected.
A local file can be uploaded without loading the complete file into memory.
A Seafile share link is created with optional password and expiration.
The file appears as a native Seafile cloud attachment in the composer.
A recipient using a different email client receives a working clickable link.
Multiple files display correct progress and partial failures.
Cancellation leaves eM Client in a consistent state.
A successful upload is not repeated merely because share-link creation failed.
A link created by eM Client can be opened, copied and revoked where the API permits it.
Credentials, passwords and temporary upload URLs do not appear in logs.
The workflow works against the agreed Community and Professional Edition test deployments.
The integration supports eM Client’s established cloud attachment behavior for large files and preferred providers.

9. Suggested Delivery Approach

Phase 1: API proof of concept

authenticate;
list libraries;
upload one file;
create and revoke one share link;
validate current and legacy authentication schemes;
confirm permission payloads with Seafile.

Phase 2: Existing cloud-provider adapter

implement the Seafile provider behind eM Client’s existing cloud attachment interface;
connect configuration, upload progress and error mapping;
render the native cloud attachment entry.

Phase 3: Full provider behavior

multiple files;
password, expiration and permission management;
link update and revocation;
synchronized-location recognition;
administrative defaults and localization.

Phase 4: Compatibility validation

current Seafile Community Edition;
supported Seafile Professional Edition;
reverse-proxy and internal-CA deployments;
large files, Unicode paths and interrupted network conditions.

10. Reference Documentation

11. Requested Response from eM Client

To continue planning, please advise:

Whether Seafile can be added to the native cloud attachment provider roadmap.
Whether eM Client has an internal provider interface that already covers upload, link creation, expiration, password and revocation.
Which technical or commercial information is required from Seafile Ltd. or a customer sponsor.
Whether an implementation can be contributed, jointly developed or delivered through a future public provider/plugin SDK.
Which eM Client desktop versions would be considered for the integration.

Olivia_Rust · August 24, 2026, 8:44am

We do not currently support Seafile or custom cloud storage setup, but I recommend adding your vote (and optionally comment, if you for example want to link back to this forum post) to the idea on our Sleekplan:

This helps our developers prioritize improvements for future updates.