Talk:DMARC

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Cleanup[edit]

I tried to clean up the English in the last paragraph of the History section. I wasn't sure whether "heathened debate" was intended to mean "heated debated" or not, so I changed it to "significant debate" after looking at a few of the posts at the link. As for "making process," I couldn't figure out whether that was intended to refer to the creation process, the design process, or what, so I left it as-is. Palmpilot900 (talk) 15:55, 22 April 2014 (UTC)[reply]

This page has some issues! There are minor editorial problems with the language (what is a "dismissed address"?), but I think the whole structure of the page needs rethinking and expanding. The section "The Underscore Issue" is at too high a level, and its mentioning of a tiny handful of specific registries seems out of place (and likely to become outdated quickly). Time permitting, I will endeavor to clean it up. TobyGoodwin (talk) 10:04, 7 May 2015 (UTC)[reply]

I agree, it's overly specific, and I cannot find any references that support that 1&1 doesn't support it --TmuSrnn (talk) 12:23, 15 January 2016 (UTC)[reply]

I suggest that we add two things;

  • Main difference to the widely known SPF records; DMARC checks From: whereas SPF checks envelope (MAIL FROM
  • Mention of the public suffix list https://wiki.mozilla.org/Public_Suffix_List/Uses#DMARC that enables DMARC to make "intelligent" decisions about organizational domains

TmuSrnn (talk) 11:54, 29 Dec 2015 (UTC)

Registrars have nothing to do with names of subdomains or RRsets[edit]

I propose the section on registrars be removed or modified. I do not think that types or identifiers of RRs or RRsets of subdomains is the purview of a registrar. The only exception is of course the subdomain of the domain they are selling, such as .org or .co.uk. Their responsibilities end at nameserver and zone signing delegation. If, on the other hand, the registrar is also providing DNS services for the purchased domain(s), OK, then they may be introducing their own restrictions. But as far as I know, there are no domains which require the registrar to provide DNS services beyond the mentioned delegations. In other words, they don't (have to) know or care that I have a _demarc.surname.us in my zone, unless as noted they are also providing DNS service for surname.us. -- Joe (talk) 19:49, 20 November 2015 (UTC)[reply]

 Done. Good point, Joe. I've changed the wording from "registrar" to "provider". Pelagic (talk) 11:47, 22 May 2016 (UTC)[reply]
Actually, another user had previously changed (Jan 2016) "registrar" to "DNS" for this section, but either missed the third instance of "registrar" or was unsure whether the change was applicable for CNAME. Pelagic (talk) 19:03, 23 May 2016 (UTC)[reply]

DKIM SSP[edit]

I'm wondering about the relationship between DKIM SSP and the sender-policy part of DMARC. Here is a reference for the former:

  • Allman, E.; Delany, M.; Fenton, J. (2006-08-30). "DKIM Sender Signing Practices [allman draft 02]". IETF. Retrieved 22 May 2016.
p= unknown / all / strict; u= yes/no; t= y,s;

Pelagic (talk) 11:30, 22 May 2016 (UTC)[reply]

Ah, SSP became ADSP. Note that there are 3 versions of draft-allman-dkim-ssp and 11 of draft-ietf-dkim-ssp. Final draft was number 10, which became RFC 5617:

dkim = unknown / all / discardable

Pelagic (talk) 12:48, 22 May 2016 (UTC)[reply]

Okay, moving ADSP to Historic status was officially unrelated to the rise of DMARC,[1] but several people on the IETF mailing list felt that it was.[2] (I got the first link from the ADSP article.)
ADSP spec. was written by Allman (Sendmail), Fenton (Cisco), Delany (Yahoo), and Levine, whereas DMARC was submitted to IETF by Kucherawy and Zwicky (the latter also from Yahoo).
ADSP's unknown/all/discardable can be seen as equivalent to DMARC's none/quarantine/reject, but the former says "this is how we sign" whilst the latter says "this is what we want you to do".
Although they were separate and in some ways competing, I find it odd that this article doesn't mention ADSP much. I'll try to remedy that when I get time, but anyone reading this might want to have a go.
Pelagic (talk) 19:33, 23 May 2016 (UTC)[reply]

Miscellaneous issues[edit]

Relating to the current version:-

  • The following sentence, whilst not unfactual, does sound a bit promotional, like something that would come from an industry consortium: "A group of leading organizations came together in the spring of 2011 to collaborate on a method for combating fraudulent email at Internet-scale, based on practical experience with DKIM and SPF." Is there a way we could make this more encyclopedic in tone without sounding awkward?
  • Heading "human policy" – I'm not quite sure what this means or how it relates to the content. Seeking a better section head. Also, the lengthy material about remailers (not sure if that's the correct term, I'm referring to mailing lists, share-via-email, etc.) deserves its own section [yes, I admit that I contributed to its lengthiness!].
  • Contributors. Are all of the listed companies actually contributors to the spec as the first sentence states? Or are some of them just implementers/adopters? (e.g. Microsoft, Twitter, Symantec) Need to check the PDF cited.
  • "After one year, in 2013, DMARC was estimated to protect 60% of the world's mailboxes" – though the statement is sourced, "protect" could do with some more explanation, maybe?

Pelagic (talk) 20:18, 23 May 2016 (UTC)[reply]

The article has had so few editors in recent years that why don't you just go bold? — kashmiri TALK 22:32, 23 May 2016 (UTC)[reply]

Example DMARC report[edit]

Adding a report in full takes a noticeable amount of space, possibly distracting a reader from more relevant aspects. It gives the unsubstantiated impression that reports consist of a few records only. It mentions acme.org, which is not obviously an example (as examle.com) but has no DMARC DNS record. It is copied and pasted verbatim from dmarc.org, which is not allowed by wikipedian policies. Hence I remove it. ale (talk) 09:29, 7 October 2016 (UTC)[reply]

DMARC support among receiving mail servers[edit]

I suggest adding a mention of how many ISPs/mailbox providers support DMARC (ie check incoming messages for DMARC records and enforce the published policy if there is one). It's currently about 4.8 billion mailboxes, or 76% of the global total. Data on this can be found at the following URLs:

Disclosure: I helped compile this data, which is why I'm suggesting it here instead of adding it directly to the page.

Dtweney (talk) 23:29, 24 October 2017 (UTC)[reply]

Do you have the DOI for your final, released study of compiled data? Please advise.
 Spintendo  ᔦᔭ  00:51, 7 December 2017 (UTC)[reply]

Suggest rewording of reports paragraph[edit]

"DMARC is capable of producing two separate types of reports." -- at the risk of being pedantic, "DMARC" per se does not produce reports. Can we reword this to something like "DMARC provides a mechanism by which receivers of messages can send optional reports to the domain owner containing information about the impact of the sending domain's DMARC policy." ? — Preceding unsigned comment added by Chconnor (talk • contribs) 19:21, 14 May 2018 (UTC)[reply]

Trim and tidy[edit]

I've done some extensive editing recently, including some pretty brutal pruning. Very happy to have any errors I've introduced fixed, and by all means add back in good information if it's needed - but please make it clear and readable. - Snori (talk) 08:04, 21 December 2018 (UTC)[reply]

SPF Limitation?[edit]

This was added under Compatability. However (a) while it's an interesting feature of SPF, it has nothing to do with DMARC compatabiliy. Yes, DMARC partly relies upon SPF, but a "good" SPF record won't cause 10+ loookups. Of course we're always going to have to deal with failed, broken, or poorly written SPF records - but that's not really a problem of SPF - and even less so of DMARC.

5321.MailFrom and 5322.From alignment claim[edit]

I can't find any source for the 5321.MailFrom and 5322.From alignment claim and it's contrary to the result I see - Gmail shows a passed DMARC test if the SPF check form 5321.MailFrom is passed and the DKIM check on 5322.From is passed, even if the domains for 5321.MailFrom 5322.From are totally different. What is more, DMARC FAQ states: "Give the third party a DKIM private key to sign the emails and publish the public key in your DNS and/or add their sending IP, maybe via a SPF include, to your SPF record.", what implies, that a DKIM key for the 5432.From should be enough. GL1zdA (talk) 15:58, 6 April 2020 (UTC)[reply]

Inconsistent information regarding alignment checks[edit]

These are contradictory statements.

In the Overview section:

a message can fail even if it passes SPF or DKIM, but fails alignment

A few sentences later, in the Alignment section:

If either SPF or DKIM alignment checks pass, then the DMARC alignment test passes.

One or some of these scenarios should be correct, but I'm not sure which ones. 1) DMARC passes on either SPF or DKIM pass. 2) DMARC fails on either SPF or DKIM fail. 3) DMARC passes when both SPF and DKIM pass. 4) DMARC fails when both SPF and DKIM fail. 5) DMARC runs its own check, and will pass if both SPF and DKIM pass. 6) DMARC runs its own check, and will fail is either SPF or DKIM fail. 7) DMARC runs its own check, and will pass if either SPF or DKIM pass. 8) DMARC runs its own check, and can pass even if SPF and DKIM fail.— Preceding unsigned comment added by 68.34.6.139 (talk) 2020-04-18T09:25:50 (UTC)

Naming: should conform with SPF and DKIM[edit]

We should pick one "standard" and stick with it. — Preceding unsigned comment added by 195.67.91.199 (talk) 11:31, 25 November 2021 (UTC)[reply]

DMARC is not a protocol or substantial method, it is merely a few words of advice about policy[edit]

The intro starts out quite misleading, as if DMARC was some kind of software package you have to implement. RFC7489 even introduces it as a mere expression of sender policy and preference, and that's what the lead sentence should say. SPF and DKIM are the elements and work without a DMARC record. Richard J Kinch (talk) 09:40, 5 September 2022 (UTC)[reply]

Sentence fragment: what does this mean?[edit]

"One of the reasons why email forwarding can affect DMARC authentication results." Huh? Equinox ◑ 16:26, 24 March 2024 (UTC)[reply]

Ch Ahmed[edit]

Ch Ahmed zaman 103.229.253.50 (talk) 05:22, 28 March 2024 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:DMARC&oldid=1215960434"