💾 Archived View for perso.pw › blog › rss.xml captured on 2024-09-29 at 02:37:53.

View Raw

More Information

⬅️ Previous capture (2024-08-31)

➡️ Next capture (2024-12-17)

🚧 View Differences

-=-=-=-=-=-=-

<?xml version="1.0" encoding="UTF-8"?> 
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Solene'%</title>
    <description></description>
    <link>gemini://perso.pw/blog/</link>
    <atom:link href="gemini://perso.pw/blog/rss.xml" rel="self" type="application/rss+xml" />
    <item>
  <title>I moved my emails to Proton Mail</title>
  <description>
    <![CDATA[
<pre># Introduction

I recently took a very hard decision: I moved my emails to Proton Mail.

This is certainly a shock for people following this blog for a long time, this was a shock for me as well!  This was actually pretty difficult to think this topic objectively, I would like to explain how I came up to this decision.

I have been self-hosting my own email server since I bought my first domain name, back in 2009.  The server have been migrated multiple times, from hosting companies to another and regularly changing the underlying operating system for fun.  It has been running on: Slackware, NetBSD, FreeBSD, NixOS and Guix.

# My needs

First, I need to explain my previous self-hosted setup, and what I do with my emails.

I have two accounts:



Ideally, having all the emails retrieved locally and not stored on my server would be ideal.  But I am using a lot of devices (most are disposable), and having everything on a single computer will not work for me.

Due to my emails being stored remotely and containing a lot of private information, I have never been really happy with how emails work at all.  My dovecot server has access to all my emails, unencrypted and a single password is enough to connect to the server.  Adding a VPN helps to protect dovecot if it is not exposed publicly, but the server could still be compromised by other means.  OpenBSD smtpd server got critical vulnerabilities patched a few years ago, basically allowing to get root access, since then I have never been really comfortable with my email setup.

I have been looking for ways to secure my emails, this is how I came to the setup encrypting incoming emails with GPG.  This is far from being ideal, and I stopped using it quickly.  This breaks searches, the server requires a lot of CPU and does not even encrypt all information.

=> https://dataswamp.org/~solene/2024-08-14-automatic-emails-gpg-encryption-at-rest.html Emails encryption at rest on OpenBSD using dovecot and GPG

Someone shown me a dovecot plugin to encrypt emails completely, however my understanding of the encryption of this plugin is that the IMAP client must authenticate the user using a plain text password that is used by dovecot to unlock an asymmetric encryption key.  The security model is questionable: if the dovecot server is compromised, users passwords are available to the attacker and they can decrypt all the emails.  It would still be better than nothing though, except if the attacker has root access.

=> https://0xacab.org/liberate/trees Dovecot encryption plugin: TREES

One thing I need from my emails is to arrive to the recipients.  My emails were almost always considered as spam by big email providers (GMail, Microsoft), this has been an issue for me for years, but recently it became a real issue for my business.  My email servers were always perfectly configured with everything required to be considered as legit as possible, but it never fully worked.

# Proton Mail

Why did I choose Proton Mail over another email provider?  There are a few reasons for it, I evaluated a few providers before deciding.

Proton Mail is a paid service, actually this is an argument in itself, I would not trust a good service to work for free, this would be too good to be true, so it would be a scam (or making money on my data, who knows).

They offer zero-knowledge encryption and MFA, which is exactly what I wanted.  Only me should be able to read my email, even if the provider is compromised, adding MFA on top is just perfect because it requires two secrets to access the data.  Their zero-knowledge security could be criticized for a few things, ultimately there is no guarantee they do it as advertised.

Long story short, when making your account, Proton Mail generates an encryption key on their server that is password protected with your account password.  When you use the service and log-in, the encrypted key is sent to you so all crypto operations happens locally, but there is no way to verify if they kept your private key unencrypted at the beginning, or if they modified their web apps to key log the password typed.  Applications are less vulnerable to the second problem as it would impact many users and this would leave evidences.  I do trust them for doing the things right, although I have no proof.

I did not choose Proton Mail for end-to-end encryption, I only use GPG occasionally and I could use it before.

IMAP is possible with Proton Mail when you have a paid account, but you need to use a "connect bridge", it is a client that connects to Proton with your credentials and download all encrypted emails locally, then it exposes an IMAP and SMTP server on localhost with dedicated credentials.  All emails are saved locally and it syncs continuously, it works great, but it is not lightweight.  There is a custom implementation named hydroxide, but it did not work for me.  The bridge does not support caldav and cardav, which is not great but not really an issue for me anyway.

=> https://github.com/emersion/hydroxide GitHub project page: hydroxide

Before migrating, I verified that reversibility was possible, aka being able to migrate my emails away from Proton Mail.  In case they stop providing their export tool, I would still have a local copy of all my IMAP emails, which is exactly what I would need to move it somewhere else.

There are certainly better alternatives than Proton with regard to privacy, but Proton is not _that_ bad on this topic, it is acceptable enough for me.

## Benefits

Since I moved my emails, I do not have deliverability issues.  Even people on Microsoft received my emails at first try!  Great success for me here.

The anti-spam is more efficient that my spamd trained with years of spam.

Multiple factor authentication is required to access my account.

## Interesting features

I did not know I would appreciate scheduling emails sending, but it's a thing and I do not need to keep the computer on.

It is possible to generate aliases (10 or unlimited depending on the subscription), what's great with it is that it takes a couple seconds to generate a unique alias, and replying to an email received on an alias automatically uses this alias as the From address (webmail feature).  On my server, I have been using a lot of different addresses using a "+" local prefix, it was rarely recognized, so I switched to a dot, but these are not real aliases. So I started managing smtpd aliases through ansible, and it was really painful to add a new alias every time I needed one.  Did I mention I like this alias feature? :D

If I want to send an end-to-end encrypted email without GPG, there is an option to use a password to protect the content, the email would actually send a link to the recipient, leading to a Proton Mail interface asking for the password to decrypt the content, and allow that person to reply.  I have no idea if I will ever use it, but at least it is a more user-friendly end-to-end encryption method.  Tuta is offering the same feature, but it is there only e2e method.

Proton offer logs of login attempts on my account, this was surprising.

There is an onion access to their web services in case you prefer to connect using tor.

The web interface is open source, one should be able to build it locally to connect to Proton servers, I guess it should work?

=> https://github.com/ProtonMail/WebClients GitHub project page: ProtonMail webclients

## Shortcomings

Proton Mail cannot be used as an SMTP relay by my servers, except through the open source bridge hydroxide.

The calendar only works on the website and the smartphone app. The calendar it does not integrate with the phone calendar, although in practice I did not find it to be an issue, everything works fine.  Contact support is less good on Android, they are restrained in the Mail app and I still have my cardav server.

The web app is first class citizen, but at least it is good.

Nothing prevents Proton Mail from catching your incoming and outgoing emails, you need to use end-to-end encryption if you REALLY need to protect your emails from that.

I was using two accounts, this would require a "duo" subscription on Proton Mail which is more expensive.  I solved this by creating two identities, label and filter rules to separate my two "accounts" (personal and professional) emails.  I actually do not really like that, although it is not really an issue at the moment as one of them is relatively low traffic.

The price is certainly high, the "Mail plus" plan is 4€ / month (48€ / year) if you subscribe for 12 months, but is limited to 1 domain, 10 aliases and 15 GB of storage.  The "Proton Unlimited" plan is 10€ / month (120€ / year) but comes with the kitchen sink: infinite aliases, 3 domains, 500 GB storage, and access to all Proton services (that you may not need...) like VPN, Drive and Pass.  In comparison, hosting your email service on a cheap server should not cost you more than 70€ / year, and you can self-host a nextcloud / seafile (equivalent to Drive, although it is stored encrypted there), a VPN and a vaultwarden instance (equivalent to Pass) in addition to the emails.

Emails are limited to 25MB, which is low given I always configured my own server to allow 100 MB attachments, but it created delivery issues on most recipient servers, so it is not a _real_ issue, but I prefer when I can decide of this kind of limitation.

## Alternatives

I evaluated Tuta too, but for the following reasons I dropped the idea quickly:



Their service is cool though, but not for me.

# My ideal email setup

If I was to self-host again (which may be soon! Who knows), I would do it differently to improve the security:



Only the SMTP server would be publicly available, all ports would be closed on all servers, servers would communicate between each other through a VPN, and exports their logs to a server that would only be used for forensics and detecting security breaches.

Such setup would be an improvement if I was self-hosting again my emails, but the cost and time to operate is non-negligible.  It is also an ecological nonsense to need 3 servers for a single person emails.

# Conclusion

I started this blog post with the fact that the decision was hard, so hard that I was not able to decide up to a day before renewing my email server for one year.  I wanted to give Proton a chance for a month to evaluate it completely, and I have to admit I like the service much more than I expected...

My Unix hacker heart hurts terribly on this one.  I would like to go back to self-hosting, but I know I cannot reach the level of security I was looking for, simply because email sucks in the first place.  A solution would be to get rid of this huge archive burden I am carrying, but I regularly search information into this archive and I have not found any usable "mail archive system" that could digest everything and serve it locally.

## Update 2024-09-14

I wrote this blog post two days ago, and I cannot stop thinking about this topic since the migration.

The real problem certainly lies in my use case, not having my emails on the remote server would solve my problems.  I need to figure how to handle it.  Stay tuned :-)
</pre>
    ]]>
  </description>
  <guid>gemini://perso.pw/blog//articles/email-selfhost-to-protonmail.gmi</guid>
  <link>gemini://perso.pw/blog//articles/email-selfhost-to-protonmail.gmi</link>
  <pubDate>Sun, 15 Sep 2024 00:00:00 GMT</pubDate>
</item>
<item>
  <title>Self-hosting at home and privacy</title>
  <description>
    <![CDATA[
<pre># Introduction

You may self-host services at home, but you need to think about the potential drawbacks for your privacy.

Let's explore what kind of information could be extracted from self-hosting, especially when you use a domain name.

# Public information

## Domain WHOIS

A domain name must expose some information through WHOIS queries, basically who is the registrar responsible for it, and who could be contacted for technical or administration matters.

Almost every registrar will offer you feature to hide your personal information, you certainly not want to have your full name, full address and phone number exposed on a single WHOIS request.

You can perform a WHOIS request on the link below, directly managed by ICANN.

=> https://lookup.icann.org/en ICANN Lookup

## TLS certificates using ACME

If you use TLS certificates for your services, and ACME (Let's Encrypt or alternatives), all the domains for which a certificate was emitted can easily be queried.

You can visit the following website, type a domain name, and you will immediately have a list of existing domain names.

=> https://crt.sh/ crt.sh Certificate Search

In such situation, if you planned to keep a domain hidden by not sharing it with anyone, you got it wrong.

## Domain name

If you use a custom domain in your email, it is highly likely that you have some IT knowledge and that you are the only user of your email server.

Using this statement (IT person + only domain user), someone having access to your email address can quickly search for anything related to your domain and figure it is related to you.

## Public IP

Anywhere you connect, your public IP is known of the remote servers.

Some bored sysadmin could take a look at the IPs in their logs, and check if some public service is running on it, polling for secure services (HTTPS, IMAPS, SMTPS) will immediately give associated domain name on that IP, then they could search even further.

# Mitigations

There are not many solutions to prevent this, unfortunately.

The public IP situation could be mitigated by either continuing hosting at home by renting a cheap server with a public IP and establish a VPN between the two and use the public IP of the server for your services, or to move your services to such remote server.  This is an extract cost of course.  When possible, you could expose the service over Tor hidden service or I2P if it works for your use case, you would not need to rent a server for this.

The TLS certificates names being public could be easily solved by generating self-signed certificates locally, and deal with it.  Depending on your services, it may be just fine, but if you have strangers using the services, the fact to accept to trust the certificate on first use (TOFU) may appear dangerous.  Some software fail to connect to self-signed certificates and do not offer a bypass...

# Conclusion

Self-hosting at home can be practical for various reasons: reusing old hardware, better local throughput, high performance for cheap... but you need to be aware of potential privacy issues that could come with it.
</pre>
    ]]>
  </description>
  <guid>gemini://perso.pw/blog//articles/self-hosting-at-home-privacy-issues.gmi</guid>
  <link>gemini://perso.pw/blog//articles/self-hosting-at-home-privacy-issues.gmi</link>
  <pubDate>Thu, 12 Sep 2024 00:00:00 GMT</pubDate>
</item>
<item>
  <title>How to use Proton VPN port forwarding</title>
  <description>
    <![CDATA[
<pre># Introduction

If you use Proton VPN with the paid plan, you have access to their port forwarding feature.  It allows you to expose a TCP and/or UDP port of your machine on the public IP of your current VPN connection.

This can be useful for multiple use cases, let's see how to use it on Linux and OpenBSD.

=> https://protonvpn.com/support/port-forwarding-manual-setup/ Proton VPN documentation: port forwarding setup

If you do not have a privacy need with regard to the service you need to expose to the Internet, renting a cheap VPS is a better solution: cheaper price, stable public IP, no weird script for port forwarding, use of standard ports allowed, reverse DNS, etc...

# Feature explanation

Proton VPN port forwarding feature is not really practical, at least not as practical as doing a port forwarding with your local router.  The NAT is done using NAT-PMP protocol (an alternative to UPnP), you will be given a random port number for 60 seconds.  The random port number is the same for TCP and UDP.

=> https://en.wikipedia.org/wiki/NAT_Port_Mapping_Protocol Wikipedia page about NAT Port Mapping Protocol

There is a NAT PMPC client named `natpmpc` (available almost everywhere as a package) that need to run in an infinite loop to renew the port lease before it expires.

This is rather not practical for multiple reasons:



Although it has shortcomings, it is a useful feature that was dropped by other VPN providers because of abuses.

# Setup

Let me share a script I am using on Linux and OpenBSD that does the following:



You can run the script from supervisord (a process manager) to restart it upon failure.

=> http://supervisord.org/ Supervisor official project website

In the example, the Java daemon I2P will be used to demonstrate the configuration update using sed after being assigned the port number.

## OpenBSD

Install the package `natpmpd` to get the NAT-PMP client.

Create a script with the following content, and make it executable:

!/bin/sh

PORT=$(natpmpc -a 1 0 udp 60 -g 10.2.0.1 | awk '/Mapped public/ { print $4 }')

check if the current port is correct

grep "$PORT" /var/i2p/router.config || /etc/rc.d/i2p stop

update the port in I2P config

sed -i -E "s,(^i2np.udp.port).*,\1=$PORT, ; s,(^i2np.udp.internalPort).*,\1=$PORT," /var/i2p/router.config

make sure i2p is started (in case it was stopped just before)

/etc/rc.d/i2p start

while true

do

date # use for debug only

natpmpc -a 1 0 udp 60 -g 10.2.0.1 && natpmpc -a 1 0 tcp 60 -g 10.2.0.1 || { echo "error Failure natpmpc $(date)"; break ; }

sleep 45

done


The script will search for the port number in I2P configuration, stop the service if the port is not found.  Then the port line is modified with sed (in all cases, it does not matter much).  Finally, i2p is started, this will only do something in case i2p was stopped before, otherwise nothing happens.

Then, in an infinite loop with a 45 seconds frequency, there is a renewal of the TCP and UDP port  forwarding happening.  If something wrong happens, the script exits.

### Using supervisord

If you want to use supervisord to start the script at boot and maintain it running, install the package `supervisor` and create the file `/etc/supervisord.d/nat.ini` with the following content:

[program:natvpn]

command=/etc/supervisord.d/continue_nat.sh ; choose the path of your script

autorestart=unexpected ; when to restart if exited after running (def: unexpected)


Enable supervisord at boot, start it and verify it started (a configuration error prevents it from starting):

rcctl enable supervisord

rcctl start supervisord

rcctl check supervisord


### Without supervisord

Open a shell as root and execute the script and keep the terminal opened, or run it in a tmux session.

## Linux

The setup is exactly the same as for OpenBSD, just make sure the package providing `natpmpc` is installed.

Depending on your distribution, if you want to automate the script running / restart, you can run it from a systemd service with auto restart on failure, or use supervisord as explained above.

If you use a different network namespace, just make sure to prefix the commands using the VPN with `ip netns exec vpn`.

Here is the same example as above but using a network namespace named "vpn" to start i2p service and do the NAT query.


!/bin/sh

PORT=$(ip netns exec vpn natpmpc -a 1 0 udp 60 -g 10.2.0.1 | awk '/Mapped public/ { print $4 }')

FILE=/var/i2p/.i2p/router.config

grep "$PORT" $FILE || sudo -u i2p /var/i2p/i2prouter stop

sed -i -E "s,(^i2np.udp.port).*,\1=$PORT, ; s,(^i2np.udp.internalPort).*,\1=$PORT," $FILE

ip netns exec vpn sudo -u i2p /var/i2p/i2prouter start

while true

do

date

ip netns exec vpn natpmpc -a 1 0 udp 60 -g 10.2.0.1 && ip netns exec vpn natpmpc -a 1 0 tcp 60 -g 10.2.0.1 || { echo "error Failure natpmpc $(date)"; break ; }

sleep 45

done


# Conclusion

Proton VPN port forwarding feature is useful when need to expose a local network service on a public IP.  Automating it is required to make it work efficiently due to the unusual implementation.
</pre>
    ]]>
  </description>
  <guid>gemini://perso.pw/blog//articles/protonvpn-port-forwarding.gmi</guid>
  <link>gemini://perso.pw/blog//articles/protonvpn-port-forwarding.gmi</link>
  <pubDate>Tue, 03 Sep 2024 00:00:00 GMT</pubDate>
</item>
<item>
  <title>Emails encryption at rest on OpenBSD using dovecot and GPG</title>
  <description>
    <![CDATA[
<pre># Introduction

In this blog post, you will learn how to configure your email server to encrypt all incoming emails using user's GPG public keys (when it exists).  This will prevent anyone from reading the emails, except if you own the according GPG private key.  This is known as "encryption at rest".

This setup, while effective, has limitations.  Headers will not be encrypted, search in emails will break as the content is encrypted, and you obviously need to have the GPG private key available when you want to read your emails (if you read emails on your smartphone, you need to decide if you really want your GPG private key there).

Encryption is CPU consuming (and memory too for emails of a considerable size), I tried it on an openbsd.amsterdam virtual machine, and it was working fine until someone sent me emails with 20MB attachments.  On a bare-metal server, there is absolutely no issue.  Maybe GPG makes use of hardware acceleration cryptography, and it is not available in virtual machines hosted under the OpenBSD hypervisor vmm.

This is not an original idea, Etienne Perot wrote about a similar setup in 2012 and enhanced the `gpgit` script we will use in the setup.  While his blog post is obsolete by now because of all the changes that happened in Dovecot, the core idea remains the same.  Thank you very much Etienne for your job!

=> https://perot.me/encrypt-specific-incoming-emails-using-dovecot-and-sieve Etienne Perot: Encrypt specific incoming emails using Dovecot and Sieve
=> https://github.com/EtiennePerot/gpgit gpgit GitHub project page
=> https://tildegit.org/solene/gpgit gpgit mirror on tildegit.org

This guide is an extension of my recent email server setup guide:

=> https://dataswamp.org/~solene/2024-07-24-openbsd-email-server-setup.html 2024-07-24 Full-featured email server running OpenBSD

# Threat model

This setup is useful to protect your emails stored on the IMAP server. If the server or your IMAP account are compromised, the content of your emails will be encrypted and unusable.

You must be aware that emails headers are not encrypted: recipients / senders / date / subject will remain in clear text even after encryption.  If you already use end-to-end encryption with your recipients, there are no benefits using this setup.

An alternative is to not let any emails on the IMAP server, although they could be recovered as they are written in the disk until you retrieve them.

Personally, I keep many emails of my server, and I am afraid that a 0day vulnerability could be exploited on my email server, allowing an attacker to retrieve the content of all my emails.  OpenSMTPD had critical vulnerabilities a few years ago, including a remote code execution, so it is a realistic threat.

I wrote a privacy guide (for a client) explaining all the information shared through emails, with possible mitigations and their limitations.

=> https://www.ivpn.net/privacy-guides/email-and-privacy/ IVPN: The Technical Realities of Email Privacy

# Setup

This setup makes use of the program `gpgit` which is a Perl script encrypt emails received over the standard input using GPG, it is a complicated task because the email structure can be very complicated.  I have not been able to find any alternative to this script.  In gpgit repository there is a script to encrypt an existing mailbox (maildir format), that script must be run on the server, I did not test it yet.

You will configure a specific sieve rule which is "global" (not user-defined) that will process all emails before any other sieve filter.  This sieve script will trigger a `filter` (a program allowed to modify the email) and pass the email on the standard input of the shell script `encrypt.sh`, which in turn will run `gpgit` with the according username after verifying a gnupg directory existed for them.  If there is no gnupg directory, the email is not encrypted, this allows multiple users on the email server without enforcing encryption for everyone.

If a user has multiple addresses, this is the system account name that is used in the local part of the GPG key address.

## GPGit

Some packages are required for gpgit to work, they are all available on OpenBSD:

pkg_add p5-Mail-GnuPG p5-List-MoreUtils


Download gpgit git repository and copy its `gpgpit` script into `/usr/local/bin/` as an executable:

cd /tmp/

git clone https://github.com/EtiennePerot/gpgit

cd gpgit

install -o root -g wheel -m 555 gpgit /usr/local/bin/


## Sieve

All the following paths will be relative to the directory `/usr/local/lib/dovecot/sieve/`, you can `cd` into it now.

Create the file `encrypt.sh` with this content, replace the variable `DOMAIN` with the domain configured in the GPG key:

!/bin/sh

DOMAIN="puffy.cafe"

NOW=$(date +%s)

DATA="$(cat)"

if test -d ~/.gnupg

then

echo "$DATA" | /usr/local/bin/gpgit "${USER}@${DOMAIN}"

NOW2=$(date +%s)

echo "Email encryption for user ${USER}: $(( NOW2 - NOW )) seconds" | logger -p mail.info

else

echo "$DATA"

echo "Email encryption for user for ${USER} none" | logger -p mail.info

fi


Make the script executable with `chmod +x encrypt.sh`.  This script will create a new log line in your email logs every time an email is processed, including the username and the time required for encryption (in case of encryption).  You could extend the script to discard the `Subject` header from the email if you want to hide it, I do not provide the implementation as I expect this task to be trickier than it looks like if you want to handle all corner cases.

Create the file `global.sieve` with the content:

require ["vnd.dovecot.filter"];

filter "encrypt.sh";


Compile the sieve rules with `sievec global.sieve`.

## Dovecot

Edit the file `/etc/dovecot/conf.d/90-plugin.conf` to add the following code within the `plugin` block:

sieve_filter_bin_dir = /usr/local/lib/dovecot/sieve

sieve_global_extensions = +vnd.dovecot.pipe +vnd.dovecot.environment +vnd.dovecot.filter

sieve_before = /usr/local/lib/dovecot/sieve/global.sieve

sieve_filter_exec_timeout = 200s


You may have `sieve_global_extensions` already set, in that case update its value.

The variable `sieve_filter_exec_timeout` allows the script `encrypt.sh` to run for 200 seconds before being stopped, you should adapt the value to your system.  I came up with 200 seconds to be able to encrypt email with 20MB attachments on an openbsd.amsterdam virtual machine.  On a bare metal server with a Ryzen 5 CPU, it takes less than one second for the same email.

The full file should look like the following (in case you followed my previous email guide):

Plugin settings

All wanted plugins must be listed in mail_plugins setting before any of the

settings take effect. See <doc/wiki/Plugins.txt> for list of plugins and

their configuration. Note that %variable expansion is done for all values.

plugin {

sieve_plugins = sieve_imapsieve sieve_extprograms

# From elsewhere to Spam folder

imapsieve_mailbox1_name = Spam

imapsieve_mailbox1_causes = COPY

imapsieve_mailbox1_before = file:/usr/local/lib/dovecot/sieve/report-spam.siev

# From Spam folder to elsewhere

imapsieve_mailbox2_name = *

imapsieve_mailbox2_from = Spam

imapsieve_mailbox2_causes = COPY

imapsieve_mailbox2_before = file:/usr/local/lib/dovecot/sieve/report-ham.sieve

sieve_pipe_bin_dir = /usr/local/lib/dovecot/sieve

# for GPG encryption

sieve_filter_bin_dir = /usr/local/lib/dovecot/sieve

sieve_global_extensions = +vnd.dovecot.pipe +vnd.dovecot.environment +vnd.dovecot.filter

sieve_before = /usr/local/lib/dovecot/sieve/global.sieve

sieve_filter_exec_timeout = 200s

}


Open the file `/etc/dovecot/conf.d/10-master.conf` and uncomment the variable `default_vsz_limit` and set its value to `1024M`. This is required as GPG uses a lot of memory and without this, the process will be killed and the email lost.  I found 1024M to works with attachments up to 45 MB, however you should raise this value higher value if you plan to receive bigger attachments.

Restart dovecot to take account of the changes: `rcctl restart dovecot`.

## User GPG setup

You need to create a GPG keyring for each users you want use encryption, the simplest method is to setup a passwordless keyring and import your public key:

$ gpg --quick-generate-key --passphrase '' --batch "$USER"

$ gpg --import public-key-file.asc

$ gpg --edit-key FINGERPRINT_HERE

gpg> sign

[....]

gpg> save


If you want to disable GPG encryption for the user, remove the directory `~/.gnupg`.

## Anti-spam service

If you use a spam filter such as rspamd or spamassassin relying on bayes filter, it will only work if it process the emails before arriving at dovecot, for instance in my email setup this is the case as rspamd is a filter of opensmtpd and pass the email before being delivered to Dovecot.

Such service can have privacy issues, especially if you use encryption.  Bayes filter works by splitting an email content into tokens (not really words but almost) and looking for patterns using these tokens, basically each emails is split and stored in the anti-spam local database in small parts.  I am not sure one could recreate the emails based on tokens, but if someone like an attacker is able to access the token list, they may have some insights about your email content.  If this is part of your threat model, disable your anti-spam Bayes filter.

# Conclusion

This setup is quite helpful if you want to protect all your emails on their storage.  Full disk encryption on the server does not prevent anyone able to connect over SSH (as root or the email user) from reading the emails, even file recovery is possible when the volume is unlocked (not on the real disk, but the software encrypted volume), this is where encryption at rest is beneficial.

I know from experience it is complicated to use end-to-end encryption with tech-savvy users, and that it is even unthinkable with regular users.  This is a first step if you need this kind of security (see the threat model section), but you need to remember a copy of all your emails certainly exist on the servers used by the persons you exchange emails with.
</pre>
    ]]>
  </description>
  <guid>gemini://perso.pw/blog//articles/automatic-emails-gpg-encryption-at-rest.gmi</guid>
  <link>gemini://perso.pw/blog//articles/automatic-emails-gpg-encryption-at-rest.gmi</link>
  <pubDate>Mon, 19 Aug 2024 00:00:00 GMT</pubDate>
</item>
<item>
  <title>Using Firefox remote debugging feature</title>
  <description>
    <![CDATA[
<pre># Introduction

Firefox has an interesting features for developers, its ability to connect a Firefox developers tools to a remote Firefox instance.  This can really interesting in the case of a remote kiosk display for instance.
The remote debugging does not provide a display of the remote, but it gives you access to the developer tools for tabs opened on the remote.

# Setup

The remote firefox you want to connect to must be started using the command line parameter `--start-debugger-server`.  This will make it listen on the TCP port 6000 on 127.0.0.1.  Be careful, there is another option named `remote-debugging-port` which is not what you want here, but the names can be confusing (trust me, I wasted too much time because of this).

Before starting Firefox, a few knobs must be modified in its configuration.  Either search for the options in `about:config` or create a `user.js` file in the Firefox profile directory with the following content:

user_pref("devtools.chrome.enabled", true);

user_pref("devtools.debugger.remote-enabled", true);

user_pref("devtools.debugger.prompt-connection", false);


This enables the remote management and removes a prompt upon each connection, while this is a good safety measure, it is not practical for remote debugging.

When you start Firefox, the URL input bar should have a red background.

# Remote connection

Now, you need to make a SSH tunnel to that remote host where Firefox is running in order to connect to the port.  Depending on your use case, a local NAT could be done to expose the port to a network interface or VPN interface, but pay attention to security as this would allow anyone on the network to control the Firefox instance.

The SSH tunnel is quite standard: `ssh -L 6001:127.0.0.1:6000`, the remote port 6000 is exposed locally as 6001, this is important because your own Firefox may be using the port 6000 for some reasons.

In your own local Firefox instance, visit the page `about:debugging`, add the remote instance `localhost:6001` and then click on Connect on its name on the left panel.  Congratulations, you have access to the remote instance for debugging or profiling websites.

=> static/firefox-debug-add-remote-fs8.png Input the remote address localhost:6001 and click on Add

=> static/firefox-debug-left-panel-fs8.png Click on connect on the left

=> static/firefox-debug-access-fs8.png Enjoy your remote debugging session


# Conclusion

While it can be tricky to debug a system you can directly see, especially if it is a kiosk in production that you can see / use in case of a problem.
</pre>
    ]]>
  </description>
  <guid>gemini://perso.pw/blog//articles/remote-firefox-debug.gmi</guid>
  <link>gemini://perso.pw/blog//articles/remote-firefox-debug.gmi</link>
  <pubDate>Thu, 08 Aug 2024 00:00:00 GMT</pubDate>
</item>
<item>
  <title>Full-featured email server running OpenBSD</title>
  <description>
    <![CDATA[
<pre># Introduction

This blog post is a guide explaining how to setup a full-featured email server on OpenBSD 7.5.  It was commissioned by a customer of my consultancy who wanted it to be published on my blog.

Setting up a modern email stack that does not appear as a spam platform to the world can be a daunting task, the guide will cover what you need for a secure, functional and low maintenance email system.

The features list can be found below:



In the example, I will set up a temporary server for the domain `puffy.cafe` with a server using the subdomain `mail.puffy.cafe`.  From there, you can adapt with your own domain.

# Quick reminder

I prepared a few diagrams explaining how all the components are used together, in three cases: when sending an email, when the SMTP servers receives an email from the outside and when you retrieve your emails locally.

=> static/img/email-setup-authenticated-mail-delivery.dot.png Authenticated user sending an email to the outside

=> static/img/email-setup-receiving-email.dot.png Outside sending an email to one of our users

=> static/img/email-setup-retrieving-emails.dot.png User retrieving emails for reading

# Packet Filter (PF)

Packet Filter is OpenBSD's firewall.  In our setup, we want all ports to be blocked except the few ones required for the email stack.

The following ports will be required:



Depending on what services you will use, only the opensmtpd ports are mandatory.  In addition, we will open the port 22/tcp for SSH.

set block-policy drop

set loginterface egress

set skip on lo0

normalisation des paquets

match in all scrub (no-df random-id max-mss 1440)

antispoof quick for { egress }

tcp_ports = "{ smtps smtp submission imaps pop3s sieve ssh http }"

block all

pass out inet

pass out inet6

allow ICMP (ping)

pass in proto icmp

allow IPv6 to work

pass in on egress inet6 proto icmp6 all icmp6-type { routeradv neighbrsol neighbradv }

pass in on egress inet6 proto udp from fe80::/10 port dhcpv6-server to fe80::/10 port dhcpv6-client no state

allow our services

pass in on egress proto tcp from any to any port $tcp_ports

default OpenBSD rules

By default, do not permit remote connections to X11

block return in on ! lo0 proto tcp to port 6000:6010

Port build user does not need network

block return out log proto {tcp udp} user _pbuild


# DNS

If you want to run your own email server, you need a domain name configured with a couple of DNS records about the email server.

## MX records

=> https://en.wikipedia.org/wiki/MX_record Wikipedia page: MX record

The MX records list the servers that should be used by outside SMTP servers to send us emails, this is the public list of our servers accepting emails for a given domain.  They have a weight associated to each of them, the server with the lowest weight should be used first and if it does not respond, the next server used will be the one with a slightly higher weight.  This is a simple mechanism that allow setting up a hierarchy.

I highly recommend setting up at least two servers, so if your main server fails is unreachable (host outage, hardware failure, upgrade ongoing) the emails will be sent to the backup server. Dovecot bundles a program to synchronize mailboxes between servers, one way or two-way, one shot or continuously.

If you have no MX records in your domain name, it is not possible to send you emails. It is like asking someone to send you a post card without giving them any clue about your real address.

Your server hostname can be different from the domain apex (raw domain name without a subdomain), a simple example would be to use `mail.domain.example` for the server name, this will not prevent it from receiving/sending emails using `@domain.example` in email addresses.

In my example, the domain puffy.cafe mail server will be mail.puffy.cafe, giving this MX record in my DNS zone:

IN MX 10 mail.puffy.cafe.


## SPF

=> https://en.wikipedia.org/wiki/Sender_Policy_Framework Wikipedia page: SPF record

The SPF record is certainly the most important piece of the email puzzle to detect spam.  With the SPF, the domain name owner can define which servers are allowed to send emails from that domain.  A properly configured spam filter will give a high spam score to incoming emails that are not in the sender domain SPF.

To ease the configuration, that record can automatically include all MX defined for a domain, but also A/AAAA records, so if you only use your MX servers for sending, a simple configuration allowing MX servers to send is enough.

In my example, only mail.puffy.cafe should be legitimate for sending emails, any future MX server should also be allowed to send emails, so we configure the SPF to allow all MX defined servers to be senders.

600 IN TXT "v=spf1 mx -all"


## DKIM

=> https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail Wikipedia page: DKIM signature

When used, the DKIM is a system allowing a receiver to authenticate a sender, based on an asymmetric cryptographic keys.  The sender publishes its public key on a TXT DNS record before signing all outgoing emails using the private key.  By doing so, receivers can validate the email integrity and make sure it was sent from a server of the domain claimed in the From header.

DKIM is mandatory to not be classified as a spamming server.

The following set of commands will create a 2048 bits RSA key in `/etc/mail/dkim/private/puffy.cafe.key` with its public key in `/etc/mail/dkim/puffy.cafe.pub`, the `umask 077` command will make sure any file created during the process will only be readable by root.  Finally, you need to make the private key readable to the group `_rspamd`.

Note: the umask command will persist in your shell session, if you do not want to create files/directory only readable by root after this, either spawn a new shell, or run the set of commands in a new shell and then exit from it once you are done.

umask 077

install -d -o root -g wheel -m 755 /etc/mail/dkim

install -d -o root -g _dkim -m 775 /etc/mail/dkim/private

openssl genrsa -out /etc/mail/dkim/private/puffy.cafe.key 2048

openssl rsa -in /etc/mail/dkim/private/puffy.cafe.key -pubout -out /etc/mail/dkim/puffy.cafe.pub

chgrp _rspamd /etc/mail/dkim/private/puffy.cafe.key /etc/mail/dkim/private/

chmod 440 /etc/mail/dkim/private/puffy.cafe.key

chmod 775 /etc/mail/dkim/private/


In this example, we will name the DKIM selector `dkim` to keep it simple.  The selector is the name of the key, this allows having multiple DKIM keys for a single domain.

Add the DNS record like the following, the value in `p` is the public key in the file `/etc/mail/dkim/puffy.cafe.pub`, you can get it as a single line with the command `awk '/PUBLIC/ { $0="" } { printf ("%s",$0) } END { print }' /etc/mail/dkim/puffy.cafe.pub`:

Your registrar may offer to add the entry using a DKIM specific form.  There is nothing wrong doing so, just make sure the produced entry looks like the entry below.

dkim._domainkey IN TXT "v=DKIM1;k=rsa;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAo3tIFelMk74wm+cJe20qAUVejD0/X+IdU+A2GhAnLDpgiA5zMGiPfYfmawlLy07tJdLfMLObl8aZDt5Ij4ojGN5SE1SsbGC2MTQGq9L2sLw2DXq+D8YKfFAe0KdYGczd9IAQ9mkYooRfhF8yMc2sMoM75bLxGjRM1Fs1OZLmyPYzy83UhFYq4gqzwaXuTvxvOKKyOwpWzrXzP6oVM7vTFCdbr8E0nWPXWKPJhcd10CF33ydtVVwDFp9nDdgek3yY+UYRuo/iJvdcn2adFoDxlE6eXmhGnyG4+nWLNZrxIgokhom5t5E84O2N31YJLmqdTF+nH5hTON7//5Kf/l/ubwIDAQAB"


## DMARC

=> https://en.wikipedia.org/wiki/DMARC Wikipedia page: DMARC record

The DMARC record is an extra mechanism that comes on top of SPF/DKIM, while it does not do much by itself, it is important to configure it.

DMARC could be seen as a public notice explaining to servers receiving emails whose sender looks like your domain name (legit or not) what they should do if SPF/DKIM does not validate.

As of 2024, DMARC offers three actions for receivers:



In my example, I want invalid SPF/DKIM emails to be rejected.  It is quite arbitrary, but I prefer all invalid emails from my domain to be discarded rather than ending up in a spam directory, so `p` and `sp` are set to `reject`.  In addition, if my own server is misconfigured I will be notified about delivery issues sooner than if emails were silently put into quarantine.

An email address should be provided to receive DMARC reports, they are barely readable and I never made use of them, but the email address should exist so this is what the `rua` field is for.

The field `aspf` is set to `r` (relax), basically this allows any servers with a hostname being a subdomain of `.puffy.cafe` to send emails for `@puffy.cafe`, while if this field is set to `s` (strict), the domain of the sender should match the domain of the email server (`mail.puffy.cafe` would only be allowed to send for `@mail.puffy.cafe`).

=> https://mxtoolbox.com/dmarc/details/dmarc-tags Mx Toolbox website: DMARC tags list

_dmarc IN TXT "v=DMARC1;p=reject;rua=mailto:dmarc@puffy.cafe;sp=reject;aspf=r;"


## PTR (Reverse DNS)

=> https://en.wikipedia.org/wiki/Reverse_DNS_lookup Wikipedia page: PTR record

An older mechanism used to prevent spam was to block, or consider as spam, any SMTP server whose advertised hostname did not match the result of the reverse lookup of its IP.

Let's say "mail.foobar.example" (IP: A.B.C.D) is sending an email to my server, if the result of the DNS request to resolve the PTR of A.B.C.D is not "mail.foobar.example", the email would be considered as spam or rejected.  While this is superseded by SPF/DKIM and annoying as it is not always possible to define a PTR for a public IP, the reverse DNS setup is still a strong requirement to not be considered as a spamming platform.

Make sure the PTR matches the system hostname and not the domain name itself, in the example above the PTR should be `mail.foobar.example` and not `foobar.example`.

# System configuration

## Acme-client

The first step is to obtain a valid TLS certificate, this requires configuring acme-client, httpd and start httpd daemon.

Copy the acme-client example `cp /etc/examples/acme-client.conf /etc/`

Modify `/etc/acme-client.conf` and edit only the last entry to configure your own domain, mine looks like this:

$OpenBSD: acme-client.conf,v 1.5 2023/05/10 07:34:57 tb Exp $

authority letsencrypt {

api url "https://acme-v02.api.letsencrypt.org/directory"

account key "/etc/acme/letsencrypt-privkey.pem"

}

authority letsencrypt-staging {

api url "https://acme-staging-v02.api.letsencrypt.org/directory"

account key "/etc/acme/letsencrypt-staging-privkey.pem"

}

authority buypass {

api url "https://api.buypass.com/acme/directory"

account key "/etc/acme/buypass-privkey.pem"

contact "mailto:me@example.com"

}

authority buypass-test {

api url "https://api.test4.buypass.no/acme/directory"

account key "/etc/acme/buypass-test-privkey.pem"

contact "mailto:me@example.com"

}

domain mail.puffy.cafe {

# you can remove the line "alternative names" if you do not need extra subdomains

# associated to this certificate

# imap.puffy.cafe is purely an example, I do not need it

alternative names { imap.puffy.cafe pop.puffy.cafe }

domain key "/etc/ssl/private/mail.puffy.cafe.key"

domain full chain certificate "/etc/ssl/mail.puffy.cafe.fullchain.pem"

sign with letsencrypt

}


Now, configure httpd, starting from the OpenBSD example: `cp /etc/examples/httpd.conf /etc/`

Edit `/etc/httpd.conf`, we want the first block to match all domains but not "example.com", and we do not need the second block listen on 443/tcp (except if you want to run a https server with some content, but you are on your own then).  The resulting file should look like the following:

$OpenBSD: httpd.conf,v 1.22 2020/11/04 10:34:18 denis Exp $

server "*" {

listen on * port 80

location "/.well-known/acme-challenge/*" {

root "/acme"

request strip 2

}

location * {

block return 302 "https://$HTTP_HOST$REQUEST_URI"

}

}


Enable and start httpd with `rcctl enable httpd && rcctl start httpd`.

Run `acme-client -v mail.puffy.cafe` to generate the certificate with some verbose output (if something goes wrong, you will have a clue).

If everything went fine, you should have the full chain certificate in `/etc/ssl/mail.puffy.cafe.fullchain.pem` and the private key in `/etc/ssl/private/mail.puffy.cafe.key`.

## Rspamd

You will use rspamd to filter spam and sign outgoing emails for DKIM.

Install rspamd and the filter to plug it to opensmtpd:

pkg_add rspamd-- opensmtpd-filter-rspamd


You need to configure rspamd to sign outgoing emails with your DKIM private key, to proceed, create the file `/etc/rspamd/local.d/dkim_signing.conf` (the filename is important):

our usernames does not contain the domain part

so we need to enable this option

allow_username_mismatch = true;

this configures the domain puffy.cafe to use the selector "dkim"

and where to find the private key

domain {

puffy.cafe {

path = "/etc/mail/dkim/private/puffy.cafe.key";

selector = "dkim";

}

}


For better performance, you need to use redis as a cache backend for rspamd:

rcctl enable redis

rcctl start redis


Now you can start rspamd:

rcctl enable rspamd

rcctl start rspamd


For extra information about rspamd (like statistics or its web UI), I wrote about it in 2021:

=> https://dataswamp.org/~solene/2021-07-13-smtpd-rspamd.html Older blog post: 2024-07-13 Filtering spam using Rspamd and OpenSMTPD on OpenBSD

### Alternatives

If you do not want to use rspamd, it is possible to replace the DKIM signing part using `opendkim`, `dkimproxy` or `opensmtpd-filter-dkimsign`.  The spam filter could be either replaced by the featureful `spamassassin` available as a package, or partially with the base system program `spamd` (it does not analyze emails).

This guide only focus on rspamd, but it is important to know alternatives exist.

## OpenSMTPD

OpenSMTPD configuration file on OpenBSD is `/etc/mail/smtpd.conf`, here is a working configuration with a lot of comments:

this defines the paths for the X509 certificate

pki puffy.cafe cert "/etc/ssl/mail.puffy.cafe.fullchain.pem"

pki puffy.cafe key "/etc/ssl/private/mail.puffy.cafe.key"

pki puffy.cafe dhe auto

this defines how the local part of email addresses can be split

defaults to '+', so solene+foobar@domain matches user

solene@domain. Due to the '+' character being a regular source of issues

with many online forms, I recommend using a character such as '_',

'.' or '-'. This feature is very handy to generate infinite unique emails

addresses without pre-defining aliases.

Using '_', solene_openbsd@domain and solene_buystuff@domain lead to the

same address

smtp sub-addr-delim '_'

this defines an external filter

rspamd does dkim signing and spam filter

filter rspamd proc-exec "filter-rspamd"

this defines which file will contain aliases

this can be used to define groups or redirect emails to users

table aliases file:/etc/mail/aliases

this defines all the ports to use

mask-src hides system hostname, username and public IP when sending an email

listen on all port 25 tls pki "puffy.cafe" filter "rspamd"

listen on all port 465 smtps pki "puffy.cafe" auth mask-src filter "rspamd"

listen on all port 587 tls-require pki "puffy.cafe" auth mask-src filter "rspamd"

this defines actions

either deliver to lmtp or to an external server

action "local" lmtp "/var/dovecot/lmtp" alias <aliases>

action "outbound" relay

this defines what should be done depending on some conditions

receive emails (local or from external server for "puffy.cafe")

match from any for domain "puffy.cafe" action "local"

match from local for local action "local"

send email (from local or authenticated user)

match from any auth for any action "outbound"

match from local for any action "outbound"


In addition, you can configure the advertised hostname by editing the file `/etc/mail/mailname`: for instance my machine's hostname is `ryzen` so I need this file to advertise it as `mail.puffy.cafe`.

Restart OpenSMTPD with `rcctl restart smtpd`.

### TLS

For ports using STARTTLS (25 and 587), there are different options with regard to TLS encryption.



It is recommended to enforce STARTTLS on port 587 as it is used by authenticated users to send emails, preventing them to send emails without network encryption.

On port 25, used by external servers to reach yours, it is important to allow STARTTLS because most server will deliver emails over an encrypted TLS session, however it is your choice to enforce it or not.

Enforcing STARTTLS might break email delivery from some external servers that are outdated or misconfigured (or bad actors).

### User management

By default, OpenSMTPD is configured to deliver email to valid users in the system.  In my example, if user `solene` exists, then email address `solene@puffy.cafe` will deliver emails to `solene` user mailbox.

Of course, as you do not want the system daemons to receive emails, a file contains aliases to redirect emails from a user to another, or simply discard it.

In `/etc/mail/aliases`, you can redirect emails to your username by adding a new line, in the example below I will redirect root emails to my user.

root: solene


It is possible to redirect to multiple users using a comma to separate them, this is handful if you want to create a local group delivering emails to multiple users.

Instead of a user, it is possible to append the incoming emails to a file, pipe them to a command or return an SMTP code.  The aliases(5) man pages contains all you need to know.

=> https://man.openbsd.org/aliases.5 OpenBSD manual pages: aliases(5)

Every time you modify this file, you need to run the command `smtpctl update table aliases` to reload the aliases table in OpenSMTPD memory.

You can add a new email account by creating a new user with a shell preventing login:

useradd -m -s /sbin/nologin username_here

passwd username_here


This user will not be able to do anything on the server but connecting to SMTP/IMAP/POP.  They will not be able to change their password either!

### Handling extra domains

If you need to handle emails for multiple domains, this is rather simple:



If you want to use a different aliases table for the other domain, you need to create a new aliases file and configure `/etc/mail/smtpd.conf` accordingly where the following lines should be added:

table lambda file:/etc/mail/aliases-lambda

action "local_mail_lambda" lmtp "/var/dovecot/lmtp" alias <lambda>

match from any for domain "lambda-puffy.eu" action "local_mail_lambda"


Note that the users will be the same for all the domains configured on the server.  If you want to have separate users per domains, or that "user a" on domain A and "user a" on domain B could be different persons / logins, you would need to setup virtual users instead of using system users.  Such setup is beyond the scope of this guide.

### Without Dovecot

It is possible to not use Dovecot.  Such setup can suit users who would like to download the maildir directory using rsync on their local computer, this is a one-way process and does not allow sharing a mailbox across multiple devices.  This reduces maintenance and attack surface at the cost of convenience.

This may work as a two-way access (untested) when using a software such as unison to keep both the local and remote directories synchronized, but be prepared to manage file conflicts!

If you want this setup, replace the following line in smtpd.conf

action "local" lmtp "/var/dovecot/lmtp" alias <aliases>


by this line: if you want to store the emails into a maildir format (a directory per email folder, a file per email), emails will be stored in the directory "Maildir" in user's homes.

action "local" maildir "~/Maildir/" junk alias <aliases>


or this line if you want to keep the mbox format (a single file with emails appended to it, not practical), the emails will be stored in /var/mail/$user.

action "local" mbox alias <aliases>


=> https://en.wikipedia.org/wiki/Maildir Wikipedia page: Maildir format
=> https://en.wikipedia.org/wiki/Mbox Wikipedia page: Mbox format

## Dovecot

Dovecot is an important piece of software for the domain end users, it provides protocols like IMAP or POP3 to read emails from a client.  It is the most popular open source IMAP/POP server available (the other being Cyrus IMAP).

Install dovecot with the following command line:

pkg_add dovecot-- dovecot-pigeonhole--


Dovecot has a lot of configuration files in `/etc/dovecot/conf.d/` although most of them are commented and ready to be modified, you will have to edit a few of them.  This guide provides the content of files with empty lines / comments stripped so you can quickly check if your file is ok, you can use the command `awk '$1 !~ /^#/ && $1 ~ /./'` on a file to display its "useful" content only (awk will not modify the file).

Modify `/etc/dovecot/conf.d/10-ssl.conf` and search the lines `ssl_cert` and `ssl_key`, change their values to your certificate full chain and private key.

Generate a Diffie-Hellman file for perfect forward secrecy, this will make each TLS negociation unique, so if the private key ever leak, every past TLS communication will remain safe.

openssl dhparam -out /etc/dovecot/dh.pem 4096

chown _dovecot:_dovecot /etc/dovecot/dh.pem

chmod 400 /etc/dovecot/dh.pem


The file (filtered of all comments/empty lines) should look like the following:

ssl_cert = </etc/ssl/mail.puffy.cafe.fullchain.pem

ssl_key = </etc/ssl/private/mail.puffy.cafe.key

ssl_dh = </etc/dovecot/dh.pem


Modify `/etc/dovecot/conf.d/10-mail.conf`, search for a commented line `mail_location`, uncomment it and set the value to `maildir:~/Maildir`, this will tell Dovecot where users mailboxes are stored and in which format, we want to use the maildir format.

The resulting file should look like:

mail_location = maildir:~/Maildir

namespace inbox {

inbox = yes

}

mmap_disable = yes

first_valid_uid = 1000

mail_plugin_dir = /usr/local/lib/dovecot

protocol !indexer-worker {

}

mbox_write_locks = fcntl


Modify the file `/etc/dovecot/conf.d/20-lmtp.conf`, LMTP is the protocol used by opensmtpd to transmit incoming emails to dovecot.  Search for the commented variable `mail_plugins` and uncomment it with the value `mail_plugins = $mail_plugins sieve`:

The resulting file should look like:

protocol lmtp {

mail_plugins = $mail_plugins sieve

}


If you do not want to use IMAP or POP3, you do not need Dovecot.  There is an explanation above how to proceed without Dovecot.

### IMAP

=> https://en.wikipedia.org/wiki/Internet_Message_Access_Protocol Wikipedia page: IMAP protocol

IMAP is an efficient protocol that returns headers of emails per directory, so you do not have to download all your emails to view the directory list, emails are downloaded upon read (by default in most email clients).  It allows some cool features like server side search, incoming email sorting with sieve filters or multi devices access.

Edit `/etc/dovecot/conf.d/20-imap.conf` and configure the last lines accordingly to the result file:

protocol imap {

mail_plugins = $mail_plugins imap_sieve

mail_max_userip_connections = 25

}


The number of connections per user/IP should be high if you have an email client tracking many folders, in IMAP a connection is required for each folder, so the number of connections can quickly increase.  On top of that, if you have multiple devices under the same public IP you could quickly reach the limit.  I found 25 worked fine for me with 3 devices.

### POP

=> https://en.wikipedia.org/wiki/Post_Office_Protocol Wikipedia page: POP protocol

POP3 is a pretty old protocol that is rarely considered by users, I still consider it a viable alternative to IMAP depending on your needs.

A major incentive for using POP is that it downloads all emails locally before removing them from the server.  As we have no tooling to encrypt emails stored on remote email servers, POP3 is a must if you want to not leave any email on the server.  POP3 does not support remote folders, so you can not use Sieve filters on the server to sort your emails and then download them as-this.  A POP3 client downloads the Inbox and then sorts the emails locally.

It can support multiple devices under some conditions: if you delete the emails after X days, your devices should synchronize before the emails are removed.  In such case they will have all the emails stored locally, but they will not be synced together: if both computers A and B are up-to-date, when deleting an email on A, it will still be in B.

There are no changes required for POP3 in Dovecot as the defaults are good enough.

### JMAP

For information, a replacement for IMAP called JMAP is in development, it is meant to be better than IMAP in every way and also include calendars and address book management.

JMAP Implementations are young but exist, although support in email clients is almost non-existent.  For instance, it seems Mozilla Thunderbird is not interested in it, an issue in their bug tracker about JMAP from December 2016 only have a couple of comments from people who would like to see it happening, nothing more.

=> https://bugzilla.mozilla.org/show_bug.cgi?id=1322991 Issue 1322991: Add support for new JMAP protocol

From the JMAP website page listing compatible clients, I only recognized the name "aerc" which is a modern console email client.

=> https://jmap.io/software.html#clients JMAP project website: clients list

### Sieve (filtering rules)

=> https://en.wikipedia.org/wiki/Sieve_(mail_filtering_language) Wikipedia page: Sieve

Dovecot has a plugin to offer Sieve filters, they are rules applied to received emails going into your mailbox, whether you want to sort them into dedicated directories, mark them read or block some addresses.  That plugin is called pigeonhole.

You will need Sieve to enable the spam filter learning system when moving emails from/to the Junk folder as it is triggered by a Sieve rule.  This improves rspamd Bayes (a method using tokens to understand information, the story of the person behind it is interesting) filter ability to detect spam accurately.

Edit `/etc/dovecot/conf.d/90-plugin.conf` with the following content:

plugin {

sieve_plugins = sieve_imapsieve sieve_extprograms

# From elsewhere to Spam folder

imapsieve_mailbox1_name = Spam

imapsieve_mailbox1_causes = COPY

imapsieve_mailbox1_before = file:/usr/local/lib/dovecot/sieve/report-spam.sieve

# From Spam folder to elsewhere

imapsieve_mailbox2_name = *

imapsieve_mailbox2_from = Spam

imapsieve_mailbox2_causes = COPY

imapsieve_mailbox2_before = file:/usr/local/lib/dovecot/sieve/report-ham.sieve

sieve_pipe_bin_dir = /usr/local/lib/dovecot/sieve

sieve_global_extensions = +vnd.dovecot.pipe +vnd.dovecot.environment

}


This piece of configuration was taken from the official Dovecot documentation: https://doc.dovecot.org/configuration_manual/howto/antispam_with_sieve/ .  It will trigger shell scripts calling rspamd to make it learn what does a spam look like, and what is legit (ham).  One script will run when an email is moved out of the spam directory (ham), another one when an email is moved to the spam directory (spam).

Modify `/etc/dovecot/conf.d/15-mailboxes.conf` to add the following snippet inside the block `namespace inbox { ... }`, it will associate the Junk directory as the folder containing spam and automatically create it if it does not exist:

mailbox Spam {

auto = create

special_use = \Junk

}


To make this work completely, you need to write the two extra sieve filters that will run trigger the scripts:

Create `/usr/local/lib/dovecot/sieve/report-spam.sieve`

require ["vnd.dovecot.pipe", "copy", "imapsieve", "environment", "variables"];

if environment :matches "imap.user" "*" {

set "username" "${1}";

}

pipe :copy "sa-learn-spam.sh" [ "${username}" ];


Create `/usr/local/lib/dovecot/sieve/report-ham.sieve`

require ["vnd.dovecot.pipe", "copy", "imapsieve", "environment", "variables"];

if environment :matches "imap.mailbox" "*" {

set "mailbox" "${1}";

}

if string "${mailbox}" "Trash" {

stop;

}

if environment :matches "imap.user" "*" {

set "username" "${1}";

}

pipe :copy "sa-learn-ham.sh" [ "${username}" ];


Create `/usr/local/lib/dovecot/sieve/sa-learn-ham.sh`

!/bin/sh

exec /usr/local/bin/rspamc -d "${1}" learn_ham


Create `/usr/local/lib/dovecot/sieve/sa-learn-spam.sh`

!/bin/sh

exec /usr/local/bin/rspamc -d "${1}" learn_spam


Make the two scripts executable with `chmod +x /usr/local/lib/dovecot/sieve/sa-learn-spam.sh /usr/local/lib/dovecot/sieve/sa-learn-ham.sh`.

Run the following command to compile the sieve filters:

sievec /usr/local/lib/dovecot/sieve/report-spam.sieve

sievec /usr/local/lib/dovecot/sieve/report-ham.sieve


### Manage Sieve

By default, Sieves rules are a file located on the user home directory, however there is a standard protocol named "managesieve" to manage Sieve filters remotely from an email client.

It is enabled out of the box in Dovecot configuration, although you need to make sure you open the port 4190/tcp in the firewall if you want to allow users to use it.

### Start the service

Once you configured everything, make sure that dovecot service is enabled, and then start / restart it:

rcctl enable dovecot

rcctl start dovecot


# Webmail

A webmail will allow your users to read / send emails from a web interface instead of having to configure a local email client.  While they can be convenient, they enable a larger attack surface and are often affected by vulnerability issues, you may prefer to avoid webmail on your server.

The two most popular open source webmail are Roundcube mail and Snappymail (a fork of the abandoned rainloop) and Roundcube, they both have pros and cons.

## Roundcube mail setup

Roundcube is packaged in OpenBSD, it will pull in all required dependencies and occasionally receive backported security updates.

Install the package:

pkg_add roundcubemail


When installing the package, you will be prompted for a database backend for PHP.  If you have one or two users, I highly recommend choosing SQLite as it will work fine without requiring a running daemon, thus less maintenance and server resources locked.  If you plan to have a lot of users, there are no wrong picks between MySQL or PostgreSQL, but if you already have one of them running it would be better to reuse it for Roundcube.

Specific instructions for installing Roundcube are provided by the package README in `/usr/local/share/doc/pkg-readmes/roundcubemail`.

We need to enable a few PHP modules to make Roundcube mail working:

ln -s /etc/php-8.2.sample/zip.ini /etc/php-8.2/

ln -s /etc/php-8.2.sample/intl.ini /etc/php-8.2/

ln -s /etc/php-8.2.sample/opcache.ini /etc/php-8.2/

ln -s /etc/php-8.2.sample/pdo_sqlite.ini /etc/php-8.2/


Note that more PHP modules may be required if you enable extra features and plugins in Roundcube.

PHP is ready to be started:

rcctl enable php82_fpm

rcctl start php82_fpm


Add the following blocks to `/etc/httpd.conf`, make sure you opened the port 443/tcp in your `pf.conf` and that you reloaded it with `pfctl -f /etc/pf.conf`:

server "mail.puffy.cafe" {

listen on egress tls

tls key "/etc/ssl/private/mail.puffy.cafe.key"

tls certificate "/etc/ssl/mail.puffy.cafe.fullchain.pem"

root "/roundcubemail"

directory index index.php

location "*.php" {

fastcgi socket "/run/php-fpm.sock"

}

}

types {

include "/usr/share/misc/mime.types"

}


Restart httpd with `rcctl restart httpd`.

You need to configure Roundcube to use a 24 bytes security key and configure the database: edit the file `/var/www/roundcubemail/config/config.inc.php`:

Search for the variable `des_key`, replace its value by the output of the command `tr -dc [:print:] < /dev/urandom | fold -w 24 | head -n 1` which will generate a 24 byte random string.  If the string contains a quote character, either escape this character by prefixing it with a `\` or generate a new string.

For the database, you need to search the variable `db_dsnw`.

If you use SQLite, change this line

$config['db_dsnw'] = 'sqlite:///roundcubemail/db/sqlite.db?mode=0660';


by this line:

$config['db_dsnw'] = 'sqlite:///db/sqlite.db?mode=0660';


If you chose MySQL/MariaDB or PostgreSQL, modify this line:

$config['db_dsnw'] = 'mysql://roundcube:pass@localhost/roundcubemail';


by

$config['db_dsnw'] = 'mysql://USER:PASSWORD@DATABASE_NAME';


Where `USER`, `PASSWORD` and `DATABASE_NAME` must match a new user and database created into the backend.


Because PHP is chrooted on OpenBSD and that the OpenSMTPD configuration enforces TLS on port 587, it is required to enable TLS to work in the chroot:

mkdir -p /var/www/etc/ssl

cp -p /etc/ssl/cert.pem /etc/ssl/openssl.cnf /var/www/etc/ssl/


To make sure the files `cert.pem` and `openssl.cnf` stay in sync after upgrades, add the two commands to a file `/etc/rc.local` and make this file executable.  This script always starts at boot and is the best place for this kind of file copy.

If your IMAP and SMTP hosts are not on the same server where Roundcube is installed, adapt the variables `imap_host` and `smtp_host` to the server name.

If Roundcube mail is running on the same server where OpenSMTPD is running, you need to disable certificate validation because `localhost` will not match the certificate and authentication will fail.  Change `smtp_host` line to `$config['smtp_host'] = 'tls://127.0.0.1:587';` and add this snippet to the configuration file:

$config['smtp_conn_options'] = array(

'ssl' => array('verify_peer' => false, 'verify_peer_name' => false),

'tls' => array('verify_peer' => false, 'verify_peer_name' => false));


From here, Roundcube mail should work when you load the domain configured in `httpd.conf`.

For a more in-depth guide to install and configure Roundcube mail, there is an excellent guide available which was written by Bruno Flückiger:

=> https://www.bsdhowto.ch/roundcube.html Install Roundcube on OpenBSD

# Hardening

It is always possible to improve the security of this stack, all the following settings are not mandatory, but they can be interesting depending on your needs.

## Always allow the sender per email or domain

It is possible to configure rspamd to force it to accept emails from a given email address or domain, bypassing the anti-spam.

To proceed, edit the file `/etc/rspamd/local.d/multimap.conf` to add this content:

local_wl_domain {

type = "from";

filter = "email:domain";

map = "$CONFDIR/local.d/whitelist_domain.map";

symbol = "LOCAL_WL_DOMAIN";

score = -10.0;

description = "domains that are always accepted";

}

local_wl_from {

type = "from";

map = "$CONFDIR/local.d/whitelist_email.map";

symbol = "LOCAL_WL_FROM";

score = -10.0;

description = "email addresses that are always accepted";

}


Create the files `/etc/rspamd/local.d/whitelist_domain.map` and `/etc/rspamd/local.d/whitelist_email.map` using the command `touch`.

Restart the service rspamd with `rcctl restart rspamd`.

The created files use a simple syntax, add a line for each entry you want to allow:



There is no need to restart or reload rspamd after changing the files.

Reusing the same technique can be done to block domains/addresses directly in rspamd by giving a high positive score.

## Block bots

I published on my blog a script and related configuration to parse OpenSMTPD logs and block the bad actors with PF.

=> https://dataswamp.org/~solene/2023-06-22-opensmtpd-block-attempts.html 2023-06-22 Ban scanners IPs from OpenSMTP logs

This includes an ignore file if you do not want some IPs to be blocked.

## Split the stack

If you want to improve your email setup security further, the best method is to split each part into dedicated systems.

As dovecot is responsible for storing and exposing emails to users, this component would be safer in a dedicated system, so if a component of the email stack (other than dovecot) is compromised, the mailboxes will not be exposed.

## Network attack surface reduction

If this does not go against usability of the email server users, I strongly recommend limiting the publicly opened ports in the firewall to the minimum: 25, 80, 465, 587.  This would prevent attackers to exploit any network related 0day or unpatched vulnerabilities of non-exposed services such as Dovecot.

A VPN should be deployed to allow users to reach Dovecot services (IMAP, POP) and other services if any.

SSH port could be removed from the public ports as well, however, it would be safer to make sure your hosting provider offers a serial access / VNC / remote access to the system because if the VPN stops working, you will not be able to log in into the system using SSH to debug it.

# Email client configuration

If everything was done correctly so far, you should have a complete email stack fully functional.

Here are the connection information to use your service:



The webmail, if any, will be available at the address configured in `httpd.conf`, using the same credentials as above.

# Verify the setup

There is an online service providing you a random email address to send a test email to, then you can check the result on their website displaying if the SPF, DKIM, DMARC and PTR records are correctly configured.
=> https://www.mail-tester.com www.mail-tester.com

The score you want to be displayed on their website is no least than 10/10.  The service can report meaningless issues like "the email was poorly formatted" or "you did not include an unsubscribe link", they are not relevant for the current test.

While it used to be completely free last time I used it, I found it would ask you to pay after three free checks if you do not want to wait 24h.  It uses your public IP address for the limit.

# Maintenance

## Running processes

The following processes list should always be running: using a program like monit, zabbix or reed-alert to notify you when they stop working could be a good idea.



## Certificates renewal

In addition, the TLS certificate should be renewed regularly as ACME generated certificates are valid for a few months.  Edit root crontab with `crontab -e` as root to add this line:

10 4 * * 0 -s acme-client mail.puffy.cafe && rcctl restart dovecot httpd smtpd


This will try to renew the certificate for `mail.puffy.cafe` every Sunday at 04h10 and upon renewal restart the services using the certificate: dovecot, httpd and smtpd.

## All about logs

If you need to find some logs, here is a list of paths where to find information:



A log rotation of the new logs can be configured in `/etc/newsyslog.conf` with these lines (take only what you need):

/var/log/rspamd/rspamd.log 600 7 500 * Z "pkill -USR1 -u root -U root -x rspamd"

/var/www/roundcubemail/logs/errors.log 600 7 500 * Z

/var/www/roundcubemail/logs/sendmail.log 600 7 500 * Z


## Disk space

Finally, OpenSMTPD will stop delivering emails locally if the `/var` partition has less than 4% of free disk space, be sure to monitor the disk space of this partition otherwise you will not receive emails anymore for a while before noticing something is wrong.

# Conclusion

Congratulations, you configured a whole email stack that will allow you to send emails to the world, using your own domain and hardware.  Keeping your system up to date is important as you have network services exposed to the wild Internet.

Even with a properly configured setup featuring SPF/DKIM/DMARC/PTR, it is not guaranteed to not end in the spam directory of our recipients.  The IP reputation of your SMTP server also account, and so is the domain name extension (I have a `.pw` domain which I learned too late that it was almost always considered as spam because it is not mainstream).
</pre>
    ]]>
  </description>
  <guid>gemini://perso.pw/blog//articles/openbsd-email-server-setup.gmi</guid>
  <link>gemini://perso.pw/blog//articles/openbsd-email-server-setup.gmi</link>
  <pubDate>Thu, 25 Jul 2024 00:00:00 GMT</pubDate>
</item>
<item>
  <title>Cloud gaming review: Xbox xCloud and Amazon Luna+</title>
  <description>
    <![CDATA[
<pre># Introduction

There are not many cloud gaming services around, here is a quick summary of Xbox Gaming and Amazon Luna services.

# Xbox Cloud Gaming (Microsoft)

The Xbox Cloud gaming service is available for Xbox Game Pass Ultimate subscribers at a price of 17.99$€ / month.

## pros



## cons



=> https://github.com/redphx/better-xcloud better-xcloud GitHub page: Userscript to improve Xbox Cloud Gaming (xCloud)

## Conclusion

The Xbox Ultimate subscription bundles a game library for Xbox and Windows games with high price titles, this makes the price itself quite cheap compared to the price of available games as a high-priced game is more expensive than four months of subscription.  However, I have mixed feelings about the associated streaming service: on one hand it works perfectly fine (no queue, input lag is ok) but the video quality is not fantastic on a 1080p screen.  The service seems perfectly fitted to be played on smartphones, every touchscreen compatible games have a specific layout customized for that game, making the touchscreen a lot more usable than displaying a full controller over the layout when you only need a few buttons, in addition to the low bandwidth usage it makes a good service for handheld devices.  On desktop, you may want to use the streaming to try a game before installing it, but not much more.

There is no client for Android TV, so you can not use these devices except if you can run a web browser in it.

Really, with a better bitrate, the service would be a blast (not for 4k and/or 120 fps users though), but at the moment it is only ok as a game library, or as a streaming service to play on small or low resolution screens.

# Luna (Amazon)

The Luna+ cloud gaming service is available for 9.99$€ / month, or people who have an Amazon Prime account.

## pros



## cons



## Conclusion

The service could be good with a better bitrate, the input lag is ok and I did not experience any waiting time.  The hardware specs seem good except the loading times, it feels like the data are stored on a network storage with poor access time or bandwidth.  The bitrate is so bad that I can not recommend playing anything in first person view or moving too fast as it would look like a pixel mess.  However, playing slow paced games is perfectly fine.

There have a killer feature that is unique to their service, you can invite a friend to play a game in streaming with you by just sending them a link, they will join your game, and you can start playing together in a minute.  While it is absolutely cool, the service lacks fun games to play in couch coop...

As you can use Luna if you have Amazon Prime, I think it is a good fit for casual players who do not want to pay for games but would enjoy a session from time to time on any hardware.

I mentioned the subscription cancelling process twice, here are the facts: on your account you click on unsubscribe, then it asks if you are really sure because you will lose access to your service, you have to agree, then it will remind you that you are about to cancel, and maybe it is a mistake, so you need to agree again, then there is a trick.  The web page says that your account will be cancelled and that you can still use your account up to cancel date, it looks fine here, but it is not, there is a huge paragraph of blah blah below and a button to confirm the cancel!  Then you are done.  But first time I cancelled I did not pass the third step as I thought it was fine, when double-checking my account status before the renewal, I saw I missed something.

# GeForce NOW (NVIDIA)

I wrote a review of their services a few months ago.  Since then, I renewed my account with 6 months of priority tier.  I mostly use it to play resource intensive games when it is hot at home (so my computer does not heat at all), at night when I want to play a bit in silence without fan noise, finally I enjoy it a lot with slow paced games like walking simulators on my TV.

=> https://dataswamp.org/~solene/2024-03-07-geforce-now-review.html 2024-03-07 GeForce NOW review

# Final conclusion

On one hand, Luna seems to target casual users: people who may not notice the bad quality or input lag and who will just play what is available.

On the other hand, Xbox service is a game library first, with a streaming feature.  It is quite perfect for people playing Xbox library games on PC / Xbox who wants to play on a smartphone / tablet occasionally, but not for customers looking only for playing streaming games.

Both services would not need much to be _good_ streaming services, the minimum upgrade should be a higher bitrate. Better specs would be appreciated too: improved loading times for Luna, and Xbox games running on a better platform than Xbox Series S.
</pre>
    ]]>
  </description>
  <guid>gemini://perso.pw/blog//articles/cloud-gaming-xbox-luna.gmi</guid>
  <link>gemini://perso.pw/blog//articles/cloud-gaming-xbox-luna.gmi</link>
  <pubDate>Fri, 19 Jul 2024 00:00:00 GMT</pubDate>
</item>
<item>
  <title>WireGuard and Linux network namespaces</title>
  <description>
    <![CDATA[
<pre># Introduction

This guide explains how to setup a WireGuard tunnel on Linux using a dedicated network namespace so you can choose to run a program on the VPN or over clearnet.

I have been able to figure the setup thanks to the following blog post, I enhanced it a bit using scripts and sudo rules.

=> https://www.ismailzai.com/blog/creating-wireguard-jails-with-linux-network-namespaces Mo Ismailzai's blog: Creating WireGuard jails with Linux network namespaces

# Explanations

By default, if you connect WireGuard tunnel, its "allowedIps" field will be used as a route with a higher priority than your current default route.  It is not always ideal to have everything routed through a VPN, so you will create a dedicated network namespace that uses the VPN as a default route, without affecting all other software.

Unfortunately, compared to OpenBSD rdomain (which provide the same features in this situation), network namespaces are much more complicated to deal with and requires root to run a program under a namespace.

You will create a SAFE sudo rule to allow your user to run commands under the new namespace, making it more practical for daily use.

# Setup

## VPN tunnel and namespace

You need a wg-quick compatible WireGuard configuration file, but do not make it automatically used at boot.

Create a script (for root use only) with the following content, then make it executable:

!/bin/sh

your VPN configuration file

CONFIG=/etc/wireguard/my-vpn.conf

this directory is used to have a per netns resolver file

mkdir -p /etc/netns/vpn/

cleanup any previous VPN in case you want to restart it

ip netns exec vpn ip l del tun0

ip netns del vpn

information to reuse later

DNS=$(awk '/^DNS/ { print $3 }' $CONFIG)

IP=$(awk '/^Address/ { print $3 }' $CONFIG)

the namespace will use the DNS defined in the VPN configuration file

echo "nameserver $DNS" > /etc/netns/vpn/resolv.conf

now, it creates the namespace and configure it

ip netns add vpn

ip -n vpn link set lo up

ip link add tun0 type wireguard

ip link set tun0 netns vpn

ip netns exec vpn wg setconf tun0 <(wg-quick strip "$CONFIG")

ip -n vpn a add "$IP" dev tun0

ip -n vpn link set tun0 up

ip -n vpn route add default dev tun0

ip -n vpn add

extra check if you want to verify the DNS used and the public IP assigned

ip netns exec vpn dig ifconfig.me

ip netns exec vpn curl https://ifconfig.me


This script autoconfigure the network namespace and the VPN interface + the DNS server to use.  There are extra checks at the end of the script that you can uncomment if you want to take a look at the public IP and DNS resolver used just after connection.

Running this script will make the netns "vpn" available for use.

The command to run a program under the namespace is `ip netns exec vpn your command`, it can only be run as root.

## Sudo rule

Now you need a specific rule so you can use sudo to run a command in vpn netns as your own user without having to log in as root.

Add this to your sudo configuration file, in my example I allow the user `solene` to run commands as `solene` for the netns vpn:

solene ALL=(root) NOPASSWD: /usr/sbin/ip netns exec vpn /usr/bin/sudo -u solene -- *


When using this command line, you MUST use full paths exactly as in the sudo configuration file, this is important otherwise it would allow you to create a script called `ip` with whatever commands and run it as root, while `/usr/sbin/ip` can not be spoofed by a local script in $PATH.

If I want a shell session with the VPN, I can run the following command:

sudo /usr/sbin/ip netns exec vpn /usr/bin/sudo -u solene -- bash


This runs bash under the netns vpn, so any command I'm running from it will be using the VPN.

# Limitations

It is not a real limitation, but you may be caught by it, if you make a program listening on localhost in the netns vpn, you can only connect to it from another program in the same namespace.  There are methods to connect two namespaces, but I do not plan to cover it, if you need to search about this setup, it can be done using socat (this is explained in the blog post linked earlier) or a local bridge interface.

# Conclusion

Network namespaces are a cool feature on Linux, but it is overly complicated in my opinion, unfortunately I have to deal with it, but at least it is working fine in practice.
</pre>
    ]]>
  </description>
  <guid>gemini://perso.pw/blog//articles/linux-vpn-netns.gmi</guid>
  <link>gemini://perso.pw/blog//articles/linux-vpn-netns.gmi</link>
  <pubDate>Thu, 04 Jul 2024 00:00:00 GMT</pubDate>
</item>
<item>
  <title>The Old Computer Challenge v4 (Olympics edition)</title>
  <description>
    <![CDATA[
<pre># Introduction

This is the time of the year where I announce the Old Computer Challenge (OCC) date.

I recommend visiting the community website about the OCC if you want to connect with the community.

=> https://occ.deadnet.se/ Old Computer Challenge community

=> https://dataswamp.org/~solene/tag-oldcomputerchallenge.html The Old Computer Challenge history

=> static/occ-v4.jpg The Old Computer Challenge v4 poster, by @prahou@merveilles.town on Mastodon

# When?

The Old Computer Challenge 4th edition will begin 13th July to 20th July 2024.  It will be the prequel to Olympics, I was not able to get the challenge accepted there so we will do it our way.

# How to participate?

While the three previous editions had different rules, I came to agree with the community for this year.  Choose your rules!

When I did the challenge for the first time, I did not expect it to become a yearly event nor that it would gather aficionados during the trip.  The original point of the challenge was just to see if I could use my oldest laptop as my main computer for a week, there were no incentive, it was not a contest and I did not have any written rules.

Previous editions rules were about using an old laptop, use a computer with limited hardware (and tips to slow down a modern machine) or limit Internet access to a single hour per day.  I always insist on the fact it should not hinder your job, so people participating do not have to "play" during work.  Smartphones became complicated to handle, especially with the limited Internet access, all I can recommend to people is to define some rules you want to stick to, and apply to it the best you can.  If you realllyyyy need once to use a device that would break the rules, so be it if it is really important, nobody will yell at you.

People doing the OCC enjoy it for multiple reasons, find yours!  Some find the opportunity to disconnect a bit, change their habit, do some technoarcheology to run rare hardware, play with low-tech, demonstrate obsolescence is not a fatality etc...

Some ideas if you do not know what to do for the challenge:



# What to do during the challenge?

You can join the community and share your experience.

There are many ways!  It's the opportunity to learn how to use Gopher or Gemini to publish content, or to join the mailing list and participate with the other or simply come to the IRC channel to chat a bit.

# I can't join during 13th to 20th July!

Well, as nobody enforces you to do the OCC, you can just do it when you want, even in December if it suits your calendar better than mid July, nobody will complain at you.

# Conclusion

There is a single rule, do it for fun!  Do not impede yourself for weird reasons, it is here for fun, and doing the whole week is as good as failing and writing about the why you failed.  It is not a contest, just try and see how it goes, and tell us your story :)
</pre>
    ]]>
  </description>
  <guid>gemini://perso.pw/blog//articles/old-computer-challenge-v4-announce.gmi</guid>
  <link>gemini://perso.pw/blog//articles/old-computer-challenge-v4-announce.gmi</link>
  <pubDate>Mon, 24 Jun 2024 00:00:00 GMT</pubDate>
</item>
<item>
  <title>How to mount ISO or file disk images on OpenBSD</title>
  <description>
    <![CDATA[
<pre># Introduction

If you ever happen to mount a .iso file on OpenBSD, you may wonder how to proceed as the command `mount_cd9660` requires a device name.

While the solution is entirely documented into man pages and in the official FAQ, it may not be easy to find it at first glance, especially since most operating system allow to mount an iso file in a single step where as OpenBSD requires an extra step.

=> https://www.openbsd.org/faq/faq14.html#MountImage OpenBSD FAQ: Mounting disk images
=> https://man.openbsd.org/vnconfig#EXAMPLES OpenBSD manual page: vnconfig(8) EXAMPLES section

Note that this method does also work for disk images, not only .iso files.

# Exposing a file as a device

On OpenBSD you need to use the command `vnconfig` to map a file to a device node, allowing interesting actions such as using a file as a storage disk (which you can encrypt) or mounting a .iso file.

This command must be used as root as it manipulates files in /dev.

# Mounting an ISO file

Now, let's see how to mount a .iso file, which is a dump of a CD9660 file (most of the time):

vnconfig vnd0 /path/to/file.iso


This will create a new device `/dev/vnd0`, now you can mount it on your file-system with:

mount -t cd9660 /dev/vnd0c /mnt


You should be able to browser your iso file content in /mnt at this point.

# Unmounting

If you are done with the file, you have to umount it with `umount /mnt` and destroy the vnd device using `vnconfig -u vnd0`.

# Going further: Using a file as an encrypted disk

If you want to use a single file as a file system, you have to provision the file with disk space using the command `dd`, you can fill it with zeroes but if you plan to use encryption on top of it, it's better to use random data. In the following example, you will create a file `my-disk.img` of a size of 10 GB (1000 x 10 MB):

dd if=/dev/random of=my-disk.img bs=10M count=1000


Now you can use vnconfig to expose it as a device:

vnconfig vnd0 my-disk.img


Finally, the command `bioctl` can be used to configure encryption on the disk, `disklabel` to partition it and `newfs` to format the partitions.  You can follow OpenBSD FAQ guides, make sure use the the device name `/dev/vnd0` instead of wd0 or sd0 from the examples.

=> https://www.openbsd.org/faq/faq14.html#softraidCrypto OpenBSD FAQ: Encrypting external disk
</pre>
    ]]>
  </description>
  <guid>gemini://perso.pw/blog//articles/mount-iso-file-openbsd.gmi</guid>
  <link>gemini://perso.pw/blog//articles/mount-iso-file-openbsd.gmi</link>
  <pubDate>Tue, 18 Jun 2024 00:00:00 GMT</pubDate>
</item>

  </channel>
</rss>