Aliassen, doorsturen en catch-all: handig, maar met risico's

Module 3: Je mailbox beheren · Leestijd: 11 minuten

Leerdoel: Na deze les kun je kiezen tussen een mailbox, een alias, een doorsturing en een catch-all, en uitleggen waarom doorsturen naar een extern adres en een catch-all de aflevering van je mail kunnen schaden.

Kernbegrippen: mailbox, alias, forwarder (doorsturing), intern en extern doorsturen, SPF breekt bij doorsturen, SRS (Sender Rewriting Scheme), DKIM bij doorsturen, ARC (RFC 8617), catch-all, woordenboekaanval, backscatter, versturen namens een ander adres

Vier manieren om een adres te laten werken

Als je offerte@example.com wilt laten werken, heb je vier keuzes:

In sommige panelen is een alias technisch hetzelfde als een forwarder naar een adres op dezelfde server. Het verschil dat ertoe doet, is dit: blijft de mail op dezelfde server, of gaat hij naar buiten?

Doorsturen binnen je eigen domein: geen probleem

Stuur je offerte@example.com door naar info@example.com, en staan beide op dezelfde server, dan levert de server de mail gewoon af in de mailbox van info@. Er gaat niets over het internet, er wordt niets opnieuw gecontroleerd. Dat is veilig en betrouwbaar.

Doorsturen naar buiten: waar het misgaat

Anders wordt het als je doorstuurt naar een adres bij een andere partij, bijvoorbeeld een privéadres bij Gmail of Outlook.com. Dan verstuurt jouw server de mail opnieuw, nu naar Gmail. En Gmail controleert de mail alsof hij van jouw server komt.

Stel: klant@example.net stuurt een mail aan info@example.com. Jouw server stuurt hem door naar Gmail. Wat ziet Gmail?

• Afzender (From): klant@example.net.
• Envelope-afzender: nog steeds klant@example.net, tenzij jouw server die herschrijft.
• Verzendende server: jouw server, bijvoorbeeld 192.0.2.25.

Gmail kijkt in het SPF-record van example.net. Daar staat jouw server natuurlijk niet in. SPF faalt. Heeft example.net een DMARC-beleid p=reject, en staat er geen geldige DKIM-handtekening op de mail, dan weigert Gmail de mail. Jouw server krijgt een bounce terug, en die gaat naar... de oorspronkelijke afzender, die nu een foutmelding van jóuw server krijgt.

Er zijn drie mechanismen die dit verzachten:

1. DKIM overleeft (meestal)

Een DKIM-handtekening (les 4.3) zit in de mail zelf. Stuurt jouw server de mail ongewijzigd door, dan klopt de handtekening van example.net nog. DMARC slaagt dan op DKIM, ook al faalt SPF. Daarom is DKIM zo belangrijk: het is het enige dat doorsturen overleeft.

Maar het gaat mis als de doorsturende server de mail verandert: een tekst onderaan toevoegen ("doorgestuurd door..."), het onderwerp aanpassen ([SPAM] ervoor), of de opmaak omzetten. Dan klopt de handtekening niet meer.

2. SRS herschrijft de envelope-afzender

Met SRS (Sender Rewriting Scheme) verandert de doorsturende server de envelope-afzender in een adres op zijn eigen domein, bijvoorbeeld:

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

Nu kijkt Gmail in het SPF-record van example.com, en daar staat jouw server wel in. SPF slaagt. Komt er een bounce, dan kan jouw server het adres terugvertalen en de bounce naar de echte afzender sturen.

Let op: SRS lost SPF op, maar niet DMARC. De uitlijning (les 4.4) vergelijkt het domein van de envelope-afzender met het From-adres. Dat is nu example.com tegenover example.net: niet uitgelijnd. DMARC moet dus nog steeds op DKIM slagen.

3. ARC: een verklaring van de tussenpersoon

ARC (Authenticated Received Chain, RFC 8617, experimenteel) laat een tussenpersoon vastleggen wat hij zag: "toen deze mail bij mij binnenkwam, slaagden SPF, DKIM en DMARC". De doorsturende server tekent die verklaring. De eindontvanger kan besluiten die verklaring te vertrouwen als hij de tussenpersoon vertrouwt. Grote ontvangers zoals Gmail en Microsoft gebruiken ARC, maar je kunt er niet op rekenen: het is een gunst, geen recht.

En de spam?

Er is nog een probleem, en dat is vaak het grootste. Jouw spamfilter houdt niet alles tegen. Alle spam die erdoor komt, stuurt jouw server nu door naar Gmail. Voor Gmail lijkt het alsof jouw server spam verstuurt. Daar gaat de reputatie van je server (en bij gedeelde hosting: die van alle klanten op die server) aan onderdoor. Gmail zet daarna ook je echte mail eerder in de spam.

Wat is beter?

Wil je je zakelijke mail in de Gmail- of Outlook-app lezen? Voeg de mailbox dan toe als IMAP-account (module 2). De app haalt de mail rechtstreeks bij jouw server op. Er wordt niets doorgestuurd, er faalt niets, en er gaat geen spam naar buiten. Moet je toch doorsturen, zet dan het spamfilter streng vóór de doorsturing.

Catch-all: waarom bijna nooit

Een catch-all vangt alle mail aan adressen die niet bestaan. Een tikfout als inof@example.com komt dan toch aan. Dat klinkt handig, maar:

• Spam. Spammers sturen massaal mail naar verzonnen adressen op bestaande domeinen (a.jansen@, sales2@, xkq7@). Dat heet een woordenboekaanval. Zonder catch-all weigert je server dat allemaal meteen. Met catch-all komt alles binnen, vaak honderden per dag.
• Geen foutmelding meer. Wie zich vergist in je adres, krijgt geen bounce en denkt dat zijn mail is aangekomen. Zonder catch-all weet hij meteen dat het adres niet klopt.
• Doorsturen maakt het erger. Een catch-all die doorstuurt naar Gmail, stuurt al die spam naar Gmail.
• Backscatter. Een server die eerst alles aanneemt en pas later ontdekt dat een adres niet bestaat, stuurt een bounce naar de (vervalste) afzender. Dat heet backscatter: foutmeldingen aan onschuldige mensen, en een reden om op een blocklist te komen.

Wil je een paar extra adressen opvangen, zoals een veelgemaakte tikfout of een oud adres? Maak daar losse aliassen of forwarders voor. Gebruik je per website of webwinkel een eigen adres (webshop-x@), om te zien wie je adres doorverkoopt? Maak dat adres dan aan als alias op het moment dat je het gebruikt.

Versturen vanaf een alias

Een alias kan ook een afzender zijn. Je wilt bijvoorbeeld antwoorden als offerte@example.com terwijl je bent ingelogd als info@. Dat kan, maar:

• Veel mailservers controleren tegenwoordig welk afzenderadres bij welke login hoort. Je mag dan alleen versturen vanaf je eigen adres en de aliassen of forwarders die naar jouw mailbox wijzen. Een willekeurig ander adres wordt geweigerd ("account can not send emails from ..."). Dat beschermt tegen misbruik.
• In je mailprogramma voeg je het alias toe als extra identiteit (Thunderbird: Identiteiten beheren; Apple Mail: extra adressen bij het account, gescheiden door komma's; Outlook: het veld Van tonen en het adres intypen).
• SPF, DKIM en DMARC werken gewoon, zolang het alias op hetzelfde domein staat en je via je eigen server verstuurt.

In de praktijk: zo ziet het eruit in een paneel

In DirectAdmin maak je doorsturingen bij E-mail Beheer, Forwarders. De catch-all staat bij Geavanceerde Functies, Catch-All E-mail; daar is "catch-all uitschakelen" de aanbevolen stand (mail aan niet-bestaande adressen wordt geweigerd). Heb je alleen een domeinnaam zonder pakket, dan staan doorsturingen in Mijn WebOké bij Mijn Domeinen, Doorsturingen. Andere panelen (cPanel, Plesk, Microsoft 365, Google Workspace) hebben vergelijkbare onderdelen, soms onder namen als "aliassen", "doorsturen" of "groepen".

Samenvatting

• Een alias of doorsturing binnen dezelfde server is veilig.
• Doorsturen naar buiten breekt SPF. SRS herstelt SPF, maar niet de DMARC-uitlijning; alleen een intacte DKIM-handtekening redt de mail, en ARC kan helpen.
• Doorgestuurde spam schaadt de reputatie van je server. Lees externe mail liever via IMAP in de app.
• Een catch-all trekt spam aan, verstopt tikfouten en kan backscatter veroorzaken. Gebruik losse aliassen.
• Versturen vanaf een alias kan, binnen de regels van je server.

Quiz

Opdracht

Opdracht O3.3: Inventaris van je adressen. Maak een lijst van alle adressen op je domein: mailboxen, aliassen, doorsturingen en of er een catch-all aan staat. Zet bij elke doorsturing of die binnen je eigen domein blijft of naar buiten gaat (Gmail, Outlook.com, een ander bedrijf). Beantwoord daarna: welke doorsturing naar buiten kun je vervangen door een IMAP-account in de app, en staat er een catch-all aan die uit kan? Vul de checklist in.

Verder lezen

De stappen in deze artikelen gelden voor de panelen van WebOké; bij andere aanbieders werkt het vergelijkbaar.

• DirectAdmin handleiding 7.5: Forwarders: mail doorsturen naar een ander adres
• DirectAdmin handleiding 7.6: Catch-All E-mail: mail aan niet-bestaande adressen
• E-mail doorsturen naar een ander adres (forwarders, catch-all afgeraden)
• Mailen vanaf meerdere aliassen, error: Account xxx can not send emails from
• WebOké handleiding 5.9: E-mail- en domeindoorsturingen
• Gratis DNS-cursus 4.3: SPF: wie mag mailen namens jouw domein?
• RFC 8617 (ARC), RFC 7208 bijlage D (SPF en tussenpersonen zoals doorstuurders)