[ Toimitettavuus ja lähettäjäsäännöt ]

Estolistan poistaminen: laadi luotettava korjauspöytäkirja

Luo tarkistettava tili luetellusta kohteesta, todistetusta syystä, suorita korjaus ja todentaminen ennen kuin valtuutettu omistaja ottaa yhteyttä operaattoriin.

EmailAuth -tutkimusryhmä · 7 min lukuaika

[Avainkohdat]

  • Selvitä listattu kohde ja sen omistaja ennen pyynnön laatimista.
  • Pidä hypoteesit, suunnitellut toimet, tehdyt muutokset ja todetut tulokset erillään.
  • Operaattorin asema, toimituksen hyväksyminen ja postilaatikon sijoittaminen vaativat erilliset todisteet.
Tällä sivulla

Selitä muutosta poistotietueen

Uskottava estoluettelo poistopyyntö on lyhyt todisteketju: toiminnanharjoittaja tunnisti tietyn kohteen, vastuullinen omistaja tutki asiaankuuluvan käytöksen, korjaavat toimet korjasivat syyn ja myöhemmät havainnot tukevat väitettyä parannusta. Pitkä julistus yrityksen laillisuudesta ei korvaa tätä ketjua. Ei myöskään kuvakaappaus, joka osoittaa, että asiaankuulumaton todennustarkastus läpäisi.

Valmistele tietue ennen lähetyslomakkeen avaamista. Tässä artikkelissa kuvataan sisäinen valmistelutyönkulku, ei suoritettu pyyntö. Tietojen hakua, ulkoista viestiä, poistolähetystä, maksua tai tilin muutosta ei suoritettu. Vastuullisen omistajan on tarkasteltava sekä tekniset tosiasiat että tiedot, jotka voidaan jakaa toiminnanharjoittajan kanssa.

Määritä operaattori ja listattu objekti

Tallenna operaattorin nimi, luettelo tai tietojoukko, tarkka IP-osoite, toimialue tai muu objekti, luettelon viite, jos saatavilla, ja aikaleima. Lähettäjä voi käyttää toimialuetta, jaettua IP-osoitetta ja upotettuja linkkiverkkotunnuksia samassa viestissä; ne eivät ole keskenään vaihdettavia esineitä. Palveluntarjoajan asiakkaalla ei ehkä myöskään ole valtuuksia pyytää kyseisen palveluntarjoajan omistaman infrastruktuurin poistamista. Selvitä omistajuus ja yhteydenottoreitti ennen kuin teet hallintavaatimuksen.

Spamhaus yleinen ohje ohjaa pyynnöt tarkistajansa kautta ja vaatii rekisteröityä omistajaa toimimaan tai asiakasta ottamaan palveluntarjoajan mukaan. Se on Spamhaus-spesifinen menettely, ei yleinen sääntö jokaiselle listalle. Nykyisten operaattorin ohjeiden tulee määrittää soveltuva kanava ja pyydetyt todisteet. Spamhaus yleisiä kysymyksiä.

Erottele todistettu syy uskottavasta syystä

Pöytäkirjasta tulee kertoa, mitä tutkinta todellisuudessa totesi. "Vaarantunut postilaatikko lähetti luvattomia viestejä tallennetun ajanjakson aikana" edellyttää tilin ja viestien todistusta. "IP on jaettu ja palveluntarjoaja tutkii" kuvaa erilaista, epätäydellistä tilaa. Älä muunna epäilyä varmuudeksi vain saadaksesi lomakkeen näyttämään täydelliseltä. Rehellinen ratkaisematon syy on hyödyllisempi kuin keksitty korjauskertomus.

Säilytä syyn ja teon välinen yhteys. Salasanan vaihto ei selitä käytäntöluetteloa osoitealueella, jota ei ole tarkoitettu lähettämään suoraa MX-postia. DNS muutos ei selitä, miksi sovellus lopetti ei-toivotun sähköpostin lähettämisen. Jos havaittu ongelma koskee yhteistä lähetyspalvelua, selvitä, mitä palveluntarjoaja on vahvistanut ja mikä jää asiakkaan näkyvyyden ulkopuolelle.

Sido jokainen korjaava toimenpide päivättyyn havaintoon

Merkitse jokaisen väitetyn toimenpiteen omistaja, laajuus, valmistumisaika ja sitä tukevat todisteet ylös. Erottele hyväksytty suunnitelma suoritetusta muutoksesta ja suoritettu muutos onnistuneesta vahvistuksesta. "Tiimi tarkistaa edelleenlähetyssäännöt" ei vastaa sanaa "säännöt tarkistettiin", eikä se myöskään osoita, että luvaton edelleenlähetys on pysähtynyt.

Spamhaus kysyy syytä, korjaavia toimia, ajoitusta ja ehkäiseviä toimenpiteitä ja varoittaa, että pyyntö ei takaa poistamista. Käytä sitä konkreettisena esimerkkinä operaattorin näyttöodotuksista, älä lupauksena, että samat neljä kenttää täyttävät jokaisen palvelun. Vältä epämääräisiä lauseita, kuten "kaikki on korjattu", kun suppeampaa väitettä voidaan tukea. Spamhaus yleisiä kysymyksiä.

Valmistele kuvitteellinen todistepaketti

Kuvittele kuvitteellinen lähettäjä, jonka sovellustunnuksia käytettiin väärin integraation vuoksi. Pakettiluonnos tunnistaisi vaikuttaneen virran, operaattorin vahvistaman listatun objektin, tapahtumaikkunan, valtuutetun rajoituspäätöksen ja integraation korjauksen. Se liittäisi vain hyväksyttyjä, asiaankuuluvia todisteita ja ilmoittaisi mahdolliset seurantapuutteet. Tämä on esimerkki levyn rakenteesta; tilin vaarantumista tai listaamista ei ole havaittu.

Vahva paketti erottaisi identiteetin omistajan suojaustodistuksen sähköpostintarjoajan lähetyslokeista ja listaoperaattorin tilasta. Jos tiimi on nollannut vain yhden salasanan integraation pääsyn ollessa ratkaisematta, paketin pitäisi pysyä epätäydellinen. Jos palveluntarjoaja omistaa listatun IP-osoitteen, paketti tulee valmistaa kyseisen palveluntarjoajan tarkastettavaksi sen sijaan, että se lähetettäisiin keksityn omistajuusvaatimuksen perusteella.

Älä sekoita poistamista vastaanottajan hyväksyntään

Listoilla on eri tarkoitukset ja elinkaaret. SpamCop kuvaa automaattisen luettelon IP-osoitteista, jotka liittyvät raportoituihin posteihin, ja automaattisen poiston, kun raportit lakkaavat. Sen dokumentaatio tunnustaa myös väärät positiiviset tulokset ja neuvoo varovaiseen käyttöön. Älä käytä siihen toisen luettelon ajoitusta, manuaalista prosessia tai kaupallista tarjousta. Sivu itse toteaa, että sen yksityiskohtainen kuvaus voi muuttua. SpamCop estoluettelon selitys.

Vastaanotin voi käyttää muita signaaleja, kun käyttäjä on poistanut merkinnän. Säilytä täydelliset SMTP vastaukset, tarjoajan tai vastaanottajan laajuus ja tarkkailuajat. Viestidatan jälkeinen viimeinen positiivinen valmistuminen muodostaa SMTP kanavanvaihdon, ei postilaatikon sijoittelua tai myöhemmän suodatuksen puuttumista. Operaattorin tilan tarkistus ja toimituksen uusintatesti kuuluvat siis eri kenttiin. RFC 5321 , kohta 4.2.5.

Minimoi paljastaminen ja vältä ennenaikaisia ​​sitoumuksia

Valmistele kompakti tietue, joka sisältää käyttäjän tarvitseman, ja työkopiosta on poistettu arkaluontoinen viestisisältö ja asiaankuulumattomat vastaanottajatiedot. Säilytä alkuperäiset lokit suojattuna, jotta editointi ei peitä todisteita sisäisesti. Älä koskaan sisällytä salasanoja, tunnuksia, yksityisiä avaimia tai maksutietoja poistoselostukseen. Kaikki tilikohtaiset tiedot tai toimitukset edellyttävät asianmukaista lupaa.

Jos operaattori tarjoaa maksullisen palvelun, käsittele sen hinta, ehdot ja laajuus erillisenä päätöksenä. Maksu ei ole todiste siitä, että syy on korjattu, eikä se voi taata toimitusta kaikilla palveluntarjoajilla. Samoin toistuvien pyyntöjen ei pitäisi korvata tutkimuksen loppuun saattamista. Säilytä yksi selkeä kronologia ja asiaankuuluva tapausviittaus, jotta myöhemmät arvioijat ymmärtävät, mikä on muuttunut kontaktien välillä.

Päätä, onko paketti valmis lähetettäväksi

Omistajan arvion pitäisi vastata kolmeen kysymykseen: ovatko väitteet tuetut, onko tämä operaattorin nykyinen reitti ja onko ehdotettu julkistaminen hyväksytty? Ratkaisemattomat tosiasiat tulisi mieluummin leimata kuin piilottaa. Jos oikea operaattorin reitti ei ole saavutettavissa, lopeta lähetysvaihe ja jatka sellaisten todisteiden valmistelua, jotka eivät riipu pääsystä.

Operaattorin vahvistama listaus ja dokumentoitu syy, korjaava toimenpide ja toimituksen uusintatesti. Tämä tarkka luettelovaatimus on edelleen avoinna. Alla oleva räätälöity pakettikartta sisältää vain ehdotetut kentät. Tähän luonnokseen ei liity operaattorin vahvistamaa luetteloa, suoritettuja korjaavia toimenpiteitä, valtuutettua lähetystä tai kontrolloitua toimituksen uudelleentestiä, eikä mitään poistamis- tai palautustulosta luvata.

[ Takeaway ]

Toimita tuetut tiedot sovellettavan operaattorin reitin kautta; pyyntö ei ole todiste korjaamisesta tai lupaus poistamisesta.

[ Roolin mukaan ]

Mitä tämä tarkoittaa sinulle

Valitse roolisi ja seuraa käytännön toimia.

Tapahtuman tai korjauksen omistaja

Yhdistä syy toimintaan

Uskottava paketti selittää, miksi suoritettu toiminta käsittelee havaittua käyttäytymistä.

Seuraavat vaiheet

  1. Säilytä jokaisen tosiasiallisen väitteen päivätty lähde.
  2. Pidä ratkaisemattomat perimmäiset kysymykset näkyvissä.

Infrastruktuurin tai palvelun omistaja

Luo auktoriteetti kohteeseen

Palvelua käyttävä osapuoli ei saa omistaa listattua osoitetta tai hallita operaattorin pyyntöä.

Seuraavat vaiheet

  1. Vahvista omistajuus ja oikea palveluntarjoajan eskalaatiopolku.
  2. Vahvista tarkka virta ja infrastruktuuri, jota korjaus koskee.

Tuki- tai viestintätarkastaja

Hyväksy rajoitettu ilmoitus

Ulkoisen kertomuksen tulee olla tarkkaa, tarpeellista ja valtuutettua.

Seuraavat vaiheet

  1. Poista salaisuudet ja asiaankuulumattomat henkilötiedot työpaketista.
  2. Tarkista nykyinen operaattorikanava ja kaupalliset ehdot erikseen.

[ UKK ]

Usein kysytyt kysymykset

Voiko asiakas pyytää palveluntarjoajan omistaman IP-osoitteen poistamista sen omistajana?

Älä keksi sitä auktoriteettia. Tunnista rekisteröity omistaja ja sovellettava operaattorimenettely; palveluntarjoajan osallistuminen voi olla tarpeen.

Entä jos epäiltyä syytä ei vahvisteta?

Merkitse se hypoteesiksi ja kerro, mitä todisteita puuttuu. Poistokertomus ei saa muuttaa uskottavaa selitystä näytetyksi tapahtumaksi.

Onko läpäistävä DMARC -tulos korjaustietue?

Ei. Se kuvaa todennustulosta, ei sitä, miksi ei-toivottu toiminta tapahtui tai mikä korjaava toimenpide pysäytti sen.

Miten keskeneräisen toiminnon pitäisi näkyä paketissa?

Suunniteltu tai odotustilassa, omistajan ja suunnitellulla todennuksella. Älä kuvaile ehdotettua tarkistusta valmiiksi muutokseksi.

Käytetäänkö jokaisessa luettelossa manuaalista poistopyyntöä?

Ei. Esimerkiksi SpamCop kuvaa automaattista luettelointia ja poistoa, joka on sidottu ilmoitettuun sähköpostiin. Tarkista kyseisen operaattorin nykyinen menettely.

Mitä pitäisi jättää pois ulkoisesta poistosarratiivista?

Salasanoja, kuten salasanoja ja tunnuksia, tarpeeton henkilökohtaisten viestien sisältö, asiaankuulumattomat vastaanottajatiedot ja tukemattomat väitteet. Hanki lupa tarvittavalle paljastamiselle.

Voiko maksu taata, että posti saapuu jokaiseen postilaatikkoon?

Tällaista takuuta ei tueta. Kaikilla maksullisilla vaihtoehdoilla on omat laajuutensa ja ehdot; se ei todista, että perimmäinen syy on korjattu, eikä valvo kaikkia vastaanottavia palveluntarjoajia.

Mikä erottaa valmiin omistajan arvioitavaksi valmiista lähetettäväksi?

Todistuspaketti voidaan laatia sisäisesti, mutta tuetut tosiasiat, nykyinen operaattorin soveltuvuus, omistusoikeus ja hyväksytty luovutus on selvitettävä ennen erillistä toimitusvaihetta.

[ Lähteet ]

Lähteet

  1. RFC 5321 : Yksinkertainen postinsiirtoprotokolla
  2. RFC 9989 : verkkotunnuspohjainen viestien todennus, raportointi ja vaatimustenmukaisuus
  3. SpamCop : estoluettelon tarkoitus ja toiminta
  4. Spamhaus : yleiset luettelointi- ja poistokysymykset

[ Sanasto ]

Sanasto

Listattu kohde
Tarkka IP-osoite, verkkotunnus, alue tai muu tunniste, jonka tietty operaattorimerkintä kattaa.
Korjauspöytäkirja
Päivätty tili, joka yhdistää osoitetun syyn, korjaavan toimenpiteen, vastuullisen omistajan ja varmistustodistuksen.
Ennaltaehkäisevä valvonta
Toimenpide, jonka tarkoituksena on vähentää tietyn käyttäytymisen toistumista, joka eroaa pelkästä olemassa olevan merkinnän poistamisesta.
Poistaminen listalta
Operaattorin tekemä merkinnän poistaminen oman käytäntönsä mukaisesti, ei tae vastaanottajan hyväksymisestä.
Todistustodistus
Havainto, joka näyttää mitä tapahtui muutoksen jälkeen, erillään muutostietueesta tai hyväksynnästä.

Yrityksen alkuperä

Miksi parhaat rahoituslaitokset ja hallitukset lopettivat sähköpostin suojauksen hallintapaneelinsa.

Perinteiset sähköpostin todennusalustat myyvät sinulle kojelaudan ja pyytävät insinöörejäsi tekemään työtä. Korkeiden panosten ympäristöissä manuaalinen valvonta tarkoittaa viivästynyttä täytäntöönpanoa, konfiguraatioiden siirtymistä ja valvomattomia varjoalueita.

EmailAuth on agentti sähköpostin alkuperäalusta. Agenttimme valvovat p=reject, pidä kolmannen osapuolen lähettäjät kohdakkain ja siirrä verkkotunnuksesi täyteen RFC 9989 noudattaminen, uusi DMARC standardi, jossa on in-the-loop -tarkastettavuus.

hallitukset Suuret yritykset Tason 1 rahoituslaitokset

SaaS · Dedikoitu vuokrasopimus · Ilmarakoinen on-prem · BYOK-salaus

Tietokanta