|Email Plug-in (Reporting):||1.1.0-129|
|Email Plug-in (Encryption):||1.2.1-151|
according to the documentation, when you set SPF conformance level to SPF only, no PRA identity verification takes place (as that is part of the outdated SIDF).
At the same time, the documentation also mentions this:
You can only use the spf-status message filter rule to check results against HELO, MAIL FROM, and PRA identities. You cannot use the spf-status content filter rule to check against identities. The spf-status content filter checks only the PRA identity.
Does this mean if conformance is set to SPF (not SIDF-compatible), I *have* to use message filters and can't use content filters?
Thanks Pratham. Is it possible this information/documentation is outdated? Because I have set up content filters and they seem to work just fine on MAILFROM and HELO identities. AsyncOS 12.5.x, set to SPF conformity. Logs contain SPF status based on MAILFROM and HELO and content filters are applied. The filters work fine.
yes, our ESA is pushing mails into a quarantine that only show SPF MAILFROM in the logs. We actually never see any mention of PRA at all in the logs. Which would be logical to me, as PRA - as I understand it - is part of SIDF. Which is disabled when you set conformity to SPF only (not SIDF compatible).
That's why I am wondering.
Why are the other identities not available in content filters, anyway?
I was able to check on the user guide for Async OS version 12.5 and it mentions as below:
"You can only use the spf-status message filter rule to check results against HELO, MAIL FROM, and PRA identities. You cannot use the spf-status content filter rule to check against identities. The spf-status content filter checks only the PRA identity."
So I am not sure what is causing the emails to get quarantined with SPF only since it doesn't check the PRA identity. Maybe you can open a TAC case and provide more details to investigate further on this on the case.
For the other identities, not available in content filters are something which development teams are looking under the enhancement request as below:
Thanks. This enhancement request has been open for four years. To be honest, I am starting to get fed up with Cisco and all the little inconsistencies in ESA. Just like the other bugs I reported about. Does Cisco ever fix any of them?
I am starting to wonder if it was the right decision to go with Cisco for email security.
We had a defect a few years back where the SPF content-filter would only trigger against the first SPF verification within the headers (commonly PRA). However, this was supposedly fixed back in 9.7.2 and 10.0, and now the SPF content filter should trigger against any/all verdicts. So, if you're seeing unexpected behavior then it may be configuration related or something else within these emails. As mentioned, it may be best to open a case so that we can help investigate.