Alias, vidarebefordran och catch-all: smidigt, men med risker

Modul 3: Hantera din e-postlåda · Lästid: 11 minuter

Lärandemål: Efter den här lektionen kan du välja mellan en brevlåda, ett alias, en vidarebefordran och en catch-all, och förklara varför vidarebefordran till en extern adress och en catch-all kan skada leveransen av din e-post.

Nyckelbegrepp: brevlåda, alias, forwarder (vidarebefordran), intern och extern vidarebefordran, SPF går sönder vid vidarebefordran, SRS (Sender Rewriting Scheme), DKIM vid vidarebefordran, ARC (RFC 8617), catch-all, dictionary-attack, backscatter, skicka i någon annans namn

Fyra sätt att få en adress att fungera

Vill du att offerte@example.com ska fungera har du fyra alternativ:

I vissa paneler är ett alias tekniskt sett samma sak som en vidarebefordran till en adress på samma server. Skillnaden som faktiskt spelar roll är: stannar e-posten på samma server, eller skickas den vidare utåt?

Vidarebefordran inom ditt eget domän: inga problem

Vidarebefordrar du offerte@example.com till info@example.com, och båda ligger på samma server, levererar servern bara e-posten direkt i brevlådan för info@. Inget skickas ut på internet, inget kontrolleras på nytt. Det är säkert och tillförlitligt.

Vidarebefordran utåt: där det går fel

Det blir annorlunda när du vidarebefordrar till en adress hos en annan aktör, till exempel en privat adress hos Gmail eller Outlook.com. Då skickar din server e-posten på nytt, nu till Gmail. Och Gmail kontrollerar e-posten som om den kom från din server.

Säg att klant@example.net skickar e-post till info@example.com. Din server vidarebefordrar den till Gmail. Vad ser Gmail?

• Avsändare (From): klant@example.net.
• Envelope sender (envelope-avsändare): fortfarande klant@example.net, om inte din server skriver om den.
• Skickande server: din server, till exempel 192.0.2.25.

Gmail tittar i SPF-posten för example.net. Där finns givetvis inte din server med. SPF misslyckas. Har example.net en DMARC-policy på p=reject, och saknas det en giltig DKIM-signatur på e-posten, då nekar Gmail e-posten. Din server får ett studs tillbaka, och det skickas till... den ursprungliga avsändaren, som nu får ett felmeddelande från din server.

Det finns tre mekanismer som mildrar detta:

1. DKIM överlever (oftast)

En DKIM-signatur (lektion 4.3) sitter i själva e-posten. Vidarebefordrar din server e-posten oförändrad stämmer signaturen från example.net fortfarande. DMARC lyckas då via DKIM, även om SPF misslyckas. Därför är DKIM så viktigt: det är det enda som överlever vidarebefordran.

Men det går fel om den vidarebefordrande servern ändrar e-posten: lägger till en text längst ner ("vidarebefordrad av..."), ändrar ämnesraden ([SPAM] framför), eller konverterar formateringen. Då stämmer inte signaturen längre.

2. SRS skriver om envelope-avsändaren

Med SRS (Sender Rewriting Scheme) ändrar den vidarebefordrande servern envelope-avsändaren till en adress på sitt eget domän, till exempel:

SRS0=HHH=TT=example.net=klant@example.com

Nu tittar Gmail i SPF-posten för example.com, och där finns din server med. SPF lyckas. Studsar e-posten kan din server översätta tillbaka adressen och skicka studsen till den riktiga avsändaren.

Observera: SRS löser SPF, men inte DMARC. Uppriktningen (lektion 4.4) jämför domänet för envelope-avsändaren med From-adressen. Den är nu example.com mot example.net: inte uppriktad. DMARC måste alltså fortfarande lyckas via DKIM.

3. ARC: ett intyg från mellanhanden

ARC (Authenticated Received Chain, RFC 8617, experimentell) låter en mellanhand dokumentera vad den såg: "när den här e-posten kom in till mig lyckades SPF, DKIM och DMARC". Den vidarebefordrande servern signerar det intyget. Slutmottagaren kan välja att lita på intyget om den litar på mellanhanden. Stora mottagare som Gmail och Microsoft använder ARC, men du kan inte räkna med det: det är en förmån, inte en rättighet.

Och spammen?

Det finns ytterligare ett problem, och det är ofta det största. Ditt spamfilter stoppar inte allt. All spam som kommer igenom vidarebefordrar din server nu till Gmail. För Gmail ser det ut som att din server skickar spam. Det sänker ryktet för din server (och vid delad hosting: för alla kunder på den servern). Gmail sätter därefter också din riktiga e-post i spam oftare.

Vad är bättre?

Vill du läsa din företagsmejl i Gmail- eller Outlook-appen? Lägg då till brevlådan som ett IMAP-konto (modul 2). Appen hämtar e-posten direkt från din server. Inget vidarebefordras, inget misslyckas, och ingen spam skickas ut. Måste du ändå vidarebefordra, ställ in spamfiltret strikt innan vidarebefordran.

Catch-all: varför nästan aldrig

En catch-all fångar upp all e-post till adresser som inte finns. Ett skrivfel som inof@example.com kommer då ändå fram. Det låter smidigt, men:

• Spam. Spammare skickar massvis med e-post till påhittade adresser på befintliga domäner (a.jansen@, sales2@, xkq7@). Det kallas en dictionary-attack. Utan catch-all nekar din server allt detta direkt. Med catch-all kommer allt in, ofta hundratals per dag.
• Inget felmeddelande längre. Den som skriver fel adress får ingen studs och tror att e-posten kom fram. Utan catch-all vet personen direkt att adressen är fel.
• Vidarebefordran gör det värre. En catch-all som vidarebefordrar till Gmail skickar all den spammen till Gmail.
• Backscatter. En server som först tar emot allt och senare upptäcker att en adress inte finns skickar en studs till den (förfalskade) avsändaren. Det kallas backscatter: felmeddelanden till oskyldiga personer, och en anledning att hamna på en blocklista.

Vill du fånga upp ett par extra adresser, som ett vanligt skrivfel eller en gammal adress? Skapa separata alias eller forwarders för det. Använder du en egen adress per webbplats eller webbshop (webshop-x@) för att se vem som säljer vidare din adress? Skapa då den adressen som alias just när du använder den.

Skicka från ett alias

Ett alias kan också vara en avsändare. Du vill till exempel svara som offerte@example.com medan du är inloggad som info@. Det går, men:

• Många mejlservrar kontrollerar numera vilken avsändaradress som hör till vilken inloggning. Du får då bara skicka från din egen adress och de alias eller forwarders som pekar mot din brevlåda. En godtycklig annan adress nekas ("account can not send emails from ..."). Det skyddar mot missbruk.
• I ditt e-postprogram lägger du till aliaset som en extra identitet (Thunderbird: Hantera identiteter; Apple Mail: extra adresser vid kontot, åtskilda med kommatecken; Outlook: visa fältet Från och skriva in adressen).
• SPF, DKIM och DMARC fungerar precis som vanligt, så länge aliaset ligger på samma domän och du skickar via din egen server.

I praktiken: så ser det ut i en panel

I DirectAdmin skapar du vidarebefordringar under E-posthanterare, Forwarders. Catch-all finns under Avancerade funktioner, Catch-all-e-post; där är "stäng av catch-all" det rekommenderade läget (e-post till adresser som inte finns nekas). Har du bara ett domännamn utan paket finns vidarebefordringar i Mitt WebOké under Mina domäner, Vidarebefordringar. Andra paneler (cPanel, Plesk, Microsoft 365, Google Workspace) har liknande delar, ibland under namn som "alias", "vidarebefordran" eller "grupper".

Sammanfattning

• Ett alias eller en vidarebefordran inom samma server är säkert.
• Vidarebefordran utåt bryter SPF. SRS återställer SPF, men inte DMARC-uppriktningen; bara en intakt DKIM-signatur räddar e-posten, och ARC kan hjälpa.
• Vidarebefordrad spam skadar ryktet för din server. Läs hellre extern e-post via IMAP i appen.
• En catch-all drar till sig spam, döljer skrivfel och kan orsaka backscatter. Använd separata alias.
• Att skicka från ett alias går bra, inom ramarna för din server.

Quiz

Uppgift

Uppgift O3.3: Inventering av dina adresser. Gör en lista över alla adresser på ditt domän: brevlådor, alias, vidarebefordringar och om en catch-all är aktiverad. Notera för varje vidarebefordran om den stannar inom ditt eget domän eller går ut (Gmail, Outlook.com, ett annat företag). Besvara sedan: vilken extern vidarebefordran kan du ersätta med ett IMAP-konto i appen, och finns det en catch-all som kan stängas av? Fyll i checklistan.

Läs mer

Stegen i dessa artiklar gäller för WebOkés paneler; hos andra leverantörer fungerar det på liknande sätt.

• DirectAdmin-guide 7.5: Vidarebefordrare: skicka vidare e-post till en annan adress
• DirectAdmin-guide 7.6: Catch-all-e-post: mejl till adresser som inte finns
• Vidarebefordra e-post till en annan adress (forwarders, catch-all avråds)
• Skicka e-post från flera alias, fel: Account xxx can not send emails from
• WebOké manual 5.9: E-post- och domänvidarebefordringar
• Gratis DNS-kurs 4.3: SPF: vem får skicka e-post i din domäns namn?
• RFC 8617 (ARC), RFC 7208 bilaga D (SPF och mellanhänder som vidarebefordrare)