Mail relay with ProtonMail

Environment used for this Guide

I set-up my server with the latest stable Debian Network install minimal CD (currently bullseye) and add the meta package progress-linux maintained by the Linux and Infrastructure Team of the Bern University of applied sciences - my first employer in Switzerland.

Download ProtonMail Bridge .deb

Get the .deb file
Currently: protonmail-bridge_2.3.0-1_amd64.deb

Install required packages

apt -y install pass libsasl2-2

Install the bridge and configure it

apt install ./protonmail-bridge_2.3.0-1_amd64.deb
It will install many additional packages that are only installed as this is mainly a GUI based software :(.
Create a passphrase-free GPG key non-interactively

gpg --batch --passphrase '' --quick-gen-key 'ProtonMail Bridge' default default never

The above command creates a basic GPG key, and its ID is ProtonMail Bridge. This key does not have a passphrase, so pass does not need to ask users for a passphrase whenever it tries to use the key.
The key does not expire. Don’t use this key for other things (such as encryption, signing, identity, etc.). It is not safe.
This creates a new password database in pass (pass calls the database password store). And the GPG key ProtonMail Bridge can be used to open the database.
pass init “ProtonMail Bridge”
The planned way to run ProtonMail Bridge, in the background like the Postfix mail server, does not allow users to interact with the protonmail-bridge daemon. We have to set up protonmail-bridge interactively in advance.
Start the bridge for the inital login and configuration

hostname#protonmail-bridge --cli

        Welcome to Proton Mail Bridge interactive shell
                          ___....___
^^                __..-:'':__:..:__:'':-..__
              _.-:__:.-:'':  :  :  :'':-.:__:-._
            .':.-:  :  :  :  :  :  :  :  :  :._:'.
         _ :.':  :  :  :  :  :  :  :  :  :  :  :'.: _
        [ ]:  :  :  :  :  :  :  :  :  :  :  :  :  :[ ]
        [ ]:  :  :  :  :  :  :  :  :  :  :  :  :  :[ ]
::::::::[ ]:__:__:__:__:__:__:__:__:__:__:__:__:__:[ ]::
!!!!!!!![ ]!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!![ ]!!
^^^^^^^^[ ]^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^[ ]^^
        [ ]                                        [ ]
        [ ]                                        [ ]
  jgs   [ ]                                        [ ]
~~^_~^~/   \~^-~^~ _~^-~_^~-^~_^~~-^~_~^~-~_~-^~_^/   \~
>>>login
Username: [UsernameToLoginToProtonMail]
Password: [PasswordIsVerySecretAndComplex!1!Jaw0hl?]

After logging in with login and providing the 2nd factor you surely have enabled with Proton Mail, get the required SMTP/IMAP credentials to use the ProtonMail Bridge on the device you installed the bridge with info.

        [ ]                                        [ ]
  jgs   [ ]                                        [ ]
~~^_~^~/   \~^-~^~ _~^-~_^~-^~_^~~-^~_~^~-~_~-^~_^/   \~
>>> info
Configuration for YourDefaultEmailOnYourPaidAccount@proton.me
IMAP Settings
Address:   127.0.0.1
IMAP port: 1143
Username:  [YourDefaultEmailOnYourPaidAccountproton.me]
Password:  wzRrv5R6xOREfmcQ12837ASUDFiudfhsai
Security:  STARTTLS

SMTP Settings
Address:   127.0.0.1
SMTP port: 1025
Username:  [YourDefaultEmailOnYourPaidAccountproton.me]
Password:  wzRrv5R6xOREfmcQ12837ASUDFiudfhsai
Security:  STARTTLS

>>>
Set-up bridge as service

Setting up the ProtonBridge Client as a Linux service that will always run and be restarted after e.g. a reboot
vim /etc/systemd/system/protonmailbridge.service
Add this to the file

[Unit]
Description=Protonmail client bridge service
[Service]
Type=simple
StandardOutput=journal
ExecStart=/usr/bin/protonmail-bridge --noninteractive
User=<name of the login with which you login to your server>
[Install]
WantedBy=default.target

Now enable and start protonmailbridge as a service
systemctl enable protonmailbridge
systemctl start protonmailbridge
Maybe you need to use sudo if you are not working as root, which you are not, right?!
If there are any error messages, check if the service is up and running, if so - errors can be ignored.

<user>@hostname:~# ss -plant | grep 1025
LISTEN 0      4096               127.0.0.1:1025         0.0.0.0:*     users:(("proton-bridge",pid=859038,fd=11))
Recap
  • Required packes are installed
  • ProtonMail Bridge installed
  • ProtonMail Bridge running a Service
  • Port listening on 1025/TCP
  • We know the required User and Password for Postfix

Install and configure Postfix

apt -y install mailutils postfix

Edit the postfix main.cf file

vim /etc/postfix/main.cf

In this file search for relayhost and edit the line to look like

relayhost = [127.0.0.1]:1025

To allow Postfix use the ProtonMail Bridge with the required encryption details add the following to main.cf

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_CApath = /etc/ssl/certs
smtp_use_tls = yes
sender_canonical_maps = regexp:/etc/postfix/canonical

The canonical file needs to be updated so we have a default

vim /etc/postfix/canonical

Add the following

/.*/ YourProtonEmilAddress here or your custom Emailaddress

Now save the account details you received from the ProtonMail Bridge, these are different than you login for the website at https://mail.proton.me/

[127.0.0.1]:1025 <login>@protonmail.com:P@ssw0rdPr0videdByBridge

Now protect this file from users that should not know these credentials

chmod 0600 /etc/postfix/sasl_passwd
chown root:root /etc/postfix/sasl_passwd

Run Postmap to generate the DB file

postmap /etc/postfix/sasl_passwd

As Postfix will be connecting to the bridge with STARTSSL, it will need to validate the bridge certificate.
Symlinking the self-signed certificate will be necessary:

ln -s /user/.config/protonmail/bridge/cert.pem /etc/ssl/certs/protonmail-bridge.pem
Restart

At this point your postfix config has been complete and postfix needs a restart

systemctl restart postfix

If the services using this relay are not on the server you configured Postfix and the ProtonMail Bridge on, e.g. your home LAN or LAB LAN, allow then to use Postfix as relay by adding to open up the networks in /etc/postfix/main.cf
Edit the line

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128

Add extra networks as needed

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/24 10.10.0.0/16

Restart postfix for this to take effect.

systemctl restart postfix

Now test the setup by feeding a simple Email to Postfix

user@server:~# echo "this is the body" | mail -r "MustBeAnExistingEmail@proton.me" -s "this is the subject  " "RecepientOfThisTestMail@internet.invalid"

You can check the forwarding by postfix to the ProtonMain Bridge in the Log

tail -f /var/log/mail.log

Any error messages should provide you with enough clues to find a solution via e.g. Google Foo or you preffered search engine.

FlexEthernet (FlexE)

Function

FlexE supports the bonding of multiple links, which supports creating larger links out of multiple slower links in a more efficient way than the traditional link aggregation. FlexE also supports the sub-rating of links, which allows an operator to only use a portion of a link. FlexE also supports the channelization of links, which allows one link to carry several lower-speed or sub-rated links from different sources.

Compatibility

FlexE is backwards compatible with the existing optical transport network (OTN) infrastructure. A FlexE compatible interface can be connected to a piece of transport gear that is not aware of FlexE. When using it in this manner, FlexE traffic appears to the transport gear as if it was ordinary Ethernet traffic

Main difference to Ethernet

FlexE has low added latency as compared to regular Ethernet. The multiplexing is accomplished using time-division multiplexing instead of packet buffers. This type of multiplexing delivers deterministic latency that is near the minimum needed to deliver the bandwidth

FlexE adds a layer between Layer 2 (MAC layer) and Layer 1 physical interface rates (PHY layer). The main difference between standard Ethernet and FlexE is how the MAC layer is mapped onto the PHY layer, using a ‘FlexE Shim’. Essentially, FlexE uses this shim to dissociate the Ethernet rate on the client side from the actual physical interface rate. This makes it possible to map Ethernet MAC rates, which can be greater than or less than the Ethernet PHY rates
alt text
© Image Olaf Baumert after1
FlexE client is an Ethernet flow, based on a MAC data rate that may or may not correspond to any Ethernet PHY rate. This can be 10, 40, or n x 25Gbps.
A 100G FlexE instance is a unit of information consisting of 100G of capacity, able to carry FlexE client data, together with its associated overhead.
FlexE group refers to a group of one or many 100 Gbps FlexE instances, which may consist of 100, 200, or 400Gbps PHY/s. A 50Gbps PHY will be added within the OIF FlexE 2.1 Project.
FlexE calendar is used to assign TDM-like slots called calendar slots on each of the 100G FlexE instances. The calendar can have either 5Gbps or 25Gbps slot granularity. For example, there are 205Gbps calendar slots per 100Gbps FlexE instance and there are 425Gbps calendar slots per 100Gbps FlexE instance. The calendar slots, which carry the FlexE client traffic, are logically interleaved with other frames responsible for mapping, control, synchronization, error correction, and faults.
FlexE mux maps the FlexE clients to the FlexE group, and FlexE demux de-maps the FlexE clients from the FlexE group.

Below is an illustration of how a 10G client is muxed onto a 100G FlexE instance via 2 separate 5G calendar slots. The FlexE group comprises 4x100GbE PHYs. The 20x5G calendar slots that correspond to each 100G FlexE instance are then mapped onto the corresponding 100GbE PHYs. The overhead and other control frames are not shown here, for simplicity.
alt_text
© Image Olaf Baumert after1

Networking Basics

Function

The Internet Protocol is responsible for addressing host interfaces, encapsulating data into datagrams (including fragmentation and reassembly) and routing datagrams from a source host interface to a destination host interface across one or more IP networks.[2] For these purposes, the Internet Protocol defines the format of packets and provides an addressing system.

Each datagram has two components: a header and a payload. The IP header includes source IP address, destination IP address, and other metadata needed to route and deliver the datagram.
alt_text
The payload is the data that is transported. This method of nesting the data payload in a packet with a header is called encapsulation.

Encapsluation

The IP encapsulation is, within the OSI Model, the Network Layer and the payload on this layer starts with TCP/UDP headers from the next up Transport Layer.
alt_text