Category Archives: postfix

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.

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

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

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

Gateway pi

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

Certificates Redux

An earlier post talked about switching my server tarragon (where this blog sits) to a wildcard certificate from letsencrypt. There were two reasons why I was using a wildcard certificate. One had to do with test versions of websites that run on this server, and the need that some of those sites have for wildcards, of the form: bob.websitename.com, sally.websitename.com, etc. The other reason was that I have a lot of hosts (oregano, cinnamon, paprika, lemongrass) in addition to tarragon that “need” to have a certificate, for https, for imap, and for smtp, and when I was having to pay for them, it was cheaper to get one wildcard for wmbuck.net. Continue reading Certificates Redux

Webmail

Update 2017-08-07:

I switched from using squirrelmail to a product called rainloop. Rainloop was relatively easy to install, and is far nicer that squirrelmail. But the basic idea is the same.

A next step for providing mail service for some of my users is a primitive webmail facility. For this I used a product called squirrelmail.

Squirrelmail installs, on fedora, into /usr/share/squirrelmail, with config in /etc/squirrelmail. /usr/share/squirrelmail/config contains a perl script, conf.pl, which provides a simpler configuration experience with explanation of all the somewhat cryptically named fields.

As part of doing this I obtained certificates for all the domains I am hosting – at least all of them over which I have enough control to meet the validation requirements of startssl.com, meaning either I am postmaster or the documentroot of the website is on tarragon. Without this I would have to choose between not encrypting the mail, or having the user have to put up with mail programs complaining about the certificate.

Saslauth, mail and realms

This server (tarragon) runs a postfix instance which provides mail service for my own wmbuck.net as well as for about a dozen other domains belonging to friends and clients. Postfix offers three different ways that a server can receive (be the final destination for) mail directed to a domain:

1) as what postfix calls the canonical destination (i.e. mail for x@wmbuck.net) where tarragon IS wmbuck.net, and each mail recipient maps onto a user who has a login account on the server, and messages are delivered to that account;

2) as a virtual alias destination, where mail directed to y@somedomain.com is accepted, but for each such address there is a corresponding forward address to some other location bob@gmail.com or something, and the actual mail messages do not reside on the server; and finally

3) as a virtual mailbox destination, where mail directed to z@anotherdomain.com arrives and is stored in mailboxes on tarragon, awaiting pickup/reading by the user, but without requiring that there be a user z with an actual login account on tarragon. This requires that the mail store on tarragon be set up to maintain different sets of mailboxes for different domains. There can be a user fred@wmbuck.net and another user fred@fredsdomain.com and the mail is not intermixed.

Tarragon uses cyrus-imap as the mail store, and it provides the ability to have different mailboxes for different domains. To support that, the mailboxes are actually constructed differently, so that cyrus-imap can have a mailbox fred, but can also have a mailbox fred@fredsdomain.com.

This requires, in turn, that the imap server be able to identify the correct mailbox when a mail client attaches, and be able to separately authenticate for each mailbox. When cyrus-imap is configured to support this separation, it requires that the username on login be fred@fredsdomain.com, rather than simply fred.

Cyrus-imap uses the saslauthd daemon to authenticate, and saslauthd in turn calls upon pam, passing in the username,  password and realm (domain) received from imap (or postfix for smtp, or apache for website auth), who receives it in the login message from the user’s mail client. Pam’s authentication for mail is set to use a module called pam_mysql, which is able to match against credentials in a mysql database.

Here is where things get tricky. Take the mail account dee@thegraygeek.com. There is also a user dee with a system account (i.e a type 1 canonical mail account dee@wmbuck.net). I can choose either to have a) only one entry in the database, for user dee, with a password. That same entry is consulted for access to either mailbox (dee@wmbuck.net or dee@thegraygeek.com) but the are still separate mailboxes. Or alternatively, b) I can have different database entries for dee and dee@thegraygeek.com, each with its own password. 

A digression: I could, and for many years did, choose to list thegraygeek.com as a canonical final destination in postfix. If I do that, then mail for dee@thegraygeek.com goes into the mailbox for user dee on tarragon, just the same as mail for dee@wmbuck.net. They go into the same mailbox. But when I began supporting virtual mailbox domains, I separated them – using the gray geek account as a test case for hosting virtual mailbox domains. 

Originally I set it up with the idea that there would be seapate database entries. With them separated, an imap login for user dee at host wmbuck.net will attach to the mailbox for the user dee, while an imap login for user dee@thegraygeek.com at host wmbuck.net will attach to the mailbox for user dee@thegraygeek.com who does not have an account on tarragon.

I set all this up over a year ago, and it seemed to be working. Then I set up a new account for a friend who had a new domain name. And I discovered that I had a problem. It so happened that in every case where I had created a mailbox of the form fred@fredsdomain.com, I actually also had an account fred on wmbuck.net, many of those never used and left over from the days when I was only doing canonical logins. I discovered that even though I had entries in the database for login as fred@fredsdomain.com, the login process was actually using the database entry for fred. It so happened that all these accounts (fred and fred@) had the same password. As soon as I added an account bob@ which did NOT have a corresponding server login account bob, with the same password, it failed.

When I tried using testsaslauthd -u bob@bobsdomain.com -p <pw> it would work, so the pam machinery and the pam_mysql plugin were working right. The problem occurred between cyrus-imap and saslauthd. I discovered that (a) cyrus imap takes an incoming username of a@b and separates it into “username” and “realm”, and passes those separately to saslauthd, and (b) saslauthd has a parameter ‘-r’ which I had previously failed to discover, which causes it to append the incoming ‘realm’ to the incoming ‘username’ when it attempts to authenticate. Without the ‘-r’ parameter, saslauthd was using only the incoming ‘username’ – fred or bob, in its call on pam. If there was such an account and the password matched, saslauthd would succeed, and the connection would be permitted. Note that cyrus-imapd would now actually connect to the correct mailbox – the issue was that it used the wrong database entry to authenticate against.

Once I turned on the ‘-r’ parameter to saslauthd, imap works for both dee and dee@thegraygeek.com, but I get a problem in smtp.  On the call from smtp->saslauthd->pam_mysql when saslauthd has the -r parameter simply ‘dee’ as the username will not authenticate. The log record coming from pam_mysql indicates the username comes across as ‘dee’, but fails. If I create a database entry for dee@wmbuck.net, and set the username on smtp to dee@wmbuck.net, it works.

After a couple of weeks, I began to change my mind. The database is used for several kinds of logins. Going this way – with separate logins for bob@bobsdomain.com and bob meant: I have to have 2 records in the database. Bob could get confused if he changed his password on one but not the other. For some users I could probably just delete the ‘bob’ entry, and force bob to type in his full email address in order to log in for other things. But I decided this was unappealing.

So I have turned off the ‘r’ parameter, and eliminated all the entries that say bob@bobsdomain.com from the database. Bob must still use his full email address when connecting to imap but for plain logins in other places, he can use just bob. This also means I no longer have to have a separate database record for canonical mail users to do smtp.