MX įrašai:
ar jūsų pašto serveris atsako?

Įveskite domeną viršuje. Užklausiame jo MX įrašus, surikiuojame pagal prioritetą, kiekvieną serverio vardą išsprendžiame į IPv4 ir IPv6, prie kiekvieno adreso pasukame FCrDNS ratą, pagal šabloną atpažįstame pašto teikėją ir tada iš savo tikrinimo taškų tinklo prisijungiame prie kiekvieno serverio 25 prievade — perskaitome SMTP pasisveikinimą ir išbandome STARTTLS. Nemokamai, be registracijos, viskas per kelias sekundes.

Mažesnis skaičius = bandomas pirmiau. Siuntėjai leidžiasi sąrašu žemyn tik tada, kai geresnio prioriteto serveriai neatsako. Vienodi prioritetai nėra klaida — tai darbo paskirstymas ratu, ir stambūs teikėjai jį naudoja (klasikiniame Google rinkinyje du serveriai turi 5, dar du — 10). Kelių pakopų schemoje problema ne skaičiai — atsarginėje pakopoje sukasi senesnė programinė įranga ir laisvesnis filtravimas, todėl būtent į ją taikosi šlamšto siuntėjai.

Forward-confirmed reverse DNS: jūsų pašto serverio IP privalo turėti PTR įrašą, o to PTR vardas privalo išsispręsti atgal į tą patį IP. Tai pigus įrodymas, kad tas, kas valdo IP, valdo ir vardą — šlamšto siuntyklos užgrobtuose adresų blokuose to paprastai padaryti negali. Google siuntėjų taisyklėse galiojantis ir sutampantis PTR yra privalomas reikalavimas pristatant į Gmail, o dauguma filtrų jį vertina. Ir prieš nurašydami tai prie “tik išsiunčiamų laiškų”: jūsų MX serveris taip pat siunčia — kiekvieną atmetimo pranešimą, kiekvieną automatinį atsakymą, kiekvieną persiuntimą. Neužsidarantis ratas gaunančiame serveryje tyliai kenkia visiems tiems laiškams.

Vienintelis MX įrašas su 0 prioritetu ir DNS šaknimi vietoj serverio — 0 . — apibrėžtas RFC 7505. Tai standartinis būdas pasakyti “šis domenas laiškų nepriima.” Siuntėjai jį pamato ir per kelias sekundes grąžina galutinį atmetimo pranešimą, užuot griebęsi numanomo MX taisyklės ir dienų dienas daužę jūsų svetainės serverį pakartotiniais bandymais. Tai teisingas įrašas užparkuotiems ir tik svetainę turintiems domenams — kartu su v=spf1 -all ir DMARC reject politika, kad niekas negalėtų siųsti domeno vardu.

Kad ir kaip keista — taip. RFC 5321 numanomo MX taisyklė sako: kai MX nėra, siuntėjai domeno A/AAAA įrašą laiko MX įrašu su 0 prioritetu — taigi laiškas pristatomas ten, kas atsako jūsų svetainės serverio IP adresu. Jei tame serveryje atsitiktinai sukasi MTA, laiškai keliauja; žmonės su šiuo nesusipratimu metų metus laiko tikrą darbinį paštą. Tai trapu — perkelsite svetainę, neteksite laiškų — ir retai kada daroma sąmoningai. Tikram paštui paskelbkite aiškius MX įrašus, o jei pašto nereikia — 0 ..

Ne — ir tai dažnas nesusipratimas. MX atsako į klausimą, kur keliauja laiškai, siunčiami šiam domenui; jūsų išsiunčiamų laiškų reputacija glūdi siunčiančiame IP, SPF, DKIM ir DMARC įrašuose, kuriuos po vieną įvertina gretimi mūsų įrankiai. Dvi išimtys: jei serverį laikote pas save, MX serveris ir yra siunčiantis serveris, todėl jo FCrDNS ir TLS tvarka svarbi dvigubai; be to, kai kurie gaunantieji serveriai pasitikrina, ar laiškus siunčiantis domenas geba juos ir priimti — netvarkingas MX rinkinys šios patikros tyliai neišlaiko.

Tikrinimo taškas atveria TCP ryšį su kiekvienu MX serveriu 25 prievade, perskaito pasisveikinimo eilutę, siunčia EHLO ir patikrina, ar siūlomas STARTTLS — tada jį suderina ir užsirašo TLS versiją bei sertifikatą. Laiškų jis nesiunčia: pokalbis nutrūksta prieš MAIL FROM. Iš namų ryšio to nepadarysite, nes namų interneto tiekėjai blokuoja išeinantį 25 prievadą, kovodami su botnetų šlamštu. Vieną dalyką verta žinoti: STARTTLS 25 prievade yra neprivalomas — ryšio kelyje esantis užpuolikas gali pasiūlymą tiesiog nutrinti. Spyna yra MTA-STS; o mūsų TLS versijų tikrintuvas pereina visas protokolo versijas, kuriomis jūsų serveris sutinka kalbėti.