Aliaser, videresending og catch-all: praktisk, men med risiko

Modul 3: Administrere mailboksen din · Lesetid: 11 minutter

Læringsmål: Etter denne leksjonen kan du velge mellom en mailboks, et alias, en videresending og en catch-all, og forklare hvorfor videresending til en ekstern adresse og en catch-all kan skade leveringen av e-posten din.

Nøkkelbegreper: mailboks, alias, forwarder (videresending), intern og ekstern videresending, SPF brytes ved videresending, SRS (Sender Rewriting Scheme), DKIM ved videresending, ARC (RFC 8617), catch-all, ordboksangrep, backscatter, sending på vegne av en annen adresse

Fire måter å få en adresse til å fungere

Hvis du vil at offerte@example.com skal fungere, har du fire valg:

I enkelte kontrollpaneler er et alias teknisk sett det samme som en forwarder til en adresse på samme server. Forskjellen som faktisk betyr noe, er denne: blir e posten på samme server, eller går den ut?

Videresending innenfor ditt eget domene: ikke noe problem

Sender du offerte@example.com videre til info@example.com, og begge ligger på samme server, leverer serveren rett og slett e posten i mailboksen til info@. Ingenting går over internett, ingenting kontrolleres på nytt. Det er trygt og pålitelig.

Videresending ut: her går det galt

Det blir annerledes når du videresender til en adresse hos en annen aktør, for eksempel en privat adresse hos Gmail eller Outlook.com. Da sender serveren din e posten på nytt, nå til Gmail. Og Gmail kontrollerer e posten som om den kom fra serveren din.

Si at klant@example.net sender en e post til info@example.com. Serveren din videresender den til Gmail. Hva ser Gmail?

• From-header: klant@example.net.
• Envelope sender: fortsatt klant@example.net, med mindre serveren din skriver den om.
• Sendende server: serveren din, for eksempel 192.0.2.25.

Gmail sjekker SPF-posten til example.net. Der står naturligvis ikke serveren din oppført. SPF feiler. Har example.net en DMARC-policy p=reject, og mangler e posten en gyldig DKIM-signatur, avviser Gmail e posten. Serveren din får en bounce i retur, og den går til... den opprinnelige avsenderen, som nå får en feilmelding fra serveren din.

Det finnes tre mekanismer som demper dette:

1. DKIM overlever (som regel)

En DKIM-signatur (leksjon 4.3) ligger i selve e posten. Videresender serveren din e posten uendret, stemmer signaturen til example.net fortsatt. DMARC lykkes da på DKIM, selv om SPF feiler. Derfor er DKIM så viktig: det er det eneste som overlever videresending.

Men det går galt hvis serveren som videresender endrer e posten: legger til en tekst nederst ("videresendt av..."), endrer emnefeltet ([SPAM] foran), eller konverterer formateringen. Da stemmer ikke signaturen lenger.

2. SRS skriver om envelope senderen

Med SRS (Sender Rewriting Scheme) endrer serveren som videresender envelope senderen til en adresse på sitt eget domene, for eksempel:

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

Nå sjekker Gmail SPF-posten til example.com, og der er serveren din faktisk oppført. SPF lykkes. Kommer det en bounce, kan serveren din oversette adressen tilbake og sende bouncen til den egentlige avsenderen.

Merk: SRS løser SPF, men ikke DMARC. Justeringen (leksjon 4.4) sammenligner domenet til envelope senderen med From-adressen. Nå er det example.com mot example.net: ikke justert. DMARC må derfor fortsatt lykkes på DKIM.

3. ARC: en erklæring fra mellomleddet

ARC (Authenticated Received Chain, RFC 8617, eksperimentell) lar et mellomledd dokumentere hva det observerte: "da denne e posten kom inn til meg, lyktes SPF, DKIM og DMARC". Serveren som videresender signerer denne erklæringen. Sluttmottakeren kan velge å stole på erklæringen hvis den stoler på mellomleddet. Store mottakere som Gmail og Microsoft bruker ARC, men du kan ikke stole på det: det er en gunst, ikke en rettighet.

Og spammen?

Det er enda et problem, og det er ofte det største. Spamfilteret ditt stopper ikke alt. All spam som slipper gjennom, videresender serveren din nå til Gmail. For Gmail ser det ut som om serveren din sender spam. Det går hardt ut over omdømmet til serveren din (og ved delt hosting: omdømmet til alle kunder på den serveren). Gmail legger deretter også den ekte e posten din raskere i spam.

Hva er bedre?

Vil du lese den forretningsmessige e posten din i Gmail- eller Outlook-appen? Legg da til mailboksen som en IMAP-konto (modul 2). Appen henter e posten direkte fra serveren din. Ingenting videresendes, ingenting feiler, og det går ingen spam ut. Må du likevel videresende, sett spamfilteret strengt før videresendingen.

Catch-all: hvorfor nesten aldri

En catch-all fanger opp all e post til adresser som ikke finnes. En skrivefeil som inof@example.com kommer da likevel frem. Det høres praktisk ut, men:

• Spam. Spammere sender masse e post til oppdiktede adresser på eksisterende domener (a.jansen@, sales2@, xkq7@). Det kalles et ordboksangrep. Uten catch-all avviser serveren din alt dette umiddelbart. Med catch-all kommer alt inn, ofte hundrevis per dag.
• Ingen feilmelding lenger. Den som skriver feil adresse, får ingen bounce og tror at e posten har kommet frem. Uten catch-all vet vedkommende straks at adressen er feil.
• Videresending gjør det verre. En catch-all som videresender til Gmail, sender all den spammen videre til Gmail.
• Backscatter. En server som først tar imot alt og først senere oppdager at en adresse ikke finnes, sender en bounce til den (forfalskede) avsenderen. Det kalles backscatter: feilmeldinger til uskyldige mennesker, og en grunn til å havne på en blokkeringsliste.

Vil du fange opp noen få ekstra adresser, som en vanlig skrivefeil eller en gammel adresse? Lag separate aliaser eller forwarders for det. Bruker du en egen adresse per nettsted eller nettbutikk (webshop-x@), for å se hvem som videreselger adressen din? Opprett den adressen som et alias idet du begynner å bruke den.

Sending fra et alias

Et alias kan også være en avsender. Du vil for eksempel svare som offerte@example.com mens du er logget inn som info@. Det kan la seg gjøre, men:

• Mange mailservere kontrollerer i dag hvilken avsenderadresse som hører til hvilken innlogging. Du kan da kun sende fra din egen adresse og aliasene eller forwarderne som peker til mailboksen din. En vilkårlig annen adresse blir avvist ("account can not send emails from ..."). Det beskytter mot misbruk.
• I e postprogrammet legger du til aliaset som en ekstra identitet (Thunderbird: Administrer identiteter; Apple Mail: ekstra adresser på kontoen, atskilt med komma; Outlook: vis feltet Fra (From) og skriv inn adressen).
• SPF, DKIM og DMARC fungerer helt normalt, så lenge aliaset ligger på samme domene og du sender via din egen server.

I praksis: slik ser det ut i et kontrollpanel

I DirectAdmin oppretter du videresendinger under E-mail Manager, Forwarders. Catch-all finner du under Advanced Features, Catch-All E-mail; der er "deaktiver catch-all" den anbefalte innstillingen (e post til adresser som ikke finnes, blir avvist). Har du bare et domenenavn uten pakke, ligger videresendinger i Min side under Mine domener, Doorsturingen. Andre kontrollpaneler (cPanel, Plesk, Microsoft 365, Google Workspace) har tilsvarende funksjoner, noen ganger under navn som "aliaser", "videresending" eller "grupper".

Oppsummering

• Et alias eller en videresending innenfor samme server er trygt.
• Videresending ut brekker SPF. SRS reparerer SPF, men ikke DMARC-justeringen; kun en intakt DKIM-signatur redder e posten, og ARC kan hjelpe.
• Videresendt spam skader omdømmet til serveren din. Les heller ekstern e post via IMAP i appen.
• En catch-all tiltrekker spam, skjuler skrivefeil og kan forårsake backscatter. Bruk separate aliaser.
• Sending fra et alias er mulig, innenfor reglene til serveren din.

Quiz

Oppgave

Oppgave O3.3: Oversikt over adressene dine. Lag en liste over alle adresser på domenet ditt: mailbokser, aliaser, videresendinger og om en catch-all er aktivert. Noter for hver videresending om den blir innenfor ditt eget domene eller går ut (Gmail, Outlook.com, et annet selskap). Svar deretter: hvilken ekstern videresending kan du erstatte med en IMAP-konto i appen, og er det en catch-all aktivert som kan slås av? Fyll ut sjekklisten.

Les mer

Trinnene i disse artiklene gjelder for kontrollpanelene til WebOké; hos andre leverandører fungerer det på lignende måte.

• DirectAdmin-veiledning 7.5: Forwarders: videresend e-post til en annen adresse
• DirectAdmin-veiledning 7.6: Catch-All E-mail: e-post til adresser som ikke finnes
• E-post videresending til en annen adresse (forwarders, catch-all frarådes)
• Sende e-post fra flere aliaser, feil: Account xxx can not send emails from
• WebOké-veiledning 5.9: E-post og domenevideresendinger
• Gratis DNS-kurs 4.3: SPF: hvem kan sende e-post på vegne av domenet ditt?
• RFC 8617 (ARC), RFC 7208 tillegg D (SPF og mellomledd som videresendere)