It is really hard to test some of this stuff out. In my last post I did certainly cover the effect but I thought I understood the cause as well. That is not the case, so I was full of shit, so to speak, and sort of.
The problem was, if my customer sent or forwarded from some domains both related to one company the emails were rejected. A reject email was sent back to the originator of the email.
I thought this had to do with configuration of the Proxmox Mail Gateway (PMG). That was partially correct. Those things I spoke about in my previous post were problems, and I did correct them, and that is a good thing. There was more wrong. I needed to resolve that as well, only I didn’t know what it was. Testing showed this:
If she sent from those two domains in question, the emails, be they forwarded emails or new email, were sent back with rejection notices. If I took the PMG out of the chain the emails were delivered. Which means, if the PMG was in place they were rejected and when removed the actual email server allowed them.
One would conclude from this that the PMG was rejecting them instead of the email server itself.
From my investigation of the data collected by the PMG’s tracking center it showed that the IP address in question ended in “.70”. The reject notices that the user received said that there was an SPF Fail.
Sender Policy Framework (SPF) is a mechanism that says “the domain that has this record is permitted to send emails”. The SPF record has a bunch of parameters. One of them is the “all” parameter and in addition to that there are parameters that specify the IP addresses within the domain that are allowed to send emails, so not just the domain name is checked but the IP addresses to.
When I looked at the SPF record for the two domains in question they all go through this server that has an IP address ending in “.70” however the SPF records for each of those domains does have the IP parameter, one multiple times, but neither domain has the IP address ending in “.70”, meaning because they used the “-all” instead of the “~all” the receiving email server would score that higher as SPAM. However, the email servers generally do not force a reject even with the “-all” unless they are either incorrectly set up or they are being highly restrictive.
Now we get to why these email were being rejected.
I set this up as a Proxmox Server with a reverse proxy container, a website container, and an email container. The PMG is in its own container.
The purpose of the PMG is to receive incoming emails on port 25 and check them for spam, blacklisting, viruses, etc, and then if they pass they are sent onto the actual email server. The PMG did receive the emails and it did show in the tracking center that it was received and rejected. The status information did show that IP address ending in “.70”, and it showed the “SPF Fail” as the reject reason. If you read closely it shows that it had attempted to send it to the actual email server and was rejected. I take that to mean that the email server rejected it and told the PMG it was rejected and the PMG then sent the email back to the sender with the reject notice.
So, what caused the email server to reject it without even looking at it (at least that’s what seems to have happened)? When I realized it was the email server rejecting it, instead of the PMG, I decided to look more closely at the email server’s configuration. It too has the standard virus checking, DKIM checking, SPF checking, the Spam checking, etc. It’s doing much of what the PMG is doing, except it doesn’t handle management of it as well as the gateway does. The PMG can keep your email server from taking a big hit of resources if some spammer goes after your email server. It can keep the load off the email server itself. That’s part of it. The other part is that it has a decent interface for whitelisting/blacklisting and setting up rules to check for different conditions. A basic email server could be configured this way but normally isn’t — except in all but the largest or organizations.
So, I had to look at the configuration from all these standpoints, at least that’s what I planned. I started to review each of the different services (virus, SPF, spam, etc) and then jumped over to looking at how the SPF was handled by the email server itself. I went back to the guide that I used to set it up and found that the configuration was done via the main.cf file which is in the /etc/postfix folder.
I looked at this file and noted that it had nearly nothing in it. It had what appeared to be a basic install (basic configuration). I looked at my own email server and noted it was far more extensive. I knew it would be because I spent a great deal of time configuring all sorts of settings in there.
So, I copied my main.cf, master.cf, header_check, body_checks, and sender_access files from my email server to this one. I copied those in place and ran “postmap” on the “sender_access” file (so I wouldn’t forget), and then reviewed the main.cf file for site specific information. I corrected for this server. I then did the same for the master.cf (which had no server specific information). After a couple of reviews I restarted the postfix service. I half expected errors. Since postfix didn’t give me an error and neither did dovecot (clamav and amavis and spamassassin were all still functional and active services) I rebooted the container and checked again.
I first tested with my Android tablet running K9 Mail. That worked. I then loaded the “RoundCube” webmail which is run from that same container. All of it worked.
At this point I put the PMG back into service and tested again. It all still worked so I asked the user that was receiving the reject notices to try again. Those were successful, they were delivered properly.
What was the lesson learned? Stick with it. When one service seems to have rejected something it doesn’t mean it is rejecting it. It could be some other service further down the chain that’s rejecting it.