|Email Plug-in (Reporting):||1.1.0-129|
|Email Plug-in (Encryption):||1.2.1-151|
Need your help for below query:
If sender IP does not belong to sender domain or you can say MX record is invalid for sender domain mails should be quarantined or rejected.
Sender Verification already enabled in my mail flow policy but default action is accept so here i want to achieve my requirement with incoming content filter.
Thanks in advance for your help.
I think comparing sender IP and MX record is not very good idea. SPF records are used to checking if sender's email server is allowed to send email on behalf of particular domain.
You can create Incoming Content Filter and set SPF Verification for each message:
What are the SPF Verification results to match?
Then you can create action for each verification result if you'd like to.
Thanks for your response.
In my environment i can not use SPF because lot of senders do not have SPF TXT record for their domain and result of that all mails coming from them will not pass SPF verification.
I am looking for incoming content filter rule which can verify sender MX record belonging to sender domain or not.
mail received from "firstname.lastname@example.org" mail id and sender MX record for test.com is "mail.test.com"
here my incoming content filter should check if "mail.test.com" MX record doesn't belong to test.com mail should be quarantined or rejected.
SPF is much better option. I know some companies are still not using it and others breaks it. But it's a better choice :)
MX records are by design used for incoming email only.
Many companies send legitimate emails from many sources, not just from receiving email server.
Many companies use one server for receiving (MX record) and another server for outgoing emails (normally "only" A and maybe PTR record).
Even RFC doesn't require valid MX record for sending valid email.
What's the core issue you've been experiencing? Can't you solve it with fine tuning anti-spam parameters?
Actually the core issue is we already using SPF verification because of that everyday hundreds of mails getting quarantined and consuming our man power to release them.
Now we have two options either remove SPF verification which will cause security risk or verify sender domain by their MX record.
I'd rather fine-tune anti-spam parameters (Positively Identified Spam and Suspected Spam values at least).
For example: you can deliver suspected spam emails to user mailboxes and add a subject tag/header values to those messages. And then create new rule in Outlook (or other email client) to move these messages in JUNK folder.
If you're using AD you can let users access their own SPAM quarantine on ESA and release emails from it.
You can use outlook plugin for users to help ESA learn what are good and bad emails.
You can fine-tune SFP rules: what to do if message soft-fails, what to do if message fails etc.
I have no idea how anti-spam will take place of SPF verification but if you can help me i really appreciate.
As of now users are able to release spam quarantined mails but there is no such option in ironport for SPF quarantined mails (storing in policy quarantine), if you have any solution for that please share.
Policy quarantine is centralized only as you already know.
My suggestion was to disable SPF checking completely (you said you don't get satisfied results) or maybe fine tune it (block only emails that hard fails - companies are breaking the rules they've set by themselves).
And then use anti-spam (not related to SPF) settings to deliver (marked) suspected email to client Inbox and use spam quarantine further on (but only for "definitely" spam emails only).
I'd check message tracking to investigate properties of some random choosen false positive emails to see how can I fine-tine settings.
This may help you and Jernej as well.
But actually while you're correct -- when using content filters if you take action based on SPF results the only option would be to send it to policy quarantines (or custom quarantines) rather than the spam-quarantine where end-users have access to.
But if you do really wish to send these emails to the end user spam quarantine rather than policy quarantine, you can do so with the following content filter action.
Rather than select 'quarantine' action, select 'send to alternate destination host'
THen for the host, use -> the.euq.queue
The.euq.queue is the mail queue that sends emails to the designated spam quarantine, if you're using a centralized spam quarantine, it will deliver to the centralized spam quarantine, if you're running local spam quarantines, it will deliver there, but it will deliver to the actual end-user spam quarantine :)
Hope this helps.
I didn't know that - thanks.
I wouldn't mind if you could share some other hidden features (that can't be found in user guide and advanced guide) :)
I'd say it's more of mail manipulation over hidden features :P
Because if done wrong, it can cause some issues i'd say.
As for other things, off the top of my head from a common issue i see is something with blocking filenames of attachments or filtering a different list of senders.
Some people like to use dictionaries, i personally stay away from dictionaries as the results from it isn't something that is always consistent (to me anyway).
I like the use of message filters or content filters.
For example attachment file name.
Rather than create for instance 5 conditions for 5 different file names ,you can put something like this
Attachment file info -> file name contains ->
This is essentially the same as running 5 conditions, but all in one also gives you more flexibility with playing with conditions :)
The | (pipe) means "OR"
Message filter syntax would be similar.
You can do the same with envelope senders/recipients as well using the (?i)(name@domain\.com|name@domain2\.com) etc
It just comes down to the scenario that I can get some information on alternative methods so i wouldn't say its hidden :)
By hidden I meant I can't find "the.euq.queue" as the name of the spam quarantine in the docs (that can be even addressed directly).
And I know there are also some very handy CLI commands that are not listed when pressing question mark.
Sorry for misunderstanding.