DMARC գրառման կառուցվածքը և v=DMARC1 տարրի դերը
DMARC (Domain-based Message Authentication, Reporting, and Conformance) արձանագրությունը հանդիսանում է էլեկտրոնային փոստի պաշտպանության հիմնասյուներից մեկը։ Ցանկացած վավեր DMARC TXT գրառում պետք է սկսվի v=DMARC1 տարրով։ Այս արժեքը զգայուն է մեծատառերի և փոքրատառերի նկատմամբ, և ցանկացած շեղում անվավեր է դարձնում ամբողջ գրառումը։
DMARC գրառման ստուգիչ գործիքը վերլուծում է ձեր տրամադրած TXT արժեքը՝ համոզվելու համար, որ այն համապատասխանում է սահմանված կանոններին։ Եթե գրառումը չի սկսվում այս նույնականացուցիչով, համակարգը ցույց կտա «Գրառումը պետք է սկսվի v=DMARC1-ով։» սխալը։ Բացի այդ, v=DMARC1 տարրը պարտադիր պետք է լինի հենց առաջին դիրքում։ Եթե այն հայտնվի այլ տեղում, կցուցադրվի «Տարր ‹position›․ v=DMARC1-ը պետք է լինի առաջին տարրը։» հաղորդագրությունը։
DMARC քաղաքականությունների ազդեցությունը. p, sp և np
DMARC գրառման հիմնական նպատակն է հրահանգել ընդունող սերվերներին, թե ինչպես վարվել այն նամակների հետ, որոնք չեն անցնում SPF կամ DKIM ստուգումները։ Դրա համար օգտագործվում են հետևյալ քաղաքականությունները.
- Հիմնական տիրույթի քաղաքականություն (p). Սահմանում է գործողությունները հիմնական տիրույթի համար։ Եթե այս տարրը բացակայում է, կիրառվում է լռելյայն սկզբունքը, և գործիքը ցույց կտա «p → none» նշումը, ինչը նշանակում է, որ տիրույթի քաղաքականությունը վերադառնում է
noneարժեքին։p=noneքաղաքականությունը միայն մոնիտորինգ է իրականացնում և չի հրահանգում սերվերներին կարանտինացնել կամ մերժել նամակները։ Այս դեպքում գեներացվում է «p=none» զգուշացումը։ - Ենթատիրույթների քաղաքականություն (sp). Որոշում է կանոնները ենթատիրույթների համար։
- Գոյություն չունեցող ենթատիրույթների քաղաքականություն (np). Սահմանում է կանոնները չստեղծված ենթատիրույթների համար։
Եթե ավելի կոնկրետ տարրեր բացակայում են, համակարգը կիրառում է աստիճանական անցման սկզբունքը՝ np տարրի բացակայության դեպքում անցում է կատարվում sp տարրին, իսկ վերջինիս բացակայության դեպքում՝ հիմնական p քաղաքականությանը։
Թեստավորման փուլում գործում է t=y տարրը, որը փոփոխում է քաղաքականության խստությունը։ Այն իջեցնում է reject քաղաքականությունը quarantine-ի, իսկ quarantine-ը՝ none-ի։ Այս դեպքում գործիքը կարձանագրի «t=y: reject → quarantine; quarantine → none» կարգավիճակը։
Իդենտիֆիկատորների համապատասխանեցում և հաշվետվությունների կարգավորում
DMARC-ն ապահովում է SPF և DKIM նույնականացման համապատասխանեցումը (alignment)։ Բացի այդ, այն հնարավորություն է տալիս ստանալ երկու տեսակի հաշվետվություններ.
- Ամփոփ հաշվետվություններ (rua). Ուղարկվում են նշված էլեկտրոնային հասցեներին։ Եթե վավեր
ruaհասցե նշված չէ, ամփոփ հաշվետվություններ չեն հարցվում, ինչի մասին վկայում է «rua=∅» նշումը։ - Խափանումների հաշվետվություններ (ruf). Ուղարկվում են կոնկրետ նամակների ձախողման դեպքում։
Հաշվետվությունների ուղարկման կանոնները սահմանող fo տարրն ամբողջությամբ անտեսվում է, եթե գրառման մեջ նշված չէ վավեր ruf հասցե։ Այդ դեպքում գործիքը ցույց կտա «fo → ∅ (ruf=∅)» նշումը։ Ժամանակակից ստանդարտներում հաշվետվության հասցեի վերջում կիրառվող չափի սահմանափակման !size վերջածանցը համարվում է հնացած և ընդունող սերվերների կողմից պետք է անտեսվի, ինչը գործիքում նշվում է որպես «!size → ∅ (RFC 9989)»։
Պատմական տարրեր և ժառանգված կարգավորումներ
DMARC ստանդարտների զարգացմանը զուգընթաց որոշ տարրեր ստացել են պատմական (historic) կարգավիճակ։ Օրինակ՝ pct (տոկոսային սահմանափակում) տարրը համարվում է հնացած։ Այն սահմանափակում է քաղաքականության կիրառումը միայն այն ընդունողների համար, որոնք դեռևս հետևում են հին DMARC սպեցիֆիկացիաներին։ Նման դեպքերում գործիքը գրանցում է «pct=‹detail›% (RFC 7489)» նշումը։
Եթե գրառման մեջ հայտնաբերվում են հնացած տարրեր, որոնք ներկայիս ստանդարտներով կարող են անտեսվել ընդունող համակարգերի կողմից, գործիքը նշում է դրանք որպես «RFC 7489 → RFC 9989: ‹tag› (‹position›)»։
Շարահյուսական սխալների հայտնաբերում և վերլուծություն
DMARC գրառման ստուգիչը մանրակրկիտ վերլուծում է յուրաքանչյուր տարր և հայտնաբերում հետևյալ շարահյուսական խնդիրները.
- Կրկնվող տարրեր. Եթե նույն տարրը հանդիպում է մեկից ավելի անգամ, գեներացվում է «×2:
‹tag›(‹position›)» սխալը։ - Սխալ ձևաչափ. Տարրերը պետք է լինեն կետ-ստորակետով բաժանված name=value զույգեր։ Հակառակ դեպքում կցուցադրվի «name=value ✕ (
‹position›)» հաղորդագրությունը։ - Դատարկ արժեքներ. Եթե տարրը չունի արժեք, գրանցվում է «
‹tag›=∅ (‹position›)» սխալը։ - Անվավեր արժեքներ. Ոչ վավեր տվյալների դեպքում ցուցադրվում է «
‹tag›=‹detail›✕ (‹position›)» հաղորդագրությունը։ - Սխալ հասցեներ. Եթե հաշվետվության URI-ն սխալ է ձևակերպված, համակարգը նշում է «URI ✕:
‹tag›(‹position›)»։ - Չգրանցված տարրեր. Ցանկացած անհայտ տարր, որը չի ճանաչվում ընդունող սերվերների կողմից, նշվում է որպես «Անհայտ:
‹tag›(‹position›)»։
Եթե DNS-ից պատճենված տեքստը պարունակում է չակերտներ, գործիքը միացնում է այդ հատվածները նախքան վերլուծությունը՝ ցուցադրելով «Չակերտների մեջ գտնվող DNS TXT հատվածները միացվել են վերլուծությունից առաջ։» նշումը։
Տվյալների մշակում և գաղտնիություն
Այս գործիքն ամբողջությամբ աշխատում է օգտատիրոջ սարքի վրա։ Ձեր ներկայացրած DMARC գրառումը մնում է բացառապես ձեր դիտարկիչում։ BroBroGo-ն չի վերբեռնում, չի պահպանում և չի փոխանցում ձեր մուտքագրած տվյալները որևէ արտաքին սերվերի։ Մուտքագրված տեքստը չի գրվում նաև դիտարկիչի տեղային հիշողության մեջ։
Հաճախ տրվող հարցեր (FAQ)
Ի՞նչ սահմանափակումներ ունի մուտքագրվող տեքստի չափը։
Գործիքն ընդունում է մինչև 20,000 նիշ երկարությամբ տեքստ։ Եթե ներկայացված գրառումը գերազանցում է այս սահմանաչափը, կցուցադրվի «Այս գրառումն անսովոր մեծ է։ Այն պահեք 20,000 նիշից կարճ։» սխալը։
Շարահյուսության և քաղաքականության նշումներ: p / sp / np?
p=none · t=y · np → sp → p։
RFC 9989: pct / rf / ri?
Ոչ։ Այս էջը ստուգում է միայն ձեր տեղադրած տեքստը։ Այն DNS հարցում չի կատարում, չի բացում մատակարարի գրառումները, չի ստուգում ուղարկողի IP-ն և չի հաստատում, թե ինչ կվերադարձնի ընդունող փոստային սերվերը։ RFC 9989: pct / rf / ri → historic; np / psd / t → active։
Անթերի արդյունքը ապացուցո՞ւմ է, որ իմ DMARC կարգավորումն աշխատում է։
Ոչ։ Այս էջը ստուգում է միայն ձեր տեղադրած տեքստը։ Այն DNS հարցում չի կատարում, չի բացում մատակարարի գրառումները, չի ստուգում ուղարկողի IP-ն և չի հաստատում, թե ինչ կվերադարձնի ընդունող փոստային սերվերը։