Käsittele luetteloa toisena lähetysvaiheena
Simplelists-viestissä on vähintään kaksi asiaankuuluvaa vaihetta: jäsen lähettää viestin, jonka jälkeen luettelo jakaa sen uudelleen. Alkuperäisessä lähetyksessä toiminut todennus ei välttämättä kuvaa jäsenille toimitettua kopiota. Tämä opas käsittelee dokumentoitujen Multiple List -tilien mukautettuja verkkotunnuksia ja uudelleen jaettujen viestien toimintaa. Se ei oleta, että jokainen tilityyppi, luetteloasetus tai alkuperäinen lähettäjä käyttää samaa identiteettiä.
Aloita valitsemalla liiketoiminnan lopputulos. Ilmoituslista voi johdonmukaisesti edustaa organisaatiota. Keskusteluluettelossa on ehkä näytettävä eri jäseniä ja ohjattava vastauksia asianmukaisesti. Kirjaa ylös, mitä käyttäytymistä ihmiset odottavat, ennen kuin muutat lähettäjän uudelleenkirjoitusta. Muuten teknisesti onnistunut muutos voi tehdä keskusteluista hämmentäviä tai paljastaa yksityiskohtia anonyymin listan, joka on tarkoitus piilottaa.
Määritä toimialueen ja saapuvan liikenteen reititysraja
Simplelists oman verkkotunnuksen opas kuvataan verkkotunnuksen lisäämistä Yleisten asetusten ja sitten Verkkotunnusten kautta Multiple List -tilissä, sen asettamista ensisijaiseksi ja tuloksena olevien luetteloosoitteiden tarkistamista. Tämä on palveluntarjoajan vuoden 2017 asetusartikkeli, joten vahvista nykyisen tilin ohjaimet ennen kuin käytät sen navigointia. Se myös ohjaa järjestelmänvalvojat tiliin SPF ja DKIM tiedot. Hae arvot oikealta tililtä ja toimialueelta julkisen esimerkin kopioimisen sijaan.
Sama opas nimeä mx1.simplelists.com ja mx2.simplelists.com ensisijaiselle ja toissijaiselle saapuvalle MX lle, ja varoittaa, että muutokset voivat kestää jopa 72 tuntia. Vahvista nykyisen tilin ohjeet ja välimuistin todellinen tila sen sijaan, että käsittelet kulunutta aikaa hyväksymisenä. Käsittele sitä saapuvan reitityspäätöksenä. Jos organisaatio vastaanottaa jo työntekijöiden postia juuriverkkotunnuksessaan, korvaa ne MX tietueita voi vaikuttaa paljon enemmän kuin luettelo. Päätä, onko oma luettelon aliverkkotunnus sopiva, tunnista nykyinen postin omistaja ja tallenna hyväksytty reititysalue ennen julkaisemista.
Säilytä saapuvan reitityksen ja lähtevän todennus erillisillä laskentataulukon riveillä. Viestin onnistunut toimittaminen luetteloon ei tarkoita sitä, että siitä lähetetyt kopiot todistuisivat. Toisaalta DKIM ongelma ei sinänsä oikeuta yrityksen saapuvan postin siirtämistä.
Hanki ja tarkista tilille myönnetyt tietueet
Tallenna jokaisen julkaistun tietueen koko tietueen omistaja, tyyppi, julkinen arvo ja tarkoitettu verkkotunnus. Vertaa ehdotettua omistajaa olemassa oleviin DNS tietoihin välttääksesi valitsin törmäyksiä tai päällekkäistä verkkotunnuksen päätettä. Tarkista muutokset arvovaltaisella vyöhykkeellä, ei pelkästään rekisteröijän tilillä, jos toinen palveluntarjoaja isännöi DNS .
Jos kyseessä on SPF , säilytä muut lailliset lähettäjät samassa verkkotunnuksessa. RFC 7208 määrittää kuinka monta SPF tietueita ja DNS-riippuvaisia termejä käsitellään. Tarkista täydellinen käytäntö ja sisäkkäiset hakukustannukset ennen lisäpalvelun valtuuttamista. Älä luo kilpailevaa SPF käytäntöä, koska asennusnäytössä näkyy erillinen esimerkki.
Jos kyseessä on DKIM , vertaa annettua valitsinta ja julkista tietuetta valvotun luettelosanomassa luotuun allekirjoitukseen. RFC 6376 määrittää d=- ja s=-kentät. Julkaistu avain on hyödyllinen vain, kun varsinaisessa viestissä on vastaava kelvollinen allekirjoitus. Säilytä jokainen havaittu allekirjoitus, mukaan lukien kaikki alkuperäiset jäsenen allekirjoitukset, todistepaketissa.
Päätä, kuinka ulkoisten jäsenten identiteettejä käsitellään
Yksinkertaisten DMARC selitys erottaa tilin toimialueelta lähettämisen toisesta verkkotunnuksesta peräisin olevan postin uudelleenjakamisesta. Se kuvaa ehdollista uudelleenkirjoitusta ulkopuolisille verkkotunnuksille. Sen ominaisuusopas dokumentoi myös mahdollisuuden kirjoittaa uudelleen johdonmukaisesti ja ohjaimet alkuperäisen lähettäjän tietojen näyttämiseksi.
Nämä vaihtoehdot ansaitsevat ihmisen päätöksen. Toimikunta voi asettaa etusijalle vakaan luetteloosoitteen; keskusteluryhmä voi asettaa osallistujan tunnustamisen etusijalle. Tallenna valittu Lähettäjä-näyttö- ja vastauskohde ja tarkista sitten molemmat toimitetusta kopiosta. Jos nimettömyydellä on merkitystä, tarkista myös tekstiosa ja lainattu viestiketju. Yhden otsikon piilottaminen ei voi poistaa jäsenen allekirjoituslohkoa tai aiemmin lainattua osoitetta.
Älä oleta, että luettelo voi allekirjoittaa ulkopuolisen jäsenen verkkotunnuksena. Tunnista lopullinen näkyvä From-toimialue ja sitä tukeva todennuspolku. Säilytä odotettu keskustelukäyttäytyminen tutkiessasi mahdollisia ristiriitoja sen sijaan, että muutat useita asetuksia kerralla.
Sisällytä sisällön muutokset testisuunnitelmaan
Alatunniste, otsikon lisäys tai aiheen etuliite voivat vaikuttaa alkuperäiseen allekirjoitukseen sen mukaan, mikä on allekirjoitettu. Yksinkertaiset toimituksen vianmääritysopas käsittelee näitä muutoksia tutkiessaan epäiltyä huijauksen hylkäämistä. Siinä lukee myös kirjekuoren lähettäjä on yleensä luetteloosoite ja osoittaa vastaanottajan ja palvelimen tiedot sähköpostin toimitusnäkymään.
Rakenna pieni matriisi: organisaation lähettäjä, ulkopuolinen lähettäjä, jolla on tiukka käytäntö, ja todelliset luettelon muokkausasetukset. Lisää tiivistelmä tai muita erillisiä toimitustapoja vain, jos organisaatio käyttää niitä ja tili tukee niitä. Jokaisen rivin tulee edustaa todellista työnkulkua, ei teoreettista ominaisuuksien tarkistuslistaa.
Käytä vaarattomia viestejä ja valvottuja vastaanottajia. Säilytä lähetysaika ja viestin tunniste, jotta luetteloloki voidaan yhdistää vastaanotettuun kopioon. Testaa ulkoista vastaanotinta sekä organisaation omaa yhdyskäytävää, kun molemmat ovat tärkeitä. Sisäinen hyväksyntä voi riippua paikallisesta poikkeuksesta, jota ulkoiset jäsenet eivät jaa.
Kirjaa lopullinen identiteetti ja tulos
Tallenna jokaiselle toimitetulle kopiolle näkyvä Lähettäjä, Vastaanottaja, kirjekuoren verkkotunnus, kaikki DKIM d=- ja s= -parit sekä luotettavan vastaanottajan SPF , DKIM ja DMARC tuloksia. Säilytä alkuperäisen viestin tulos erikseen. Nämä kaksi vaihetta vastaavat eri kysymyksiin, eivätkä ne saa ylikirjoittaa toisiaan testitietueessa.
RFC 9989 määrittelee DMARC linjaus. Tunnista välitysmekanismi ja sitä tukeva verkkotunnussuhde. Palveluntarjoajan ja verkkotunnuksen passi, joka ei liity lopulliseen Lähettäjä-verkkotunnukseen, ei luo tätä suhdetta. Uudelleenkirjoitettu Lähettäjä-osoite voi muuttaa asiaankuuluvaa vertailua, minkä vuoksi lopullisen kopion tarkastaminen on välttämätöntä.
Jos vastaanottava palvelin hylkää viestin, säilytä sen tarkka diagnostiikkateksti. Jos se hyväksyy viestin, mutta vastaanottaja ei löydä sitä, jatka toimitustutkimusta olettamatta DNS virhettä. Vältä laajaa sallittujen luetteloa alkuperäisenä korvikkeena todennuksen tuloksen tunnistamiselle.
Käytä luettelon uudelleenjakolaskentataulukkoa
Simplelists-reitin ja lähettäjän käyttäytymisen laskentataulukko (luo erillinen tarkistustietue tässä kuvatuilla kentillä) tallentaa saapuvan luettelon toimialueen, alkuperäisen julisteluokan, uudelleenkirjoituspäätöksen, sisällön muutokset ja lopulliset identiteetit. Se antaa yrityksen omistajalle paikan hyväksyä vastauskäyttäytymistä ja sähköpostin ylläpitäjälle paikan liittää teknisen tuloksen.
Vertaa kaikkia testirivejä ennen uloskirjautumista. Yksi onnistunut organisaatioilmoitus ei vahvista ulkopuolisen jäsenen keskusteluviestiä. Jätä kattamattomat reitit nimenomaisesti odottamaan ja ilmoita, mitä lisätestejä tarvitaan. Säilytä verkkotunnuksen määritykset ja luetteloasetukset tulosten kanssa, jotta myöhemmät muutokset voidaan jäljittää.
Kuvitteellinen diagnoositapaus, johon liittyy keskustelun alatunniste
Vain kuvitteellinen kirjallinen tapaus: SLS-01 edellyttää alkuperäistä From member@outside.example alkuperäisellä ohitusallekirjoituksella d=outside.example. Uudelleen jaetussa kopiossa alkuperäinen allekirjoitus epäonnistuu alatunnisteen muutoksen jälkeen; lopullinen From jää member@outside.example . Listan kirjekuori, mahdolliset lisäallekirjoitukset ja niiden tulokset ovat tuntemattomia, joten täydellistä DMARC -tuomiota ei seuraa. Listan omistajan on tarkastettava lopullinen kopio ja dokumentoidut uudelleenkirjoitusasetukset, hyväksyttävä aiottu vastauskäyttäytyminen ja testattava tarkka reitti. SPF lisääminen organisaation toimialueeseen ei korjaa asiaankuulumatonta alkuperäistä allekirjoitusta. Varsinaista luetteloa tai viestiä ei tarkastettu.
Palauta asetukset häiritsemättä jäsenpostia
Tallenna aikaisemmat luetteloasetukset ja DNS tila ennen kontrolloitua muutosta. Jos vastaukset tai lähettäjän esitys ovat virheellisiä, keskeytä kyseinen käyttöönotto ja palauta hyväksytty toiminta, kun omistaja tarkistaa sen. Koordinoi tietueiden poistaminen jäljellä olevien luetteloiden ja jonossa olevien viestien kanssa. Jaettu toimialue voi tukea useita luetteloita erilaisilla toiminta-aikatauluilla.
Testaa uudelleen verkkotunnuksen muutosten, muutosten uudelleenkirjoituksen, uusien alatunnisteiden, reititysmuutosten tai siirron jälkeen. Tämä julkaisematon luonnos vaatii edelleen live-tilin tarkastuksen, myönnetyt arvot, DNS -havainnot, vastaanotettujen viestien todisteet, alkuperäisen laajuuden hyväksymisen, visuaalisen tarkastelun ja ihmisen pk-yrityksen hyväksynnän.
Erottele ohimenevä viesti täytäntöönpanovalmiudesta
RFC 9989 Kohta 7.4 edellyttää kelvollista DKIM ää verkkotunnuksen julkaisua varten p=reject ja varoituksia epäsuoran postin yhteentoimivuudesta. Yksittäinen kohdistettu SPF tulos ei sinänsä oikeuta hylkäyskäytännön käyttöönottoa. Tarkista kaikki lailliset reitit ja käytännön omistajuus erikseen tästä palveluntarjoajan asetuksesta.