Viesti, jossa näyttää olevan kaksi lähettäjää, voi sisältää useita eri asioita: yksi Lähettäjä-kenttä, joka sisältää useita kirjoittajia, kaksi erillistä Lähettäjä-kenttää tai näyttönimi, joka näyttää toiselta osoitteelta. Nämä ovat erilaisia jäsennys- ja suojaustapauksia. Kuvakaappaus sähköpostiohjelman lähettäjälinjasta ei voi luotettavasti erottaa niitä.
Säilytä alkuperäinen viestin otsikko ja aloita sen rakenteesta. Älä valitse hiljaa sitä osoitetta, joka on kohdakkain ohimenevän allekirjoituksen kanssa. Se voi piilottaa epäselvyyden, jonka vastaanottajan ja vastaanottajan on ymmärrettävä.
Erillinen kenttien määrä osoitemäärästä
RFC 5322 sallii yhden Lähettäjä-kentän postilaatikkoluettelon kanssa. Kun luettelo sisältää useamman kuin yhden postilaatikon, yhden postilaatikon sisältävä Lähettäjä-kenttä on pakollinen. Viestimuotosäännöt määrittelevät edelleen yhden Lähettäjä-kentän, joten kaksi erillistä Lähettäjä-kenttää eivät ole sama rakenne kuin yksi kelvollinen monen tekijän kenttä.
Lähettäjä tunnistaa lähettävän agentin viestimuotomallissa. Se ei korvaa Lähettäjä-verkkotunnusta DMARC's Author Domain. Vastaus, Return-Path ja näyttönimi palvelevat myös eri tarkoituksia.
Käyttää identiteettiketjun läpikäynti pitää nämä roolit erillään ennen todennuksen tutkimista.
Käytä DMARC verkkotunnuksen sääntöä nimenomaisesti
RFC 9989Normaali käsittely vaatii täsmälleen yhden osoitteesta poimitun verkkotunnuksen. Jos nolla tai useampi kuin yksi toimialue erotetaan, sen tavallinen validointiprosessi päättyy. Spesifikaatio sallii vastaanottimen jatkaa usean toimialueen tapauksessa ja käsittelee turvallisuus- ja prosessointivaikutuksia.
Se ei anna diagnoosityökalulle lupaa valita sopivinta tekijää ja raportoida ehdottomasta menestyksestä. Jos vastaanotin päättää arvioida useita verkkotunnuksia, tuloksena oleva menettely ja kattavuus on tallennettava.
Kohdassa 11.5 käsitellään kunkin toimialueen arviointia ja vahvimman politiikan soveltamista epäonnistuneiden tarkistusten joukossa. Se myös varoittaa, että liiallisen verkkotunnuksien käsittely voi aiheuttaa resurssiongelman. jos kaikkia ei ole käsitelty, arviointi on epätäydellinen. Nämä ovat vastaanottajien käsittelyyn liittyviä näkökohtia, eivät lupausta siitä, että jokainen tuote hyväksyy tai näyttää tällaisen postin samalla tavalla.
Käytä kontrolloituja koteloita, joissa on merkittyjä odotuksia
Alla olevat tapaukset ovat synteettisiä otsikkokappaleita. Ne eivät ole suoritettuja testejä tai raportoituja vastaanottimen tuloksia, ja jokainen tarvitsisi loput oikein rakennetusta viestistä kontrolloidussa testissä.
| Asia | Havainnollistavat kentät | Arviointi tallennettavaksi |
|---|---|---|
| Yksi kirjoittaja | Lähettäjä: author@example.com | Tavallinen yhden verkkotunnuksen polku, jäljellä olevat viestit ja todennustarkistukset |
| Useita kirjoittajia yhdellä alalla | Lähettäjä: author@example.com , editor@example.net | Vaaditulla erillisellä yhden postilaatikon Lähettäjä-kentällä tämä voi olla kelvollinen monen tekijän muoto. useat From-verkkotunnukset vaativat edelleen DMARC poikkeuksellisen käsittelyn analyysiä |
| Kopioi kentistä | Yksi Lähettäjä-kenttä example.com ja toinen example.net | Viestimuotovirhe; älä korjaa sitä näkymättömästi väittäen arvioivasi alkuperäistä viestiä |
| Osoitteen kaltainen näyttönimi | Näytä näkyvän osoitteen sisältävä teksti ennen varsinaista postilaatikkoa | Jäsennä todellinen postilaatikon toimialue; arvioida näyttöriski erikseen |
Säilytä kussakin tapauksessa raaka-teline ja jäsentimen lähtö. Laske kentät, luettele poimitut postilaatikon arvot ja tallenna verkkotunnuksen tulos, joka johti valittuun käsittelypolkuun. Jos kaksi postilaatikkoa käyttävät samaa toimialuetta, älä oleta, että sähköpostiohjelman näyttö vastaa, kuinka arvioija käsittelee tätä monen tekijän rakennetta. säilyttää poimintatuloksensa ja testata toteutusta.
Pidä todennustodistus sidottuina jäsennettyyn identiteettiin
An SPF tai DKIM yhden verkkotunnuksen pass ei voi selittää toista näytettävää identiteettiä ilman vaadittua linjaus analyysi. Säilytä kaikki asiaankuuluvat DKIM d -arvot ja luotettavat vastaanottimen tulokset. Säilytä myös tarkat From-tavut, mukaan lukien taitto ja kommentit, jotta jäsennys voidaan toistaa.
Älä kirjoita alkuperäistä lähettäjää uudelleen yhdelle tekijälle ennen kuin olet tarkistanut alkuperäisen allekirjoituksen tai tutkinut, mitä vastaanottava järjestelmä näki. Uudelleenkirjoitettu kopio voi olla hyödyllinen erillisenä testitapauksena, mutta merkitse se muokatuksi kiinnikkeeksi, jossa on erilainen identiteettikysymys.
Hylätty yritys ei välttämättä koskaan tuota toimitettuja otsikoita. Säilytä SMTP vastaus ja vastaanottolokit, jos saatavilla, sen sijaan, että keksit toimitetun Authentication-Results näyte.
Testin esitys sekä käsittely
Turvallisuus koskee myös sitä, mitä vastaanottaja näkee. Yksi komponentti voi arvioida yhden rakenteen, kun taas sähköpostiohjelma korostaa toisen näennäisen kirjoittajan. Vertaa valtuutetussa testiympäristössä jäsentimen lähtöä, todennustulosta, käsittelyä ja näytettävää lähetysriviä täsmälleen samalle laitteistolle.
Tallenna ohjelmistoversiot ja asetukset todellisilla havainnoilla. Älä kopioi yhden asiakkaan käyttäytymistä universaaliksi väitteeksi. RFC 9989 tunnistaa usean verkkotunnuksen rakenteet mahdollisena tapana välttää normaalia DMARC käsittelyä, joten tulos, jossa on merkintä "ei arvioitu", ei saa olla "turvallinen".
Käytännöllinen lähtevän postin kokoonpano hyötyy yleensä yhdestä selkeästä postilaatikosta tavalliselle automaattiselle postille. Jos tarvitaan aitoa monen tekijän toimivuutta, vahvista soveltuva muoto ja tuettu käsittely järjestelmillä, jotka käsittelevät sen sen sijaan, että olettaisit, että vaadittu Lähettäjä-kenttä ratkaisee kaikki myöhemmän tason todennusongelmat.
Tutkimus on valmis, kun se säilyttää alkuperäisen syntaksin, selittää erotetun verkkotunnuksen päätöksen ja yhdistää sen todelliseen vastaanottimen käsittelyyn ja esittämiseen. Pidä poikkeuksellinen tai epätäydellinen käsittely näkyvissä sen sijaan, että valmistaisit yhden vihreän todennusvastauksen.