Aliasser, videresendelse og catch-all: praktisk, men med risici

Modul 3: Administration af din mailboks · Læsetid: 11 minutter

Læringsmål: Efter denne lektion kan du vælge mellem en postkasse, en alias, en videresendelse og en catch-all, og forklare hvorfor videresendelse til en ekstern adresse og en catch-all kan skade leveringen af din mail.

Centrale begreber: postkasse, alias, forwarder (videresendelse), intern og ekstern videresendelse, SPF brydes ved videresendelse, SRS (Sender Rewriting Scheme), DKIM ved videresendelse, ARC (RFC 8617), catch-all, ordbogsangreb, backscatter, afsendelse på vegne af en anden adresse

Fire måder at få en adresse til at virke

Hvis du vil have offerte@example.com til at virke, har du fire muligheder:

Valg	Hvad det er	Hvornår det er praktisk
Postkasse	Et eget opbevaringssted med egen adgangskode. Du kan logge ind på den.	Nogen skal selv arbejde med den, eller mailen skal gemmes separat.
Alias	Et andet navn for en eksisterende postkasse. Mail til `offerte@` havner i postkassen til `info@`.	Én person med flere adresser.
Forwarder (videresendelse)	Mail til adressen videresendes til en eller flere andre adresser. Der gemmes ikke noget.	En adresse som flere kolleger skal modtage mail på; en gammel adresse der stadig skal virke.
Catch-all	Al mail til adresser der ikke findes, havner på én adresse.	Næsten aldrig (se nedenfor).

I nogle kontrolpaneler er et alias teknisk set det samme som en forwarder til en adresse på samme server. Den forskel der betyder noget, er denne: bliver mailen på samme server, eller sendes den videre ud?

Videresendelse inden for dit eget domæne: intet problem

Videresender du offerte@example.com til info@example.com, og ligger begge på samme server, afleverer serveren bare mailen i postkassen til info@. Der sendes intet over internettet, og intet kontrolleres igen. Det er sikkert og pålideligt.

Videresendelse til udlandet: her går det galt

Det bliver anderledes, når du videresender til en adresse hos en anden udbyder, for eksempel en privat adresse hos Gmail eller Outlook.com. Så sender din server mailen igen, nu til Gmail. Og Gmail kontrollerer mailen, som om den kom fra din server.

Forestil dig: klant@example.net sender en mail til info@example.com. Din server videresender den til Gmail. Hvad ser Gmail?

Afsender (From): klant@example.net.
Envelope sender: stadig klant@example.net, medmindre din server omskriver den.
Afsendende server: din server, for eksempel 192.0.2.25.

Gmail kigger i SPF-posten for example.net. Der står din server naturligvis ikke. SPF fejler. Har example.net en DMARC-politik på p=reject, og er der ikke en gyldig DKIM-signatur på mailen, afviser Gmail mailen. Din server får en bounce tilbage, og den går til... den oprindelige afsender, som nu får en fejlmeddelelse fra din server.

Der findes tre mekanismer der afbøder dette:

1. DKIM overlever (som regel)

En DKIM-signatur (lektion 4.3) sidder i selve mailen. Videresender din server mailen uændret, stemmer signaturen fra example.net stadig. DMARC bliver så godkendt på DKIM, selvom SPF fejler. Derfor er DKIM så vigtig: det er det eneste der overlever videresendelse.

Men det går galt, hvis den videresendende server ændrer mailen: tilføjer en tekst nederst ("videresendt af..."), ændrer emnet ([SPAM] foran), eller konverterer formateringen. Så stemmer signaturen ikke længere.

2. SRS omskriver envelope sender

Med SRS (Sender Rewriting Scheme) ændrer den videresendende server envelope sender til en adresse på sit eget domæne, for eksempel:

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

Nu kigger Gmail i SPF-posten for example.com, og der står din server faktisk. SPF godkendes. Kommer der en bounce, kan din server oversætte adressen tilbage og sende bouncen til den rigtige afsender.

Bemærk: SRS løser SPF, men ikke DMARC. Tilpasningen (alignment, lektion 4.4) sammenligner domænet for envelope sender med From-adressen. Det er nu example.com over for example.net: ikke tilpasset. DMARC skal derfor stadig godkendes på DKIM.

3. ARC: en erklæring fra mellemleddet

ARC (Authenticated Received Chain, RFC 8617, eksperimentel) lader et mellemled registrere hvad det så: "da denne mail kom ind til mig, blev SPF, DKIM og DMARC godkendt". Den videresendende server underskriver den erklæring. Den endelige modtager kan beslutte at stole på den erklæring, hvis den stoler på mellemleddet. Store modtagere som Gmail og Microsoft bruger ARC, men du kan ikke regne med det: det er en kulance, ikke en ret.

Og spammen?

Der er endnu et problem, og det er ofte det største. Dit spamfilter stopper ikke alt. Al spam der kommer igennem, videresender din server nu til Gmail. For Gmail ser det ud som om din server sender spam. Det går hårdt ud over dit servers omdømme (og ved delt hosting: alle kunders omdømme på den server). Gmail placerer derefter også din rigtige mail hurtigere i spam.

Hvad er bedre?

Vil du læse din erhvervsmail i Gmail- eller Outlook-appen? Tilføj postkassen som IMAP-konto (modul 2). Appen henter mailen direkte fra din server. Der videresendes intet, intet fejler, og der sendes ingen spam ud. Skal du alligevel videresende, så sæt spamfiltret strengt op inden videresendelsen.

Catch-all: hvorfor næsten aldrig

En catch-all opfanger al mail til adresser der ikke findes. En tastefejl som inof@example.com kommer så alligevel frem. Det lyder praktisk, men:

Spam. Spammere sender massevis af mail til opdigtede adresser på eksisterende domæner (a.jansen@, sales2@, xkq7@). Det kaldes et ordbogsangreb. Uden catch-all afviser din server det hele med det samme. Med catch-all kommer alt ind, ofte hundredvis om dagen.
Ingen fejlmeddelelse mere. Den der taster forkert i din adresse, får ingen bounce og tror at sin mail er kommet frem. Uden catch-all ved han straks at adressen er forkert.
Videresendelse gør det værre. En catch-all der videresender til Gmail, sender al den spam videre til Gmail.
Backscatter. En server der først accepterer alt og først senere opdager at en adresse ikke findes, sender en bounce til den (forfalskede) afsender. Det kaldes backscatter: fejlmeddelelser til uskyldige mennesker, og en grund til at havne på en blokeringsliste.

Vil du opfange nogle få ekstra adresser, som en ofte lavet tastefejl eller en gammel adresse? Lav separate aliasser eller videresendere til det. Bruger du en egen adresse pr. hjemmeside eller webshop (webshop-x@) for at se hvem der videresælger din adresse? Opret den adresse som alias på det tidspunkt du bruger den.

Afsendelse fra et alias

Et alias kan også være en afsender. Du vil for eksempel svare som offerte@example.com, mens du er logget ind som info@. Det kan lade sig gøre, men:

Mange mailservere kontrollerer i dag hvilken afsenderadresse der hører til hvilken login. Du må så kun sende fra din egen adresse og de aliasser eller videresendere der peger på din postkasse. En vilkårlig anden adresse bliver afvist ("account can not send emails from ..."). Det beskytter mod misbrug.
I dit mailprogram tilføjer du aliasset som en ekstra identitet (Thunderbird: Administrer identiteter; Apple Mail: ekstra adresser ved kontoen, adskilt med kommaer; Outlook: vis feltet Fra og indtast adressen).
SPF, DKIM og DMARC virker helt normalt, så længe aliasset ligger på samme domæne, og du sender via din egen server.

I praksis: sådan ser det ud i et kontrolpanel

I DirectAdmin opretter du videresendelser under E-mailadministration, Videresendere. Catch-all'en findes under Avancerede funktioner, Catch-all e-mail; dér er "deaktiver catch-all" den anbefalede indstilling (mail til ikke-eksisterende adresser bliver afvist). Har du kun et domænenavn uden pakke, findes videresendelser i Mit WebOké under Mine domæner, Videresendelser. Andre kontrolpaneler (cPanel, Plesk, Microsoft 365, Google Workspace) har tilsvarende dele, nogle gange under navne som "aliasser", "videresendelse" eller "grupper".

Opsummering

Et alias eller en videresendelse inden for samme server er sikkert.
Videresendelse til udlandet bryder SPF. SRS genopretter SPF, men ikke DMARC-tilpasningen; kun en intakt DKIM-signatur redder mailen, og ARC kan hjælpe.
Videresendt spam skader din servers omdømme. Læs hellere ekstern mail via IMAP i appen.
En catch-all tiltrækker spam, skjuler tastefejl og kan forårsage backscatter. Brug separate aliasser.
Afsendelse fra et alias kan lade sig gøre, inden for din servers regler.

Quiz

Opgave

Opgave O3.3: Oversigt over dine adresser. Lav en liste over alle adresser på dit domæne: postkasser, aliasser, videresendelser, og om der er en catch-all slået til. Noter ved hver videresendelse om den bliver inden for dit eget domæne eller går ud af huset (Gmail, Outlook.com, en anden virksomhed). Besvar derefter: hvilken videresendelse ud af huset kan du erstatte med en IMAP-konto i appen, og er der en catch-all slået til, som kan slås fra? Udfyld tjeklisten.

Opgave O3.3: Oversigt over dine adresser

Denne opgave laver du selv; ingen tjekker den. Afkryds hvad du har gjort, og markér opgaven som udført.

Ingen catch-all, eller en bevidst grund noteret.
Enhver ekstern videresendelse har en grund, eller er erstattet af IMAP i appen.
Spamfilteret er slået til før enhver ekstern videresendelse.
Adresser, jeg sender fra (aliasser), er indstillet som identitet i mit program.

Hvilke adresser har du (postkasse, alias, videresendelse, catch-all), og hvor går de hen?

Hvilken ekstern videresendelse erstatter du med en IMAP-konto i appen? Er der en catch-all slået til, og kan den slås fra?

Dine afkrydsninger og noter forbliver kun i denne browser; vi sender dem ingen steder hen. Er du logget ind, gemmer vi kun i Mine kurser, at du har udført opgaven.

Videre læsning

Trinene i disse artikler gælder for kontrolpanelerne hos WebOké; hos andre udbydere fungerer det på lignende måde.

Cookies hos WebOké

Cookieindstillinger

Nødvendige

Marketing