News
- 1.7.2025 After having refactored ezmlm-idx while providing complete integration with DJB's ezmlm
and my fehQlibs, all my mailing lists are served now by the new ezmlmx (to be published soon).
As a welcome enhancement, the mailings posted to those lists are made public and available on the Web. However, neither email address harvesting is possible nor are those lists enummerated. In particular end of April, the AI bots were so busy to really impact my web server significantly given its load (like others as well). Please follow the provided URLs on the respective web pages. - 23.3.2024 March 21./22. (Thursday/Friday) 2024 'fehcom' was not reachable due to a malfunction hardware at S4U Datadoc center
in Strasbourg. Routers and Nameservers need to be switched of because of a water leak in the basement. My server though was running
well: india167:~$ uptime
20:05:27 up 329 days, 56 min, 1 user, load average: 0.04, 0.08, 0.04 - 12.9.2023 While I was using Binc IMAP on this server for virtual domains (feeded through VMailMgr) and IMAPS, after the last crash some changes were lost and I took the chance to rebuild Binc IMAP to version 2.
- 27.12.2022 The Debian OS upgraded from 'Stretch' to 'Bullseye' in order to get propper OpenSSL support.
However, though OpenSSL-1.1.1n is showing as version, symbols in qmail-dkim tell OPENSSL_1_1_0 together with OPENSSL_1_1_1 are in use.
Let's Encrypt X.509 certificates and certchains trimmed on 'www.fehcom.de'. Outgoing mails are now DKIM signed by s/qmail-4.2. - 7.10.2022 After a few weeks, my root server is finally recovered. However, due to the change of the
Debian system ('Stretch' is in place now) still some applications don't work. I had a hard time to get vmailmgr
done; the CGI modules don't work yet. Omail -- which I used occasionally -- was not yet on my todo-list. I had owncloud
running with an ancient version; nextcloud demands a newer version of PHP (7.3) which I can't install. Dependency hell.
Things can not be installed due to irrelevant dependencies and respositories are wiped out for older verions. Congratulation,
Linux community! You participate in the 'Cancel Culture'.
Oh! I almost forgot: Emails are now DKIM-signed. s/qmail 4.2 should be done soon. - 1.9.2022 Last week - after a scheduled down time -
my server crashed with a double hard-drive failure. Though I use this machine just as an Internet node to
provide content (and forward mails) but really a lot of configuration was realized here, which was not backuped entirely.
Thus I'm still suffering from incomplete settings, faulty URLs, missing scripts and other things. Too bad. The new machine is actually the old one; now with Debian 'Stretch'. Here, TLS 1.3 is not available and need to be included. Since the compiler has changed to 'gcc 6', programs need to be adjusted at the source (refactoring). I was busy one day to make 'bincimapd' running - version 1.3.4, the older ones don't work with 'vmailmgr'. ClamAV does not work anymore (OpenSSL). I need to accustom to 'systemd' (not that bad). Furtunately, my own developments are working fine with the new settings. - 29.01.2022: Finally, after migrating from MacOS to Linux, a new PGP key was necessary. OpenPGP servers are a mess. New PGP key id: 20FD6E671A94DC1E. PGP key fingerprint: 8C6B 155B 0FDA 64F1 BCCE A6B9 20FD 6E67 1A94 DC1E.
- 20.10.2021: My own tinydns name server listening on port 53 is now CurveDNS enabled. You can use
uz5wujwwhqr5sup7j6ulk1zwnrx9bn1hw5kgbpwukl52v8lw5g7rr6.fehcom.net as trust anchor. - 10.7.2021: Changed unicode symbol in web pages for selection menu ('hamburger') from '☰' to '≡'.
- 2.3.2021: s/qmail 4.1 uses now DANE verification for outgoing mails prior of the TLS handshake.
- 28.12.2020: s/qmail 4.1 is running now with Greylisting support.
- 20.10.2020: Server was down on October 14./15./16. due to power failure in computer center ... and a malfunctioning CPU fan.
- 20.9.2020: Uff, one busy year since my last post here. Already now, s/qmail-4.0 will be superseded by s/qmail-4.1.0 soon including DANE and DKIM support. A major step to be compatible with other MTAs. TLS 1.3 for libdkim and GCC 10 issues have been tackled also since then.
- 3.10.2019: I'm close to finish my long-running project porting s/qmail to
use my fehQlibs. The main part of my s/qmail instance is now already running this
new version, while some modules still need tweaking.
Since fehQlibs-13 are required (and the new DNS stub substitudes the 25 years of qmail modules using BIND syntax) I update ucspi-tcp6, ucspi-ssl, and in addition djbdnscurve6 to be compatbile with the most recent fehQlibs.
While providing the code in a Doxygen format, I finally was able to produce a suitable home page here using Doxygen's markdown capabilities on the README file. Enjoy!
- 3.08.2019: SMTP Mail over IPv6 and TLS 1.3 are still not very common theses days.
In particular not for my domain (fehcom.de, fehcom.net) since my provider
(Server4Free) does not support IPv6. Thus I'm running IPv6 over a Hurrican Electric tunnel,
which works quite well and reliable.
Since I deplopy my IPv4/v6 settings and the fehcom's MXs on my own server, occisionally it happens, that mail is send local over IPv6. In the qmail-smtpd logs it looks the following (using Apple Mail):
sslserver: pid 26149 from 2003:c9:3715:3900:9c2c:3573:be52:15c4 sslserver: ok 26149 mail.fehcom.de:2001:470:1f0a:58c::2:465 p200300c9371539009c2c3573be5215c4.dip0.t-ipconnect.de:2003:c9:3715:3900:9c2c:3573:be52:15c4::50049 sslserver: tls 26149 accept TLSv1.2:ECDHE-RSA-AES256-SHA qmail-smtpd: pid 26149 Accept::AUTH::plain P:ESMTPSA S:2003:c9:3715:3900:9c2c:3573:be52:15c4:p200300c9371539009c2c3573be5215c4.dip0.t-ipconnect.de H:[IPv6:2003:c9:3715:3900:9c2c:3573:be52:15c4] F:hoffmann@fehcom.de T:XX@stud.fra-uas.deInteresting to see, that the Apple mail includes '[IPv6:.....]' in the Helo greeting.
Too bad, that even MacOS Mojave does not support TLS 1.3. Otherwise I would see in my logs:
sslserver: pid 22825 from 93.200.251.55 sslserver: ok 22825 india167:85.25.149.179:6209 p5dc8fb37.dip0.t-ipconnect.de:93.200.251.55::58996 sslserver: info: valid client cert received for pid: 22825 sslserver: tls 22825 accept TLSv1.3:TLS_CHACHA20_POLY1305_SHA256 sslserver: ended by 22815 status 0 sslserver: status: 1/40Of course, using my personal favorit Cipher CHACHA20-POLY1305 instead of OpenSSL's default AES26-GCM. This is now feaseable using ucspi-ssl-0.10.11.
- 21.03.2019: While the 'official' DNS name servers for my domains are:
dnsqr ns fehcom.de 2 fehcom.de: 81 bytes, 1+2+0+0 records, response, noerror query: 2 fehcom.de answer: fehcom.de 82444 NS ns5.nameserverservice.de answer: fehcom.de 82444 NS ns6.nameserverservice.de dnsip ns5.nameserverservice.de 217.172.162.55 dnsip ns6.nameserverservice.de 217.172.161.234I am running my version of tinydns in dualstack mode:
- IPv4: 85.25.149.179
- IPv6: 2001:470:1f0a:58c::2
Though this DNS service is public and will provide only information about the domains I'm hosting, it is not anchored and only be used for iterative DNS queries.
- 10.10.2018: TLS 1.3 and OpenSSL 1.1.1. integration finally finished.
s/qmail is working fine with TLS 1.3, though TLS communication breakdown
in at least one case sending emails has been recognised. Fortunately, with qmail-remote's
capabilities, these cases can be identified and mitigated.
2018-10-13 16:09:26.424424500 starting delivery 64: msg 28851126 to remote XXX@bb-c.de 2018-10-13 16:09:26.424428500 status: local 0/10 remote 1/100 2018-10-13 16:09:26.494943500 delivery 64: deferral: TLS_connection/protocol_error_for_host:_bb-c.de?._(#4.4.1)/
control/tlsdestinations:!bb-c.de: *: - 11.7.2018 : Finally, I updated my Webpage to make it more 'responsive'. qmail and
s/qmail and ipnet pages have been merged and called 'djbware'. It is not yet perfect
and requires an HTML5 capable browser for best results.
In addition, djbdnscurve6 is finished and working now on that page; to be made public soon. - 22.5.2018 : Sorry, I'm currently struggling with 'Lets Encrypt' getssl which does not perform as expected. Actually, it is bad to depend on anybody else resource/implementation. Isn't it?
- 9.2.2018: djbdnscurve6
starts to get momentum. Usually, I run some tests on this Linux server. However, this
failed miserably regarding dnscache:
2018-02-09 14:39:38.987179500 query 18 7f000001:d891:058f 12 140.24.52.164.in-addr.arpa. 2018-02-09 14:39:38.987206500 tx 0 12 140.24.52.164.in-addr.arpa. . 00000000000000000000ff0000000000 0000000000ffffc0cb00000000000000 000000ff000000000000000000000000 00000000ff00000000000000000000ff 2018-02-09 14:39:39.120059500 query 19 7f000001:ba3f:ed48 12 80.168.229.46.in-addr.arpa. 2018-02-09 14:39:39.120124500 tx 0 12 80.168.229.46.in-addr.arpa. . 000000ff000000000000000000000000 00000000000000000000ff0000000000 00000000ff00000000000000000000ff 0000000000ffffc0cb00000000000000
While standard dnscache is running fine, my IPv6 version including EDNS0 support and based upon Qlibs (see below) does neither display IP addresses correctly, nor IP response packets received for DNS queries are recognised. A quick check on a RasPi system is however ok. Conclusion: gcc in version 4.7.2 is broken beyond repair. - 14.1.2018: s/qmail version 3.3 is it's final stage. Together with Kai Peter, I started development of aqmail and the current s/qmail includes already a few backports from aqmail.
- 11.6.2017: While experimenting with the coming s/qmail release 3.3
I tried to incorpate support for 'International Domain Names'. In order to do so,
one needs to have the libs -libidn2 installed and included in the Makefile.
To bad, I installed by mistake libidn on my FreeBSD 10.3 developing systems, which triggered a lot of unrecognized changes and broke the system finally :-(
Not regarding my own SW, but some depending modules. Thus, I decided to move on to FreeBSD 11, which is required for some other SW I am working on.
This ended to be a desaster:- The pkg update seg-faulted.
- Due to some missing libs, I had to use /usr/local/sbin/pkg-static.
- The labels of my ZFS pool disks were changed, leaving the system in
an unfavorate state:
GEOM: ada1: the primary GPT table is corrupt or invalid. GEOM: ada1: using the secondary instead -- recovery strongly advised. GEOM: ada2: the primary GPT table is corrupt or invalid. GEOM: ada2: using the secondary instead -- recovery strongly advised. GEOM: diskid/DISK-Y2UYU5UPS: the primary GPT table is corrupt or invalid. GEOM: diskid/DISK-Y2UYU5UPS: using the secondary instead -- recovery strongly advised. GEOM: diskid/DISK-14DEJ7SNS: the primary GPT table is corrupt or invalid. GEOM: diskid/DISK-14DEJ7SNS: using the secondary instead -- recovery strongly advised.
- Samba (3.6) seems to be broken as well:
[2017/06/11 12:06:02.043342, 0] lib/util.c:1117(smb_panic) PANIC (pid 38634): internal error [2017/06/11 12:06:02.052251, 0] lib/util.c:1221(log_stack_trace) BACKTRACE: 5 stack frames: #0 0x1409058
- I had many other installation errors; sigh. In order to resolve those dependencies I have to install FreeBSD 11 from scratch.
- 16.11.2016: Finally, I integrated
Jana Saout's SPF feature
into s/qmail (version 3.2).
Thus, the regular SMTP connections are analysed and an 'Received-SPF:' header is added.
What was initially thought as Anti-Spam mechanism acts solely now as an authentication
information for the sending domain. After some hustle, beginning of this year
with Microsoft's strange email behavior
I was urged to publish some SPF records for my domains in the DNS as well:
v=spf1 ip4:85.25.149.179/32 ip6:2001:4dd0:ff00:3d4::2/64 -all
Now, s/qmail is smart enough to analyse and act on these information .... But, it is mostly useless. Even prominent MTA's don't posses a correct SPF Record. A waste of roughly 1000 lines of C code in qmail-smtpd. - 1.06.2016: According to my current experiences, SW quality is rather bad
the days. In particular am I fighting constantly with Apple's MacOS X 'El Capitan'.
The 'Mail.App' reconfigures itself, in case it can not contact a server. One of
many other problems. DNS is also not a well understood: A Zeroconf name like
'db._dns-sd._udp.0.192.168.192.in-addr.arpa.' makes absolutely no sense at all ....
Since at least one decade I support in my Anti-Virus Tools QMVC and QHPSI for Qmail ClamAV (though it is not mentioned on their home page: https://www.clamav.net/downloads). However, what makes me angry, is the failing of clamdscan (0.99) in case of a virus!
QMVC reports the following:
Reply-To:
From: "EDWIN GRANT"
Subject: PLEASE TREAT AS URGENT !!!
Date: Tue, 31 May 2016 16:10:41 -1200
MIME-Version: 1.0
Content-Type: text/html;
charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
#### Internal Errors ....
LibClamAV Warning: cli_loadldb: logical signature for Win.Trojan.ssid18332-1 uses PCREs but support is disabled, skipping
LibClamAV Warning: cli_loadldb: logical signature for Win.Ransomware.Locky-4 uses PCREs but support is disabled, skipping
LibClamAV Warning: cli_loadldb: logical signature for Html.Exploit.CVE_2016_0184-1 uses PCREs but support is disabled, skipping
#### Attachment Results ....(prepended with: 227589649-)
+++ 227589649-1464754350.9840-0.india167: HTML document, ASCII text, with very long lines
+++ Found 1 Attachments; thereof 1 Positive for scanning
#### Errormail Reports ....
#### E-Mail Errors ... (condition 64):
+++ Missing 'To:' information in header
#### Badmail Reports ....
#### Virus Reports ....
#### Actions on Incident ....
+++ The blocked E-Mail (ErrorHeader) was purged
#### Reactions on Incident ....
What a mess! Or let's phrase it a little more diplomatic: Virus scanners are as reliable as the weather forecast currently in Germany ... - 28.02.2016: IPv6 is a 'Jack in the Box': In case you use IPv6 for communication
and your DNS zone does not provide AAAA records (and the IPv6 PTRs) things may
behave erratic. Reversely, if somebody publishes DNS AAAA records but the client
app use IPv4 addresses to communicate with an IPv6 enabled server....
At least, the last case is taken care of now in sslserver and tcpserver. Curious, what problems will occure next. - 24.12.2015: s/qmail (3.0.0) is out and feeding now the mail delivery and reception!
- 24.11.2015: I'm close to reach one of my targets: To release s/qmail
(3.0). Version 2.15 is currently running on my systems and I expect to
include the QMQ feature easily.
While my servers are FreeBSD and (Debian) Linux, I use MacOS X as client. Of course, 'El Capitan' was an my update list as well. After waiting for the fist updates, I finally installed it on my 'Pro' last week. Instead of a 'standard' update path, I decided to install it freshly on SSD.
It took me two days to complete the move (almost). However, 'El Capitan' is a disappointment: MacOS X boots now in 25 secs. To compare: My old Mac Mini with a 1.5 GHz PPC and IDE drive achieves this in 45 secs!
The new Mail.app (V3) is *very* slow. Reinstalling GPG at the first place re-generated my PGP key; thus be careful sending me encrypted mails! The new pub key in online and my key signature is now EE00CF65.
Finder performance is additionally not good at all. Sigh. We call this progress. - 8.8.2015: Last week, my server was down for two days. The reason was
a scheduled reboot -- and the thing didn't come back online. It took me and the
support some investigation to figure out what went wrong. It turned out that
by means of Debian's udev due to unknown reasons (and probably after a
general package upgrade earlier this year) the name of the Ethernet interface
was changed from eth0 to eth1. Of course, the network
starting script did not bind the IP address to this interface. Too bad.
This updated messed things up. Now, the Debian has traditional init scripts, upstart and concurrently systemd services installed. What a mess. - 21.6.2015: Since more and more people use their smartphone or tablett to surf the Web,
I changed my Website's default setting to support something like 'liquid design'.
Too bad: The situation is worse than before; at least concerning my own smartphone. Autsch.
At least I almost finised version 2.12 of s/qmail which is now safe use. - 22.6.2015: Finally: s/qmail (2.12.9) is working on my own server as IPv6-enabled MTA! Unfortunately, my hoster 'server4you' is not able neither to provide direct IPv6 support nor to add a AAAA DNS records for my server. Anyway: You can reach me via SMTP/SMTPS and IPv6 2001:4dd0:ff00:3d4::2.
- 13.2.2015: On Arrive! Our book 'Technik der IP-Netze' finally came into the bookshops. Therefore, I put an advertising banner on my home page -- which failed initially. The publisher ('Hanser') send me two images; the one I used has the file named 'Ip-Netzwerk-160x600.png' which was called from my Apache server by the browser (in the logs); but the browser (Opera, Safari; but not Chrome) didn't display anything until I changed the name to simply 'Ip-Netzwerk.png'. It seems, both bowsers use the additional information for rendering -- but only if the HTML page is called via HTTP and not directly from disk. Very strange!
- 17.01.2015: Uff! Already a year has gone! Since finishing my book 'Technique of IP Networks' and my new professorship kept me busy, I just started with s/qmail develoment end of December 2014. However, I've already finished the major parts. Unfortunately, my provider does not support IPv6 these days directly, thus I will use SIXXS to deploy my IPv6 address in order to alllow sending emails to my qmail-smtpd instance using IPv6 even without a AAAA record. IPv6: 2001:4dd0:ff00:3d4::2
- 10.05.2014: MRTG working now. Since my new server is operational,
neither MRTG nor Webalizer did work. Calling any of those, I always
got the annoying warning:
/usr/bin/webalizer: symbol lookup error: /usr/bin/webalizer: undefined symbol: gdImagePng
even though I installed everything in place and without problems.
Finally, I found the problem:
The new libgd-2.1.0 simply does not work. With the old library gd-2.0.33 however, I succeeded, provided the configure script was pointing to the correct conf-libpng (in my case in /usr/bin):
'./configure --with-png=/usr'. - 29.04.2014: Spamcontrol 2.7.31 is out. It provides even more TLS
tweaking knobs. Though TLS (and in particular OpenSSL, where it depends upon)
has been massively criticised lately, there is little alternative.
Fortunately, the design of UCPSI-SSL an qmail/spamcontrol does not allow
an active abuse of the Heartbleed bug by third persons.
Our book 'Technik der IP-Netze' is closed to get finished. Lately, we included MPTCP and DTLS (with reference to the Heartbeat function). - 14.04.2014: Disk crash on my development server ;-( (FreeBSD 9.1).
Actually, it was not a hardware crash on my Samsung 1.5 TByte disk, but rather an inconsistance of the file system - unfortunately where paging happens ...
Foruntately, this was the backup drive. However, fsck'ing the drive the following happend: fsck was swapped out -- and the page was stored in the bad section. Reloading the page, the kernel realized an inconsistancy and panic'd. What a mess. The difference w.r.t. Linux is, that fsck can run in the background. But rather the process should neither be paged-out nor swapped-out. Physical memory was enough there ...
Ok. Fixed. The removal of the hard drive was enough. However, setting up FreeBSD 10.0 was again challenging. Just clang C-compiler, no gcc. Some programs don't compile with clang (ie. my vmailmgr and Binc). My first attempt was to sym-linking gcc to clang. Very bad idea. The later install of gcc from ports failed miserably. However, after having installed gcc and g++ runnig ./configure with the path to those progs saved my day.
I used an Adata SSD for the OS and a ZFS Raid 1 for my data (/home). What made me wonder is that ZFS not only includes a Volume Manager and a Filesystem but in addition provides Gpart functions. Even if gparted the disk with GPT and freebsd-zfs label, it disappeared after having installed the ZFS. Strange and not documented. In fact, gparting the disk even after having installed ZFS does not harm (at least not doing nasty things). The disk partiton table seems not to have any dependency on ZFS ! Unfortunately, missing documentation on the behaviour of ZFS is quite common. - 27.01.2014: After upgrading my root server to a 64 bit system, one
striking Spamcontrol bug became obvious: Within smtpdlog.c, I've forgotten to
declare some logging variables. This does not hurt 32 bit systems, but makes
qmail-smtpd stop within an SMTP auth session under 64 bit.
Additionally with this bug fix, some more issues
have been corrected in Spamcontrol 2.7.30 together with some enhancements.
Apart from my own bugs, making lagacy C programs run under AMD64 is a challenge. - 14.01.2014: I've received some bug reports from John Levine, regarding ucspi-tls6. Thus, I took the chance not only to fix those but rather to streamline ucspi-tcp6 (1.00) with ucspi-ssl (0.93). Ready for download.
- 27.11.201: I've moved from 'Snow Leopard' to 'Mavericks' on my MacBook Pro.
Instead of replacing 'SL' I used a spare partition -- and had to re-install
all my Apps. To get the Mail.app working, it drove me nuts. Finally, I figured
out, that qmail's qmail-popup does not announce 'CAPA=User'. After including
it into the new spamcontrol-2719 ,
it is working fine; though the GUI for
the Mail.app setup is still broken (three places to change setttings ...).
The good news: 'Mulberry' is still running great under Mavericks! - 06.10.2013: ucspi-tcp6-0.99a is out. No changes to binaries.
- 05.10.2013: The first two chapters of our book 'Technik der IP-Netz' have been successfully converted from the 'doc' format to 'tex'; an explanation about the RSA KeX has been included into my SMTP TLS tutorial.
- 25.09.2013: Relaunched web site now with (moderate) CSS instead of table layout.
- 18.09.2013 - 23.09.2013: Server down due to power supply failure.
This site is powered by an AMD X2 Dual Core Processor 3400+ with 4 GByte memory.
Old: Linux india167 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux
Previous: Linux india167 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux
Current: Linux india167 6.1.0-37-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22) x86_64 GNU/Linux
SW: s/qmail, vmailmgr, ezmlmx, bincimap, djbdnscurve6, ucspi-tcp6 + ucspi-ssl, Daemontools, Apache2 (and systemd).