I assume that your problem is:
- cloudspro.dk is an infrastructure service used by many legitimate clients
- alyssa@turbojot.com is an attacker who is exploiting the service.
So you need the ability to filter on the Reply-to header.
I spoke about the need for reply-to filtering here:
More generally, identifiers in the email message can have one of these roles:
- An infrastructure resource used by many clients. We should expect them to be a mix of acceptable and unacceptable actors.
- An entity who is using the infrastructure resource, who is responsible for the message
- An identifier that has been impersonated by the responsible identity.
As you have noticed, an infrastructure service can appear at many levels, including the entire From address.
Assuming that you have good filtering rules in place for known identifiers, all of your risk involves unknown identifiers which have no risk categorization.
For responsible identifiers that have no known reputation, our options are:
- Allow unknown identifiers by default, defend using a mixture of after-the-fact reviews, user complaints, and content filtering results. Some malicious traffic will penetrate. This is the mode that we have been taught should be our "normal."
- Quarantine unknown identifiers by default, allow or block after quarantine review. No malicious actor can penetrate. This is safer.
In either case, we cannot evaluate the reputation unless we notice the identifier. The reply-to address needs to be evaluated any time that it is different from the Return-Path address and the From address.
Infrastructure resources are a little trickier, because they probably have (or will have) clients that are acceptable. Inversely, they may not warrant full trust, even if we all of their observed clients are legitimate. So these should almost never be whitelisted and never blacklisted. So, quarantine by default is safest even if the experience has been good. Then the final disposition is based on the client, as long as the client identity has a known reputation.
All of this falls apart if you don't identify and block impersonation, and the only way to eliminate all impersonation is to authenticate everyone.