Category Archives: postfix

cloud, networking, postfix, security

Switching Mail Sending to Amazon

This is another aide-memoire about changes in mail on Tarragon.

Some weeks back a change in one of the website contact pages was done and the captcha code was inadvertantly omitted. There followed a period of massive junk email directed at the owner of the site, on her google gmail account. Google decided to cut off tarragon’s ip address.

Although the problem is fixed, google has not relented. And this is the same kind of issue I have had in the past with microsoft. Although I have never been a source of spam, the big mail outfits are quick to ban the ip address of any small personal smtp server, and it takes a lot of effort to convince them to release the ban. I am tired of it. Despite my quixotic desire to run my own mail server as a symbolic cry against the erosion of personal services on the internet, I am tired of fighting, and I think it is time to stop.

Continue reading Switching Mail Sending to Amazon →
cloud, linux, mail, postfix

Adding mail accounts

This is a memory aid, like a lot of these posts. Because I forget how to do things and have to figure it out again.

Adding mail accounts on a virtual mailbox domains requires two things: a) make an entry in /etc/postfix/virtualmb and posthash it, b) ensure the username exists in the users database on tarragon.

Adding mail accounts on the primary wmbuck.net domain (without creating a login account and home directory, etc.) requires a) make an entry in /etc/postfix/localrecipientsmap and posthash it, and b) adding the username to the users database.

arch linux, gateways, ipv6, linux, mac, networking, openssh, postfix, raspberry pi, raspbian, security, ubuntu, vpn

IPv6 Re-implementation

This is a follow up to the activities in IPv6 implementation, which was published on March 2nd and revised up through March 19th, as new challenges were addressed. Since March 19th a great deal of what I wrote has been revised, as I have learned a lot more.

The main issue was that there remained a number of problems with the implementation of IPv6 in my residence.

  • The biggest was the question how to handle the delegated prefix, particularly in renumbering. Over the course of the last several months I have to note that Comcast has never changed my prefix, except early on, when I forced it to do so by changing my DUID. And I don’t think it likely that my prefix would change unless some great catastrophe befalls which results in my being down for a very extended period – like 30 days; or more likely there is some change in my service (a change in ISP, or perhaps fiber arriving in my area).
  • The first implementation required that I make patches to the code of my router. This meant that I would have to figure out how to carry those patches forward in the event of firmware updates from Ubiquiti, the maker of the Edgerouter-X that I am using.
  • The implementation was pretty fragile, with a lot of unrelated bits in different places. In particular there was a lot of hand-waving in trying to assign and maintain a separate network for the virtual machines on one of the interior boxes.
Continue reading IPv6 Re-implementation →
linux, mail, postfix, spamassassin

more spam improvements

Over the last couple of weeks I have made the following improvements in spam checking for mail handling on tarragon. Tarragon handles mail for about 20 domains, although only about a dozen have any mail to speak of.

I used to have entries in the amavis whitelist file, but this is/was a weakness. It is easy to fake sender addresses. Use of the amavis sendermaps feature is preferable as that way one can give a spamassassin bump to a known address or domain, but the value of the bump can be small enough not to overcome other attributes of the message. So egregious spam that claims to come from my own domain will still be caught. Also, I can have sendermaps for each separate email domain, instead of a whitelist applying to everyone. The file /etc/amavis/conf.d/56-sendermaps now has all the sendermaps.

Continue reading more spam improvements →
linux, mail, postfix, spamassassin

Spamassassin change

I seemed to have more spam getting through. When I look at those messages which I think should have been caught, I observe that many/most/almost all of them contain in the X-Spam-Status the value: RCVD_IN_DNSWL_HI=-5. Spamassassin is giving them a whopping -5 whole points if the dns source of the message appears in the High Reliability list of the site DNSWL.org, which according to what I read, is one of those sites that maintains reputation lists, and says of the High list:

“Recommended Usage: Skip spam filtering for medium and high ranked IPs. These are trusted to send spam rarely enough that they are not worth filtering.”

There is some discussion on the net, others too seem to think they are getting a lot of spam because of this, suggesting that a site on the dnswl high list can be induced to forward spam. I know little of all of this, but I have added a rule to /etc/spamassassin/local.cf: 

score RCVD_IN_DNSWL_HI 0 -0.1 0 -0.1

This changes the value from -5 to -0.1. If I set it to 0 (as I originally did) then I can’t tell in X-Spam-Status whether the rule applied or not. Now I see the rule in X-Spam-Status with a small value.

So far this seems to have helped. Encouraged by this, I’ve added another couple of specifications to /etc/spamassassin/local.cf, to wit:

ok_languages en fr
ok_locales en fr

Which should act to increase the “spaminess” score of emails in other languages and character sets. A couple of mail users are French speakers, but AFAIK nobody using tarragon for mail speaks any other language or/and receives mail in another language.

fedora, gateways, linux, mail, postfix, raspberry pi, raspbian, saslauthd, security

No Worthy mechs

I just built another little gateway pi, on Raspbian. It is a newer Raspbian than I used for the others. And newer is better, right? But when the little fellow came up, postfix claimed it couldn’t relay through tarragon, because it couldn’t accomplish login. Sasl authentication failed, no worthy mechs.

I remember good old “no worthy mechs” from way back when, always thought it a very cool error message. But why in the heck am I getting this? I’m not doing anything fancy.

I had a vague nagging feeling from some old Fedora problems, long ago. Could it be that I have to install some kind of sasl library, even to do plain authentication? Poked around a little. Eventually did an apt install libsasl2-modules and sasl2-bin. Sure enough, they actually installed.

And afterwords postfix came up and send the mail out of the queue. I’ll be dipped in … I am surprised. This was not something I had to do before. Is this an improvement in Raspbian. Don’t package any sasl mechs, make the poor sod figure out why sasl authentication won’t work.

This is to help me remember the next time this happens.

apache, backup, centos, cloud, fedora, linux, mail, postfix, security, website building

Clamd signatures and Apache memory

After implementing the new tarragon the biggest problem I had involved the clamav package, and its loading of signatures. If clamd doesn’t come up and open its socket, then amavisd (the daemon who is consulted by postfix to handle all the checking of each piece of mail on input and output) will fail (assuming he is configured to do virus checking), This results in various problems. Amavis will mark the mail as “unchecked”, but worse, it will report failure back to postfix who gets confused and very often the message is delivered two or three times.

Clamd, the clamav daemon, now has over 6 million signatures. There are a lot of bad boys out there. The signatures are loaded by clamd from its database (in /var/lib/clamav) on startup, into memory. As a result, clamd has a large memory footprint, almost 800Mb on my system. The first issue, discovered before going live, was that systemd’s default parameters expect any daemon he starts to load within 90 seconds. If it fails to check in within that time, systemd considers it broken and terminates it. Clamd takes at least 3 minutes to load. I had to set a special TimeoutStartSec value in the systemd service script for clamd@.service.

Whew! I thought, boy I’m glad I figured that out. Hah!

Continue reading Clamd signatures and Apache memory →
apache, backup, btrfs, centos, cloud, fedora, linux, mail, mysql, networking, postfix, website building

Tarragon Rebuild 2019

This server, on Amazon, hosts my website and a dozen others, provides mail service for several people’s email including my own with postfix, dovecot, opendkim, amavis, spamassassin and clamd, provides contacts and calendar service using radicale, provides vpn service with openvpn, provides a tor relay, provides nextcloud service, and hosts my svn repository.

The server was last rebuilt in 2017. Long, long ago when I built the first version of it, I was most familiar with Red Hat/Fedora, and since then it has been easiest just to upgrade it with Fedora, always grumbling to myself that someday I’m going to change it. The problem with being on Fedora, of course, is that Fedora changes every 6 months, so I’m constantly behind. And after a year I’m at end of life. This is dumb for a server that I don’t want to be messing with all the time.

Continue reading Tarragon Rebuild 2019 →
backup, mac, mail, networking, postfix, security, Uncategorized

Setting up a mac remotely

I want to be able to get to my wife’s mac, in another city. She is an unsophisticated user, and I’d like to be able to help her when she needs help, but I can’t ask her to do very much setup. I also want to be able to provide backup for her files.

The first step was to outfit her with one of the little gateway pis previously described. Once that was done, we managed, together, to enable me to get to her mac with ssh, by way of the pi tunnel. And we managed to set up an account on her mac under my name.

Continue reading Setting up a mac remotely →
backup, linux, networking, postfix, security, ubuntu

Gateway pi

1 Comment

I realized as I was writing a new post that I had never documented the gateway pi undertaking.

This started when a friend in the mountains got a new internet service where the ISP would not allow him (and therefore me) access to his router. As a result I could no longer use ssh to connect to his systems.

I solved this problem by setting his systems up to use a tool called autossh, with which I could have his system start, monitor, and keep running an ssh daemon with reverse tunnels open to my system. I could then reach him by attaching through the reverse tunnels.

Continue reading Gateway pi →