Have a look at /etc/postfix/access, but these domains aren't valid. Also have a look at More anti-spam and e-mail defence measures. I am a fan of the Graylisting app all but it is quite high maintenance as you need to manually whitelist more domains than you'd expect.

Thank you Nick.
I have had Greylisting installed for a number of years and found it works well. So I'm not sure how these get through.
I have also included most of the suggestions in the link provided. Thank you for this. Until the past week, everything worked well.
Two of my children are getting these spam every few minutes. At most, 2 emails are sent from one IP address. I'm collecting the IP addesses to see if I can find a pattern but so far I can't see it.
I have been using spamhouse and barracudacentral. I know these help a lot.
The SPAM header is showing up in the SUBJECT so they can filter them to the Junk folder but it is annoying. I will try lowering the discard threshold and hopefully that will reduce the problem.

Did you look at /etc/postfix/access and read what was in there?

Oh very interesting. I'm going to have to find some examples to get my head around this. Thank you very much Nick. This may be exactly what I'm looking for.

I haven't been able to find many examples of what this access file is supposed to look like. I guess my limited knowledge shows itself here.

Before I go and completely screw up the mail server by changing the access file, would you mind commenting on the following regex?

In the access file, to match 6 digits followed by a "dot" followed by 6 digits followed by "@" followed by 5 digits followed by ".com" to match the pattern: "902185.902185@62495.com"

#Address patterns            #Actions    

\d{6}\.\d{6}@\d{5}\.com    REJECT

I've googled "postfix access pcre" and it comes up with some interesting links such as https://serverfault.com/questions/765848/postfix-check-sender-access-map-ignored (with an example for testing), and perhaps https://serverfault.com/questions/972173/unsupported-dictionary-type-pcre-postfix-header-checks. Also try "man regexp_table".

It looks like regex's should be between and opening and closing / and there are examples for testing.

I think if you use the standard access file you use regex's and have to hash it with "postmap /etc/postfix/access", but not if you use a file access.pcre with pcre's. Check "man pcre_table"

To start with I would use the action "WARN" and just check the logs that you are not blocking stuff you want and would block the junk., then change it to REJECT when you become confident.

If this does not stop them, also have a look at /etc/postfix/header_checks. AFAIK, access comes into play when someone connects to your server, before even the headers are sent. header_checks appear a little later on in the mail receiving process.

Nick,

I was about to run a test and find that I have:

smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unknown_reverse_client_hostname, check_client_access pcre:/etc/postfix/fqrdns.pcre

Is it OK to have multiple check_client_access records followed by each other? ie.

check_client_access pcre:/etc/postfix/fqrdns.pcre check_client_access hash:/etc/postfix/access.db

or perhaps 

check_client_access pcre:/etc/postfix/fqrdns.pcre hash:/etc/postfix/access.db

Or should I be adding this regex to the fqrdns.pcre? I think this one gets updated by system updates?

**updated to add some additional thoughts**

I would have thought it was fine to have multiple checks, but comma separated, so:

check_client_access pcre:/etc/postfix/fqrdns.pcre, check_client_access hash:/etc/postfix/access.db

, or you could put everything in one file.

I've no idea where you have got the pcre check from. I've never seen one in ClearOS. Googling fqrdns.pcre returns a lot of hits so I think it is something you've set up before. If you have a regular updater for the file then you can't add your settings to it. Also you need to check your sources and perhaps adjust them as it looks like the original project has not been updated since 2015, but there are forks of it.

[edit]
Accirding to this (good thread), you should be using check_reverse_client_hostname_access instead of check_client_access.
[/edit]