Getting increased amount of spam on 9124 versus 8930.

Do you have some example EMLs we could take a look at? I know they won't help us simulate rDNS/forward confirm but they may allow us to find examples of it happening in our own environments that we can use to find a solution for you. 

what email do you prefer to receive them on?

RFC2317 (Classless IN-ADDR.ARPA delegation) specifically permits and encourages the use of CNAMEs in this scenario.

RFC2181 (Clarifications to the DNS Specification) clears up the confusion relating to the statement 'PTR records must point back to a valid A record, not an alias defined by a CNAME.

Yes, per RFC, "PTR records must point back to a valid A record, not an alias defined by a CNAME."

@Kyle, do you need any more info from me?  I could send you .EML files but they would just have the IPs listed above which fail FCrDNS at MultiRBL but don't get scored in SmarterMail. Thanks.

If I'm understanding correctly I don't think I should even need the EMLs most likely. Just to confirm, you're using this option in SmarterMail here correct?

And with that in place you're seeing them not be scored though the rDNS links back to a CNAME? Thank you!

Kyle, yes, that's exactly how we have Reverse DNS configured (our scores are a bit different).

And we're not seeing any scoring on messages that the Forward Confirm of rDNS uses a CNAME. According to RFC and MultiRBL, the FCrDNS should use an A record. So this is one way spammers are sneaking thru. Thanks!

I have been using forward-confirmed DNS on both HELO and RDNS for a long time.  I can provide a Python script, callable from Declude, if others want to start using fcDNS tests immediately.

I don't understand why CNAME matters, and have never tested for it.   I would be interested in having someone clarifiy that concern.

For verifying server names, I assume that the server name is verified if:

- fcDNS on HELO is true, or

- fcDNS on ReverseDNS is true AND the HELO name is in the same PSL organization as HELO.

(EDIT:  In the statistics below, the middle statistic was originally mislabeled.)

I don't use fcDNS results directly for dispositioning, but they are a powerful clue.  These are my results:

121% HELO unverified

4.3% ReverseDNS verified but unrelated to unverified HELO

63.8% HELO verified by fcDNS directly

Note: Outlook.com is the primary source of indirect verification, because their HELO names never confirm but ReverseDNS names always do and both names have the same parent domain.

Here are my percentages for messagse that are allowed to proceed to content filtering, after all sender verification tests are applied:

HELO verified directly, 90% allowed

 ReverseDNS verified but unrelated to unverified HELO, 7.1% allowed

HELO not verified, 2.9% allowed

More spam today from IPs that fail FCrDNS, but unfortunately the messages don't receive a score for failing.

Example: https://multirbl.valli.org/lookup/185.126.176.218.html

More spam today from this IP: 103.129.199.34

It has a Reverse DNS/PTR = clcconstruction.emory.edu (good)

But the Forward Confirm uses a CNAME (not good). 

MultiRBL shows FCrDNS Failed as no A or AAAA records:

Can we fix SmarterMail's FCrDNS test so it works like MultiRBL? This would help us fight spam. Thanks.

Thanks for providing additional details on this Kevind. We have a task to do some deeper testing on this over the next few days now that we have release testing completed so with any luck I'll have some news for you later this week.

Great, thanks for update. A fix for this will help everyone reduce spam.

Coincidentally, receiving messages today on how to cut my electric bill by 90% thanks to Elon Musk!  These messages fail FCrDNS but are not getting scored.

Sorry for the delay in follow up on this. We've simulated similar tests in-house but we're not seeing anything out of the ordinary. I think our best bet might be getting a ticket going for you so we can gather live details and have development review further. I do believe Douglas is right most likely in that this is more a DNS concern, but we'd love to handle it better if we can as always!

Kyle, this shouldn't be that complicated. Basically spammers are using CNAMES and that fools SmarterMail so it doesn't score FCrDNS. Example:

Just trying to help SmarterMail be better at blocking spam.

Another idea is to implement this idea:
https://portal.smartertools.com/community/a96231/expand-dmarc-options-scoring.aspx

Thanks.

It is that complicated, unfortunately. Without being able to replicate in house we need to collect enough detail from a live case to justify pulling developers off of their projects to investigate. If I can't prove the issue isn't stemming from a localized DNS behavior then I lack the requisite details to escalate to them in most cases. I can work around that if we have information from an affected environment but collecting those here could be a privacy concern since it'll involve logging. 

The reason being; I could see a situation where the DNS result being passed back to SmarterMail is ignored (for whitelisting or whatever other reasons) leading it to look as if we're not scoring these messages when we might be normally. I need to eliminate that (and any others) as a possibility before I start pinging developers :) Thank you.

Reverse engineer the case and use a third party domain for testing in which you can handle DNS and setup the cname record.

It should be fairly easy to replicate.

Mail comes in from this IP:  103.129.199.34

In example provided by kevind, FCrDNS check should fail as there are no A records for clcconstruction.emory.edu pointing to IP 103.129.199.34.

Are there any other tools besides "multirbl.valli.org" that demonstrate this behavior. I haven't looked through any RFC's yet but this is typical DNS behavior. The RFC mentioned above is only proposed (from 1997) and was never accepted from the looks?

Non exhaustive list

Changing code to implement this test will have performance implications, so the question of effectiveness cannot be ignored.   I don't check for CNAME, but I do collect data on Helo verification, which can be achieved in one of these three ways:   

Since the Reverse DNS name is often the ISP, the fcDNS on the Reverse DNS name means very little to me unless it can be linked to the HELO name or can be linked directly to a blacklist entr y.

Based on 600,000 messages from 35000 unique IPs, I have this relationship between HELO verification state and disposition based on sender reputation:   Rows total to 100% horizontally,

 

All of which says to me that weighting based on fcDNS alone is not very effective, so refining the test based on CNAME will add very little value.   I am happy to be convinced otherwise, with evidence.