SPF på Debian 12 (Bookworm)

[_{Uppdatering 2024-03-06: Lägger till länk till Debians manualsida som berör SPF}]

Sender Policy Framework (SPF) var en av de tekniker som G-mail (Google) började ställa krav på att e-post-servrar har under 2023. Även DKIM verkade det ställas krav på, visade det sig. DKIM blir i en annan artikel, här blir det bara SPF.

SPF och DKIM är två typer av TXT-poster i DNS som gör det möjligt att upptäcka spoofing av e-post och hjälpa legitim e-post att levereras till mottagarens in-box, istället för i skräp-korgen. Om de inte lade till dig i deras adress-bok.

DNS-posten för SPF beskriver vilken host, eller IP-adresser, som är tillåtna att använda för att skicka e-post för domänen. Du bör bara tillåta din egen e-post-server eller din ISPs server som sänder e-post för din domän.

SPF tolkar jag som, är en teknik som fungerar så att jag skickar e-post från A till B. När B tar emot min e-post, kan den kontrollera på min domän om min e-post kommer från rätt host. Om det finns en SPF-post på min domän. Så den ändrar inget på utgående e-post, bara gör det möjligt att kontrollera inkommande e-post.

Jag har använt många källor innan jag kom till skott. Den som fick mig att ta steget, var den artikel som Xiao Guoan skrev på linuxbabe.com, 2022.

Steg 1: Skapa en TXT-post i DNS för SPF

Där du konfigurerar din DNS, skapa en ny TXT-post, enligt nedan. Detta enligt de källor jag hittat på nätet.

TXT @ v=spf mx ~all

Använder du One.com kan det se ut så här.

TXT @ v=spf include:_custspf.one.com ~all

Förklaring:

TXT	indikerar att detta är en TXT-post.
@	anges i fältet för ”hostname” och jag gissar att det har med alla att göra. Men hur? Och olika för olika webb-hotell. Jag lade bara till host för en under-domän jag har. Så jag har två TXT-poster.
v=spf	indikerar att detta är en SPF-post och att det är version SPF1.
ip4:(ip-nr)	anger vilken host som är giltig att skicka e-post från.
include:_custspf.one.com	anger att SPF från en annan källa också används. Tror jag i alla fall. Det var vad one.com tyckte att man skulle ange, så att deras system kan användas.
mx	betyder alla hosts listade med MX-poster har tillåtelse att sända e-post för din domän. Jag använde inte denna.
~all	indikerar att e-post från din domän ska bara komma från hosts beskrivna i SPF-posten. Möjliga andra alternativ är [+all, -all, ?all], men är sällan använda.

Steg 2: Kontrollera SPF-posterna i DNS

För att kontrollera om SPF-posten har spridits, så att den kan användas, använd tex ”dig”-verktyget på lin Linux-dator. På Ubuntu behöver man installera paketet bind9-dnsutils för att komma åt kommandot.

sudo apt install bind9-dnsutils

dig ripop.se txt

Attributet txt säger till dig att bara visa TXT-poster.

Du kan även använda ”https://dmarcian.com/spf-survey” för att testa syntax för din SPF-post. Om det finns bättre? Det vet jag inte. Nytt område för mig.

Steg 3: Konfigurera SPF Policy Agent

Postfix behöver också veta något om SPF, för att kontrollera SPF-posterna för inkommande e-post. SPF kontrolleras på inkommande sidan. Inget görs på utgående e-post.

Först installeras de paket som behövs.

sudo apt install postfix-policyd-spf-python

Därefter editeras Postfix konfiguration av huvud-processer.

sudo nano /etc/postfix/master.cf

Lägg till följande linje i slutet av filen. Den säger åt Postfix att starta policy-demonen för SPF när den själv startar. Gör gärna en kommentar i anslutning, så att du vet varför och när.

# 2024-03-03: Rickard: G-mail har börjat kräva detta. 
policyd-spf unix - n n - 0 spawn
  user=policyd-spf argv=/usr/bin/policyd-spf

Nästa steg är att editera Postfix primära fil för konfiguration.

sudo nano /etc/postfix/main.cf

Lägg till följande i slutet av filen. Första linjen anger Postfix timeout för policy-agenten. Efter-följande linjer skapar restriktioner för inkommande e-post genom att avvisa obehörig e-post och kontrollera SPF-posten. Debian rekommenderar 3600, som det verkar på Debians manual-sida som berör SPF.

# 2024-03-03: Rickard: Vad som krävs för att kontrollera SPF på inkommande.
policyd-spf_time_limit = 3600 
  smtpd_recipient_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_unauth_destination,
  check_policy_service unix:private/policyd-spf

Kommentar från Postfix:
reject_unauth_destination behöver vara före check_policy_service.
https://www.postfix.org/SMTPD_POLICY_README.html#client_config
Kommentar om rad 8,9.

Spara. Starta om Postfix.

sudo systemctl restart postfix

Nästa gång jag får en e-post från en domän som har SPF-poster, kan jag se att SPF har kontrollerat resultatet i e-post-headern. Följande header indikerar att sändaren har skickat e-post från en giltig host.

Received-SPF: Pass (sender SPF authorized).

Detta gick förhållandevis smärtfritt. Nästa artikel kommer att handla om mitt äventyr med DKIM. Den var inte lika lätt att fundera ut.

Länkar

Xiao Guoan
https://www.linuxbabe.com/mail-server/setting-up-dkim-and-spf

SPF Debian
https://manpages.debian.org/testing/postfix-policyd-spf-python/policyd-spf.1.en.html

Testa SPF (finns många andra, jag testade med denna)
https://dmarcian.com/spf-survey

SPF på One.com
https://help.one.com/hc/sv/articles/115005595945-L%C3%A4gg-till-en-SPF-post

Postfix SMTPD policy
https://www.postfix.org/SMTPD_POLICY_README.html#client_config

2023-06-02

Lets Encrypt till Dovecot på Debian (Buster)

Jag verkar ha kopplat Dovecot och SSL till fel nycklar. Fick problem för ett litet tag sedan, när den jag kopplat tog slut.

Efter lite sökande hittar jag vad jag tror är rätt sätt att koppla Dovecot. Apache uppdateras med automatik, så det bästa verkar vara att koppla Dovecot till samma SSL-nycklar.

/etc/dovecot/conf.d/10-ssl.conf

10-ssl.conf har inställning för att koppla SSL till Dovecot, och det ändras på följande sätt.

ssl_cert = </etc/letsencrypt/live/YOURSITE/fullchain.pem
ssl_key = </etc/letsencrypt/live/YOURSITE/privkey.pem

Detta hittade jag på länken nedan.

Länkar:

https://community.letsencrypt.org/t/simple-guide-using-lets-encrypt-ssl-certs-with-dovecot/2921

2018-06-12

ClamAv slutar uppdatera

Ibland slutar ClamAv att uppdatera, då behöver jag göra följande.

cd /var/lib/clamavservice clamav-freshclam stopmv mirrors.dat mirrors.dat.old
freshclam -v
service clamav-freshclam start

eventuellt även nedan kan behövas före ”freshclam”

mv daily.cld daily.cld.old

En av många länkar som beskriver detta i mer detalj.

https://nolabnoparty.com/en/clamav-update-error/

2018-04-292020-06-14

LetsEncrypt på sub-domän (uppdaterad)

Uppdatering – 2018-07-15 – Efter uppgradering till Debian 9 (Stretch) verkar det som att certbot slutat fungera. Klagade på att inte kunna importera jose! Vad det nu ska betyda. Men se längre ned för mer info om hur jag löste det problemet. Min första lösning med ”certbot standalone” visade sig också vara fel väg.

Jag har försökt att få LetsEncrypt att fungera en längre tid, men inte fått det att fungera. Deras mer automatiserade system har gett mig fel-meddelanden. Och jag har inte i stunden hittat något sätt att lösa de problem som eventuellt fanns.

Nu äntligen tog jag mig tid att verkligen försöka gå hela vägen.

Tack vare en sida på DigigtalOcean.com, tillsammans med en kommentar på LetsEncrypt.org lyckades jag hitta problemet.

I stort sett följde jag instruktionerna på DigitalOcean. Punkt 3 att hämta certifikat var jag tvungen att göra lite annorlunda.

Se till att ServerName är definierad i conf-filen under ”/etc/apache2/sites-enabled/” för webb-platsen.
Se till att brandvägg är öppen för port 443 tcp.
Hämta certifikat – gjorde enligt kommentar i länk 2
Se till att certifikat kommer att uppdateras – certbot renew

Mer detaljerad vad jag gjorde

Ser till att ”ServerName” är definierat i config-filerna för Apache.
/etc/apache2/sites-available/000-default.conf
ServerName = ”subdomain.domain.tld”
Brandvägg såg jag till att jag öppnat port 443/tcp. Det är olika hur man gör för olika brandväggar, och beroende på om du kör något ramverk ovanpå. Tex Shorewall är rätt populär, men det finns ett antal andra.
Enligt länk 2 skapar jag ett certifikat till den subdomän jag vill att den ska finnas för.
certbot --authenticator standalone --installer apache -d sudbomain.domain.tld --pre-hook "service apache2 stop" --post-hook "service apache2 start"
Jag kör apache 2, och instruktionerna var för NGINX. Så jag hoppas att de ändringar jag gjorde är rätt. Det verkade så i alla fall. Egentligen borde jag nog använda ”systemctl” som är det nya sättet att göra saker på.
Se till att det finns ett cron-job som uppdaterar certifikaten. Det fanns redan installerat efter installation av certbot. Men jag hade stängt av den då jag först gjorde mina försök. I stort sett är det ett enkelt kommando:
certbot renewOch det verkar fungera. Jag har iofs inte ännu sett något certifikat uppdateras, den säger ifrån att inget certifikat är på gång att gå ut. Så jag får vänta.

Problem

Hade jag haft den senaste versionen av ”certbot” hade det varit enkelt att sätta upp certifikaten för mina subdomäner. Nu visade det sig att certbot i Debian är lite för gammal, och LetsEncrypt har uppdaterat sina protokoll så den äldre fungerade inte med det enkla kommandot:

certbot --apache

Nu hittade jag åt hur man kunde göra på ett alternativt sätt, enligt kommentar på länk 2.

Problem efter uppgradering till Debian 9 – Stretch

Fick fel som klagade på att certbot inte kunde importera ”jose”. Letade på nätet ett tag tills jag fick reda på att vissa kunnat lösa problemet med att aktivera ”backports”, så jag gjorde också det.

deb http://ftp.debian.org/debian stretch-backports main

Med detta kunde jag installera följande.

apt-get install certbot python3-certbot python3-acme python3-cryptography python3-josepy python3-setuptools -f -t stretch-backports

Det verkar fungera nu. Bara att avvakta till nästa cron-jobb och se om det fungerar.

https://backports.debian.org/Instructions/

https://github.com/certbot/certbot/issues/5599

Efter ett dygn väntan och kolla om uppdatering fungerar, så visar det sig att det var ytterligare problem. Hittade dokumentation till certbot.

https://certbot.eff.org/lets-encrypt/debianstretch-apache.html

sudo certbot --authenticator webroot --installer apache

Ovan kod verkar löst problemet. Återstår att se om det blir några fler problem. Scriptet frågar efter ”webroot” för varje domän som läggs till. Eller först frågar om man vill lägga till en ny. Jag hoppas att jag kommer ihåg hur jag gjorde nästa gång jag behöver detta. Det lär dröja i alla fall 2,5 månader.

Scriptet avslutar med att rekommendera att testa domänen på:

https://www.ssllabs.com/ssltest/analyze.html

Tankar

Jag hoppas att jag kan förstå vad jag skrivit. Om jag i framtiden behöver göra om detta, så hoppas jag att jag förstår. Det är inte helt enkelt att förstå allt, då man inte jobbar med detta. Jag tycker mig ha en god grund-kunskap, men det är detaljerna som ofta gör det.

Jag har skrivit ett dokument som jag kan titta i, om det skulle behövas. ”LetsEncrypt – 2018-04-28.odt”.