FreeBSD Sendmail Setup Part 9

The original Japanese version is available here.

We have gone through 8 long installments to make sendmail practical, and we have continued to use it afterwards, so we would like to inform you of its status and deliver Part 9 of the sendmail series. Before that, let’s review what we have covered so far.

So far, I have been able to use email normally on Windows PCs within my home and on my iPhone, not just on my home WiFi but also when I’m outside using 4G. I use Thunderbird as my email client on Windows, as I just can’t get into using M$ Outlook :).

On the iPhone, we used the standard iOS mail client. It seems like there are people who are struggling with sendmail + starttls 🙂

In this time, there have been some interesting things that have happened while using it for fun, so I would like to try to understand the trends and take action on them.

Initially, it started as soon as I began port forwarding on my ISP router. I think a port scanner robot detected that the smtp port was open and has been playing with it non-stop since then. It could be resolved by blocking it with ipfw or pf, but when considering whether to write an article about firewall or sendmail, I thought it would be more interesting to write about how I was playing with those “visitors” 🙂 So, it became part of sendmail Part 9. From the perspective of a network administrator, I don’t particularly like to play with firewall on the server side and prefer to use a dedicated security appliance. I apologize for that.

Well, to give an idea of the state of the smtp port, here is a portion of the mail log.

It’s quite fancy, isn’t it ? At first, there were only one or two addresses that came to play, and I was having fun looking at the contents of the traffic with tcpdump and so on, but after using it normally for a while, the number of addresses that come to play exceeded several tens. Once an IP address information is published, is it shared all over the place like a special fraud list?

As for what they are doing on the SMTP port, it can be seen from the logs that they are trying to find the username and password that can be used with SMTP AUTH through brute force. Reports also come in this form via email.

So, for now, it’s only slowing down the responses of sendmail and not causing any problems to the public. Specifically, I’m using the /etc/mail/access file to increase the time it takes for the smtp session greeting message to be displayed when the session is established. I’ve set it to 30 seconds, as making it too long may result in it no longer being fun with them with leaving us.

So, as long as it’s not causing problems to others, I’ve only been slowing down the response time of sendmail manually. At first, I thought it would be a good exercise not to forget the usage of grep, sort, uniq, and awk commands while handling up to 30 guests manually, but it gradually became cumbersome, so I thought about writing a script to check the logs and automatically create the access file. But it wouldn’t be sensible to spend time on just passing guests, so I reread the sendmail README file as a learning opportunity. I found a suitable solution for my home email server from the CONNECTION CONTROL section, which is around 63% of the file. I set it to reject the connection with error 421 “Connection rate limit exceeded” if the frequency of smtp connections exceeds a specified number within a certain time (default 60 seconds). Two changes are required to use this function. First, in the mc file of the original sendmail.cf file, it’s jf3vqb.mc file for the server dhcp. It will look like this.

First, I need to modify the mc file of the current sendmail.cf file, on the case of the server server dhcp, it is jf3vqb.mc file. It looks like this. Then, I made these changes and recreated sendmail.cf and restarted sendmail. The second change required is the access file. I removed all GreetPause and replaced it with one line.

If there are more than three connections per minute, the connection will be rejected with a 421 error. The log immediately after the change look like this.

Well, this method may not be usable for mail providers with heavy traffic, but since it is a privately set up mail server at home, there will not be a lot of emails coming from the same IP address. If such emails are recorded, it will require defining exceptions. If it is not a foolish robot but something that is controlled by AI or there is a human being involved, the frequency may be adjusted. But as set, it will be blocked if more than three times per minute. How many times will it be set? I may not be alive by the time someone can obtain the password with brute force 🙂 What will happen is left to your imagination 🙂 but I had thought this, but some smtp connections already came throug with this setting.

I don’t know if it’s “surface butter” or “toast butter”, but it’s slipping through. It might have originally been connected at a very low frequency. When I checked who it was from the IP address with whois command, it seemed to be from country code LT, so it looks like it’s from Lithuania. There is also access from another address range, and when I checked the address with whois command, it was also country code LT. Despite the low frequency of connection, it connects from different IP addresses every time and is carefully separated into different host names.

Is there any organization that specializes in this kind of thing? Anyway, it seems risky to continue allowing these connections, so I’d like to do something about it. However, there doesn’t seem to be a good solution by just looking at it. For now, I see connections only from 141.98.10.0/23 and 185.36.81.0/24 network segments. I’ll use the original Greeting Delay. I’ll observe the situation for a while. By the way, there has never been a connection from these types of people using IPv6. Should I make the IPv6 only SMTP server? If the mail client can use IPv6 addresses, there is no problem, and even if clients are in IPv4 only environment, there is no problem as long as IPv4 can be used on the submission port. Strangely enough, only regular connections are recorded on the IMAP and submission ports. If the goal is to steal user names and passwords, the same can be done through these ports, too.

I have also enabled the SPAM filter, which was not mentioned in the previous explanation. I think I have covered all the features that are normally desired. It is good, isn’t it?

The SPAM filter I use is SPAMASSASSIN. The setup information is all here.

The default options are used for everything. If customization is needed, you can look at these files and the comments section has various things written.

I don’t think we can have more functions on the server dhcp. All memory is used and t’s swapping a little bit.

This server dhcp is a very old 32-bit PC with only 1G of memory. As I mentioned in a previous article, running a virus scanner made it extremely difficult. Therefore, I set up a FreeBSD operating on a VMware Player on a Windows PC to check for viruses through MILTER. The Windows PC I normally use is Windows 11, but I stopped Windows Update to prevent it from restarting on its own. However, this also stopped updates for the Defender definition files, so I had no choice but to use a second physical machine. At my company, the IT support team manages everyone’s computer, so I asked them if they had any discarded computers. They gave me a partially broken computer, a DELL Latitude E6400 with an none-SSD disk and only 4G of memory. But it is much better than the server dhcp and 64-bit OS can run on it. At first, I set up a FreeBSD server on VMware ESXi, but because the CPU is too old, it only runs ESXi 6.5 and lacks excitement, so I decided to run FreeBSD directly. For these reasons, the host name is esxi.home.jf3vqb.net. This is simply because I didn’t want to change the DNS, and the name refers to the FreeBSD machine rather than the VMware ESXi server.

Although the server dhcp only has one processor, it uses about 50% when receiving emails, but other than that, it is mostly idle at around 97-98% when “visitors” are just playing with SMTP ports.

As for the server esxi, it seems to reach the limit, too. Anyway, clamav consumes a lot of resources.

Both machines would be beautiful if they were all combined into VMware ESXi, but since VMware ESXi stops everything stops, they are kept as physical machines. Both are in the category of antiques, so the power consumption is not to be taken lightly, but since they are individual physical machines, the experimental environment can be scratch-built as much as desired. In addition, there are no complaints from the family about networking 🙂 The mail environment created this time turned out to be unexpectedly pleasing, so it will be used as is for a while. This is really supposed to be the final episode of sendmail.

Advertisement below