On Fri, 22 Nov 2019 at 12:45, Jaroslaw Rafa <r...@rafa.eu.org> wrote:
> Dnia 22.11.2019 o godz. 11:40:29 Dominic Raferd pisze: > > > > The limitations you describe affect SPF but not DMARC because DMARC can > > rely *either* on SPF *or* on DKIM. > > But it probably depends on how the *recipient* configured DMARC checking > and > the sender can't do anything about it - am I right? > > Recently I was forced to set up both SPF *and* DKIM on outgoing mail (I > still don't verify SPF, DKIM nor DMARC on incoming mail and don't plan to) > because someone set up a DMARC record at my parent domain, eu.org, and > Google started using this DMARC record to verify messages coming from my > domain rafa.eu.org (which it shouldn't do because eu.org is a "public > suffix" - anybody can register their subdomain under eu.org - so my domain > "rafa.eu.org" is an "organizational domain" in terms of DMARC, ie. the > receiver should not look for DMARC records above that domain). Because I > didn't have neither SPF nor DKIM, my messages started to fail DMARC tests > at > Gmail (which could be probably one of the reasons Gmail started to put my > messages to recipients' spam folders - I'm not sure because I did many > different things trying to resolve the issue and get out of spam folder, so > I'm not sure what actually helped). Configuring SPF alone didn't help - > Gmail still indicated DMARC as failed, I had to configure both SPF and DKIM > to satisfy it. > > BTW, as I don't like SPF, I configured my SPF record with "?all" at the > end, > which means "I have no opinion about other IP addresses sending mail for my > domain, do whatever you would otherwise do with them". I think this is the > proper way SPF should be used, if it must be used at all. The currently > omnipresent "-all" at end of SPF records is in my opinion justified in only > one case: when it's the only item SPF record specifies, ie. the domain > declares it sends no mail at all. And it's the only case when receivers > should strictly respect SPF and outright reject all mail coming from such > domains. In all other cases, if the domain sends *any* mail, that mail can > be forwarded; so "-all" doesn't make sense. > I am very surprised to hear that such a big (and generally competent) provider as Gmail would misapply DMARC. Nevertheless as I read the RFC at 3.2 and 6.6.3 I agree that the process of locating a DMARC record should not proceed below the Organizational Domain which in your case would be [n]. eu.org (based on latest from https://publicsuffix.org/list/public_suffix_list.dat). My guess is that the Gmail code just carries on stripping labels from the left-hand side of the domain address and testing what is left until it finds a DMARC record, hence it finds the record that should not be, but is, published for eu.org. Or they may use a different source for their public suffix list. Even so, the eu.org DMARC policy is 'none' so it is *not* advising receiver to quarantine or block emails that fail the DMARC policy (which begs the question of why bother with a DMARC policy at all of course). I suppose it is possible that Gmail use a DMARC fail even with p=none as a point-score in their internal algorithm to determine whether to move an email to a recipient's spam folder. BTW, I dislike SPF too!
