eMail Server, Again

I’ve now been retired for over 10 years and my software and IT skills are not what they used to be. Nor, for that matter, is my patience in dealing with annoying issues. From time to time I have considered throwing in the towel on running my own server. I only have six users and it would not be all that much more expensive to pay for six accounts on a privacy respecting email provider than to pay for my Virtual Private Server (VPS).

But I also use my server for the email distribution lists for several volunteer organizations I am associated with. Those lists are small, I think the largest has only a couple of dozen addresses. Moving those lists to some commercial provider, and the associated hassle of modifying the custom web software associated with them, is a large factor on my staying on the current course.

There have been a couple of issues recently which the reason for this post.

Microsoft Issues

A while back I recounted the issues I had trying to get Microsoft to accept email from my server when they blacklisted my server as a spam source. Now I have the reverse problem: I am getting spam from Microsoft based accounts. I almost came to the point of blacklisting all of Microsoft’s email servers but there are four people I correspond with that use Microsoft’s services so I decided against that measure. Though I kind of hope that one of the major blacklists will start blocking their servers as I think that would get Microsoft’s attention.

The spam emails are pretty well done. They are personalized with my name and look like they might be really from the retailers they claim to be from.

The initial batches of spam had the From: in the headers in the form Later ones started using At first I thought that ` was itself fake but a check showed that it is a domain registered to Microsoft and the email comes from servers with domain names. So they really are using Microsoft accounts.

For other reasons, I already had the following in my Postfix server’s file:

header_checks = regexp:/etc/postfix/header_checks

So it was a simple matter to add the following line to the header_checks file

/^[F|f]rom: .*\<infos*_.*@.*\        REJECT JUNK is not allowed by this server

That quieted things down a bit. But later they started using other prefixes so now I have nine similar lines in the header checks and I guess I will be adding more as time goes by as I play “whack a mole” with them.

I do wish that Microsoft improved their procedures for account creation and detection of spammers using accounts on their system.

Edit: It is even worse. Looking at my server logs I see a large number of records showing mail from servers being rejected because of SPF failures. The servers actually have names like as if they actually are doing some sort of outbound email gatekeeping. When I check the claimed domains for the From: address on some of the emails I see that those domains exist, they are not owned by Microsoft, and they have published SPF records indicating that only their servers can send mail for their domains. Either Microsoft is not validating the from address in emails originating with them or they are running an open relay. How long can they keep this up before all these “” servers are in widely published public blacklists?

Mail Lists and SPF

While working on the above issue I noticed that the outgoing mail queue had several items in it. All from volunteer mail lists and all destined for gmail accounts. The information associated with the queue entries indicated that Google was slowing down delivery because the Sending Policy Framework (SPF) records from the provider(s) of the sending accounts did not list my server as authorized.

This is entirely on me and I have been hypocritical about it too: My server honors the SPF records and rejects email that fails. And I knew that my mail list scheme that simply uses mail server aliases was not doing the right thing.

I have to complement Google for doing something well: Instead of simply rejecting or accepting the mail they slow down delivery. That keeps spammers at bay without causing too much of an issue for their gmail users.

But it was time for me to fix that. Unfortunately it took me a lot more hours to figure out a fix than it should have.

On email there are two from addresses that are usually the same. One in the headers which is what a person sees when the open the email. And another one in the “envelope” which is only seen by the email servers.

In my case, I want any mail list email to have the envelope from to be an account owned by my server. I have several domains and for regular email from one of my domains, I do not want that envelope sender to be modified. But if the email is because of an alias being expanded (i.e. email list) then I do.

The solution is not terribly hard but it took me a while to understand how to do this. Postfix has some processing that allows you to put email addresses into an canonical form, so in the master.cffile:

sender_canonical_classes = envelope_sender
sender_canonical_maps = regexp:/etc/postfix/sender_canonical

The first line says only to work with the envelope sender address. The second one says to apply the sender email modification rules found in the file sender_canonical:

# Sender from for local domains should not be changed
/(.*@mydomain\.org)/ $1
/(.*@myotherdomain\.com)/ $1

# Any other sending domains should be from people sending
# to mailing lists, so change the sender to a local domain

Postfix looks at each line from the top and uses the first match. So I have my domains listed at the top with the transformation being to keep the match. If none of those match, which should only happen for aliases being expanded as a mail list or possibly an email forwarding alias, then the /.*@.*/ line will change the envelope sender to thus changing the owner used in SPF to an account at my server.

Since the envelope from address is the one bounces should be sent to, as system administrator I ought to get notifications when there is a problem.

This seems to work. No doubt there will be further issues with things like DKIM but I will cross those bridges when I come to them.