" SMTP aikakatkaisu" voi kuvata useita erilaisia tapahtumia. DNS kysely on saattanut aikakatkaista, TCP-yhteyttä ei ole ehkä valmistunut tai muodostettu yhteys on saattanut odottaa liian kauan tervehdys- tai lopullista vastausta. Näillä vaiheilla on erilainen näyttö ja erilaiset päällekkäistoimituksen riskit. Tunnista vaihe ennen korjauksen valitsemista.
Selvitä kohde ennen sen testaamista
Tallenna vastaanottajan toimialue ja tosiasiallisesti käytetty MX vastaus, mukaan lukien asetusarvot ja hakuaika. RFC 5321 kuvaa MX -valinnan ja osoitteen resoluution, mukaan lukien implisiittisen MX käyttäytymisen, kun ei MX tietueita olemassa. Kun toimialue on olemassa, mutta sillä ei ole MX tietueita, implisiittinen MX käsittely käyttää itse toimialuetta soveltuvien osoitetietueiden kanssa; NXDOMAIN ja väliaikaiset DNS virheet ovat erilaisia tuloksia. Tämä eroaa eksplisiittisestä nolla MX -ilmoituksesta, joka ilmaisee, että toimialue ei hyväksy RFC 7505 -sähköpostia. Älä muunna jokaista epätavallista DNS tulosta arvatuksi määränpääksi. RFC 5321 § 5.
Säilytä kunkin valitun isännän osuvat osoiteperhetulokset ja yhteyden tulos. Onnistunut IPv4 testi ei varmista, että epäonnistuneen lähettäjän IPv6 polku toimii. Samoin toimiva julkinen ratkaisutulos ei todista sitä, mitä tietty lähetysjärjestelmä näki aiemmin. Tallenna DNS virheet erillään onnistuneista vastauksista, jotka osoittavat tavoittamattomiin isäntiin.
Erottele kieltäytyminen hiljaisuudesta
Yhteyden epääminen tarkoittaa yleensä TCP-yhteysyrityksen nimenomaista hylkäämistä. Aikakatkaisu tarkoittaa, että odotettua tapahtumaa ei havaittu sallitulla aikavälillä. Kumpikaan havainto ei yksin tunnista vastuullista palomuuria, palvelun omistajaa tai reittiä. Suodatus, verkkovirheet, kuuntelijan saatavuus ja muut olosuhteet voivat aiheuttaa samanlaisia käyttäjälle näkyviä oireita.
Kun TCP on onnistunut, pane merkille, lähettikö palvelin SMTP tervehdyksen. Tunnista sitten tarkka komento, joka odottaa vastausta. RFC 5321 määrittää erilliset aikakatkaisuohjeet useille SMTP vaiheille. Käyttäjän lyhyt diagnostinen aikakatkaisu on testausvalinta, ei todiste tuotannosta MTA rikkoo tai täyttää näitä vaatimuksia. Älä käytä yhtä aggressiivista aikakatkaisua jokaisessa vaiheessa ja kutsu tulosta lopulliseksi.
Säilytä epävarmuus viestin siirron jälkeen
Aikakatkaisu viimeisen viestin datan jälkeen on herkempi kuin yhteyden epäonnistuminen. Vastaanottaja saattoi ottaa vastuun, vaikka sen lopullinen vastaus katosi. Tapahtuman toistaminen voi siis tuottaa kaksoiskappaleen. Pidä lopullisen vastauksen tila tuntemattomana, ellei todisteiden lähettäminen ja vastaanottaminen ratkaise sitä; Älä merkitse viestiin automaattisesti "ei koskaan vastaanotettu". RFC 5321 kohdat 4.5.3.2 ja 6.1.
Jos yhteys epäonnistuu ennen SMTP vaihtoa, viestiä ei ole siirretty kyseisessä yhteydessä. Tämä suppeampi johtopäätös ei vieläkään kuvaa aiempia yrityksiä samassa jonossa. Korreloi kaikki yritykset, ennen kuin päätät, tarvitseeko liiketapahtuma uuden lähetyksen.
Vertaa kolmea hypoteettista aikakatkaisutietuetta
Tapaus A ei koskaan muodosta TCP:tä valittuun MX . Pidä diagnoosi yhteysvaiheessa; Mikään SMTP viesti ei mennyt kyseisen yhteyden yli. Tapaus B muodostaa TCP:n, mutta ei tallenna 220-tervehdystä ennen diagnostiikkatyökalun valitsemaa määräaikaa. Tutki kuuntelijan käyttäytymistä ja asiaankuuluvaa tervehdyksen aikakatkaisua sen sijaan, että kutsuisit sitä samaksi epäonnistumiseksi kuin A.
Tapaus C lähettää viestidatan ja sen päätteen, mutta menettää lopullisen vastauksen. Hyväksymistä ei tunneta, joten tarkista lähettäjän jono ja vastaanottajan todisteet ennen uuden kopion lisäämistä. Nämä keksityt tapaukset eivät sisällä suoritettuja socket-testejä, mitattua palautusta tai palveluntarjoajan ajoitusvaatimusta. Lyhyt diagnoosiaikakatkaisu ei ole tuotantosuositus.
Jos kyseessä on todellinen unavailable-MX-tapahtuma, säilytä ratkaistut isännät ja asetukset, jokainen osoiteperheyritys, epäonnistunut vaihe ja jonopäätös. Alemman prioriteetin MX joka toimii itsenäisessä testissä, ei osoita, että lähettäjä käytti sitä. tarkista todellinen yrityshistoria.
Korjaa ja vahvista viallinen polku
Määritä DNS , verkko- ja sähköpostipalvelun todisteet omistajilleen. Testaa sama hyväksytty kohde ja osoiteperhe uudelleen yhden asianmukaisen korjauksen jälkeen ja säilytä vertailu toisesta valtuutetusta verkosta vain, jos se on hyödyllistä. Vahvista jonon palautus- ja ikääntymisviestit ennen onnistumisen ilmoittamista. Älä heikennä sähköpostin todennusta, koska TCP-istuntoa ei voitu muodostaa.
Valitse epäonnistuneen vaiheen omistaja
- DNS virhe: Säilytä varsinainen ratkaisutulos ja aika.
- TCP-virhe: tallenna kohde, osoiteperhe ja polku todisteet.
- Tervehdys tai komento odota: nimeä puuttuva vastaus ja määritetty aikakatkaisu.
- Lopullinen DATA-vastaus puuttuu: sovita hyväksyntä ennen manuaalista uudelleenlähetystä.
- Palautus: ota huomioon vanhentuneet ja vanhentuneet jonokohdat, ei vain yksi onnistunut yhteys.