”COVID-19 bryr sig inte om dina känslor”

Lämna ett svar

För att förstå problemen med COVID-19 kanske man måste vara verksam inom någon form av problemlösar-bransch. Det kanske är först då man förstår vad det handlar om.

Jag har ett yrke som programmerare där vi ibland möts av rena rama galenskaperna, som mycket handlar om hur man blandar ihop system som inte alltid är redo att hantera uppgifterna man ger dom. Lite som en del sjukdomar alltså, där vissa sjukdomar trivs bättre eller sämre i olika miljöer. Samma sak gäller alltså här, det kommer ständigt nya problem på grund av bland annat ständig rörelse i infrastrukturerna – men lyckligtvis i många fall kommer dom symtom som man känner igen sen tidigare. Därför kan man lösa problemen snabbare, utifrån erfarenheterna.

När vi ställs inför saker vi aldrig sett förr däremot, så är det inte ett problem som blir löst i en handvändning heller. Det finns ett fåtal tillfällen i mitt liv där problemen aldrig blivit lösta heller. Jag betraktar COVID-19 på exakt samma sätt och därmed har FHM och alla kämpar där ute min största respekt för det de gör. Saknar ni de kunskaperna, sluta då killgissa professionalism från soffbordet hemma. Dom är helt enkelt otillräckliga.

Postfix smtpauth and clients without imap/pop-auth

Lämna ett svar

Clients that does not support SMTP authentication via imap or pop

Full documentation of a postfix setup is also available at Tornevall Networks at https://docs.tornevall.net/x/JQDpAw – for updates, I suggest that you read there first.

This text is written in october 2020 after ripping my hair of my head off for a while. What I did not think of, during the first round of installation, was that there will be non standard clients that won’t do a pop/smtp-auth before entering the SMTP out. For example, Postfix, straight out of the box – where you want to relay from postfix to postfix via an authenticated user. With the solution above, there might happen things that you do not want. The error message below for example, is quite common but very much unanswered in different kinds of forums. Most of the idiots^H^H^H^H^Hposts are relating their problems to dovecot, cyrus and different kind of solutions that in the end seem to be database driven. This is not bad, it’s just a little bit stupid since you suddenly rely your systems on yet another point of failure: The database. And the more crap you implement, the harder it will be to find the failing point.

warning: SASL authentication failure: unable to canonify user and get auxprops

However, the solution may be much simpler than you think in this case. It was first, when I stumbled over theURLs below URLs, I realized that some settings are just misconfigured with the sasl authentication daemon.

As the first step after finding the entire solution, I tried to change the auth mechanism to a shadow based solution as I don’t like extra databases to just make authentication work. This however failed, and since the server itself is in a production state I have to stick with the db solution for a while (because I actually don’t know if this have effect on other working systems currently in operation).

The solution?

Well, since at least one of the sites are mentioning chrooted files, saslauthd won’t read the ”real” /etc/sasldb2, since it’s not really in /etc – the real file resides in /var/spool/postfix/etc, and requires only one thing: That you create it and put it there and making the sasl user the group owner of the file. This is how it should look.

# ls -l /var/spool/postfix/etc/sasldb2
-rw-r----- 1 root sasl 12288 Oct 4 12:00 sasldb2

The only backside of this is that you may have another load of users in another location /etc/passwd, that still won’t be able to authenticate as long as they are not added to sasldb2.

The documented problem URLs

https://serverfault.com/questions/409828/cant-get-sasl-auxprop-sasldb-working-with-postfix-ubuntu-12-04
https://annvix.com/enabling_sasl_in_postfix