የDMARC መዝገብ አወቃቀር እና ክፍሎቹን መረዳት
የDMARC (Domain-based Message Authentication, Reporting, and Conformance) የTXT መዝገብ የኢሜይል ጎራ ባለቤቶች የደብዳቤዎቻቸውን ትክክለኛነት ለመጠበቅ የሚጠቀሙበት የDNS መዝገብ ነው። የDMARC መዝገብ መፈተሻ መሣሪያው እርስዎ የሚያስገቡትን የDMARC TXT እሴት በመተንተን የፖሊሲ ምርጫዎችን፣ የአሰላለፍ ቅንብሮችን፣ የሪፖርት አድራሻዎችን እና የቀድሞ የቅርስ መቶኛ እሴቶችን ይገመግማል። መሣሪያው ልክ ያልሆኑ ውሎችን በመለየት በአገባብ እና በፖሊሲ ጉዳዮች ላይ ዝርዝር ማስታወሻዎችን ያቀርባል።
በDMARC መዝገብ ውስጥ እያንዳንዱ ውል የራሱ የሆነ ሚና አለው። መዝገቡ የግድ በ v=DMARC1 መጀመር አለበት። ይህ እሴት ለጉዳዩ ስሜታዊ (case-sensitive) ሲሆን፣ ሁልጊዜም የመጀመሪያው ውል መሆን ይኖርበታል። ይህ ካልሆነ መሣሪያው "መዝገቡ በ v=DMARC1 መጀመር አለበት።" ወይም "ውል ‹position›፦ v=DMARC1 የመጀመሪያው ውል መሆን አለበት።" የሚሉ ስህተቶችን ያሳያል።
የDMARC ፖሊሲዎች ዓላማ እና ተፅዕኖ (p, sp, np)
የDMARC ዋና ተግባር የኢሜይል ተቀባዮች የማረጋገጫ ፍተሻ (SPF እና DKIM) ያላለፉ መልዕክቶችን ምን ማድረግ እንዳለባቸው መመሪያ መስጠት ነው። ይህ በዋናነት በሦስት የፖሊሲ ውሎች ይወሰናል፡
- የጎራ ፖሊሲ (p)፦ ለዋናው ጎራ የሚተገበር ፖሊሲ። በመዝገቡ ውስጥ ምንም ዓይነት የ
pውል ከሌለ፣ የጎራው ፖሊሲ በራስ-ሰር ወደnoneይቀየራል። በዚህ ጊዜ መሣሪያው "p → none" የሚል ማስታወሻ ያሳያል። የp=noneፖሊሲ ውድቀቶችን ለመቆጣጠር ብቻ የሚያገለግል ሲሆን፣ ተቀባዮች ያልተረጋገጡ መልዕክቶችን እንዲያግዱ (reject) ወይም ወደ ማቆያ (quarantine) እንዲልኩ አይጠይቅም። ይህ ሲሆን መሣሪያው "p=none" የሚል የፖሊሲ ማስታወሻ ይሰጣል። - የንዑስ ጎራ ፖሊሲ (sp)፦ ለንዑስ ጎራዎች የሚተገበር ፖሊሲ።
- የማይኖሩ ንዑስ ጎራዎች ፖሊሲ (np)፦ በሕልውና ለሌላቸው ንዑስ ጎራዎች የሚተገበር ፖሊሲ።
የንዑስ ጎራ ፖሊሲዎች ይበልጥ የተለየ ውል በሌለበት ጊዜ ከ np ወደ sp ከዚያም ወደ p የመሸጋገር (fallback) ባህሪ አላቸው። በተጨማሪም፣ በሙከራ ጊዜ የ t=y ውል ጥቅም ላይ ከዋለ፣ የ quarantine ፖሊሲን ወደ none ዝቅ የሚያደርገው ሲሆን፣ የ reject ፖሊሲን ደግሞ ወደ quarantine ዝቅ ያደርገዋል። ይህ ሁኔታ ሲገኝ መሣሪያው "t=y: reject → quarantine; quarantine → none" የሚል ማሳሰቢያ ይሰጣል።
የSPF እና DKIM አሰላለፍ እንዲሁም የሪፖርት ውቅረት
የDMARC መዝገብ የSPF (Sender Policy Framework) እና የDKIM (DomainKeys Identified Mail) መለያዎች ከአስተላላፊው ጎራ ጋር እንዴት እንደሚሰለፉ ይወስናል። መሣሪያው እነዚህን የአሰላለፍ ቅንብሮች በመተንተን በ "DKIM / SPF" ክፍል ውስጥ ያሳያል።
የDMARC ሪፖርቶች ጎራዎን ለመጠበቅ ወሳኝ ናቸው። ሪፖርቶች በሁለት ይከፈላሉ፡
- የተደመሩ ሪፖርቶች (rua)፦ አጠቃላይ የደብዳቤዎችን ሁኔታ የያዙ ሪፖርቶች የሚላኩበት አድራሻ። በመዝገቡ ውስጥ ምንም ዓይነት ትክክለኛ የ
ruaአድራሻ ከሌለ፣ የተደመሩ ሪፖርቶች አይጠየቁም። በዚህ ጊዜ መሣሪያው "rua=∅" የሚል ማስታወሻ ያሳያል። - የውድቀት ሪፖርቶች (ruf)፦ የደብዳቤ ማረጋገጫ ሲወድቅ የሚላኩ ዝርዝር ሪፖርቶች አድራሻ። የ
fo(failure options) ውል ትክክለኛ የrufየውድቀት ሪፖርት አድራሻ በሌለበት ሁኔታ ችላ ይባላል። ይህ ሲከሰት መሣሪያው "fo → ∅ (ruf=∅)" የሚል ማስታወሻ ያወጣል።
በሪፖርት URI ላይ የሚቀመጠው የ !size ቅጥያ በአሁኑ ጊዜ ጊዜ ያለፈበት (obsolete) በመሆኑ፣ አሁን ባሉ ተቀባይ አገልጋዮች ዘንድ ችላ ሊባል ይገባል። ይህ ሲገኝ መሣሪያው "!size → ∅ (RFC 9989)" የሚል ማስታወሻ ያሳያል።
የታሪክ እና የቅርስ ውሎች (Historic Tags)
በDMARC ዝርዝር መግለጫዎች ለውጥ ምክንያት፣ አንዳንድ ውሎች በአዲሱ መስፈርት መሠረት እንደ ታሪክ (historic) ይቆጠራሉ። ለምሳሌ የ pct (percentage) እሴት በአሁኑ ጊዜ እንደ ታሪክ የሚቆጠር ሲሆን፣ የፖሊሲ ሽፋን ገደብን የሚተገብረው አሁንም የድሮውን የDMARC መግለጫ ለሚከተሉ ተቀባዮች ብቻ ነው። መሣሪያው ይህንን ሲያገኝ "pct=‹detail›% (RFC 7489)" የሚል ማስታወሻ ይሰጣል።
የአሁኑን የDMARC መስፈርት የሚከተሉ ተቀባይ ስርዓቶች እነዚህን የታሪክ ውሎች ችላ ሊሏቸው ይችላሉ። መሣሪያው እነዚህን ውሎች ለይቶ "RFC 7489 → RFC 9989: ‹tag› (‹position›)" በሚል ምልክት ያሳያል።
የተለመዱ የአገባብ ስህተቶች እና መፍትሔዎቻቸው
የDMARC መዝገብን በሚያዘጋጁበት ጊዜ የሚከተሉትን የአገባብ ስህተቶች ለማስወገድ ጥንቃቄ ማድረግ ያስፈልጋል። መሣሪያው እነዚህን ስህተቶች በመለየት ተገቢውን መልዕክት ያሳያል፡
| የስህተት ዓይነት | የመሣሪያው የስህተት መልዕክት |
|---|---|
| ባዶ እሴት መለጠፍ | "መጀመሪያ የDMARC መዝገብ ይለጥፉ።" |
| እጅግ በጣም ረጅም መዝገብ | "ይህ መዝገብ ባልተለመደ ሁኔታ ትልቅ ነው። ከ20,000 ቁምፊዎች በታች ያቆዩት።" |
| ከአንድ በላይ የተደጋገመ ውል | "×2: ‹tag› (‹position›)" |
| የተሳሳተ የውል አወቃቀር | "name=value ✕ (‹position›)" |
| ባዶ እሴት ያለው ውል | "‹tag›=∅ (‹position›)" |
| ልክ ያልሆነ እሴት | "‹tag›=‹detail› ✕ (‹position›)" |
| ልክ ያልሆነ የሪፖርት URI | "URI ✕: ‹tag› (‹position›)" |
| ያልታወቀ ውል | "ያልታወቀ: ‹tag› (‹position›)" |
በተጨማሪም፣ በጥቅስ ውስጥ ያሉ የDNS TXT ክፍሎች ከተተነተኑ በፊት በራስ-ሰር ይጣመራሉ። ይህ በሚሆንበት ጊዜ "በጥቅስ ውስጥ ያሉ የDNS TXT ክፍሎች ከትንተናው በፊት ተጣምረዋል።" የሚል ማሳሰቢያ ያገኛሉ።
የግላዊነት እና የውሂብ አያያዝ መርህ
ይህ መሣሪያ የተጠቃሚዎችን ግላዊነት ሙሉ በሙሉ በሚያከብር መልኩ የተገነባ ነው። ያስገቡት የDMARC መዝገብ በአሳሽዎ ውስጥ ብቻ የሚቆይ ሲሆን፣ BroBroGo መዝገቡን ወደ አገልጋይ አይሰቅለውም ወይም አያስቀምጠውም። ግብዓቱ በአሳሽ ማከማቻ (browser storage) ውስጥ የማይጻፍ ሲሆን፣ ከመዝገቡ ጋር የተያያዘ ምንም ዓይነት ጥያቄ ወደ ውጭ አይላክም።
ተደጋግሞ የሚጠየቁ ጥያቄዎች (FAQ)
የአገባብ እና የፖሊሲ ማስታወሻዎች: p / sp / np?
የ p ውል ለዋናው ጎራ ፖሊሲ ሲሆን፣ sp ለንዑስ ጎራዎች፣ እና np ደግሞ ለማይኖሩ ንዑስ ጎራዎች የሚያገለግሉ ፖሊሲዎች ናቸው። ይበልጥ የተለየ ውል በሌለበት ጊዜ ፖሊሲው ከ np ወደ sp ከዚያም ወደ p ይሸጋገራል። የ p=none ፖሊሲ ክትትል ለማድረግ ብቻ የሚያገለግል ሲሆን፣ የ t=y የሙከራ ውል ደግሞ የ quarantine ፖሊሲን ወደ none እንዲሁም የ reject ፖሊሲን ወደ quarantine ዝቅ ያደርገዋል።
RFC 9989: pct / rf / ri?
አይ። ይህ ገጽ የሚፈትሸው የለጠፉትን ጽሑፍ ብቻ ነው። DNSን አይጠይቅም፣ የአቅራቢ መዝገቦችን አያስፋፋም፣ የላኪ IPን አይፈትሽም ወይም ተቀባይ የደብዳቤ አገልጋይ የሚመልሰውን አያረጋግጥም። RFC 9989: pct / rf / ri → historic; np / psd / t → active።
ንጹህ ውጤት የDMARC ቅንብሬ እንደሚሠራ ያረጋግጣል?
አይ። ይህ ገጽ የሚፈትሸው የለጠፉትን ጽሑፍ ብቻ ነው። DNSን አይጠይቅም፣ የአቅራቢ መዝገቦችን አያስፋፋም፣ የላኪ IPን አይፈትሽም ወይም ተቀባይ የደብዳቤ አገልጋይ የሚመልሰውን አያረጋግጥም።
የDMARC መዝገብ የግድ በ v=DMARC1 መጀመር አለበት?
አዎ። የDMARC መዝገብ የግድ ለጉዳዩ ስሜታዊ በሆነው v=DMARC1 እሴት መጀመር አለበት። ይህ ውል በመዝገቡ ውስጥ የመጀመሪያው መሆን ይኖርበታል።