using Rebex.Net;

Rebex Buru SFTP Server 2.18.0: Post-quantum cryptography and SSH/SFTP core improvements

Lukas Paluzga — Tue, 03 Mar 2026 00:00:00 GMT

We have released Rebex Buru SFTP Server v2.18.0. Here is an overview of changes, fixes and improvements.

Post-quantum key exchange ciphers (2.18.0)

Quantum computers, once sufficiently powerful, might be able to break classical public-key cryptography such as RSA and elliptic-curve Diffie-Hellman. While large-scale quantum computers don't exist yet, encrypted data captured today could be decrypted in the future — a threat known as "harvest now, decrypt later".

To address this, Buru SFTP Server 2.18.0 adds support for NIST-standardized post-quantum key exchange based on ML-KEM (CRYSTALS-Kyber), used in a hybrid construction alongside classical algorithms. This means the key exchange is secure against both classical and quantum attacks:

mlkem768x25519-sha256 — ML-KEM-768 combined with X25519
mlkem768nistp256-sha256 — ML-KEM-768 combined with NIST P-256
mlkem1024nistp384-sha384 — ML-KEM-1024 combined with NIST P-384

These algorithms are already supported by OpenSSH 9.0+ and other modern SSH clients. See the full list of supported SSH algorithms.

SSH/SFTP core overhaul (2.18.0)

The SSH and SFTP processing core has been significantly redesigned to improve performance and reduce memory and thread usage. These improvements are most noticeable when serving many simultaneous connections.

Elliptic curve algorithm performance has also been improved on modern platforms.

Additional key exchange algorithms (2.18.0)

Two additional Diffie-Hellman key exchange algorithms are now supported, offering stronger security:

diffie-hellman-group17-sha512
diffie-hellman-group18-sha512

See the full list of supported SSH algorithms.

`copy-data` SFTP extension (2.18.0)

Buru SFTP Server now supports the copy-data SFTP extension, which allows clients to request server-side file copies without transferring data over the network. This results in significantly faster copy operations, especially for large files.

Minor changes and fixes

SSH
- Improved compatibility with some SSH clients that are sensitive to the order of SSH shell channel messages. (2.18.1)
FTP
- Fixed behavior of ftp.bindings[].externalAddress and ftp.bindings[].dataPortRange in FTPS implicit mode. (2.18.2)
Installer
- Now checks for a valid license before overwriting the existing installation when upgrading. (2.18.0)
- Silent uninstallation (/SILENT) no longer prompts for confirmation and deletes all configuration files. (2.17.3)
Web Admin
- Log viewer now shows the last 50 kB of the log file, with an option to view or download the full file. (2.18.3)
- Fixed 2FA status not being indicated correctly for some users. (2.18.0)
- Fixed an error when saving a user with an SSH public key. (2.17.2)
- Fixed an incorrect warning message "The WebRootPath was not found". (2.17.3)
- Log viewer is now accessible even when the configuration file is invalid but readable. (2.17.3)
- User's virtual path can now be specified without a leading slash. (2.17.3)
- Improved readability of users' public keys. (2.17.3)
Other
- Fixed LiteDB database locking error. (2.18.3)
- Fixed startup error when sshTunneling is present but disabled in the configuration file. (2.17.1)
- User authentication method is now logged at information level (previously debug). (2.17.3)
- Added an error log message when the service starts under the SYSTEM account with defaultShellType: terminal and allowSystemAccount not enabled. (2.17.3)

For a complete list of fixes and improvements, see the Release notes.

You can report issues and submit feature requests on our Github issue tracker.

For discussions and specific problems, please continue using our support forum.

Rebex .NET components 7.0.9448: Support for .NET 10

Lukas Pokorny — Tue, 18 Nov 2025 00:00:00 GMT

Support for .NET 10

This release adds a new set of binaries targeting .NET 10. The following platforms are supported:

Windows (x64, x86, ARM64)
Linux (x64, ARM32, ARM64)
Android (x64, ARM32, ARM64)
macOS (ARM64, x64)
iOS/iPadOS/tvOS (ARM64)

Of course, we still support earlier versions of .NET as well, including .NET Framework 3.5-4.8.1 and .NET 8-9. Additionally, support for .NET Compact Framework 3.5/3.9 and .NET Framework 2.0 is still available with Legacy Edition. For more information about supported platforms, see our framework support chart.

Support for Visual Studio 2026

In addition to Visual Studio 2022 and 2019, Rebex libraries and samples support the latest Visual Studio 2026.

And more...

For a detailed list of changes, see the release history.

Migrating from EWS to Microsoft Graph

Lukas Matyska — Tue, 23 Sep 2025 00:00:00 GMT

Microsoft will retire Exchange Web Services (EWS) in Exchange Online on October 1, 2026. The recommended way to access Exchange Online (Microsoft 365) going forward is via the Microsoft Graph API. This guide describes how to migrate from EWS to Microsoft Graph in order to access Exchange Online, and demonstrates how the same mailbox operations can be performed using Rebex EWS and Rebex Graph libraries for .NET.

Working directly with Microsoft Graph API means dealing with raw HTTP requests and handling many low-level details of the REST protocol. Rebex Graph provides a high-level API for accessing Exchange Online via Graph - without requiring deep knowledge of the protocol itself.

Key advantages of using Rebex Graph library:

A developer-friendly easy-to-use API that abstracts away the complexity of raw Graph requests.
Built-in S/MIME support, including parsing and working with signed or encrypted messages.
Automatic handling of throttling responses (HTTP 429/503/504 error codes) with retries logic.
Wide platform support, including .NET 5-10, .NET Framework 3.5-4.8 on Windows 7/8/10/11
(even .NET Compact Framework 3.5-3.9 is still supported).

Note: Microsoft Graph does not offer full feature parity with EWS. Some advanced or specialized operations may not yet be available or may require workarounds.

Configuring Graph access to Exchange Online
Migrating to Graph

Configuring Graph access to Exchange Online

Migrating from EWS to Microsoft Graph is not just a matter of switching API calls — it also requires updates to your authentication and permission setup. In this section, we'll highlight two essential changes you need to make before your application can access Exchange Online via Graph.

Changing application permissions

To access Exchange Online, your application needs to obtain an OAuth 2.0 token. Since Microsoft started disabling Basic Authentication for Exchange Online in October 2022, your app should already be registered in Azure Portal using an App Registration.

To switch to Microsoft Graph, you must configure new Graph-specific permissions in the Azure Portal based on your application's functionality. Here are some commonly used permissions when working with emails:

Mail.Read - read mailbox contents
Mail.ReadWrite - full read/write access to mailbox
Mail.Send - send mail as a user

Depending on you application type choose either Delegated or Application permission type.

Example of permission changes for an application operating in delegated (signed-in user) mode:

Previous EWS permissions:

New Graph permissions:

Example of permission changes for an application operating in unattended (application) mode:

Previous EWS permissions:

New Graph permissions:

If you prefer to configure new Azure App Registration from start, you can follow our blog posts to configure Graph access in delegated (signed-in user) mode or unattended (application) mode.

Changing OAuth scopes

When moving from EWS to Microsoft Graph, you also need to update the OAuth scope used for token requests.

Previous EWS scopes: commonly include either https://outlook.office365.com/.default or https://outlook.office365.com/EWS.AccessAsUser.All

New Graph scopes: the simplest option is to use https://graph.microsoft.com/.default - this instructs the Microsoft identity platform to issue a token based on the permissions configured in the App Registration. Alternatively, you can explicitly request only a subset of those permissions using scopes such as:

https://graph.microsoft.com/Mail.Read
https://graph.microsoft.com/Mail.ReadWrite
https://graph.microsoft.com/Mail.Send

Find more about scopes and permissions in the Microsoft identity platform.

Sample applications

To verify that your configuration works, you can use our sample applications available on GitHub.

To test access in delegated (signed-in user) mode, use the GraphOAuthWpfApp sample.
To test access in unattended (application) mode, use the GraphOAuthAppOnlyConsole sample.

Migrating to Graph

In this section, we’ll demonstrate how common mailbox operations were implemented using Rebex EWS and how they can be implemented using Rebex Graph.

Connecting and authenticating to Exchange Online

With Rebex EWS, connecting and authenticating looks like this:

// create EWS client instance
var client = new Rebex.Net.Ews();

// connect and authenticate to Exchange Online server
client.Connect("outlook.office365.com");
client.Login(token, EwsAuthentication.OAuth20);

With Rebex Graph, the code for connecting and authenticating looks similar:

// create Graph client instance
var client = new Rebex.Net.GraphClient();

// connect and authenticate to Exchange Online server
client.Connect();
client.Login(token);

In EWS SOAP API, client connects to https://outlook.office365.com/EWS/Exchange.asmx.
In Graph REST API, all requests go to https://graph.microsoft.com/.

In both cases, client authenticates using the Authorization header with a Bearer token.

Note: EWS supports both on-premises Exchange servers and Exchange Online, whereas Microsoft Graph is available exclusively for Exchange Online.
Note: EWS supports various authentication methods, including Basic Auth, NTLM, and Kerberos, whereas Microsoft Graph relies exclusively on OAuth 2.0.

Listing Inbox messages

With Rebex EWS, listing messages looks like this:

// create, connect and authenticate EWS client instance
var client = new Rebex.Net.Ews();
client.Connect("outlook.office365.com");
client.Login(token, EwsAuthentication.OAuth20);

var messages = client.GetMessageList(EwsFolderId.Inbox);

With Rebex Graph, the code for listing messages looks similar:

// create, connect and authenticate Graph client instance
var client = new Rebex.Net.GraphClient();
client.Connect();
client.Login(token);

var messages = client.GetMessageList(GraphFolderId.Inbox);

In EWS SOAP API, messages were listed using the FindItems operation.
In Graph REST API, messages from the Inbox are retrieved by requesting:

GET https://graph.microsoft.com/v1.0/me/mailFolders/inbox/messages

For details, see List messages in the Microsoft documentation.

Searching for messages

Microsoft Graph API provides two kinds of searching: $filter and full-text $search.

With Rebex EWS, the equivalent code for a $filter search and full-text $search (uses AQS search) looks like this:

// create, connect and authenticate EWS client instance
var client = new Rebex.Net.Ews();
client.Connect("outlook.office365.com");
client.Login(token, EwsAuthentication.OAuth20);

// perform EWS message search
var messages = client.Search(EwsFolderId.Inbox, EwsSearchParameter.Subject("invoice"));

// perform full-text AQS search
var fullText = client.Search(EwsFolderId.Inbox, EwsItemFields.Envelope, new EwsListView(), "subject:invoice");

With Rebex Graph, searching for messages looks like this:

// create, connect and authenticate Graph client instance
var client = new Rebex.Net.GraphClient();
client.Connect();
client.Login(token);

// perform the `$filter` search
var messages = client.Search("inbox", GraphMessageSearchParameter.Subject("invoice"));

// perform full-text `$search`
var query = new GraphMessageSearchQuery()
{
    RawSearch = "subject:invoice"
};
var fullText = client.Search("inbox", query);

In EWS SOAP API, messages were searched using the FindItems operation with search filters.
In Graph REST API, search can be performed using the $filter query parameter:

GET https://graph.microsoft.com/v1.0/me/messages?$filter=contains(subject,'invoice')

or the $search query parameter for full-text search:

GET https://graph.microsoft.com/v1.0/me/messages?$search="subject:invoice"

Note: Microsoft Graph $search works only for a limited set of message properties (approximately 15).
Note: Microsoft Graph cannot apply $filter to properties that are collections of complex objects (such as toRecipients, ccRecipients or bccRecipients). Use $search for filtering based on recipients instead.
Note: Microsoft Graph does not support combining $filter and $search in a single query, which makes it difficult to filter messages effectively - especially when filtering by recipients.
Note: Microsoft Graph imposes limitations on the use of the $orderby parameter. In some cases, this may result in the The restriction or sort order is too complex for this operation error. For details, see Using filter and orderby in the same query in the Microsoft documentation.

For details, see Filter and Search in the Microsoft documentation.

Downloading e-mail messages

With Rebex EWS, downloading messages looks like this:

// create, connect and authenticate EWS client instance
var client = new Rebex.Net.Ews();
client.Connect("outlook.office365.com");
client.Login(token, EwsAuthentication.OAuth20);

// get the message ID
EwsItemId messageId = ...

// download the message directly to a file on disk
client.GetMessage(messageId, "mail.eml");

// download the message and parse it for further processing
MailMessage message = client.GetMailMessage(messageId);

With Rebex Graph, the code for downloading messages looks similar:

// create, connect and authenticate Graph client instance
var client = new Rebex.Net.GraphClient();
client.Connect();
client.Login(token);

// get the message ID
GraphMessageId messageId = ...

// download the message directly to a file on disk
client.GetMessage(messageId, "mail.eml");

// download the message and parse it for further processing
MailMessage message = client.GetMailMessage(messageId);

In EWS SOAP API, a message was retrieved using the GetItem operation.
In Graph REST API, a message is retrieved by requesting its $value:

GET https://graph.microsoft.com/v1.0/me/messages/{messageId}/$value

For details, see Get message in the Microsoft documentation.

Sending messages

With Rebex EWS, sending messages looks like this:

// create, connect and authenticate EWS client instance
var client = new Rebex.Net.Ews();
client.Connect("outlook.office365.com");
client.Login(token, EwsAuthentication.OAuth20);

// compose message
MailMessage message = ...

// send the message
client.SendMessage(message);

With Rebex Graph, the code for sending messages looks similar:

// create, connect and authenticate Graph client instance
var client = new Rebex.Net.GraphClient();
client.Connect();
client.Login(token);

// compose message
var message = new MailMessage();
message.To = "to@example.com";
message.Subject = "Hello from Rebex Graph";
message.BodyHtml = "This message was sent using <b>Rebex Graph</b>";

// send the message
client.SendMessage(message);

In EWS SOAP API, the CreateItem operation with SendAndSaveCopy was used.
In Graph REST API, sending a message requires a POST request:

POST https://graph.microsoft.com/v1.0/me/sendMail

and setting desired Content-Type header and request body content.

Note: This operation requires Mail.Send permission to be configured in Azure App Registration.
Note: Microsoft occasionally changes the limits of Microsoft Graph API. In 2024, the size limit for a MIME message sent via sendMail was 3 MB. However, as of September 2025, we were able to successfully send a 45 MB message using sendMail (with default mailbox settings). The message size limits can be configured in the Microsoft 365 Exchange admin center (up to 150 MB).

For details, see Send mail in the Microsoft documentation.

Updating messages

With Rebex EWS, updating messages looks like this:

// create, connect and authenticate EWS client instance
var client = new Rebex.Net.Ews();
client.Connect("outlook.office365.com");
client.Login(token, EwsAuthentication.OAuth20);

// prepare message updates
var updates = new EwsMessageMetadata()
{
    Flag = new EwsFlag(EwsFlagStatus.Completed) { CompleteDate = DateTime.Today },
    Categories = new EwsCategoryCollection("Invoice", "Processed"),
    Importance = MailPriority.Low,
    IsRead = true,
};

// apply updates
client.UpdateItem(messageId, updates);

With Rebex Graph, the code for updating messages looks similar:

// create, connect and authenticate Graph client instance
var client = new Rebex.Net.GraphClient();
client.Connect();
client.Login(token);

// prepare message updates
var updates = new GraphMessageData()
{
    Flag = GraphFlag.CreateCompleted(DateTime.Today),
    Categories = new GraphCategoryCollection("Invoice", "Processed"),
    Importance = GraphImportance.Low,
    IsRead = true,
};

// apply updates
client.UpdateMessage(messageId, updates);

In EWS SOAP API, message updates were made using the UpdateItem operation.
In Graph REST API, messages are updated using a PATCH request:

PATCH https://graph.microsoft.com/v1.0/me/messages/{messageId}

and setting desired Content-Type header and request body content.

Note: This operation requires Mail.ReadWrite permission to be configured in Azure App Registration.
Note: The GraphClient.UpdateMessage() API will be available in upcoming 8.0 release (check-it out at NuGet.org as RC1).

For details, see Update message in the Microsoft documentation.

Deleting messages

With Rebex EWS, deleting messages looks like this:

// create, connect and authenticate EWS client instance
var client = new Rebex.Net.Ews();
client.Connect("outlook.office365.com");
client.Login(token, EwsAuthentication.OAuth20);

// get the message ID
EwsItemId messageId = ...

// delete message
client.DeleteItem(messageId, EwsDeleteMode.Permanent);

With Rebex Graph, the code for deleting messages looks similar:

// create, connect and authenticate Graph client instance
var client = new Rebex.Net.GraphClient();
client.Connect();
client.Login(token);

// get the message ID
GraphMessageId messageId = ...

// delete message
client.DeleteMessage(messageId, permanent: true);

In EWS SOAP API, the DeleteItem operation supported soft and hard deletes.
In Graph REST API, messages are soft-deleted using a DELETE request:

DELETE https://graph.microsoft.com/v1.0/me/messages/{messageId}

And hard-deleted using a POST request:

POST https://graph.microsoft.com/v1.0/me/messages/{messageId}/permanentDelete

Note: This operation requires Mail.ReadWrite permission to be configured in Azure App Registration.

For more details about soft-delete see Delete message and hard delete, see Permanent delete in the Microsoft documentation.

Listing folders

With Rebex EWS, listing folders looks like this:

// create, connect and authenticate EWS client instance
var client = new Rebex.Net.Ews();
client.Connect("outlook.office365.com");
client.Login(token, EwsAuthentication.OAuth20);

// list folders in the root folder
var rootFolders = client.GetFolderList();

// list folders in the 'Inbox' folder
var inboxFolders = client.GetFolderList(EwsFolderId.Inbox);

With Rebex Graph, the code for listing folders looks similar:

// create, connect and authenticate Graph client instance
var client = new Rebex.Net.GraphClient();
client.Connect();
client.Login(token);

// list folders in the root folder
var rootFolders = client.GetFolderList();

// list folders in the 'Inbox' folder
var inboxFolders = client.GetFolderList(GraphFolderId.Inbox);

In EWS SOAP API, listing folders was done using the FindFolder operation.
In Graph REST API, folders can be listed by requesting:

GET https://graph.microsoft.com/v1.0/me/mailFolders
or
GET https://graph.microsoft.com/v1.0/me/mailFolders/{folderId}/childFolders

For details, see List mail folders and List child folders in the Microsoft documentation.

Creating folders

With Rebex EWS, creating folders looks like this:

// create, connect and authenticate EWS client instance
var client = new Rebex.Net.Ews();
client.Connect("outlook.office365.com");
client.Login(token, EwsAuthentication.OAuth20);

// create new folder 'Orders' under 'Inbox'
EwsFolderId folderId = client.CreateFolder(EwsFolderId.Inbox, "Orders");

With Rebex Graph, the code for creating folders looks similar:

// create, connect and authenticate Graph client instance
var client = new Rebex.Net.GraphClient();
client.Connect();
client.Login(token);

// create new folder 'Orders' under 'Inbox'
GraphFolderInfo folder = client.CreateFolder(GraphFolderId.Inbox, "Orders");

In EWS SOAP API, folders were created using the CreateFolder operation.
In Graph REST API, folders can be created using POST request:

POST https://graph.microsoft.com/v1.0/me/mailFolders
or
POST https://graph.microsoft.com/v1.0/me/mailFolders/{folderId}/childFolders

and setting Content-Type: application/json header and request body content.

Note: This operation requires Mail.ReadWrite permission to be configured in Azure App Registration.

For details, see Create mail folder and Create child folder in the Microsoft documentation.

Deleting folders

With Rebex EWS, deleting folders looks like this:

// create, connect and authenticate EWS client instance
var client = new Rebex.Net.Ews();
client.Connect("outlook.office365.com");
client.Login(token, EwsAuthentication.OAuth20);

// get the folder ID
EwsFolderId folderId = ...

// delete folder
client.DeleteFolder(folderId);

With Rebex Graph, the code for deleting folders looks similar:

// create, connect and authenticate Graph client instance
var client = new Rebex.Net.GraphClient();
client.Connect();
client.Login(token);

// get the folder ID
GraphFolderId folderId = ...

// delete folder
client.DeleteFolder(folderId);

In EWS SOAP API, folders were deleted using the DeleteFolder operation.
In Graph REST API, folders can be deleted using DELETE request:

DELETE https://graph.microsoft.com/v1.0/me/mailFolders/{folderId}

Note: This operation requires Mail.ReadWrite permission to be configured in Azure App Registration.

For details, see Delete mail folder in the Microsoft documentation.

Rebex .NET components 7.0.9313: Maintenance release

Martin Vobr — Thu, 21 Aug 2025 00:00:00 GMT

Maintenance release

7.0.9313 is a hotfix release that resolves some minor issues and brings several improvements.

List of changes

SFTP: Added CurrentFileBytesTotal to TransferProgressChanged event arguments.
FTP: Added CurrentFileBytesTotal to TransferProgressChanged event arguments.
File System: Fixed possible ArgumentNullException when file system provider is used after an event handler is unregistered from file system notifier.
File System: Prevented internally handled NullReferenceException in implementation of VDirectory.Exists method.
Mail: Added IgnoreRedundantAsn1Data option to MailSettings/MimeOptions.
ZIP: Fixed missing logging for multi-file operations.
ZIP: Improved handling of 'version needed to extract' field to increase support for ZIP archives created on various platforms.
Networking: Prevented internal NullReferenceException when socket is closed and IO operation is in progress.
TLS Core: Fixed obfuscated type names in debug logs.
TLS Core: Fixed rare race condition between TLS 1.3 IO operations and shutdown/dispose logic.
Cryptography: Added IgnoreRedundantData option to SignedData and EnvelopedData classes.
Cryptography: Fixed NullReferenceException instead of InvalidOperationException in SignerInfo/KeyTransRecipientInfo and SignedData.

For complete version history, see the release history.

R6.18 available as well

For customers who have not yet upgraded to version 7 of Rebex libraries, we published the R6.18 update with important fixes and enhancements. Version R6.x will be supported until November 2025.

US court ruled: ComponentPro libraries stolen from Rebex

Martin Vobr — Thu, 22 May 2025 00:00:00 GMT

Using ComponentPro? We've got news that might affect your codebase. It was actually Rebex code – and we proved it in court.

ComponentPro has lost copyright infringement lawsuit because they were selling .NET components based on the code copied from our Rebex .NET libraries. Almost the same APIs, same internals – just rebranded and sold as their own. To hide the real authors, they changed the names of classes and some methods, but the vast majority of the code remains the same. We took them to court – and we won. Infringing company had to stop all business activities and Rebex acquired the ComponentPro.com domain.

What this means for you

If you bought any of the following ComponentPro products, you're using infringing software:

Ultimate Studio Suite
Network Expert Suite
FTP Expert Suite
Mail Expert Suite
FTP & FTPS
SFTP & SCP
Terminal Emulation
Mail Library
SFTP Server

A full breakdown of the case and affected libraries is available at www.componentpro.com

Here's the fix

If you bought from ComponentPro, you may not have known – but you're using code they had no right to sell. The code infringes on Rebex copyright.

We're not here to call you out – we're here to help.
We're offering a discounted upgrade to the official Rebex libraries.

Benefits of switching to the genuine version:

Latest updates, many improvements and security fixes
A real license that enables you to legally use the library
TLS 1.3 support, modern .NET compatibility
Direct support from the actual authors of the code

What to do

Just email us your original ComponentPro invoice. We'll handle the rest.
https://www.rebex.net/company/contact/

Let's get your codebase on solid ground – clean, legal, and supported.

Rebex .NET components 7.0.9209: Maintenance release

Lukas Pokorny — Wed, 23 Apr 2025 00:00:00 GMT

Support for RSA public key format from PKCS #1

SshPublicKey now supports the legacy RSA public key format specified by PKCS #1. This makes it possible to load keys that start with -----BEGIN RSA PUBLIC KEY----- header.

Improved error handling in multi-file operations

When information about a file or directory cannot be retrieved, a relevant exception with ProblemType property set to TransferProblemType.CannotRetrieveItemInfo is raised instead of an 'internal error'.

Improved IMAP folder info

HasChildren and HasNoChildren properties have been added to ImapFolder, representing \HasChildren and \HasNoChildren folder list attributes.

More fixes and improvements

For a detailed list of changes, see the release history.

Rebex Buru SFTP Server 2.17.0: SSH configuration improvements

Lukas Paluzga — Thu, 10 Apr 2025 00:00:00 GMT

We have released Rebex Buru SFTP Server v2.17.0. Here is an overview of changes, fixes and improvements.

SSH configuration improvements

SSH tunneling configuration changes (2.17.0)

SSH tunnels have been supported since early versions of Buru SFTP Server, however, without any Web Admin configuration and prone to endpoint conflicts.

We fixed the conflict issue and simplified the configuration by moving it from sshTunneling section to bindings section, on the same level as SFTP, SCP/Shell and FTP protocols:

# before
sshTunneling:
  enabled: true
  bindings:
    - { port: 22, ipAddress: 0.0.0.0 }

# after
bindings:
  - { port: 22, ipAddress: 0.0.0.0, sshTunnel: true, ... }

SSH tunneling can now be also enabled or disabled in the Web administration and is disabled by default.

Warning is shown on startup when sshTunneling section is present in the configuration file, its values are now ignored.

SSH shell configuration defaults now configurable using Web administration (2.17.0)

Default values for SSH shell home directory and SSH shell executable path are now configurable using Web administration. These values can be overridden per user.

Improved support for displaying user's public keys (2.17.0)

Based on a client's feedback, we improved the way user's public SSH keys can be displayed:

User's details in Web administration now show the user's public key with SSH algorithm prefix to make it easier to re-import to other applications, e.g. authorized_keys file.
Output of burusftp user inspect command now also contains full SSH public key, with SSH algorithm prefix.

Minor changes and fixes

Web Admin
- Fixed an issue when SSH shell settings were sometimes not editable (2.16.1)
Installer
- Fixed missing prompt to remove all configuration files when uninstalling. (2.16.1)

For a complete list of fixes and improvements, see the Release notes.

You can report issues and submit feature requests on our Github issue tracker.

For discussions and specific problems, please continue using our support forum.

Rebex Buru SFTP Server 2.16.0: Technological update

Lukas Paluzga — Fri, 31 Jan 2025 00:00:00 GMT

We have released Rebex Buru SFTP Server v2.16.0. Here is an overview of changes, fixes and improvements.

Technological Update

Buru SFTP Server is built on .NET platform, which provides the foundation for its security and reliability. With this release, we've made several key upgrades to ensure compatibility with the current .NET version and support long-term stability for our users.

In alignment with Microsoft's .NET lifecycle, we have transitioned Buru SFTP Server to .NET 8 (LTS), as .NET 6 support ended on November 12, 2024. You can read more about this change in the official .NET 6 support policy.

This transition enables us to continue delivering the latest .NET security updates to our users. However, it also means that Windows 7 and Windows 8 are no longer supported from this version on as these are not officially supported by .NET 8. For more details on .NET 8, including its support timeline, visit the official .NET 8 support page.

Library Upgrades

In addition to updating our framework, we’ve also upgraded the libraries that Buru SFTP Server relies on, including advanced logging features powered by Serilog.

Library	< 2.16.0 (previous)	>= 2.16.0 (current)
.NET	.NET 6.0	.NET 8.0
Serilog	2.12	4.1
Serilog.Extensions.Hosting	7.0	8.0
Serilog.Extensions.Logging	7.0	8.0
Serilog.Formatting.Compact	1.1	3.0
Serilog.Settings.Configuration	7.0	8.0
Serilog.Sinks.ColoredConsole	3.0.1	removed
Serilog.Sinks.Console	4.1	6.0
Serilog.Sinks.Debug	2.0	3.0
Serilog.Sinks.EventLog	3.1	4.0
Serilog.Sinks.File	5.0	6.0
Serilog.Sinks.RollingFile	3.3	removed
Serilog.Sinks.TextWriter	2.1	3.0

For more in-depth information on these features, refer to the Buru SFTP Server logging documentation.

FTP passive mode port and external address configuration (2.15.5)

In FTP passive mode, the client initiates both the command and data connections to the server. This approach is particularly beneficial when the client is behind a firewall or NAT (Network Address Translation) device, as it avoids the complications associated with incoming connections from the server.

Previously, the server would choose ports for passive mode connections from the dynamic port range assigned by the operating system. This range typically spans from 49152 to 65535.

With the latest release of Buru SFTP Server, administrators can now configure the FTP passive mode port range and specify the external IP address directly within the server settings.

The configuration can be accessed through the Web Administration interface under the FTP Settings section or configured directly in the config.yaml file.

Bug fixes

Fixed user database issue when some users couldn’t be loaded or updated (2.15.6)

We addressed an issue where user retrieval from the internal database sometimes failed due to indexing issues within the database, causing unpredictable behaviors and errors.

This manifested in various ways, including:

Inability to load specific user details
Failed attempts to delete certain users
Misleading error messages when creating a new user with an existing username

We have temporarily resolved this issue by removing the problematic index. However, a permanent solution will be implemented in the next major release when the database library is updated. The current version does not include a full fix due to the potential for breaking changes.

Added `no-cache` HTTP header to Web Admin responses to prevent displaying outdated content (2.15.6)

The Microsoft Edge browser has been observed to load content directly from its cache without checking for updates (e.g., using If-Modified-Since), unlike other browsers. This behavior can lead to users viewing outdated content.

To address this, we added the no-cache directive in the HTTP headers, instructing browsers to always verify with the server before using a cached page version.

For a complete list of fixes and improvements, see the Release notes.

You can report issues and submit feature requests on our Github issue tracker.

For discussions and specific problems, please continue using our support forum.

New Rebex prices for 2025

Martin Vobr — Wed, 29 Jan 2025 00:00:00 GMT

Why we are changing prices

For more than 22 years, we’ve been committed to delivering reliable, high-quality .NET libraries to help developers like you deliver complex projects with ease. Over the years, we’ve made significant improvements to our products, introduced new features and maintained exceptional support. After keeping our prices flat for the past 6 years, costs have increased to the point where a price adjustment is needed. Increased prices will allow us to continue improving our products and to continue supporting the software in the years to come.

Effective date

Price changes are effective as of May 1st, 2025.

New pricing

Product	New license	Renewal
.NET library packs
File Transfer Pack	$999	$499
Mail Pack	$499	$249
SSH Pack	$1,299	$649
Total Pack	$1,499	$749
Individual .NET libraries
EWS	$299	$149
File Server	$499	$249
FTP	$499	$249
Graph	$299	$149
HTTPS	$499	$249
IMAP	$299	$149
MSG	$299	$149
POP3	$299	$149
Security	$199	$99
SFTP	$499	$249
SMTP	$199	$99
SSH Shell	$999	$499
Syslog	$299	$149
Time	$199	$99
TLS	$999	$499
WebSocket	$499	$249
ZIP	$299	$149
Servers
Buru SFTP Server	$399	$199

(Prices for 1 developer / 1 server)

Current customers

We understand that price changes are never easy, and we’re committed to making this transition as smooth as possible.

90 days to get new licenses at the old price

The prices will change 90 days from the publication of this announcement. If you are considering purchasing additional licenses, you can do so in advance and pay the current price.

Buy new licenses

Lock your renewal prices for up to 3 years

You can lock in your current renewal pricing for up to 3 years if you renew your current support contract before the price changes. This applies if you choose to renew for multiple years. If you still have a few months left on your support contract, renew it before the price change on May 1st. Those additional years will be added to the end of your current contract.

Renew your support contract

Contact support

We understand that you may have questions regarding the price change. Please feel free to contact us at support@rebex.net. We're always here to help.

Rebex .NET components 7.0.9147: Maintenance release

Lukas Pokorny — Sun, 19 Jan 2025 00:00:00 GMT

Mitigated potential timing attack in XTS/AES

The tweak chunk preparation algorithm from IEEE 1619-2018 standard, used in Xts, XtsStream and FileEncryption classes, was found to be potentially susceptible to timing attacks. This release of Rebex Security / Rebex Total Packs resolves the issue.

Improved FTP compatibility

This release adds a workarounds for instances of HGFTP server that issue badly-formatted PWD response.

Tested with Windows 11 24H2, .NET 9.0.1 and .NET 8.0.12

All Rebex libraries have been tested on latest versions of Windows and .NET.

More fixes and improvements

For a detailed list of changes, see the release history.

Rebex .NET components 7.0.9083: Support for .NET 9

Lukas Pokorny — Tue, 12 Nov 2024 00:00:00 GMT

Support for .NET 9

This release adds a new set of binaries targeting .NET 9. All .NET 9 platforms are supported:

Windows (x64, x86, ARM64)
Linux (x64, ARM32, ARM64)
Android (x64, ARM32, ARM64)
macOS (ARM64, x64)
iOS/iPadOS/tvOS (ARM64)

Of course, we still support earlier versions of .NET as well, including .NET Framework 3.5-4.8.1 and .NET 5-8. For more information about supported platforms, see our framework support chart.

Rebex FTP/SSL renamed to Rebex FTP

We dropped the old 'SSL' part from the name of Rebex FTP library. In 2024, referring to TLS as 'SSL' no longer made sense. Of course, Rebex FTP still supports TLS. FTP over SSL 3.0 can be enabled as well, although it's discouraged because SSL is no longer secure and has been deprecated years ago.

And more...

For a detailed list of changes, see the release history.

R6.17 available as well

For customers who have not yet upgraded to version 7 of Rebex libraries, we published the R6.17 update with important fixes and enhancements. Version R6.x will be supported until November 2025.

New component: Rebex Graph - client API for MS Graph

Lukas Pokorny — Mon, 14 Oct 2024 00:00:00 GMT

Rebex Graph is a .NET library for accessing Microsoft 365 (Exchange Online) using Microsoft Graph API. It makes it possible to send, receive, list and search e-mail messages. It supports TLS 1.3/1.2 and S/MIME on all recent .NET platforms (including .NET Framework 3.5-4.8 and .NET 6.0-8.0).

Easy-to-use API

With Rebex Graph's simple API, working with e-mails in Microsoft's cloud is easy:

var client = new Rebex.Net.GraphClient();

// connect and authenticate to Exchange Online (Microsoft 365) server
client.Connect();
client.Login(token);

// get list of top 10 unread messages in Inbox and show their headers
var page = new GraphPageView(0, 10);
var unread = GraphMessageSearchParameter.IsRead(false);
var list = client.Search(GraphFolderId.Inbox, page, unread);

foreach (var info in list)
{
    Console.WriteLine("{0}: {1}", info.ReceivedDate, info.Subject);
}

Having troubles with setting up client access for your app in Microsoft's Azure? Check out our extensive blog posts that come with working sample code:

Rebex Graph is available as a standalone package, or as a part of Rebex Total Pack or Rebex Mail Pack. If you already have an active support contract for Rebex Total Pack or Rebex Mail Pack (formerly Rebex Secure Mail), you can download the full version including the Graph library now!

Secure Mail becomes Mail Pack. Mail libraries available separately.

Jan Sotola — Thu, 10 Oct 2024 00:00:00 GMT

We are introducing new packaging of Rebex email libraries:

Individual libs

All mail libraries

Mail Pack

Why are we making this change?

In the past, most of Rebex mail libraries were available together in Rebex Secure Mail. However, some users needed only a part of the functionality.

Now, it is possible to buy any of these libraries separately at a lower price, or all together for the same price.

We've also added the MSG library to 'Secure Mail', and renamed the bundle to 'Mail Pack'. This makes the naming consistent with our other .NET library packages.

I already have a Rebex Secure Mail license. What changes for me?

You've been upgraded to Rebex Mail Pack for free.
You can use the MSG library as well.
API and DLLs stay the same. No change is needed in your code.
When renewing your Rebex Secure Mail support contract, you will be offered a Rebex Mail Pack renewal.

Introductory pricing

For a limited time, the price of Rebex Mail Pack is the same as for Rebex Secure Mail ($299 for a new single developer license, $149 for renewal). Individual component are priced lower (starting at $199 or $99 for SMTP).

Questions?

If you have any questions or comments, please contact us at support@rebex.net.

Rebex Buru SFTP Server 2.15.4: FTP protocol support.

Lukas Paluzga — Thu, 10 Oct 2024 00:00:00 GMT

We have released Rebex Buru SFTP Server v2.15.4. Here is an overview of changes, fixes and improvements.

FTP protocol support

Buru SFTP Server now supports FTP and FTPS protocol, in addition to already supported SFTP, SCP and SSH protocols. FTP protocol is disabled by default and can be enabled either for individual users or for all users at once. Each FTP endpoint can be assigned a separate set of X.509 certificates. Both implicit and explicit FTPS modes are supported.

Buru SFTP Command Prompt now asks for administrator privileges by default

This has been source of confusion for users as running most burusftp commands without administrator privileges would fail with permission errors.

Minor fixes and improvements

2.14.5

Fixed errors when parsing some configuration IP addresses with leading or trailing whitespace.
Web Admin - added SSH port placeholder on SSH endpoints page.
Web Admin - fixed Maximum renegotiation threshold caption on Additional SSH settings page.
Web Admin - fixed minor UI issue when typing a file path containing a space character.

2.15.0

Initial FTP protocol support:
- Added support for FTP protocol (plain FTP, implicit and explicit FTPS).
- Disabled by default. Can be enabled globally in configuration or per user.
- Each FTPS endpoint can be configured with different certificate(s).
Added user field ’note’ for user comments.
Installer - Buru SFTP Command Prompt now runs with administrator privileges by default.
Removed server configuration parameters passwordPolicy and usernamePattern. These parameters have been deprecated since v1.1.0.
Web Admin - configuration pages are now accessible when configuration file is invalid but readable.
Fixed burusftp user key delete -F <fingerprint> behavior with SHA-256: prefix.
Updated Serilog logging libraries.

2.15.1

Fixed an issue where username leading/trailing whitespace was not trimmed when creating a user.
Web Admin - fixed error when loading user detail page for user with special characters in username.
Web Admin - fixed error message when adding user with existing username.

2.15.2

Web Admin - fixed browser cache issue after application upgrade.

2.15.3

Web Admin - fixed error when loading FTP settings page.

2.15.4

Added burusftp certgen command to generate self-signed X.509 (TLS) certificates. This is an alias for burusftpwa certgen.
Web Admin - FTP certificate group can now be renamed.
Web Admin - fixed FTP binding custom certificate group not being saved properly.

For complete list of fixes and improvements see Release notes

Issues and feature requests on Github

You can report issues and submit feature requests on our Github issue tracker. For discussions and specific problems please keep using our support forum.

Rebex .NET components 7.0.9048: Maintenance release

Lukas Pokorny — Tue, 08 Oct 2024 00:00:00 GMT

Rebex Secure Mail becomes Rebex Mail Pack

Rebex Secure Mail, our package of Rebex mail libraries, is now available as Rebex Mail Pack. In addition to IMAP, POP3, EWS, SMTP, MIME and S/MIME, it now also includes libraries for Outlook MSG format and for MS Graph API.

Libraries for individual mail protocols are also available separately: IMAP, POP3, SMTP, Graph, EWS, MSG.

Improved Graph API

Our client-side MS Graph library now supports CreateFolder and DeleteFolder methods. It also adds Settings.MarkDownloadedMessageAsRead option that instructs the client to mark downloaded messages as read (seen).

Improved FTP compatibility

This release adds a set of workarounds for FTP servers that are unable to respond properly to "MLST /" command.

More fixes and improvements

For a detailed list of changes, see the release history.

Rebex Buru SFTP Server 2.14.4: Terrapin update, silent installation mode, Web Admin improvements.

Lukas Paluzga — Wed, 31 Jul 2024 00:00:00 GMT

We have released Rebex Buru SFTP Server v2.14.4. Here is an overview of changes, fixes and improvements.

Terrapin attack mitigation

Buru SFTP Server now supports strict key exchange extension to mitigate the so-called 'Terrapin attack' - CVE-2023-48795. Although this is not a critical fix, since neither version of Buru SFTP Server relies on RFC 8308 extension negotiation mechanism, the update thwarts possible authentication disruption caused by an attacker using the Terrapin vulnerability.

Silent installation mode

Buru SFTP Server installer now supports silent installation mode. This mode allows you to install the server without any user interaction. Several command-line options are available to customize the installation process, such as installation path, SSH port and more.

Web Admin frontend overhaul

The Web Admin frontend has been updated with a new look that should feel less cluttered. It also provides a better user experience by adding several sought-after features:

Multiple users can now be selected for certain actions (lock, unlock, delete).
Warnings shown when multiple SSH keys of the same type are added.
Server public keys can now be easily exported from the web interface.
Certificate details are now shown for keys with certificates.
SSH algorithm selection is now simplified.
and more...

Minor fixes and improvements

2.11.2

Added support for strict key exchange extension.
Fixed 'not authenticated' instead of 'not connected' error message.
Allowed dates outside 1970-2999 range in SFTP v4 (or higher).

2.11.3

Fixed configuration backup when upgrading using installer.
Updated signing certificate.

2.11.4

Fixed user update command:
- Fixed error message when Windows account is not found.
- Fixed error when updating fields other than Windows account and related, when Windows account is already set, using Free license.

2.12.0

Added silent installation mode.

2.12.1

Fixed CreateProcess failed error during installation.

2.13.0

Removed KeyCertSign and CrlSign usages from burusftpwa certgen-generated certificates.
SSH banner is now configurable.

2.14.0

Web Admin - major changes:

Form visuals have been updated.
Multiple users can now be selected for certain actions (lock, unlock, delete).
UI customization changes:

Full Material UI schema is no longer supported.
Secondary palette is no longer supported.

Error shown when multiple server SSH keys of same type are added.
Public server keys can now be easily exported from the web interface.
SSH algorithm selection is now simplified. Manual sorting is still supported by editing the configuration file.
User public keys are now displayed with SSH key type prefix.

2.14.1

Added support for loading private keys in new OpenSSH key format encrypted using AES/GCM or ChaCha20/Poly1305.
Fixed handling of client's SSH_MSG_EXT_INFO message.
Added logging of SSH ciphers supported by the client on mismatch (log level: debug).
Environment variables can be used in server key paths.
Web Admin - fixed missing log level dropdown on logging configuration page.
Web Admin - server configuration page now shows full path to configuration file and revert buttons.

2.14.2

Web Admin - fixed loading comment from user public keys.
Web Admin - server key list now also shows certificate details for keys with certificates.

2.14.3

Added logging of user lockout events.
Fixed burusftp user update <username> --password "" behavior - now removes password instead of setting an empty password.
Fixed burusftp user add <username> --password "" behavior - now does nothing instead of setting an empty password.

2.14.4

Web Admin - fixed error when multiple IP address ranges were used in IP filtering textboxes.

For complete list of fixes and improvements see Release notes

Issues and feature requests on Github

You can report issues and submit feature requests on our Github issue tracker. For discussions and specific problems please keep using our support forum.

Rebex .NET components 7.0.8943: MS Graph API support, improvements and fixes

Lukas Pokorny — Mon, 08 Jul 2024 00:00:00 GMT

New library: MS Graph API client

Rebex Graph is a .NET library for accessing Microsoft 365 (Exchange Online) using Microsoft Graph API. It can send, receive, list and search e-mail messages. Supports TLS 1.3/1.2 and S/MIME on a wide range of platforms including .NET Framework 3.5, 4.0-4.8, and .NET 5-8.

The new library is part of Rebex Total Pack and Rebex Mail Pack. It's also available separately as Rebex Graph.

AES/GCM encryption for OpenSSH keys

Previously, Rebex libraries have been using the legacy AES/CBC encryption when saving private keys in new OpenSSH format. This is considered weak, and was upgraded to AES/GCM in this release.

Improved MIME-to-MSG conversion

When converting between .eml (MIME) and .msg (Outlook mail format) files, Sensitivity header is supported as well.

More fixes and improvements

For a detailed list of changes, see the release history.

Office 365 and Rebex Graph with OAuth 2.0 authentication in unattended (app-only) mode: How to make it work

Alexandr Pleskot — Wed, 26 Jun 2024 00:00:00 GMT

Microsoft 365 (formerly Office 365) supports two kinds of OAuth 2.0 authentication:

Delegated authentication is suitable for desktop, mobile or web applications with signed-in user present.
This mode is described in detail in another article.
App-only authentication is suitable for services or daemons with no user present. Instead, these unattended applications authenticate using client secrets (application credentials) to receive an access token, which is then used to gain access to a mailbox using Rebex Graph library.

Before your application can start accessing mailboxes, you have to register it with Microsoft, assign the relevant permissions and configure mailbox access. The guide below describes what needs to be done to enable Graph access for unattended apps (app-only mode). For other protocols, see EWS article or IMAP and POP3 article.

Configuring Microsoft 365
C# sample code
Documentation for Rebex Graph .NET library
Common issues

Register yourself and your company

Log into Azure Portal. If you don't have an account there yet, create it. You also have to set up a tenant that represents your company.
If you administer more than one tenant, use Directories + subscriptions filter to select the tenant for whom to register an application.

Register your application

In Azure Portal ⇒ expand the left menu ⇒ select Microsoft Entra ID ⇒ select App registrations ⇒ click + New registration. (Azure Portal is constantly evolving, so if you cannot find this page, use the search bar.)
Name your application, choose which kind of accounts are going to use it, and click Register.

Note: This guide is suitable for single tenant account types. For other types, further steps might be different.
You successfully registered your application and you can view its associated IDs. Some of them will be needed later to obtain an OAuth 2.0 token.

Set up client secret (application password)

In the left menu, select Certificates & secrets ⇒ click + New client secret.
Provide some description for this secret, choose expiration period, and click Add.
Immediately copy and save the newly created client secret's Value (not Secret ID). You will not be able to view the Value later anymore.

Add app permissions

In the left menu, select API permissions ⇒ click + Add a permission.
Navigate to Microsoft Graph.
Click Application permissions ⇒ type Mail ⇒ check Mail.Read ⇒ click Add permissions.

Note: Consider adding Mail.ReadWrite and Mail.Send as well, but these are not needed for this demo.
The newly-added Mail.Read permission has to be approved by your organization's administrator. Ask them to grant consent to your application by clicking Grant admin consent for [organization].

Note: This grants read access to all Microsoft 365 Online mailboxes in your organization. To restrict this, read How to restrict mailbox access of Azure applications in app-only mode article.
Application permissions have been granted. Optionally, you can remove the delegated User.Read permission which is not needed for app-only application - click the context menu on the right side of the permission and select Remove permission.
Congratulations! Now you have registered an application for accessing Office 365 mailboxes via Microsoft Graph API and received its Application (client) ID, Client secret and Directory (tenant) ID.

These strings are going to be used by your application to authenticate to Microsoft 365 via OAuth 2.0 and receive an OAuth token. This token is then used to authenticate to Exchange Online using Rebex Graph.

Let's write some code!

In your application, add reference to Microsoft.Identity.Client package, and specify your IDs, the secret, and the e-mail address. Specify the scope to request a token as well (use https://graph.microsoft.com/.default in app-only mode).

// application (client) ID obtained from Azure
const string ClientId = "cf2207a9-1111-1111-1111-5867ad1cf91e"; // change to your AppId

// application's 'client secret' value (application password)
const string ClientSecretValue = "ThisIsSomeVerySecretValue"; // change to your secret value

// your organization's directory (tenant) ID
const string TenantId = "fb561382-2222-2222-2222-06ab992d36b7"; // change to your TenantId

// mailbox to access (not an alias)
const string MailAddress = "someone@example.org"; // change this

// default scope of permissions to request
private static readonly string[] Scopes = new[] {
    "https://graph.microsoft.com/.default", // for accessing Exchange Online with app-only auth
};

Before your application connects to Office 365's Graph service, it has to request an OAuth 2.0 access token using the Microsoft's authentication API.

using Microsoft.Identity.Client;

...

// get an instance of 'CCA' API
var cca = ConfidentialClientApplicationBuilder
    .Create(ClientId)
    .WithClientSecret(ClientSecretValue)
    .WithTenantId(TenantId)
    .Build();

// acquire OAuth 2.0 access token from Microsoft 365
AuthenticationResult result = await cca.AcquireTokenForClient(Scopes).ExecuteAsync();
string accessToken = result.AccessToken;

Then, connect to graph.microsoft.com using Rebex Graph package and use the acquired token to start accessing your organization's mailboxes.

using Rebex.Net;

...

// connect to Office 365 
var client = new GraphClient();
client.Connect();

// specify mailbox to access
client.Settings.Impersonation = new GraphImpersonation(MailAddress);

// authenticate using the access token
client.Login(accessToken);

// start working with the mailbox
...

To give this a try before adding the code to your application, try our GraphOAuthAppOnlyConsole sample.

Documentation for Rebex Graph .NET library

Any issues?

Use an up-to-date version of Rebex Graph. Old versions have not been tested with contemporary Exchange Online. They might still work, but if you encounter any issues, please try the latest release.
This guide is only suitable for Rebex Graph. For Exchange Web Services guide, see Office 365 and EWS with OAuth 2.0. For IMAP/POP3 guide, see Office 365 and IMAP or POP3 with OAuth 2.0.
Need help? Ask at Rebex Q&A Forum.

How to use OAuth 2.0 authentication for Office 365 with Rebex Graph in delegated mode (with a signed-in user)

Alexandr Pleskot — Tue, 25 Jun 2024 00:00:00 GMT

OAuth 2.0 authentication is quickly becoming a must-have feature for applications accessing cloud-based email services such as Microsoft 365 (formerly Office 365) Exchange Online (formerly Outlook Online). And although setting it up is relatively simple, there are many steps where things can easily go wrong.

In this article, we will show how to implement a .NET desktop WPF application that uses Rebex Graph component to access a Microsoft 365 mailbox via Microsoft Graph API. Apart from Rebex Graph and a JSON parser the application does not rely on third-party libraries.

If your application is a service/daemon with no user present, see Rebex Graph with OAuth 2.0 in unattended (app-only) mode instead.

You can get our sample source code from Rebex Extras repository on GitHub straight away, and use the rest of the article as a guide to how it works.

Quick overview

The sample application implements the whole OAuth 2.0 authorization code flow and don't rely on an external library for this. Another option is to use Microsoft.Identity.Client package - in that case, you might prefer another set of sample apps that use that API instead.

But even if you end up using Microsoft's API, this article is still useful, because the prerequisites and the final steps are the same, and it's useful to understand what's actually going on under the hood. The underlying logic is the same, Microsoft.Identity.Client just adds more abstraction layers and performs actions described in steps 5, 6 and 9 under the hood.

Before you actually run the application, make sure you have all the prerequisites:

Register your application in Azure and grant it appropriate permissions.
Choose a suitable "tenant".
Determine scope of permissions you need.
Consider additional options.

Then, in the actual application, you would do this:

Direct the user to an authentication URL (via embedded browser).
Retrieve the authentication code and redeem it for an access token.
Access the mailbox using Graph.
Refresh the access token (if needed).

This applies to desktop Windows applications using delegated authentication. That simply means applications with a single signed-in user present. Most mobile applications would use the same approach as well.

Note: For applications with no signed-in user present (such as services or daemons), the process is a bit different, and the application needs to be configured for unattended (app-only) authentication. This is outside the scope of this article - see Rebex Graph with OAuth 2.0 in app-only mode instead.

Now, let's get started:

1. Register your application with Microsoft

Before you can use OAuth 2.0 authentication for accessing Office 365 mailbox via Microsoft Graph API, you have to register your application with Azure Active Directory and configure it properly.

During the process, you will obtain your application's Client ID, which is a GUID that uniquely identifies your application. You will also specify a tenant and scope of permissions (more on these below).

2. Specify a suitable "tenant"

You also have to specify what kinds of Microsoft users are going to use your application. This means choosing a suitable Tenant ID value that corresponds to your application registration ("Supported account types" in the app registration form). It will usually be common (users with personal Microsoft accounts or work/school accounts), organizations (only users with work/school accounts), or consumers (only users with personal accounts).

Alternatively, if you only wish to allow users from your organization, it could be a domain name or a GUID (see the endpoints documentation) for details.

In our sample applications, we used organizations, but you can modify that easily.

3. Determine scope of permissions

Before you can direct a user to Microsoft's server to authorize your app, you also have to determine which kinds of scopes (permissions) to actually ask for.

Microsoft identity platform's scopes are not exactly trivial, but for the purpose of mailbox access, only few of them are needed.

Scopes for OAuth 2.0 access token:

"profile" - This one is needed to retrieve the user name. It's not needed for this sample.
"email" - This is not required, but might be useful.
"openid" - If you request profile or email, you'll have to include this as well to retrieve the JSON Web Token that contains that information.
"offline_access" - This permission makes it possible for the application to keep accessing the mailbox even when the original access token expires after an hour. With offline_access, the application receives a refresh token which can be used to obtain a new access token.

Scopes for Microsoft Graph API:

"https://graph.microsoft.com/User.Read" - Required for reading user's profile info.
"https://graph.microsoft.com/Mail.Read" - Required for reading mails.
"https://graph.microsoft.com/Mail.Send" - Required for sending mails.
"https://graph.microsoft.com/Mail.ReadWrite" - Required for manipulating mails.

If you want to keep configuration simple, you can just use single .default scope:

"https://graph.microsoft.com/.default" - Requests all permissions defined in app registration (cannot be combined with other "https://graph.microsoft.com/" scopes).

Make sure that you actually granted the required permissions to your application in Azure Portal.

4. Consider additional options

You might also wish specify prompt type, which determines the type of required user interaction. The following values are available:

"" - This is the default mode. The authentication server will not request the credentials if the user has already signed in.
"login" - The authentication server will always request user's credentials.
"none" - The server will never ask the user for credentials, which means this will only work once the user has already signed in.
"consent" - This will explicitly ask the user to grant requested permissions to the app (even if he already did before).
"select_account" - This will present the user with account selection dialog, which can be useful for users with multiple Microsoft accounts.

For detailed information about prompt types, see the documentation.

Another option that varies from app to app is redirect URI. This indicates where the authentication server should redirect the user once successfully authenticated (or failed). However, for the purpose of desktop or mobile application with an embedded browser, we can simply use a special URL that exists specifically for this purpose.

In our sample app, this special URL is used by default.

5. Direct the user to an authentication URL

Once the application has all of the information above (put them here), it's ready to ask the user to grant the required permissions to access their Office 365 mailbox. It does so by opening a window with an embedded browser for the user, and points it to an URL at Microsoft's authentication server.

In our sample app, we implemented a OAuthAzureAuthorizationWindow class for this purpose, and initiating the process is very simple:

// create a Window that handles OAuth2 authorization
var authenticationWindow = new OAuthAzureAuthorizationWindow();
authenticationWindow.Owner = this;

// specify the kind of authorization we need
authenticationWindow.ClientId = ClientId; // application's client ID
authenticationWindow.TenantId = "organizations"; // kinds of users to allow
authenticationWindow.PromptType = ""; // prompt type to use
authenticationWindow.Scopes = Scopes; // scope of permissions to request

// perform the authorization and obtain the credentials
var credentials = await authenticationWindow.AuthorizeAsync();

The source code for OAuthAzureAuthorizationWindow class comes with the sample app as well, and can be easily customized. This is what the AuthorizeAsync method actually does:

// get redirect URI and determine expected authority
string redirectUri = RedirectUri ?? OAuthAzureCredentials.DefaultRedirectUri;

// create an instance of OAuthAzureCredentials helper class
_credentials = new OAuthAzureCredentials(ClientId, TenantId, PromptType, redirectUri, Scopes);

// create task completion source for the whole action
_taskCompletion = new TaskCompletionSource<OAuthAzureCredentials>();

// Direct the user to authorization endpoint.
// Once completed, the application will receive an authorization code.

// show the window and navigate to authentication URI
Show();
webBrowser.Navigate(_credentials.AuthorizationUri);

// return task that will finish on succcess or failure
return _taskCompletion.Task;

The OAuthAzureCredentials helper class (source included) encapsulates the OAuth 2.0 authentication logic, while OAuthAzureAuthorizationWindow class adds WPF-specific bits - mostly the embedded browser window provided by .NET's WPF WebBrowser class.

6. Retrieve the authentication code and redeem it for an access token

Once the user has authenticated to Microsoft's server and granted us permissions, the browser window will be directed to an URL that contains an authentication code. This is essential, as this is what the application needs in order to obtain an OAuth 2.0 access token for accessing Office 365 mailboxes.

Our WPF authentication window class grabs the code from the redirected URL's query string and calls OAuthAzureCredentials's RequestAccessTokenAsync method to redeem it:

// get query part of the browser URL
var query = System.Web.HttpUtility.ParseQueryString(e.Uri.Query);

...

// get authorization code from the supplied URL
string authorizationCode = query["code"];
if (authorizationCode == null)
{
    // we are not on the final authentication page yet...
    return;
}

// The user has granted us permissions, and we received an authorization code.
// Next, we will exchange the code for an access token using the '/token' endpoint.

await _credentials.RequestAccessTokenAsync(authorizationCode);

// close the window and finish the successful asynchronous authentication request
Close();
_taskCompletion.SetResult(_credentials);

And this is what actually goes on inside the RequestAccessTokenAsync method:

// construct the request body
string requestBody = string.Format(
    CultureInfo.InvariantCulture,
    "grant_type=authorization_code&code={0}&scope={1}&redirect_uri={2}&client_id={3}",
    authorizationCode,
    _scopes,
    Uri.EscapeDataString(RedirectUri),
    _clientId);

// send it via POST request and receive response
string responseJson = await HttpPostAsync(_tokenEndPoint, requestBody);

// deserialize JSON response
var response = DeserializeJson(responseJson);

// get OAuth 2.0 access token
AccessToken = GetStringValue(response, "access_token");
...

Here, we construct an HTTP POST request and send it to an endpoint at Microsoft's server (the actual URL is https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token, where {tenant} is the tenant ID, as explained above).

The server will reply with a JSON response, which contains not only the OAuth 2.0 access token, but also additional information, such as user name, e-mail, or refresh token (based on the scope of permissions requested).

To parse the JSON response, we used Microsoft's new JSON API, but you can easily use the popular Newtonsoft.Json package as well - just add a reference to it, uncomment the relevant line of code in DeserializeJson method (and remove MS API code).

7. Access the mailbox using Microsoft Graph API

Now that the application finally has the access token, it can access the user's mailbox at graph.microsoft.com via Rebex Graph component.

It's very straightforward:

// connect to the server
var client = new Rebex.Net.GraphClient();
await client.ConnectAsync();

// authenticate using the OAuth 2.0 access token
await client.LoginAsync(_credentials.AccessToken);

// do something
GraphFolderInfo folderInfo = await client.GetFolderInfoAsync(GraphFolderId.Inbox);

// or something else
GraphMessageCollection messageList = await client.GetMessageListAsync(GraphFolderId.Inbox, ...);
...

8. Refreshing the access token (if needed)

The access token expires in one hour. If the application needs to keep accessing the mailbox for longer periods of time without asking the user to authenticate again, it also has to take care of refreshing the access token. To be able to do this, it must have been granted the offline_access scope.

To refresh the access token, application calls the RefreshAccessTokenAsync method, which again constructs a relevant HTTP POST request and posts it to an endpoint at Microsoft's server. The server responds with a new access and refresh tokens:

// construct the request body
string requestBody = "grant_type=refresh_token&client_id=" + _clientId + "&refresh_token=" + RefreshToken;

// send it via POST request and receive response
string responseJson = await HttpPostAsync(_tokenEndPoint, requestBody);

// deserialize JSON response
var response = DeserializeJson(responseJson);

// update OAuth 2.0 access token and refresh token
AccessToken = GetStringValue(response, "access_token");
RefreshToken = GetStringValue(response, "refresh_token");

What next?

We tried to make the sample code simple to read and reuse, and although we utilized .NET 4.5's await/async extensively, the code can be easily converted to .NET Framework 3.5 or 4.0. Just make sure the embedded browser on the target platform supports TLS 1.2, otherwise the user would not be able to authenticate. Actually, we have already converted the code for you.

You might also want to consider more options such as domain_hint, state or code_challenge. These are not required for desktop apps (yet), but it might be a good idea to already take advantage of them for the extra security they offer.

Another option to consider is to discard our simple OAuth 2.0 helper classes and use Microsoft.Identity.Client API instead. This is available for .NET 4.5 or later, and makes it possible to perform the whole process without the need to delve into the internals. It's a powerful API, but also somewhat complex, and seemingly simple actions might be hard to figure out. But once you get it working, you get all the latest features with no extra effort. If you prefer this option, we already have a ready-to-use sample apps as well.

Rebex not affected by xz vulnerability CVE-2024-3094

Lukas Paluzga — Tue, 02 Apr 2024 00:00:00 GMT

Rebex and its products ARE NOT affected by a recently discovered xz and subsequently OpenSSH critical vulnerability CVE-2024-3094. The vulnerability creates a backdoor in SSH authentication and thus allows the attacker to gain unauthorized access to the system.

To avoid any confusion: The list of Rebex products safe from this vulnerability includes Rebex Buru SFTP Server, Rebex Total Pack (and all .NET components included in it).

Our free tools Jumble obfuscator, Rebex Tiny SFTP Server, Rebex TLS Proxy or Rebex Mail Converter are also not affected.

using Rebex.Net;

Rebex Buru SFTP Server 2.18.0: Post-quantum cryptography and SSH/SFTP core improvements

Post-quantum key exchange ciphers (2.18.0)

SSH/SFTP core overhaul (2.18.0)

Additional key exchange algorithms (2.18.0)

copy-data SFTP extension (2.18.0)

Minor changes and fixes

Rebex .NET components 7.0.9448: Support for .NET 10

Support for .NET 10

Support for Visual Studio 2026

And more...

Migrating from EWS to Microsoft Graph

Table of contents

Configuring Graph access to Exchange Online

Changing application permissions

Example of permission changes for an application operating in delegated (signed-in user) mode:

Example of permission changes for an application operating in unattended (application) mode:

Changing OAuth scopes

Sample applications

Migrating to Graph

Connecting and authenticating to Exchange Online

Listing Inbox messages

Searching for messages

Downloading e-mail messages

Sending messages

Updating messages

Deleting messages

Listing folders

Creating folders

Deleting folders

Rebex .NET components 7.0.9313: Maintenance release

Maintenance release

List of changes

R6.18 available as well

US court ruled: ComponentPro libraries stolen from Rebex

What this means for you

Here's the fix

Benefits of switching to the genuine version:

What to do

Rebex .NET components 7.0.9209: Maintenance release

Support for RSA public key format from PKCS #1

Improved error handling in multi-file operations

Improved IMAP folder info

More fixes and improvements

Rebex Buru SFTP Server 2.17.0: SSH configuration improvements

SSH configuration improvements

SSH tunneling configuration changes (2.17.0)

SSH shell configuration defaults now configurable using Web administration (2.17.0)

Improved support for displaying user's public keys (2.17.0)

Minor changes and fixes

Rebex Buru SFTP Server 2.16.0: Technological update

Technological Update

Library Upgrades

FTP passive mode port and external address configuration (2.15.5)

Bug fixes

Fixed user database issue when some users couldn’t be loaded or updated (2.15.6)

Added no-cache HTTP header to Web Admin responses to prevent displaying outdated content (2.15.6)

New Rebex prices for 2025

Why we are changing prices

Effective date

New pricing

Current customers

90 days to get new licenses at the old price

Lock your renewal prices for up to 3 years

Contact support

Rebex .NET components 7.0.9147: Maintenance release

Mitigated potential timing attack in XTS/AES

Improved FTP compatibility

Tested with Windows 11 24H2, .NET 9.0.1 and .NET 8.0.12

More fixes and improvements

Rebex .NET components 7.0.9083: Support for .NET 9

Support for .NET 9

Rebex FTP/SSL renamed to Rebex FTP

And more...

R6.17 available as well

New component: Rebex Graph - client API for MS Graph

Easy-to-use API

Secure Mail becomes Mail Pack. Mail libraries available separately.

Why are we making this change?

I already have a Rebex Secure Mail license. What changes for me?

`copy-data` SFTP extension (2.18.0)

Added `no-cache` HTTP header to Web Admin responses to prevent displaying outdated content (2.15.6)