My wife forwarded an e-mail as attachment to me, and I could not open it in Claws Mail. The attached e-mail is stored as .eml attachment, and Claws has no way to open it.

Another user had the same problem in 2004, and the answer then was to use the eml2mbox tool. This Ruby-based tool was written in 2004, and it uses a parsedate library function that has been removed in Ruby 1.9. In 2023 we have Ruby 3.1, and eml2mbox does not work anymore.

In the end I used the Python 3 based emlToMbox, which converted the .eml to a .mbox that I could import into Claws.

It worked, but it still sucks that Claws does not open .eml files natively. Forward-as-attachment is a standard procedure.

I recently stumbled over Lightmeter, a tool that is supposed to help running your own mail server by monitoring delivery problems. It was published in version 1.0, so I thought I'd give it a try.

Installation

Since Debian has no package for it yet, and I did not want to install the whole Go compilation chain on the server, I downloaded the Control Center v1.0.1 binary for amd64 from the releases page.

I wanted to the Lightmeter control center under its own user and group, with all data in /var/lib/lightmeter:

$ mkdir /var/lib/lightmeter
$ useradd --system --home-dir /var/lib/lightmeter --groups adm --shell /usr/sbin/nologin lightmeter
$ chown lightmeter:lightmeter /var/lib/lightmeter/

Then I moved the downloaded binary into /usr/local/bin/lightmeter and made it executable. A systemd service file was also needed:

[Unit]
Description=Postfix mail monitoring
Documentation=https://gitlab.com/lightmeter/controlcenter
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/lightmeter -listen 127.0.0.1:10020 -watch_dir /var/log -workspace /var/lib/lightmeter
TimeoutStopSec=0
Restart=always
User=lightmeter
Group=lightmeter

WorkingDirectory=/var/lib/lightmeter
ProtectHome=yes
ReadOnlyDirectories=/
ReadWriteDirectories=-/var/lib/lightmeter

[Install]
WantedBy=multi-user.target

After writing that file, systemd needs to re-read is configuration and the service can be started:

$ systemctl daemon-reload
$ systemctl start lightmeter
$ systemctl status lightmeter
$ journalctl -fu lightmeter

Now Lightmeter is running and not accessible from the outside, because I use Apache for SSL-termination, proxying access to LM:

<VirtualHost *:443>
    ServerName lightmeter.example.org
    DocumentRoot /var/www/dummy

    Header set Referrer-Policy same-origin

    ProxyPass / http://localhost:10020/
    ProxyPassReverse / https://localhost:10020/

    SSLEngine On
    SSLCertificateFile /etc/letsencrypt/live/lightmeter.example.org/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/lightmeter.example.org/privkey.pem

    CustomLog /var/log/apache2/system/lightmeter-access.log combined
    ErrorLog /var/log/apache2/system/lightmeter-error.log
</VirtualHost>

Findings

Update 2021-06: All the problems listed here have been fixed.

Lightmeter itself is in its very early stages, more an alpha version than 1.0. Here is a list of some of the most serious problems I found with it:

• It stops importing when the postfix log file is rotated and you lose all data until the new postfix log file is at least as large as the old one :(
• It does not detect old rotated log files and it does not start anymore when manually importing old log files.
• It needs its own domain - it does not work in a /path/ of an "administration tools" domain.
• The only way to get notified about problems is the centralized proprietary "Slack" chat messaging system. Lightmeter does not even support e-mail notifications.

I was pretty disappointed by that Software. Version 1.0.1 only checks if you are on an e-mail blacklist and shows you which domains rejected e-mails. That's all.

The people planning and creating it seem to be more interested in layout, new technologies and monitoring instead of .. functionality. As soon as you start using it, you send tracking data ("telemetry" in new-speak) to their servers. They also decided to spend time on re-implementing their frontend instead of fixing those serious bugs and making whole software useful.

At their current development speed, I think that Lightmeter will need two years of work until it becomes actually useful.

Process mails from web applications like e-mail address verification and password reset mails should be tagged as "automatically submitted" so that mail servers do not respond with "Out of office" or vacation notification mails.

The official standard for that is RFC 3834: Recommendations for Automatic Responses to Electronic Mail, which defines an e-mail header Auto-Submitted: auto-generated for our use case.

Laravel notifications

E-mails automatically built from Laravel notifications can be modified to contain that header: Inside the toMail() method, register a modification callback for the MailMessage class:

withSwiftMessage([$this, 'addCustomHeaders'])
            ->subject(_('Reset your password'));
    }

    /**
     * Add our own headers to the e-mail
     */
    public function addCustomHeaders(\Swift_Message $message)
    {
        $message->getHeaders()->addTextHeader('Auto-Submitted', 'auto-generated');
    }
}
]]>

Google Forms is being used to send spam e-mails. The first forms spam mail was delivered on 2020-10-06, and the latest 2020-12-31 - 45 in total in my main mailbox.

As always with Google there is no way to contact them and tell them to stop allowing people to use their services to spam other people :(

My wife replied to an e-mail and got the following error back:

<user@example.org>: host smtpin.rzone.de[2a01:238:20a:202:50f0::1097]
said: 550 5.7.1 IP listed on RBL (3.0.0.127
https://www.spamhaus.org/sbl/query/SBLCSS) (in reply to RCPT TO command)

I immediately checked if my server was on blacklists. MXToolbox's blacklist check did not show any errors, and my own is-my-server-sending-too-many-mails check had not triggered.

The error message indicated that IPv6 was used, and Spamhaus's CSS FAQ says that they only list /64 subnets, and not individual IPv6 addresses - the database would simply get too large.

Now our server hoster Hosteurope only gives us a /128 block, which is a single IPv6 address. This means that another server hosted there sent spam mails, got blacklisted and now my server is punished, because we share the same /64 block :(

I contacted Hosteurope's support, but they told me that IPv6 is still in beta for them and that they could not give me my own /64 range. They also told me I should send my mail via IPv4 :(

I then configured postfix to prefer IPv4 over IPv6 (man 5 postconf):

smtp_address_preference = ipv4

After upgrading my server today, the mail server Dovecot did not work anymore - fetching mails with IMAP failed with

socket error ([Errno 104] Connection reset by peer)

The server logs said:

dovecot: imap-login: Fatal: Can't load private ssl_key: Key is for a different cert than ssl_cert
dovecot: master: Error: service(imap-login): command startup failed, throttling for 2 secs

The setup had not changed; the Dovecot + Let's Encrypt certificates had been working for over a year.

I found the solution in a forum post: My /etc/dovecot/conf/10-ssl.conf file contained:

ssl_cert = </etc/letsencrypt/live/mail.cweiske.de/fullkeychain.pem

- but using the fullkeychain was apparently wrong; after changing it to fullchain.pem (without the "key") IMAP and POP3 logins worked again.

My wife expected some e-mail, but it did not arrive in her mailbox. Looking at mail.info log file I saw:

postfix/smtpd[14884]: connect from mout.web.de[212.227.17.11]
postfix/smtpd[14884]: disconnect from mout.web.de[212.227.17.11] ehlo=2 starttls=1 quit=1 commands=4

Nothing more. A connect and an immediate disconnect from the web.de mail server.

Sending a mail from a test account worked fine and arrived in my inbox. Then I saw that the e-mail should have had an attachment, and I added a 12 MiB file to the mail in the web.de freemail interface and sent it. The log showed the same behavior: Connect and disconnect.

The web.de interface did only show that the mail was sent, but nothing more.

postconf told me that the maximal e-mail size was 10240000, which is 10 MiB. I increased message_size_limit to 100 MiB (104857600), reloaded postfix daemon and I could receive the mail.

Since setting up and moving to our new server, we had problems sending e-mails to other people. Mails did get marked as spam on the other side, and got moved to the Spam folder, or their subject got a prefix like [SPAM] $subject.

I remembered that while setting up a mail server at work, I used mail-tester.com to check my mails for problems. I sent a mail to them and ... got 6/10 points: The DKIM signature was invalid.

I'm using rspamd as milter in Postfix:

smtpd_milters = inet:localhost:11332
non_smtpd_milters = inet:localhost:11332

and rspamd is configured to add DKIM signatures:

path = "/var/lib/rspamd/dkim/$selector.key";
selector = "2019";

### Enable DKIM signing for alias sender addresses
allow_username_mismatch = true;

Now I compared the contents of /var/lib/rspamd/dkim/2019.txt with the one of my DNS zone /etc/tinydns/tinydns4/root/data-cweiske.de and found that the keys differed!

While setting up the new server, I installed rspamd for the first time. It automatically created new DKIM keys, and I did forget that I also have to update my DKIM DNS entry.

The solution for me was to change the selector to 2020, renaming the files in rspamd's dkim folder from 2019 to 2020, and adding the new 2020 DKIM signature to djbdns' zone configuration. mail-tester gave my mail a 10/10 now.

mail-tester.com only analyzes 3 mails per day per server/IP. If you want more, you have to pay.

My server uses SpamAssassin to detect if incoming mail is Spam. One of SpamAssassin's capabilities is using real-time blacklists (RBL) to check if an IP address is known to send spam mail.

Unfortunately, this did not work. E-Mails delivered to me contained the following header:

X-Spam-Status: ... tests=URIBL_BLOCKED

The URIBL about page tells us when someone gets blocked:

If you abuse it, we will block your IP, or your nameserver IP that is producing the excessive queries.

...

If you use your ISP Nameservers for resolution, and they are blocked, consider running your own caching nameserver.

And this was my problem: I used Hosteurope's DNS server - just like thousands of other servers running in their data center - and many of them tried to use the URIBL.

Testing

It is easy to verify if you are blocked:

$ host -tA 2.0.0.127.multi.uribl.com
2.0.0.127.multi.uribl.com has address 127.0.0.1

If you get 127.0.0.1 as response, then your name server is blocked.

More information:

$ host -tTXT 2.0.0.127.multi.uribl.com
2.0.0.127.multi.uribl.com descriptive text "127.0.0.1 -> Query Refused.
See http://uribl.com/refused.shtml for more information [Your DNS IP: 62.138.131.21]"

Own DNS server

So I had to run my own caching DNS server on my server, listening on 127.0.0.1.

dnscache

Because I already use DJB tinydns as name server for our own domains (and DynDNS), I tried dnscache from the same package.

After successful setup I tested a bit and found out that it has at least one bug: It could not resolve barcelona.de, while this was no problem for all other servers I queried.

The djbdns tools have not seen any official updates since a decade, and dnscache is unusable now.

Unbound

The light-weight alternative to Bind is Unbound.

It is available in the Debian package repository and quickly setup without any problems.

After setup I only had to change my server's /etc/resolv.conf to query 127.0.0.1, and that's it.

The URIBL_BLOCKED messages are gone.

During the move to our new server, I needed to test if IMAP and SMTP authentication work. Using a mail client is tedious, so I used the awesome curl.

IMAP

I already wrote about using curl for IMAP login a year ago, but here it is again:

$ curl -k imaps://alice%40cweiske.de:password@mail.cweiske.de/

SMTP

You need a mail.txt file that you want to send:

$ curl -vk smtp://mail.cweiske.de:587/ \
  --mail-from alice@cweiske.de'\
  --mail-rcpt bob@cweiske.de'\
  --upload-file mail.txt\
  --user 'alice@cweiske.de:password' --ssl