Aliasi, preusmeritve in splošna e-pošta (catch-all): priročno, a s tveganji

Modul 3: Upravljanje Vašega poštnega predala · Čas branja: 11 minut

Cilj lekcije: Po tej lekciji boste znali izbrati med poštnim predalom, aliasom, preusmeritvijo in splošno e-pošto (catch-all), ter pojasniti, zakaj lahko preusmeritev na zunanji naslov in catch-all škodujeta dostavi Vaše pošte.

Ključni pojmi: poštni predal, alias, forwarder (preusmeritev), notranja in zunanja preusmeritev, SPF se pokvari pri preusmeritvi, SRS (Sender Rewriting Scheme), DKIM pri preusmeritvi, ARC (RFC 8617), catch-all, slovarski napad (dictionary attack), backscatter, pošiljanje v imenu drugega naslova

Štirje načini, da naslov deluje

Če želite, da offerte@example.com deluje, imate štiri možnosti:

V nekaterih nadzornih ploščah je alias tehnično enak preusmeritvi na naslov na istem strežniku. Razlika, ki je pomembna, je naslednja: ali pošta ostane na istem strežniku, ali gre navzven?

Preusmeritev znotraj Vaše lastne domene: brez težav

Če preusmerite offerte@example.com na info@example.com, in sta oba na istem strežniku, strežnik pošto preprosto dostavi v poštni predal info@. Nič ne gre prek interneta, nič se znova ne preverja. To je varno in zanesljivo.

Preusmeritev navzven: kje gre narobe

Drugače je, ko preusmerite na naslov pri drugem ponudniku, na primer osebni naslov pri Gmailu ali Outlook.com. Takrat Vaš strežnik pošto znova pošlje, tokrat na Gmail. In Gmail pošto preveri, kot da prihaja z Vašega strežnika.

Recimo: klant@example.net pošlje sporočilo na info@example.com. Vaš strežnik ga preusmeri na Gmail. Kaj vidi Gmail?

• Pošiljatelj (From): klant@example.net.
• Ovojniški pošiljatelj (envelope sender): še vedno klant@example.net, razen če ga Vaš strežnik prepiše.
• Pošiljajoči strežnik: Vaš strežnik, na primer 192.0.2.25.

Gmail preveri SPF-zapis domene example.net. Vašega strežnika tam seveda ni. SPF ne uspe (fail). Če ima example.net DMARC-pravilnik p=reject, in na sporočilu ni veljavnega podpisa DKIM, Gmail sporočilo zavrne. Vaš strežnik dobi nazaj sporočilo o napaki (bounce), ki gre na... prvotnega pošiljatelja, ki zdaj dobi sporočilo o napaki z Vašega strežnika.

Obstajajo trije mehanizmi, ki to omilijo:

1. DKIM (večinoma) preživi

Podpis DKIM (lekcija 4.3) je del samega sporočila. Če Vaš strežnik sporočilo preusmeri nespremenjeno, podpis domene example.net še vedno drži. DMARC takrat uspe na podlagi DKIM, tudi če SPF ne uspe. Zato je DKIM tako pomemben: je edini mehanizem, ki preživi preusmeritev.

Gre pa narobe, če strežnik, ki preusmerja, sporočilo spremeni: doda besedilo na dnu ("preusmerjeno od..."), spremeni zadevo (doda [SPAM] pred njo), ali spremeni obliko. Takrat podpis ni več pravilen.

2. SRS prepiše ovojniškega pošiljatelja

S tehnologijo SRS (Sender Rewriting Scheme) strežnik, ki preusmerja, spremeni ovojniškega pošiljatelja v naslov na svoji lastni domeni, na primer:

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

Zdaj Gmail preveri SPF-zapis domene example.com, in tam je Vaš strežnik dejansko naveden. SPF uspe. Če pride do sporočila o napaki, lahko Vaš strežnik naslov prevede nazaj in sporočilo o napaki pošlje pravemu pošiljatelju.

Pozor: SRS reši SPF, ne pa DMARC. Uskladitev (alignment, lekcija 4.4) primerja domeno ovojniškega pošiljatelja z naslovom From. Zdaj je to example.com proti example.net: ni usklajeno. DMARC mora torej še vedno uspeti na podlagi DKIM.

3. ARC: izjava posrednika

ARC (Authenticated Received Chain, RFC 8617, eksperimentalno) omogoča, da posrednik zabeleži, kaj je videl: "ko je to sporočilo prispelo k meni, so SPF, DKIM in DMARC uspeli". Strežnik, ki preusmerja, to izjavo podpiše. Končni prejemnik se lahko odloči, da bo tej izjavi zaupal, če zaupa posredniku. Veliki prejemniki, kot sta Gmail in Microsoft, ARC uporabljajo, vendar se nanj ne morete zanesti: gre za uslugo, ne za pravico.

In neželena pošta (spam)?

Obstaja še ena težava, ki je pogosto največja. Vaš filter za neželeno pošto ne zaustavi vsega. Vso neželeno pošto, ki pride skozi, Vaš strežnik zdaj preusmeri na Gmail. Gmailu se zdi, kot da Vaš strežnik pošilja neželeno pošto. To uniči ugled Vašega strežnika (pri skupnem gostovanju pa ugled vseh strank na tem strežniku). Gmail nato tudi Vašo pravo pošto pogosteje razvršča kot neželeno.

Kaj je bolje?

Želite brati Vašo poslovno pošto v aplikaciji Gmail ali Outlook? Dodajte poštni predal kot račun IMAP (modul 2). Aplikacija pošto pridobi neposredno z Vašega strežnika. Nič se ne preusmerja, nič ne spodleti in nobena neželena pošta ne gre navzven. Če morate vseeno preusmerjati, nastavite strog filter za neželeno pošto pred preusmeritvijo.

Splošna e-pošta (catch-all): zakaj skoraj nikoli

Funkcija catch-all ujame vso pošto na naslove, ki ne obstajajo. Tipkarska napaka, kot je inof@example.com, potem vseeno prispe. To zveni priročno, vendar:

• Neželena pošta. Pošiljatelji neželene pošte množično pošiljajo sporočila na izmišljene naslove na obstoječih domenah (a.jansen@, sales2@, xkq7@). Temu pravimo slovarski napad (dictionary attack). Brez catch-all Vaš strežnik vse to takoj zavrne. S catch-all vse prispe, pogosto na stotine sporočil na dan.
• Ni več sporočil o napaki. Kdor se zmoti pri Vašem naslovu, ne dobi sporočila o napaki (bounce) in misli, da je njegova pošta prispela. Brez catch-all takoj ve, da naslov ni pravilen.
• Preusmeritev to še poslabša. Catch-all, ki preusmerja na Gmail, vso to neželeno pošto pošlje na Gmail.
• Backscatter. Strežnik, ki najprej sprejme vse in šele kasneje ugotovi, da naslov ne obstaja, pošlje sporočilo o napaki (bounce) na (ponarejenega) pošiljatelja. Temu pravimo backscatter: sporočila o napakah nedolžnim ljudem, in razlog za uvrstitev na seznam blokad.

Želite zajeti nekaj dodatnih naslovov, na primer pogosto tipkarsko napako ali star naslov? Za to ustvarite ločene aliase ali preusmeritve. Uporabljate ločen naslov za vsako spletno mesto ali spletno trgovino (webshop-x@), da vidite, kdo prodaja naprej Vaš naslov? Ta naslov ustvarite kot alias v trenutku, ko ga začnete uporabljati.

Pošiljanje z aliasa

Alias je lahko tudi pošiljatelj. Na primer, želite odgovoriti kot offerte@example.com, medtem ko ste prijavljeni kot info@. To je mogoče, a:

• Mnogi poštni strežniki dandanes preverjajo, kateri naslov pošiljatelja pripada kateri prijavi. Pošiljate lahko le z Vašega lastnega naslova ter aliasov ali preusmeritev, ki kažejo na Vaš poštni predal. Poljuben drug naslov bo zavrnjen ("account can not send emails from ..."). To ščiti pred zlorabo.
• V Vašem poštnem programu dodate alias kot dodatno identiteto (Thunderbird: Upravljanje identitet; Apple Mail: dodatni naslovi pri računu, ločeni z vejicami; Outlook: prikažite polje Od in vnesite naslov).
• SPF, DKIM in DMARC delujejo normalno, dokler je alias na isti domeni in pošiljate prek svojega lastnega strežnika.

V praksi: tako je videti v nadzorni plošči

V DirectAdmin ustvarite preusmeritve pri Upravitelj e-pošte, Forwarders. Splošna e-pošta (catch-all) je pri Napredne funkcije, Catch-All E-mail; priporočena nastavitev je "izklopite catch-all" (pošta na neobstoječe naslove se zavrne). Če imate samo domensko ime brez paketa, se preusmeritve nahajajo v Moj WebOké pri Moje domene, Preusmeritve. Druge nadzorne plošče (cPanel, Plesk, Microsoft 365, Google Workspace) imajo podobne razdelke, včasih pod imeni, kot so "aliasi", "preusmeritve" ali "skupine".

Povzetek

• Alias ali preusmeritev znotraj istega strežnika je varna.
• Preusmeritev navzven pokvari SPF. SRS popravi SPF, ne pa uskladitve DMARC; sporočilo reši le nedotaknjen podpis DKIM, pri čemer lahko pomaga tudi ARC.
• Preusmerjena neželena pošta škoduje ugledu Vašega strežnika. Zunanjo pošto raje berite prek IMAP v aplikaciji.
• Splošna e-pošta (catch-all) privablja neželeno pošto, prikrije tipkarske napake in lahko povzroči backscatter. Uporabljajte ločene aliase.
• Pošiljanje z aliasa je mogoče, znotraj pravil Vašega strežnika.

Kviz

Naloga

Naloga O3.3: Popis Vaših naslovov. Pripravite seznam vseh naslovov na Vaši domeni: poštnih predalov, aliasov, preusmeritev, in ali je vklopljen catch-all. Pri vsaki preusmeritvi zapišite, ali ostane znotraj Vaše lastne domene ali gre navzven (Gmail, Outlook.com, drugo podjetje). Nato odgovorite: katero zunanjo preusmeritev lahko nadomestite z računom IMAP v aplikaciji, in ali je vklopljen catch-all, ki ga lahko izklopite? Izpolnite kontrolni seznam.

Za dodatno branje

Koraki v teh člankih veljajo za nadzorne plošče WebOké; pri drugih ponudnikih deluje podobno.

• Priročnik DirectAdmin 7.5: Posredniki: preusmerjanje e-pošte na drug naslov
• Priročnik DirectAdmin 7.6: Splošna e-pošta: pošta na neobstoječe naslove
• Posredovanje e-pošte na drug naslov (preusmeritve, uporaba catch-all ni priporočljiva)
• Pošiljanje z več vzdevkov, napaka: Account xxx can not send emails from
• Priročnik WebOké 5.9: Posredovanja e-pošte in preusmeritve domen
• Brezplačen tečaj DNS 4.3: SPF: kdo sme pošiljati pošto v imenu Vaše domene?
• RFC 8617 (ARC), RFC 7208 priloga D (SPF in posredniki, kot so preusmerjevalniki)