Pošta z Vašega spletnega mesta in obrazcev

Modul 7: Novice in pošta z Vašega spletnega mesta · Čas branja: 11 minut

Cilj lekcije: Po tej lekciji boste znali nastaviti pošto s spletnega mesta (kontaktni obrazci, potrditve naročil, obvestila WordPress-a) tako, da prispe na cilj, ne povzroča težav z DMARC in ne omogoča zlorabe Vašega paketa.

Ključni pojmi: PHP mail(), SMTP s prijavo, pošiljatelj na ovojnici (envelope sender), From proti Reply-To, naslov obiskovalca nikoli kot From, vtičnik SMTP, transakcijska pošta, zloraba obrazcev, captcha, honeypot, omejitev pošiljanja, lokalna dostava, če je MX drugje

Vaše spletno mesto je tudi poštni program

Vaše spletno mesto pošilja več pošte, kot si mislite. Kontaktni obrazec Vam pošlje vsako prejeto sporočilo po e-pošti. Spletna trgovina pošilja potrditve naročil, račune in obvestila o pošiljkah. WordPress pošlje e-pošto ob novem komentarju, posodobitvi ali ponastavitvi gesla. Za prejemnika je to običajna pošta z Vaše domene in se preverja enako strogo kot pošta iz Vašega poštnega predala: SPF, DKIM, DMARC, ugled.

Kljub temu gre pri pošti s spletnega mesta pogosteje kaj narobe kot pri običajni pošti. Razlog je ponavadi eden od treh: način pošiljanja, naslov pošiljatelja ali zloraba obrazca.

Način 1: PHP mail()

Najpreprostejši način, da spletno mesto pošilja e-pošto, je funkcija PHP mail(). Spletno mesto nato pošto preda neposredno poštnemu programu spletnega strežnika, brez prijave. Ponavadi deluje, vendar ima pomanjkljivosti:

• Pošiljatelj na ovojnici (Return-Path) pogosto postane sistemski račun Vašega paketa, na primer gebruiker@server.hosting.example, in ne Vaš naslov. SPF se nato preveri za domeno strežnika in torej ni usklajen (aligned) z Vašo domeno v From (lekcija 7.1).
• Ali bo dodan podpis DKIM Vaše domene, je odvisno od strežnika. Na nekaterih strežnikih je, na drugih ne.
• Ničesar ne vidite nazaj. Če pošta ne prispe ali dobite povratno sporočilo (bounce), gre to na sistemski račun, kamor nihče ne gleda.
• Ni omejitve na obrazec. Če je obrazec zlorabljen, strežnik v Vašem imenu pošilja, dokler ni dosežena omejitev Vašega paketa.

Način 2: SMTP s prijavo (boljše)

Omogočite, da Vaše spletno mesto pošilja tako, kot to počne Vaš poštni program: s prijavo v odhodni poštni strežnik z resničnim poštnim predalom, prek vrat 587 (STARTTLS) ali 465 (SSL/TLS), s polnim e-poštnim naslovom kot uporabniškim imenom (lekciji 1.4 in 2.1). Tako:

• je pošiljatelj na ovojnici Vaš naslov in je pošta podpisana enako kot običajna pošta z Vaše domene;
• povratna sporočila (bounce) pridejo v poštni predal, ki ga lahko preberete;
• poslana pošta, če tako želite, ostane v mapi Poslano;
• lahko za vsak poštni predal nastavite svojo omejitev pošiljanja.

V WordPressu to storite z vtičnikom SMTP. Ta nadomesti privzeto funkcijo pošiljanja v WordPressu s pošiljanjem prek SMTP. Vnesete iste podatke kot v poštnem programu: strežnik, vrata, varnost, uporabniško ime in geslo. Za to je priporočljivo ustvariti ločen poštni predal, na primer website@example.com. Če bo geslo kdaj ukradeno, Vaš lasten poštni predal ostane varen, poleg tega pa na prvi pogled vidite, katera pošta prihaja s spletnega mesta.

Za lastno spletno mesto v PHP obstajajo knjižnice, ki pošiljajo prek SMTP, na primer PHPMailer. Geslo shranite v konfiguracijsko datoteko zunaj spletne mape, ne v kodo strani.

Pri WebOké so podatki za SMTP navedeni v priročniku DirectAdmin 8.1, skupaj z imenom strežnika Vašega paketa; pri drugih ponudnikih jih najdete v priročniku ali uvodnem e-poštnem sporočilu, delovanje pa je enako.

Veliko transakcijske pošte? Uporabite storitev

Če pošiljate na stotine potrditev naročil na dan, se splača uporabiti transakcijsko storitev: storitev za pošiljanje avtomatizirane pošte. Ta ima dober ugled in prikazuje, kaj se je zgodilo z vsakim sporočilom. Domeno povežete podobno kot pri storitvi za novičnike (DKIM prek CNAME, lekcija 7.1). Transakcijsko pošto in novičnike ločite: neuspela kampanja ne sme vplivati na potrditveno pošto Vaših naročil.

Zlato pravilo: naslov obiskovalca nikoli ni pošiljatelj

Pri kontaktnem obrazcu je mamljivo, da se pošto pošlje "od" obiskovalca. Tako lahko v poštnem programu takoj kliknete Odgovori. To izgleda takole:

From: Pieter <pieter@example.net>
To: info@example.com
Subject: Vraag via het contactformulier

Toda Vaš strežnik sploh ne sme pošiljati v imenu example.net. Recimo, da ima example.net politiko DMARC p=reject. Prejemni strežnik (Vaš lasten, ali Gmailov, če pošto preusmerjate) zazna sporočilo s From example.net, ki ne prihaja prek SPF ali DKIM domene example.net, in ga zavrne. Mnoge velike poštne domene imajo strogo politiko: pri preverjanju 8. novembra 2026 so med drugim yahoo.com, aol.com, ziggo.nl in kpnmail.nl imele politiko DMARC p=reject, icloud.com, gmx.de in web.de pa p=quarantine. Obiskovalec s takim naslovom izpolni Vaš obrazec, Vi pa sporočila nikoli ne prejmete ali pa pristane v Vaši mapi za neželeno pošto. Domene s p=none (kot sta bila takrat gmail.com in hotmail.com) lahko svojo politiko kadar koli zaostrijo, Google pa v svojih smernicah izrecno navaja, da ne smete posnemati naslovov Gmail v From. Zato se nikoli ne zanašajte na to, da bo šlo v redu.

Pravilen način:

From: Website example.com <website@example.com>
Reply-To: Pieter <pieter@example.net>
To: info@example.com
Subject: Vraag via het contactformulier

Pošiljatelj je Vaš lasten naslov, zato se SPF, DKIM in DMARC ujemajo. Naslov obiskovalca je naveden v polju Reply-To. Če kliknete Odgovori, gre Vaš odgovor Pietru. V večini vtičnikov za obrazce to najdete pri nastavitvah pošte: pri Pošiljatelj (From) nastavite stalen naslov Vaše lastne domene, pri Reply-To pa polje, v katerega obiskovalec vnese svoj naslov.

Zaščita obrazcev pred zlorabo

Obrazec brez zaščite slej ko prej odkrijejo boti. V najboljšem primeru prejmete neželeno pošto. V najslabšem primeru ga zlorabijo za pošiljanje neželene pošte drugim: če Vaš obrazec pošilja potrditev na "naslov, ki ga vnese obiskovalec", lahko bot tja vnese kateri koli naslov na svetu, z lastnim besedilom v sporočilu. Tako Vaša domena pošilja neželeno pošto, s posledicami za Vaš ugled (lekcija 5.2).

Zaščita v plasteh:

• Captcha ali nevidno preverjanje (kot reCAPTCHA ali Turnstile) ustavi večino botov.
• Honeypot: skrito polje, ki ga ljudje ne vidijo, boti pa ga izpolnijo. Če je izpolnjeno, se sporočilo ne pošlje.
• Brez prostega besedila v potrditvi obiskovalcu, ali sploh brez potrditve na navedeni naslov. Preprosto sporočilo "Hvala, prejeli smo Vaše sporočilo" na strani zadošča.
• Omejitev pošiljanja na poštni predal za poštni predal spletnega mesta, nižja od tiste za celoten paket.
• Posodabljanje programske opreme. Stari vtičniki so znan vstopni vektor za zlorabo.

Če opazite, da Vaš paket nenadoma pošilja veliko pošte, ali prejmete obvestilo, da je dosežena dnevna omejitev, čeprav sami pošiljate malo pošte? Takoj zamenjajte gesla in preverite, kateri obrazec ali skript pošilja pošto (lekcija 3.4).

Pošta je drugje, spletno mesto tukaj

Pogosta past: Vaše spletno mesto gostuje pri enem ponudniku, Vaša pošta pa pri drugem (na primer Microsoft 365 ali Google Workspace). Vaš MX kaže na tega drugega ponudnika. Toda spletni strežnik še vedno misli, da sam skrbi za pošto Vaše domene, ker je domena nastavljena tudi na njegovem lastnem paketu. Pošto iz obrazca na info@example.com tako dostavi lokalno, v poštni predal na spletnem strežniku, kamor nihče ne gleda, ali pa vrne napako, kot je 550 ... mailbox unavailable.

Rešitev je, da v nadzorni plošči spletnega strežnika označite, da se pošta obravnava drugje. Pri WebOké v DirectAdmin je to kljukica "Uporabi ta strežnik za upravljanje mojih e-poštnih sporočil" pri Zapisi MX (izklopite jo). Druge nadzorne plošče imajo podobne nastavitve, na primer "usmerjanje e-pošte: zunanje" v cPanelu. Še boljše: naj spletno mesto pošilja prek SMTP, s poštnim predalom pri ponudniku, kjer Vaša pošta dejansko gostuje.

Povzetek

• Pošta s spletnega mesta se preverja enako strogo kot običajna pošta. Naj spletno mesto pošilja prek SMTP s prijavo, ne prek mail().
• Za spletno mesto uporabite ločen poštni predal, z lastno omejitvijo pošiljanja.
• Naslov obiskovalca sodi v Reply-To, nikoli v From. Sicer DMARC ne uspe, pri domenah s p=reject (kot so yahoo.com, ziggo.nl, kpnmail.nl) pa je pošta zavrnjena.
• Obrazce zaščitite s captcho, honeypotom in brez prostih potrditev na navedene naslove.
• Če Vaša pošta gostuje pri drugem ponudniku, izklopite lokalno dostavo na spletnem strežniku ali pošiljajte prek SMTP pri tem ponudniku.

Kviz

Naloga

Naloga O7.3: Pregled pošte s spletne strani. Izpolnite obrazec na svojem spletnem mestu z naslovom Gmail ali Outlook.com kot pošiljateljem in si oglejte glave sporočila, ki ga prejmete. Odgovorite na kontrolni seznam: kateri naslov je naveden v From, ali je naslov obiskovalca v Reply-To, kaj pokažejo spf=, dkim= in dmarc= pri Authentication-Results, ali Vaše spletno mesto pošilja prek SMTP ali prek mail(), in ali ima obrazec captcho ali honeypot? Če nimate lastnega spletnega mesta, odgovorite na vprašanja za primer iz te lekcije. Nato prejmete vzorčni odgovor.

Za nadaljnje branje

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

• Kontaktni obrazec na Vaši spletni strani: pošiljanje vsebine polj po e-pošti in preprečevanje neželene pošte
• Kako v PHP z mail() dosežem pravega pošiljatelja? SMTP
• Pošiljanje pošte prek PHP ne deluje, zapisi MX kažejo drugam
• Omejitev za pošiljanje pošte
• Dosežena dnevna omejitev e-pošte
• Priročnik DirectAdmin 8.1: Vse nastavitve na enem mestu: strežniki, vrata in varnost
• Priročnik DirectAdmin 5.10: E-pošta pri Microsoft 365 ali Google Workspace, spletna stran pri WebOké