M SMTP

Diegimas ir aktyvavimas

M SMTP reikia WordPress 6.5 arba naujesnės versijos ir PHP 7.4 arba naujesnės. Aktyvavus sukuriamos dvi duomenų bazės lentelės, wp_msmtp_emails ir wp_msmtp_events (su jūsų lentelių priešdėliu), ir suplanuojami du WP-Cron įvykiai: msmtp_process_queue kas minutę pagal įskiepio įregistruotą intervalą "Every minute (M SMTP)", pirmas paleidimas po minutės, ir msmtp_purge_logs kasdien, pirmas paleidimas po 24 valandų. Svetainių tinkle aktyvavus įskiepį visame tinkle, lentelės ir cron sukuriami kiekvienoje esamoje svetainėje, o vėliau sukurtos svetainės paruošiamos automatiškai. Schemos atnaujinimai vykdomi per init kabliuką, o ne tik wp-admin, todėl atnaujinus įskiepį nė viena tinklo svetainė nelieka su sena lentelės struktūra; parinktis msmtp_upgrade_lock neleidžia lygiagrečioms užklausoms atnaujinti schemos daugiau nei kartą.

1. Įkelkite įskiepį į /wp-content/plugins/m-smtp/ arba įdiekite zip failą iš Plugins lango.
2. Aktyvuokite. Per SMTP kol kas dar niekas nesiunčiama.
3. Eikite į M SMTP, tada Settings, ir suveskite savo SMTP serverio duomenis.
4. Eikite į M SMTP, tada Tools, ir paspauskite Test Connection, o paskui Send Test Email.

• Veikia iš karto: kiekvieno wp_mail() laiško įrašymas į žurnalą kartu su visu turiniu (Log message body įjungtas iš anksto) ir 30 dienų saugojimo laikas.
• Išjungta, kol neįjungsite: atidarymų ir paspaudimų sekimas, Optimized sending (foninė eilė), visos siuntimo ribos (visos nustatytos į 0), Force From email, Force From name ir duomenų trynimas pašalinant įskiepį.
• Tuščia, kol neužpildysite: SMTP Host. Kol serverio laukas tuščias ir niekas nekeliauja į eilę, M SMTP nekeičia PHPMailer nustatymų, tad WordPress ir toliau siunčia per PHP mail(), o laiškai vis tiek įrašomi į žurnalą. Tai nustoja galioti tą akimirką, kai viršijama siuntimo riba arba pažymimas Optimized sending: tuomet laiškas nukreipiamas į eilę, kuri neturi serverio, per kurį galėtų siųsti. Apie tai 12 skyriuje, ir ne be reikalo pirmuoju punktu.

Kur rasti įskiepio langus

M SMTP prideda vieną pagrindinio meniu punktą M SMTP su voko piktograma, esantį žemiau Settings administravimo šoninėje juostoje. Sąsaja angliška net ir lietuviškoje svetainėje, todėl žemiau pateikti pavadinimai yra būtent tie, kuriuos matysite ekrane. Visiems penkiems langams reikia manage_options teisės. Vienoje svetainėje tai reiškia Administrator. Svetainių tinkle tai reiškia ir Super Admin, ir kiekvieną tos svetainės Administrator: WordPress tinkle iš svetainės administratorių manage_options neatima, atima tik įskiepių, temų, naudotojų ir sistemos atnaujinimo teises. Kiekvienas, galintis atverti Email Log, gali perskaityti tos svetainės laiškų turinį, o tai svarbu dėl 5 skyriaus įspėjimo. Programuotojai šį reikalavimą gali pakeisti filtru msmtp_capability. Kiekviename įskiepio lange, viršutiniame dešiniajame wp-admin kampe, yra Help kortelė "Background sending": ji paaiškina WP-Cron ypatumus ir parodo paruoštą cron eilutę jūsų svetainei.

• M SMTP, tada Settings: SMTP serveris, siuntėjo adresas, žurnalas, sekimas, eilė ir siuntimo ribos. Adreso dalis msmtp.
• M SMTP, tada Email Log: visi laiškai su būsena, siuntusiu įskiepiu ir įsitraukimo duomenimis. Adreso dalis msmtp-log.
• M SMTP, tada Reports: išsiųstų ir nepavykusių laiškų skaičiai, atidarymų ir paspaudimų dalys. Adreso dalis msmtp-reports.
• M SMTP, tada Routing: sąlyginių taisyklių kūrimo langas. Adreso dalis msmtp-routing.
• M SMTP, tada Tools: ryšio patikra, bandomasis laiškas, rankinis eilės paleidimas ir rankinis žurnalo valymas. Adreso dalis msmtp-tools.

Settings: Primary SMTP Server

Šiuo ryšiu siunčiami visi laiškai, nebent nukreipimo taisyklė nurodo kitaip. Numatytosios reikšmės: Port 587, Encryption TLS, Auto TLS įjungtas, Authentication įjungtas, o Host, Username ir Password tušti. Prievadų mygtukai (25, 465, 587, 2525) įrašo prievadą ir kartu parenka tinkamą šifravimą: 25 duoda None, 465 duoda SSL, 587 ir 2525 duoda TLS. Ryšio laukimo laikas fiksuotas – 10 sekundžių, ir jo keisti negalima. Slaptažodis duomenų bazėje saugomas užšifruotas AES-256-CTR algoritmu, raktą išvedant iš svetainės saugumo raktų (auth salt), aprašytų wp-config.php faile. Šis šifras vientisumo netikrina, tad nebetinkantis raktas duoda ne klaidą, o kitą slaptažodį, kurį įskiepis paskui nusiunčia jūsų pašto serveriui. Kaip tai atrodo žurnale, aprašyta 12 skyriuje, nes atrodo tai visai ne kaip šifravimo bėda. Jei OpenSSL nepasiekiamas, įskiepis slaptažodį gali tik užmaskuoti base64 kodavimu ir apie tai praneša savo languose. Bet kurį iš septynių laukų galima užrakinti wp-config.php faile; užrakintas laukas formoje neaktyvus ir pažymėtas užrašu "Defined in wp-config.php". Konstantos galioja tik pagrindiniam ryšiui ir niekada negalioja papildomiems.

• SMTP Host: numatytoji reikšmė tuščia. Kol jis tuščias, paštas siunčiamas per PHP mail(), o įskiepio languose rodomas geltonas įspėjimas.
• Port: numatytoji reikšmė 587.
• Encryption: None, SSL (SMTPS, dažniausiai 465 prievadas) arba TLS (STARTTLS, dažniausiai 587 prievadas). Numatytoji reikšmė TLS.
• Auto TLS: įjungtas iš anksto. Kai serveris praneša palaikantis STARTTLS, ryšys pakeliamas į šifruotą.
• Authentication: įjungtas iš anksto. Išjungus šią parinktį, vartotojo vardo ir slaptažodžio laukai paslepiami, o serveriui perduodamos tuščios reikšmės.
• Username ir Password: numatytai tušti. Išsaugant paliktas tuščias slaptažodžio laukas reiškia, kad išsaugotas slaptažodis lieka nepakeistas; į formą jis niekada negrąžinamas.

define( 'MSMTP_SMTP_HOST', 'smtp.example.com' );
define( 'MSMTP_SMTP_PORT', 587 );
define( 'MSMTP_SMTP_ENCRYPTION', 'tls' ); // none | ssl | tls
define( 'MSMTP_SMTP_AUTOTLS', true );
define( 'MSMTP_SMTP_AUTH', true );
define( 'MSMTP_SMTP_USER', 'user@example.com' );
define( 'MSMTP_SMTP_PASS', 'your-smtp-password' );

Settings: From Address

Du laukai, From Email ir From Name, kiekvienas su savo žymimuoju langeliu "Force this From ... on all outgoing mail". Abu laukai numatytai tušti, abu Force langeliai nepažymėti. Yra vienas dalykas, kurio ekranas neįvardija: nepažymėjus Force, reikšmė naudojama tik siuntėjui parodyti Email Log žurnale, kai laiškas neturėjo savo From antraštės. Pats išsiunčiamas laiškas perrašomas tik tada, kai Force pažymėtas. Jei norite, kad visi svetainės įskiepiai siųstų tuo pačiu adresu, pažymėkite Force. Jei priverstinis adresas netaisyklingas, jis tyliai ignoruojamas ir paliekamas pradinis siuntėjas.

Settings: Email Log

Log message body įjungtas iš anksto: saugomas visas laiško turinys, kad laiškus būtų galima perskaityti žurnale ir vėliau išsiųsti pakartotinai. Numatytasis saugojimo laikas – 30 dienų; senesnius įrašus ištrina kasdienis msmtp_purge_logs cron įvykis, o 0 reiškia saugoti neribotai. Eilėje laukiantys laiškai pagal saugojimo laiką netrinami, trinami tik pristatyti arba nepavykę. Yra dar viena riba, kuriai ekrane nėra jokio valdiklio: log_body_max, vieno laiško riba – 1048576 baitai (1 MB), laikoma msmtp_settings parinktyje. Už ją didesnis turinys išsaugomas nukirptas ir pažymimas kaip nepilnas: tokį laišką dar galima perskaityti, bet ne išsiųsti pakartotinai ar persiųsti. Išjungus Log message body žurnalas nedingsta: tema, gavėjai, antraštės, priedų pavadinimai, būsena ir klaidos vis tiek įrašomi. Tačiau ekrano formuluotė apie turinio pašalinimą po pristatymo aprašo tik pusę to, kas vyksta. Įprastu, iškart siunčiamu keliu turinys į duomenų bazę apskritai nepatenka. Vėliau turinys pašalinamas tik iš eilei atidėtų laiškų: jų turinys saugomas pažodžiui, nes tas įrašas yra vienintelė laiško kopija, ir išvalomas tada, kai laiškas pristatomas, galutinai nepavyksta arba pasibaigia jo galiojimas eilėje.

Settings: Open & Click Tracking

Sekimas numatytai išjungtas, jį valdo du žymimieji langeliai. Pirmasis įjungia nematomą vieno pikselio paveikslėlį ir perrašo laiško nuorodas; antrasis papildomai išsaugo lankytojo IP adresą prie atidarymo ar paspaudimo. Verta tiksliai žinoti, kas perrašoma: perrašymas taikomas tik kabutėse esančioms <a> elementų href reikšmėms ir niekam kitam. Href be kabučių, plika nuoroda tekste ir bet kurio kito elemento adresas lieka nepaliesti, tad paprastesniuose HTML laiškuose dažnai atsiranda tik pikselis, o perrašytų nuorodų nebūna. Sekimas taikomas tik laiškams, kurių turinio tipe yra text/html; paprasto teksto laiškai neliečiami. Ir pikselis, ir perrašytos nuorodos veda į jūsų svetainės pagrindinį adresą su užklausos eilute msmtp=o arba msmtp=c, atpažinimo žyma ir HMAC parašu, išvestu iš svetainės saugumo raktų (auth salt). Sekimo adresas atsako 403 tik tada, kai parašas nesutampa, kai užkoduoto tikslo adreso nepavyksta perskaityti arba kai žyma neatitinka jokio žurnale esančio laiško. Užklausa, kurioje tų parametrų tiesiog nėra arba žyma netinkamo pavidalo, ignoruojama, o puslapis atsidaro kaip įprasta. Dar vieną dalyką verta žinoti prieš įjungiant: kai sekimas veikia, prie kiekvieno atidarymo ir paspaudimo įrašoma gavėjo naršyklės user agent eilutė, nesvarbu, ar IP saugojimas įjungtas. Antrasis langelis valdo tik IP.

• Perrašytos nuorodos gavėją pirma nuveda per jūsų svetainę ir tik tada į tikrąjį adresą. Jei svetainė neveikia ar lėta, tokia bus ir kiekviena nuoroda kiekviename jau išsiųstame laiške.
• Pakeitus svetainės saugumo raktus, jau pristatytų laiškų sekimo nuorodos ir pikseliai ima atsakinėti 403, nes parašas tikrinamas pagal naują raktą. Svetainės perkėlimas į kitą domeną lūžta kitaip: parašas apima tik tipą, atpažinimo žymą ir tikslo adresą, bet niekada ne serverio vardą, tad iki svetainės vis dar nusigaunanti nuoroda veikia toliau, o nebenusigaunanti gauna tai, kas dabar atsiliepia tuo adresu, arba nieko.
• Autentifikacijos laiškams jokios išimties nėra. Kiekvienoje svetainėje, kurios išsiunčiamas paštas skelbiamas kaip HTML, o taip yra daugumoje svetainių su WooCommerce ar formų įskiepiu, slaptažodžio atkūrimo ar prisijungimo nuoroda perrašoma į nukreipimą per pačią svetainę. Todėl jau gautas atkūrimo laiškas nustoja veikti lygiai tada, kai nustoja veikti svetainė. Svetainėse, kurias prižiūri vienas ar du administratoriai, sekimą palikite išjungtą; jei liksite užrakinti su įjungtu sekimu, atgal grįšite tik per WP-CLI arba tiesiogiai pakeitę slaptažodį duomenų bazėje, ne paštu.
• Sekimas yra asmens duomenų tvarkymas. Paminėkite laiškų atidarymų ir paspaudimų sekimą savo privatumo politikoje.

Settings: Sending & Rate Limits

Optimized sending numatytai išjungtas. Įjungus, kiekvienas laiškas rašomas į eilę, o ne pristatomas puslapio užklausos metu, ir msmtp_process_queue cron įvykis kas minutę ją tuština po 20 laiškų. Siuntimo ribos – penki atskiri skaičiai: per minutę, valandą, parą, savaitę ir mėnesį, visi numatytai 0, o 0 reiškia jokios ribos. Tai slenkantys langai, skaičiuojami pagal žurnale jau kaip išsiųstus pažymėtus laiškus, o "per mėnesį" reiškia slenkančias 30 dienų, o ne kalendorinį mėnesį. Ribos yra bendros, o ne atskiros kiekvienam ryšiui: skaitiklis žiūri į visus žurnale kaip išsiųstus pažymėtus laiškus, nesvarbu, kuris SMTP serveris juos pristatė, tad per antrąjį ryšį paleistas naujienlaiškis suėda tą pačią kvotą kaip ir jūsų užsakymų laiškai. Viskas, kas viršija ribą, keliauja į eilę ir laukia, kol seniausias suskaičiuotas laiškas išslinks iš lango, bet ne trumpiau nei 60 sekundžių. Du dalykai eilę aplenkia: laiškai su priedais nepatenka į Optimized sending, nes saugomi tik failų keliai, o failo eilės vykdymo metu gali nebebūti, ir bet kuris laiškas, kurio turinys viršija 4 MB, visada siunčiamas iš karto, net viršijus siuntimo ribą, nes tokio dydžio kopijos nepavyktų išsaugoti nesugadintos. Siuntimo ribos priedams vis tiek galioja, o kai riba suveikia, tie priedai turi likti diske, kol eilė juos pristatys. Jei failo tuo metu nebėra, eilė laiško nesulaiko: trūkstamas priedas įrašomas į laiko juostą, o laiškas išsiunčiamas be jo, ir įrašo būsena lieka Sent. Eilėje laiškui skiriami ne daugiau kaip penki bandymai iš viso: pirmasis ir dar iki keturių pakartojimų po 60 sekundžių, 5 minučių, 30 minučių ir 2 valandų, o paskui laiškas pažymimas galutinai nepavykusiu. Nuo pirmojo bandymo tai užtrunka apie dvi su puse valandos, ne dienas. Kode yra ir 6 valandų žingsnis, bet penktasis bandymas jau yra paskutinis, tad tas žingsnis niekada nepanaudojamas. Nė vienos iš šių funkcijų neįjunkite, kol SMTP Host laukas tuščias; kodėl, paaiškinta 12 skyriuje.

define( 'DISABLE_WP_CRON', true );

* * * * * curl -s https://example.com/wp-cron.php > /dev/null

Papildomi ryšiai ir Smart Routing

Po pagrindine nustatymų forma esantis Additional SMTP Connections blokas leidžia aprašyti papildomus serverius: kiekvienas turi savo pavadinimą, adresą, prievadą, šifravimą, Auto TLS, autentifikaciją, vartotojo vardą ir slaptažodį. Naujose eilutėse iš anksto nustatyta 587 prievadas, TLS, įjungtas Auto TLS ir įjungta autentifikacija, lygiai kaip pagrindiniame ryšyje. Šis blokas turi savo mygtuką Save Connections, atskirą nuo Save Settings. Routing langas paskui nusprendžia, kuriuo ryšiu keliaus kiekvienas laiškas. Taisyklės tikrinamos iš viršaus į apačią, laimi pirma sutapusi; jokios taisyklės neatitikęs laiškas siunčiamas pagrindiniu ryšiu. Kiekviena taisyklė yra sąlygų rinkinys, sujungtas arba per "all conditions match", arba per "any condition matches", ir nurodo vieną ryšį. Sąlyga lygina lauką su reikšme operatoriais contains, does not contain, equals arba starts with, o visi palyginimai neskiria didžiųjų ir mažųjų raidžių. Galimi laukai: Subject, Message body, From address, To address ir Source plugin. Šaltinio reikšmės rašomos kaip plugin:slug, theme:slug arba wp-core, pavyzdžiui plugin:woocommerce.

• Išsaugant Additional SMTP Connections visas sąrašas perrašomas pagal tai, ką atsiuntė forma. Naršyklėje pašalinta eilutė po išsaugojimo dingsta, kaip ir bet kuri eilutė, kurios Host lauką ištuštinote.
• Sąlygos su tuščia reikšme išsaugant atmetamos, o be sąlygų likusi taisyklė atmetama kartu su jomis.
• Taisyklė, rodanti į nebeegzistuojantį ryšį, siunčiant praleidžiama. Jos laiškas tyliai keliauja į kitą tinkančią taisyklę arba į pagrindinį ryšį.
• MSMTP_SMTP_* konstantos papildomiems ryšiams negalioja niekada, o MSMTP_SMTP_PASS gelbsti tik pagrindinį ryšį. Kiekvienas papildomas ryšys slaptažodį visada ima iš užšifruotos reikšmės duomenų bazėje, ir jokia konstanta jos nepakeičia. Pakeitus svetainės saugumo raktus, kiekvienam papildomam ryšiui slaptažodį reikia įvesti iš naujo ir spustelėti Save Connections. Kol to nepadarysite, nukreipimo taisyklės ir toliau siųs savo laiškus per ryšį, kuris negali autentifikuotis, nes taisyklė praleidžiama tik tada, kai ryšio nebėra, o ne tada, kai jo prisijungimo duomenys netinkami.

Tools langas

Tools lange yra keturi veiksmai; visi jie vykdomi per įskiepio REST sritį msmtp/v1 ir reikalauja tos pačios teisės kaip ir patys langai. Test Connection prisijungia prie pasirinkto serverio, suderina šifravimą ir autentifikuojasi nieko nesiųsdamas, o po mygtukais parodo visą SMTP pokalbį. Send Test Email išsiunčia tikrą HTML laišką, adreso lauke iš anksto įrašius prisijungusio administratoriaus adresą. Process queue now iš karto paleidžia vieną eilės paketą, nelaukdamas cron, ir praneša, kiek laiškų išsiųsta, kiek nepavyko ir kiek atidėta. Purge old logs now vykdo lygiai tą patį kodą kaip ir kasdienis cron įvykis: per vieną pravažiavimą pirma pažymi kaip pasibaigusius eilės laiškus, kurių terminas praėjo daugiau nei prieš septynias dienas, o paskui ištrina už saugojimo laiką senesnius įrašus. Todėl eilėje ilgiau nei saugojimo laiką užstrigęs laiškas per tą patį paspaudimą ir pasibaigia, ir ištrinamas, nepalikdamas jokio įrašo. Abiejų patikros veiksmų rodomame įraše sąmoningai praleidžiamas laiško turinys, ir jame niekada nebūna prisijungimo duomenų: PHPMailer derinimo lygis apribotas iki 3, žemiau to vienintelio lygio, kuriame autentifikacijos apsikeitimas būtų atspausdintas atviru tekstu.

Email Log ir Reports langai

Email Log rodo visus laiškus su stulpeliais Subject, To, Source, Status, Opens / Clicks ir Date, po dvidešimt eilučių puslapyje, ir šis skaičius yra fiksuotas: jokio Screen Options valdiklio jam neregistruojama. Virš lentelės yra rodiniai All, Sent, Failed ir Queued, paieškos laukas, apimantis temą, gavėją ir siuntėją, šaltinio sąrašas ir datų filtras. Atvėrus eilutę matyti visas įrašas: adresai, antraštės, bandymai, priedų pavadinimai, paskutinio nesėkmingo bandymo SMTP pokalbis, visų įvykių laiko juosta ir pats laiškas, atvaizduotas izoliuotame rėmelyje be sekimo elementų, o po juo neapdorotas HTML kodas. Re-send ir Forward siūlomi tik tada, kai būsena yra Sent arba Failed ir buvo išsaugota pilna turinio kopija; eilėje esantys ar siunčiami laiškai mygtukų negauna, nes juos valdo eilės vykdytojas. Toliau šie du veiksmai elgiasi skirtingai, ir tas skirtumas svarbus. Re-send nukopijuoja įrašą į naują žurnalo eilutę ir pristato būtent kopiją, tad pirmojo pristatymo įrašas išlieka, o siuntimo ribų skaitiklis suskaičiuoja naująjį. Forward nusiunčia išsaugotą laišką vienu adresu, praleisdamas CC ir BCC, ir jokio žurnalo įrašo nesukuria: vienintelis pėdsakas yra Forwarded įrašas pradinio laiško laiko juostoje. Todėl persiuntimo nemato nei Sent rodinys, nei Reports, nei siuntimo ribų skaitiklis, nors tiekėjas jį suskaičiavo kaip tikrą laišką. Be to, jis iškeliauja su pradinio įrašo sekimo nuorodomis, tad persiųstos kopijos atidarymas priskiriamas pradiniam laiškui. Siuntimo ribos irgi keičia šių mygtukų elgseną: išnaudojus langą, Forward atsisako veikti ir nesiunčia nieko, o Re-send praneša apie sėkmę, nors iš tikrųjų tik įdėjo kopiją į eilę vėlesniam siuntimui. Reports keturiose plytelėse (Sent, Failed, Open rate ir Click rate) rodo paskutinių 7, 30 arba 90 dienų suvestinę ir dienos grafiką. Abi procentinės plytelės ką nors reiškia tik įjungus sekimą.

Pirmas paleidimas, žingsnis po žingsnio

Nustatykite įskiepį šia tvarka, ir nuo veikiančios konfigūracijos visada būsite nutolę ne daugiau nei per vieną žingsnį. Pirmą dieną neįjunkite nei eilės, nei siuntimo ribų, nei sekimo: pirma įsitikinkite, kad veikia paprastas siuntimas per SMTP, o paskui pridėkite po vieną funkciją ir po kiekvienos išsiųskite sau bandomąjį laišką.

1. M SMTP, Settings lange užpildykite SMTP Host, tada spustelėkite tą prievado mygtuką, kurį nurodo jūsų tiekėjas (587 STARTTLS atveju, 465 SSL atveju). Patikrinkite, ar parinktas šifravimas atitinka tiekėjo nurodymus.
2. Palikite įjungtus Auto TLS ir Authentication, įveskite Username bei Password ir spustelėkite Save Settings.
3. Eikite į Tools, palikite pasirinktą ryšį Primary ir spustelėkite Test Connection. Perskaitykite pokalbio įrašą: jis turi baigtis sėkminga autentifikacija.
4. Tame pačiame Tools lange spustelėkite Send Test Email ir patikrinkite pašto dėžutę, taip pat šlamšto aplanką.
5. Grįžę į Settings, nurodykite From Email ir From Name, o jei norite, kad jie būtų taikomi ne tik žurnalui, bet ir išsiunčiamiems laiškams, pažymėkite abu Force langelius.
6. Palikite įjungtą Log message body ir 30 dienų Retention, nebent turite priežastį keisti. Išsaugokite.
7. Išsiųskite sau tikrą laišką, pavyzdžiui, bandomosios paskyros slaptažodžio atkūrimą, ir atsiverskite jį Email Log lange: būsena turi būti Sent, o šaltinis atpažintas.
8. Tik dabar svarstykite Optimized sending ar siuntimo ribas, ir tik tada, kai Test Connection praeina sėkmingai, o tikras sistemos cron kas minutę kviečia wp-cron.php. Nė viena iš jų nėra saugi, kol SMTP Host tuščias.
9. Papildomus ryšius ir nukreipimo taisykles palikite pabaigai, kiekvieną naują ryšį prieš tai patikrinę Tools lange.

Pavojingi veiksmai ir kaip atitaisyti

M SMTP nefiltruoja srauto, neblokuoja prisijungimų ir neveikia kaip užkarda, tad tiesiogiai lankytojo iš svetainės neišmes. Užtat jis gali sustabdyti pašto siuntimą, o WordPress svetainėje būtent paštu grįžtama, kai nebegalite prisijungti. Viskas, kas išvardyta žemiau, yra tikras būdas sugadinti pristatymą arba prarasti duomenis, kartu su tuo, kas iš tikrųjų padeda atitaisyti. Perskaitykite bent pirmus du punktus: būtent jie atrodo visai ne tuo, kas yra.

• Optimized sending arba bet kokios siuntimo ribos įjungimas, kol SMTP Host laukas dar tuščias. Sprendimas kelti laišką į eilę priimamas anksčiau, nei kas nors patikrina serverio adresą, o nutrauktas siuntimas neleidžia WordPress grįžti prie PHP mail(). Todėl svetainė, kuri puikiai siuntė per PHP mail(), nustoja siųsti visiškai: eilės vykdytojas prašo ryšio, gauna "No SMTP host is configured", pakartoja keturis kartus ir maždaug po dviejų su puse valandos laišką pažymi galutinai nepavykusiu. Kartu žūva ir slaptažodžių atkūrimo laiškai, o už žurnalo ribų apie tai nepraneša niekas. Sprendimas: Settings lange grąžinkite visas ribas į 0, nuimkite varnelę nuo Optimized sending ir išsaugokite. Nauji laiškai iškart vėl keliauja per PHP mail(). Jau nepavykę įrašai yra atskira bėda, nes Re-send ir Forward visada reikalauja veikiančio SMTP ryšio: svetainėje, kuri jo niekada neturėjo, jie atsako "No SMTP connection is configured." ir nesiunčia nieko. Taigi arba įrašykite SMTP Host, sėkmingai praeikite Test Connection ir tik tada iš Email Log lango išsiųskite nepavykusius įrašus iš naujo, arba tuos įrašus nurašykite ir laiškus paleiskite iš naujo iš pirminio šaltinio: paprašykite naujo slaptažodžio atkūrimo laiško, o užsakymo laišką dar kartą išsiųskite iš WooCommerce. Jų turinys tebėra vietoje, jei Log message body įjungtas, o laiškas neviršijo 1 MB, tad pirma sutvarkyti SMTP ir pabandyti nieko nekainuoja.
• WordPress saugumo raktų ir druskų keitimas wp-config.php faile, kai SMTP slaptažodis laikomas duomenų bazėje. Slaptažodis šifruojamas AES-256-CTR algoritmu, kuris vientisumo netikrina, tad iššifravus jį nauju raktu klaidos nebūna: gaunama tiesiog kita eilutė. Įskiepis ją perduoda tikram SMTP serveriui, tas ją atmeta, ir žurnalas prisipildo įprastų autentifikacijos klaidų, dažniausiai 535 arba "Could not authenticate", o pokalbio įrašas rodo, kad ryšys užsimezgė, šifravimas suderintas ir pasiektas AUTH. Nei iššifravimas, nei saugumo raktai jame neminimi. Jei ką tik pakeitėte druskas ir staiga kiekvienas laiškas nepraeina autentifikacijos, priežastis yra būtent ši, kad ir kaip tvirtai pokalbio įrašas rodytų į tiekėją. Tuo pačiu metu nulūžta ir sekimas, tik ten tai matoma: kiekvienas jau pristatytų laiškų sekimo pikselis ir perrašyta nuoroda ima grąžinti 403, nes HMAC išvedamas iš to paties rakto. Sprendimas: atsiverskite Settings, iš naujo įveskite SMTP slaptažodį ir spustelėkite Save Settings, paskui tą patį padarykite kiekvienai Additional SMTP Connections eilutei ir spustelėkite Save Connections. MSMTP_SMTP_PASS apsaugo pagrindinį ryšį nuo kito raktų keitimo ir papildomiems nepadeda niekuo. Senų sekimo nuorodų atkurti nepavyks.
• Laiškų palikimas eilėje ilgiau nei septynioms dienoms. Kad ir kokia būtų priežastis, neveikiantis cron, išjungtas įskiepis ar niekaip neatsilaisvinanti siuntimo riba, praėjus septynioms dienoms po numatyto laiko laiškas pažymimas nepavykusiu su klaida "Expired in the queue before it could be delivered". Kai Log message body įjungtas, o turinys neviršija 1 MB, kopija lieka ir įrašą dar galima išsiųsti pakartotinai; kai turinio įrašymas išjungtas, tą akimirką turinys sunaikinamas ir laiško nebeatkursite. Dar blogiau: tas pats pravažiavimas, kuris naikina pasenusius eilės įrašus, kartu vykdo ir saugojimo laiko valymą, tad už saugojimo laiką senesnis eilės įrašas per vieną paleidimą ir pasibaigia, ir ištrinamas, nepalikdamas nieko. Vienintelė prevencija yra Tools, Process queue now dar nesuėjus savaitei.
• Per žema siuntimo riba. Ribos galioja kiekvienam laiškui, įskaitant slaptažodžių atkūrimą ir pranešimus apie naujus naudotojus, o ne tik masiniam paštui. Viskas, kas viršija ribą, keliauja į eilę, ir jei WP-Cron neveikia, ten ir lieka iki aukščiau minėto septynių dienų termino. Sprendimas: grąžinkite visas ribas į 0 ir išsaugokite, tada Tools, Process queue now. Jei prie wp-admin prieiti nebegalite, ištrinkite msmtp_settings parinktį: taip visi nustatymai grįžta į numatytuosius, o kartu išjungiamos ir visos ribos.
• Optimized sending įjungimas be tikro cron darbo. Kiekvienas laiškas patenka į eilę ir iš svetainės neiškeliauja niekas. Požymis – augantis Queued rodinys Email Log lange be jokių klaidų. Sprendimas: nuimkite varnelę nuo Optimized sending ir išsaugokite, tada spustelėkite Tools, Process queue now. Vienas paspaudimas išsiunčia vieną dvidešimties laiškų paketą, tad spauskite jį tiek kartų, kiek reikia; o jei laukia šimtai laiškų, pirma sutvarkykite tikrą sistemos cron ir tik tada bandykite dar kartą.
• Įskiepio išjungimas, kai eilė netuščia. Išjungiant panaikinami abu cron įvykiai toje svetainėje, kurioje išjungiama, tad joje eilėje likę laiškai sustoja; išjungus įskiepį visame tinkle, kiekvienoje kitoje svetainėje abu įvykiai lieka suplanuoti, nors į juos nieko nebeatsiliepia, ir jos eilė sustoja lygiai taip pat. Sprendimas: aktyvuokite iš naujo, tada abu įvykiai vėl suplanuojami, ir paleiskite eilę iš Tools lango, bet tik jei tai padarysite per aukščiau minėtą septynių dienų langą. O jei įskiepį "išjungėte" per SFTP pervadindami jo aplanką, WordPress išjungimo kabliuko apskritai nepaleidžia: abu įvykiai lieka tvarkaraštyje, nors į juos nieko nebeatsiliepia, o eilėje esantys laiškai toliau sensta iki galiojimo pabaigos.
• Sekimo įjungimas svetainėje, kurią prižiūri vienas ar du administratoriai. Tada kiekvienas svetainės siunčiamas HTML laiškas, taip pat slaptažodžio atkūrimo ir prisijungimo laiškai, iškeliauja su nuorodomis, vedančiomis per pačią svetainę. Jei druskos pakeistos, tokios nuorodos atsako 403; jei svetainė neveikia arba jos nebėra, jos neatsako išvis. Bet kuriuo atveju jau jūsų dėžutėje gulintis laiškas atgal neįleis. Atsistatoma tik per WP-CLI arba tiesiogiai pakeitus slaptažodį duomenų bazėje. Jau išsiųstos nuorodos lieka sugedusios.
• Saugojimo laiko trumpinimas. Kasdienis valymas visam laikui ištrina už nustatytą laiką senesnius įrašus: be atšaukimo ir be išankstinio eksporto. Sutrumpinus 30 dienų iki 1, per artimiausią kasdienį paleidimą dings beveik visas žurnalas. Purge old logs now padaro tą patį iš karto. Kartu tyliai susilpninamos ir siuntimo ribos: skaitiklis skaičiuoja tik žurnale dar esančius išsiųstus laiškus, tad už saugojimo laiką ilgesnis langas savo istorijos niekada nepamatys. Septynių dienų saugojimo laikas su 5000 laiškų mėnesio riba reiškia, kad mėnesio riba mato daugiausiai septynių dienų siuntimą ir tiekėjo paskyros nebesaugo gerokai anksčiau, nei būna pasiekta. Saugojimo laiką laikykite bent tokį, koks yra ilgiausias jūsų siuntimo ribos langas.
• Žurnalo įrašų trynimas. Eilutės veiksmas Delete ir grupinis Delete iš karto pašalina laišką ir jo įvykių istoriją iš duomenų bazės.
• Grupinis Re-send. Tikri laiškai vėl iškeliauja pradiniams gavėjams, iki dviejų šimtų vienoje užklausoje, be jokio atšaukimo, o užklausa, kuri nutrūksta viduryje, viską iki to momento jau yra pristačiusi.
• Papildomo ryšio Host lauko ištuštinimas arba eilutės pašalinimas prieš išsaugant. Ryšys dingsta, o į jį rodančios nukreipimo taisyklės tyliai ignoruojamos, tad jų laiškai nepastebimai persikelia į pagrindinį serverį. Niekas apie tai neįspėja.
• Įjungtas duomenų trynimas šalinant įskiepį, o paskui įskiepio ištrynimas. Abi lentelės išmetamos, visos parinktys pašalinamos. Žurnalą grąžins tik duomenų bazės atsarginė kopija.

Skubus atkūrimas be wp-admin

Jei paštas sustojo, o į wp-admin patekti negalite, dirbkite per komandinę eilutę arba SFTP. Įskiepis savo WP-CLI komandų neturi, tad žemiau pateiktos komandos yra įprastas WP-CLI, veikiantis su jo naudojamais parinkčių pavadinimais ir cron kabliukais. Iš viso jis rašo penkias parinktis: msmtp_settings, msmtp_connections, msmtp_routing_rules, msmtp_db_version ir, trumpam schemos atnaujinimo metu, msmtp_upgrade_lock; žemiau esantis blokas liečia tris iš jų. msmtp_settings ištrynimas tikrai saugus: kitos užklausos metu įskiepis ją atkuria iš numatytųjų reikšmių, o kartu išjungiamos visos siuntimo ribos, Optimized sending ir sekimas, o turinio įrašymas grąžinamas. Prarandate konfigūraciją, o ne lenteles ar žurnalą. msmtp_connections ištrynimas jau ne toks. Tai vienintelė vieta, kur saugomas ir pagrindinis, ir kiekvienas papildomas ryšys, tad kartu dingsta serverių adresai, vartotojų vardai ir užšifruoti slaptažodžiai, o kiekvieną iš jų teks suvesti iš naujo; į nebeegzistuojantį ryšį rodančios nukreipimo taisyklės siunčiant tyliai praleidžiamos. Be to, jei wp-config.php faile apibrėžta MSMTP_SMTP_HOST, paštas prie PHP mail() vis tiek negrįš, nes ta konstanta vėl uždedama ant pagrindinio ryšio jau kitos užklausos metu; slaptažodžiai sunaikinami bet kuriuo atveju. Jei neturite ir komandinės eilutės, per SFTP pervadinkite įskiepio aplanką: WordPress išjungia įskiepį, kurio failas dingo, ir paštas grįžta prie PHP mail(). Duomenys lieka nepaliesti, bet išjungimo kabliukas nepasileidžia, tad msmtp_process_queue ir msmtp_purge_logs lieka suplanuoti kabliukui, į kurį niekas nebeatsiliepia, o eilėje esantys laiškai toliau artėja prie septynių dienų galiojimo pabaigos. Pervadinkite aplanką atgal ir per savaitę paleiskite Tools, Process queue now.

# Reset every M SMTP setting to its shipped default
# (turns off all rate limits, Optimized sending and tracking)
wp option delete msmtp_settings

# WARNING: this also destroys every stored SMTP password,
# for the primary connection and for all additional ones.
# It does NOT restore PHP mail() if MSMTP_SMTP_HOST is defined:
# the constant puts the host straight back on the next request.
wp option delete msmtp_connections

# Drop all conditional routing rules
wp option delete msmtp_routing_rules

# Send ONE batch of 20 from the queue, right now
# (run it again for the next 20)
wp cron event run msmtp_process_queue

# Turn the plugin off completely; wp_mail() reverts to PHP mail()
wp plugin deactivate m-smtp

# No shell? Rename the folder over SFTP and WordPress deactivates it
# (silently: the deactivation hook does NOT run, cron events stay):
#   wp-content/plugins/m-smtp  ->  wp-content/plugins/m-smtp.off

Trikčių šalinimas

Beveik visi pranešimai apie triktis susiveda į vieną iš žemiau išvardytų dalykų. Pradėkite nuo Email Log: būsenos stulpelis, klaida po nepavykusia eilute ir SMTP pokalbio įrašas išsamiame rodinyje priežastį dažniausiai įvardija tiesiai šviesiai. Vienintelis atvejis, kai žurnalas rodo ne ta kryptimi, yra druskų pakeitimas, tad jam skirtas atskiras punktas.

• Geltonas pranešimas skelbia, kad M SMTP dar nesukonfigūruotas. SMTP Host laukas tuščias, o WordPress vis dar naudoja PHP mail(). Įrašykite serverio adresą ir, kol to nepadarėte, nežymėkite Optimized sending ir nenustatykite jokios siuntimo ribos.
• Nepavyksta Test Connection. Beveik visada nesutampa prievadas ir šifravimas: 465 reikia SSL, 587 ir 2525 reikia TLS, 25 reikia None ir jį daugelis serverių šiaip ar taip blokuoja. Pokalbio įraše matyti, kiek toli nuėjo bendravimas.
• Staiga visi laiškai nepavyksta su SMTP autentifikacijos klaida, dažniausiai 535 arba "Could not authenticate", o pokalbio įrašas pasiekia AUTH. Jei tiekėjo pusėje niekas nepasikeitė, pasikeitė druskos wp-config.php faile. Išsaugotas slaptažodis dabar iššifruojamas į kitą reikšmę ir tokia nusiunčiamas, o jokios iššifravimo klaidos niekur nėra. Iš naujo įveskite SMTP slaptažodį Settings lange ir kiekvienam papildomam ryšiui, tada išsaugokite. Apibrėžkite MSMTP_SMTP_PASS, kad pagrindinis ryšys atlaikytų kitą raktų keitimą.
• Laiškas nepavyksta su klaida, kurioje minimas išsaugotas slaptažodis ir iššifravimas. Tai sugadinta ar nukirpta išsaugota reikšmė arba iš serverio dingęs OpenSSL po to, kai slaptažodis buvo užšifruotas. Druskų pakeitimas atrodo kitaip. Įveskite slaptažodį iš naujo.
• Laiškai lieka Queued būsenoje ir nejuda. Neveikia WP-Cron. Spustelėkite Tools, Process queue now ir įsitikinkite, kad jie išsiunčiami, o paskui sutvarkykite tikrą cron darbą.
• Eilėje esantys laiškai nepavyksta su klaida "No SMTP host is configured". Optimized sending arba siuntimo riba nustūmė juos į eilę, kol SMTP Host dar buvo tuščias. Grąžinus visas ribas į 0 ir nuėmus varnelę nuo Optimized sending, nauji laiškai vėl keliauja per PHP mail(), bet nepavykusių įrašų tai negrąžina: Re-send ir Forward visada reikalauja veikiančio SMTP ryšio ir, kol serverio laukas tuščias, atsako "No SMTP connection is configured.". Norėdami atkurti tuos įrašus, pirma įrašykite serverio adresą ir sėkmingai praeikite Test Connection; kitu atveju laiškus paleiskite iš naujo iš pirminio šaltinio.
• Laiškai iškeliauja iš karto, nors Optimized sending įjungtas. Jie turi priedų arba jų turinys viršija 4 MB. Abu atvejai eilę aplenkia sąmoningai.
• Pristatytas laiškas atkeliavo be priedo. Eilės vykdymo metu failo diske jau nebebuvo. Laiškas vis tiek išsiųstas, o įrašo būsena tebėra Sent; vienintelis pėdsakas yra viena eilutė išsamaus rodinio laiko juostoje. Peržiūrėkite kiekvieno per eilę ėjusio laiško su priedais laiko juostą.
• Persiųsto laiško nėra nei žurnale, nei Reports lange. Ir nebus. Forward savo įrašo nesukuria, tik Forwarded įrašą pradinio laiško laiko juostoje, ir siuntimo ribų skaitiklis jo taip pat neskaičiuoja.
• Nėra Re-send mygtuko. Išsaugota kopija nepilna: siunčiant turinio įrašymas buvo išjungtas, turinys viršijo 1 MB saugojimo ribą arba eilutės būsena šiuo metu yra Queued ar Sending.
• Eilutė pažymėta klaida "Send was intercepted by another plugin". Kitas pašto įskiepis nutraukė siuntimą anksčiau, nei M SMTP spėjo jį perduoti SMTP serveriui. Išjunkite tą kitą įskiepį.
• Eilutė pažymėta klaida "Delivery status unknown". Užklausa nutrūko tarp laiško įrašymo ir siuntėjo atsakymo, o eilutė daugiau nei 15 minučių išbuvo Sending būsenoje. Ar laiškas pasiekė gavėją, iš žurnalo nustatyti neįmanoma.
• Reports rodo 0 procentų atidarymų. Sekimas išjungtas, laiškai yra paprastas tekstas, nuorodos buvo ne tokio pavidalo, kokį atpažįsta perrašymas, arba gavėjų programos blokuoja nutolusius paveikslėlius, o tai įprasta.
• Pranešimas sako, kad OpenSSL nepasiekiamas. Slaptažodį galima tik užmaskuoti, o ne užšifruoti. Perkelkite jį į MSMTP_SMTP_PASS.

Privatumas ir kas saugoma

M SMTP neužmezga jokių išorinių ryšių, išskyrus su jūsų nurodytu SMTP serveriu. Jokių išorinių paslaugų, licencijų tikrinimo ar analitikos nėra. Viskas, ką jis žino, guli jūsų pačių duomenų bazėje. Lentelėje wp_msmtp_emails apie kiekvieną laišką saugoma: gavėjai, įskaitant CC ir BCC, Reply-To, siuntėjas, tema, laiško turinys, kai turinio įrašymas įjungtas, papildomos antraštės, priedų pavadinimai, keliai ir dydžiai (patys failai niekada nekopijuojami), pristatymo būsena ir klaida, paskutinio nesėkmingo bandymo SMTP pokalbis, laišką siuntęs įskiepis ar tema ir sukūrimo, išsiuntimo, atidarymo bei paspaudimo laikai. Lentelėje wp_msmtp_events saugoma įvykių juosta: queued, attempt, sent, failed, resent, forwarded, open ir click kartu su paspaustos nuorodos adresu. Pokalbio įraše sąmoningai niekada nebūna nei laiško turinio, nei autentifikacijos apsikeitimo.

• Į wp_options įrašomos parinktys: msmtp_settings, msmtp_connections, msmtp_routing_rules, msmtp_db_version ir, trumpam schemos atnaujinimo metu, msmtp_upgrade_lock. Vienas laikinasis įrašas, msmtp_plugin_names, valandai išsaugo įskiepių pavadinimus.
• SMTP slaptažodis saugomas užšifruotas AES-256-CTR algoritmu. Apibrėžus MSMTP_SMTP_PASS, jis apskritai nepatenka į duomenų bazę: tai rekomenduojama tvarka bet kurioje svetainėje, kurios duomenų bazė kopijuojama į išorę. Ji apima tik pagrindinį ryšį.
• Kai sekimas įjungtas, prie kiekvieno atidarymo ir paspaudimo įrašoma gavėjo user agent eilutė. IP adresas įrašomas tik papildomai pažymėjus IP parinktį, kuri numatytai išjungta.
• Numatytasis saugojimo laikas – 30 dienų, po jų pristatyti ir nepavykę įrašai bei jų įvykiai ištrinami. Eilėje laukiantiems laiškams saugojimo laikas netaikomas, kol nesibaigia jų galiojimas: tada jie tampa nepavykusiais įrašais ir jiems galioja tos pačios taisyklės kaip ir visiems kitiems.
• Persiųstas laiškas palieka tik Forwarded įvykį pradiniame įraše. Jokio atskiro įrašo apie tai, kam jis iškeliavo, be to įvykio detalės nėra.
• Būtent laiškų turinys žurnalą daro jautrų. Visa kita yra metaduomenys; turinyje gali būti atkūrimo nuorodų, sąskaitų ir asmens duomenų.

Pašalinimas

Išjungimas ir ištrynimas čia yra du skirtingi dalykai. Išjungus panaikinami abu suplanuoti įvykiai, msmtp_process_queue ir msmtp_purge_logs, ir įskiepis nustoja liesti wp_mail(), tad WordPress iškart grįžta prie PHP mail(). Svetainių tinkle tas panaikinimas pasiekia tik tą svetainę, kurioje vykdomas: aktyvavimas apeina visas tinklo svetaines, o išjungimas ne, tad išjungus įskiepį visame tinkle abu įvykiai lieka suplanuoti kiekvienoje kitoje svetainėje, nors į juos nieko nebeatsiliepia, lygiai kaip 12 skyriuje aprašytu aplanko pervadinimo atveju. Lentelės, žurnalas, nustatymai ir ryšiai lieka tiksliai ten, kur buvo, o vėl aktyvavus viskas tęsiasi nuo tos pačios vietos, tik nepamirškite 12 skyriuje minėto septynių dienų eilės termino. Ištrynus įskiepį iš Plugins lango, paleidžiama pašalinimo procedūra, o ką ji padarys, priklauso vien nuo vieno žymimojo langelio: Settings, Uninstall, "Delete all settings and email logs when the plugin is uninstalled", kuris numatytai nepažymėtas. Jei jis nepažymėtas, ištrinami tik failai, o visos lentelės ir parinktys lieka, tad vėliau įdiegus iš naujo senas žurnalas randamas nepaliestas. Jei pažymėtas, abi lentelės išmetamos, penkios parinktys ir laikinasis įrašas ištrinami, o abu cron įvykiai panaikinami. Svetainių tinkle pašalinimo procedūra vykdoma kiekvienai tinklo svetainei, o langelio reikšmė kiekvienai jų nuskaitoma atskirai.

Automatiniai atnaujinimai

Įskiepis tikrina majevski.com dėl naujų versijų ir siūlo jas per įprastą WordPress atnaujinimų langą — tas pats pranešimas, keitimų sąrašas ir diegimas vienu paspaudimu kaip ir bet kurio kito įskiepio. Tikrinimai talpinami podėlyje, niekada nelėtina puslapių ir veikia saugiai: jei majevski.com nepasiekiamas, svetainė tiesiog dirba toliau ir pabando vėliau. Atnaujinimo paketas priimamas tik iš majevski.com per HTTPS, o senesnė versija niekada nesiūloma. Versijos iki 1.1.0 atnaujinimų kanalo dar nepažįsta, todėl naujų leidimų nemato — vieną kartą rankiniu būdu įdiekite 1.1.0 ar naujesnę, ir visi vėlesni leidimai atkeliaus savaime.