Todd,

I think you nailed it!   Just completed a test with Comcast offlist and it was clean this time so I think the a: instead of the IP4: caused a reject as you've suggested.  Good job!

And thank you for your help!

Jerry



At 02:14 PM 7/20/2018, Todd Weltz wrote:
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)

Reply via email to