We'd love to hear about it! Click here to go to the product suggestion community
I understand that there is another topic essentially identical to this one, but that thread was insufficient and did not answer the question, unfortunately.
I noticed this morning that an email from a sender who is on the allow list was quarantined by the "Spam Medium" anti-spam policy. The thread I mentioned above linked to this page which shows the policy message flow, but it makes no sense.
According to the message flow, the "Anti-Spam" policies should be some of the last policies taken into account - well after the allow list. So, I am confused as to how an email in the allow list managed to be caught by the last recognized policy.
Is that document no longer valid? Are there additional steps to force the allow list to be taken seriously by the system?
Any assistance would be greatly appreciated.________________
Virtual Email Appliance v188.8.131.52
I have this same issue as well and was given that link. My problem is that white lists or allow lists should occur first or at a minimum only after virus scanning. I should be able to manually set the order of processing of the different policies like most other email av/ security software does.
I did see this recommendation, though I did not try it:
Create an Additional Policy using "Watch list" then add the email address **@domain.com and **@*.domain.com on the include sender then select deliver immediately for the action.
In reply to April Beachy:
The policy flow is as you'r link describes. However I would agree it needs a little photoshop loving.
Filtering options / perimiter protection MTA / Block lists (blacklist) threat protection datacontrol
rule #2 additional policy
spam checking user controlled black/white list ToC URL rewrites
If you add a user to the whitelist than you are only overriding a spam hit.. If you have an additional policy or a data control rule that comes before spam checking than those rules would apply first.
the watch list rule would work for the envelope from, not the data from. Chances are if your getting unexpected results you may need to try a normal header rule and use the From field.
If you export logs to a syslog server, the messages log will show you every rule the message hit against, the UI will only show you the rule that triggered the end action as each message can only have 1 final result.
rule add banner, rule search for text (continue processing), rule clone message (send a copy to server x), rule quarantine .. In this case all 4 rules are hit but the rule with the action of quarantine would be the result of the message..
so you could have a message that hits multiple rules, but only one action.. that action is determined by the priority of the rules as listed above.
In reply to Red_Warrior:
While I appreciate the response, it doesn't answer my question.
You say that the user controlled whitelist only overrides emails that would otherwise be caught by the antispam rules, correct? As I noted in my original post, my precise issue is that it is the default "spam medium" rule that is catching these emails that are listed in my whitelist. So, if what you say is correct, my whitelist entries should override the "spam medium" policy - but they aren't.
I understand that I can probably create some hodge-podge policy to achieve the sort of functionality I am expecting, but as I understand it, this is the intended function of the user controller allow list - so my concern is that the understood message flow is not behaving normally.
In reply to Austin Blevins:
That's correct, however your question can not be answered without a sample of the email and access to the appliance.. For this you would need to release the message to yourself.. create a new message, drag and drop the message as a .eml attachment and send it to email@example.com.
Unfortunately there could be many issues here, it could be configuration on the appliance itself, per user white/block list or even an issue with false positive or a labs rule. The only way to be sure is to get the sample, inject it into the appliance and evaluate the results and or send the sample to labs for confirmation.
Let's assume the issue is not related to the individual email, seeing as all emails appear to equally ignore the mail-flow in regards to my allow list I feel it is most probable to be a configuration issue. Further, I operate two different virtual email appliances for different companies that both behave the same way.
So, under the assumption that it is a configuration issue, are there any common underlying issues that affect the order of mail flow? Or any common issues that affect the functionality of the allow/block lists? Is there any known cause for the allow list to be ignored?
Or, perhaps, are there even any common problems new users to Sophos run into in regards to installation and configuration? Things that get overlooked. Anything that I can look into while I wait on further tech support from Sophos.
There are no known development issues with allow/block and it is working as expected.
adding a domain to hosts will allow envelope senders from that domain to connect
adding an email address to the senders will scan the DATA from after the message is accepted. In terms of policy the hosts is done at connection level the senders is done close to the end of policy.
If you wanted to prevent someone from your domain
add : yourdomain.com to the hosts file and @yourdomain.com to the senders list ..
This would prevent any MTA that resolves to or connects from yourdomain.com externally.. and during message processing any message From: yourdomain.com in the DATA field (the From in your outlook) would be dropped.
Common mistakes include reversing the senders and hosts, or not getting all of the message headers and adding the incorrect envelope sender .. as a general rule spammers will not make it easy and may spoof their domain, create fake dns entries and or mask their ips in various ways.
This is why the message submission is required to properly troubleshoot the issue, the received from headers in the email its self is what is required.