Strictly following the SPF RFC would require rejecting the message as a PERMERROR without even analyzing the mechanisms.
After retrieving records, the first check is check_host to evaluate the record itself - The syntax of the record is validated first, and if there are any syntax errors anywhere in the record, check_host() returns immediately with the result "permerror", without further interpretation or evaluation. After that, individual terms begin being evaluated. A lot of systems are configured in a more relaxed way and if the syntax of the record is correct and only an individual mechanism has an issue, they won't permerror unless they hit that mechanism because they haven't yet passed and completed the check. It seems the system in question is likely being more specific. In the end, it's probably not a major issue. You have resolved the error in the record, and that message didn't fail DMARC, it passed DMARC on the DKIM portion. On Fri, Jul 20, 2018 at 1:57 PM, Jerry Warner via dmarc-discuss < dmarc-discuss@dmarc.org> wrote: > > I don't have anything else on the fail. That report from Comcast is all I > have. Yes, that is the IP on the mail server. I don't know how Linkin is > tied to this. They don't send mail on our behalf. I guess Comcast could > have seen the bad a: on the SPF record and failed it just from spite <g> > since the IP4 listed wasn't even involved. No one else had failed email > because of that. This is the first time I've seen a failed DMARC from > something that originated from our IP. > > Not knowing anything about the emails that fail is frustrating because it > means it's really hard to fix. I don't get any more information than that > on anything. > > > > > > At 01:38 PM 7/20/2018, Ken O'Driscoll via dmarc-discuss wrote: > >> On Fri, 2018-07-20 at 09:30 -0400, Jerry Warner wrote: >> > Posting it in text just now I see a link for Linkedin. I'll take that >> as >> > a clue. OK, did a search of the mail logs for that date. Nothing with >> > "linkedin" is listed in the logs. >> >> Are they not details an aggregate report from LinkedIn? I thought it was >> Comcast that sent the report? >> >> If that's the IP (24.142.161.51) that was reported having a PERMFAIL on >> the >> SPF in the original report you posted, then my money is still on that >> being >> caused by your faulty SPF record. Even if that wasn't the IP that had the >> incorrect entry. >> >> > Without knowing something about the email it would be pretty hard to >> find >> > it in the server logs. There isn't even a time listed. >> >> Aggregate reports are not intended to give that level of detail and >> forensic reports, which are, are rarely supported because of previously >> mentioned privacy concerns. >> >> A thorough understanding of your mail flow combined with aggregate reports >> is usually sufficient to see exactly what might be breaking DMARC policy. >> >> Using separate selectors for DKIM (e.g. one for service desk emails etc.) >> can also be a useful strategy to help get more value from aggregate >> reports. >> >> Ken. >> _______________________________________________ >> dmarc-discuss mailing list >> dmarc-discuss@dmarc.org >> http://www.dmarc.org/mailman/listinfo/dmarc-discuss >> >> NOTE: Participating in this list means you agree to the DMARC Note Well >> terms (http://www.dmarc.org/note_well.html) >> > > > _______________________________________________ > dmarc-discuss mailing list > dmarc-discuss@dmarc.org > http://www.dmarc.org/mailman/listinfo/dmarc-discuss > > NOTE: Participating in this list means you agree to the DMARC Note Well > terms (http://www.dmarc.org/note_well.html) > -- Todd Weltz, Software Developer twe...@agari.com l M: 416.471.8633 l www.agari.com Changing Email Security For Good
_______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
