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
SPF på one.com
SPF på one.com

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

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

 

”egrep” och ”fgrep” kommer att försvinna

Från version 3.8 kommer ”grep” att ge varningar när man använder ”egrep” och ”fgrep”. Dessa kommandon kommer att försvinna med tiden. De är en kvarleva från tider när utrymme var ont om.

Istället för ”egrep” och ”fgrep” ska man använda ”-E” och ”-F” respektive.

”-F” används för att söka med en fix sträng. Tex grep -F "/mnt" /etc/fstab.

”-E” används för utökad reguljära uttryck. Vissa tecken får en speciell mening, som tex ’?’, ’+’, ’{’, ’}’ och behöver inte ledas med ’\’ för att få dess speciella mening. Läs mer på länkar nedan.

https://www.gnu.org/software/sed/manual/html_node/BRE-vs-ERE.html

https://www.gnu.org/software/grep/manual/html_node/Basic-vs-Extended.html

Montera ”nfs” v4 ställer till det, mot Synology NAS (DS212J) under Debian och Mint

Har monterat mappar på min NAS (Synology DS212J) med ”nfs” och aktiverade version 4 för ett tag sedan. Det visar sig att det var ett misstag.

När man monterar ”nfs” med stöd för version 4 visas fel information om användare och grupp. Och det ställer till det. Jag tror att det är mer än att det ”visas” fel. Annars borde det fungera.

För mig blev användare ”Anonomus” och grupp blev ett nummer som var rätt högt. Men kunde tolkas som ”-2”.

Jag av-aktiverade stödet för version 4 på NAS:en och monterade om mapparna från ”nfs4” till ”nfs”. Och nu fungerar det som tidigare.

Hittade noteringar som ledde mig i denna riktning när jag letade efter ”nfs”, version 4 och att användare och grupp blev annat än väntat.

ClamAv uppdaterar inte daily.cvd

Jag upptäckte att uppdatering av daily.cvd misslyckats de senaste dagarna. Efter letande efter orsak och lösning hittades en möjlig väg fram.

FreshClam behöver till en början stängas ned. Därefter kan man köra den manuellt, men det räckte inte denna gång. Jag behövde även ändra i config-filen.

ClamAv och clamav-freshclam är version 0.103.2 för framtida information. Om datum för inlägget ändras.

systemctl stop clamav-freshclam.service

/etc/clamav/freshclam.conf
#ReceiveTimeout 30
ReceiveTimeout 300

freshclam

systemctl start clamav-freshclam.service

Jag ändrar timeout till 90 när jag blir klar. Tiden är i sekunder, så 300 är lite väl mycket.

Efter detta kunde jag köra ”freshclam” manuellt och uppdatera ”daily.cvd”.

Dock blev jag blockerad igen när nästa databas skulle hämtas. ”main.cvd”. Så jag får vänta ytterligare. De databaser som behöver hämtas är, ”daily.cvd”, ”main.cvd”, ”bytecode.cvd”.

Det räckte med ytterligare en körning av ”frechclam”. Efter den så rapporteras bara att allt är under kontroll.

Jag har sett ett antal noteringar på nätet om att ClamAv placerar användare i timeout pga ”rate limit”, error 429. Från vad jag kan tolka det, så beror det på den hosting-lösning de använder. Och jag tror att ClamAv har gjort ändringar i hur de hanterar hämtning av data. Jag såg även att de har funderingar på att göra ändringar av systemet, om de hittar en lösning som de tror på. Det har blivit mer att hantera för systemet än vad systemet från början var byggt för. De vill bli mer effektiv, och kanske hitta möjlighet att få lite intäkter.

Länkar:
https://dhenandi.com/solved-clamav-download-failed-message-timeout-was-reached/
https://www.linode.com/community/questions/21157/clamav-update-receives-429-error-to-many-requests