4
Disabling sender verification "shield" and popup
Question asked by Sébastien Riccio - 3/25/2023 at 2:04 PM
Answered
Hello,

This feature is a very nice plus to have, but for now we would like to be able to disable it.

We use front incoming gateways (not based on SmarterMail) that are doing all the spam checks and add specific headers to the mail before forwarding the mail to SM.
On SmarterMail we have all spam checks disabled except custom checks that are done on these specific headers so we can transfer the spam score into SM spam scoring system. It works very well.

The issue as you might have guessed is that as SmarterMail isn't doing any of the checks used by "sender verification" (SPF/DKIM/DMARC) itself, the information is therefore never available.

Until we find a  solution to tell SM to use the SPF/DKIM/DMARC check results from our incoming gateways to base it's sender verification results on, we would really prefer disabling this information in the webmail as it would lead to questions.

As a side question. Let's say we use external rspamd instances to do the spam checks as it is now available in SM, will the sender verification use the SPF/DKIM/DMARC check results from rspamd or does it still need to have SPF/DKIM/DMARC check also enabled (so double check?) in SM ?

Thanks in advance for the info.

Kind regards.
Sébastien Riccio
System & Network Admin

17 Replies

Reply to Thread
0
Douglas Foster Replied
Same here.

We also perform sender authentication at our incoming gateway.   We quarantine any message that does not produce SPF PASS or the equivalent from a local policy rule.  (No Policy, PermError, Fail, and SoftFail are equally unacceptable.)    It took a bit of concerted effort to get to this point, but it is proving to be pretty valuable for detecting some lazy spammers.    About one in five of the quarantined messages are legitimate and are given an SPF-equivalence rule.   Four out of five messages are unwanted and are given an always-block rule. 

Bottom-line, if the message gets to my mailstore server at all, it is as free of impersonation risk as I know how to make it, and I do not check SPF or DMARC there.  I don't want a spurious warning on every message.

Doug Foster
1
Sébastien Riccio Replied
Coincidently, while reading a recent post on the community:

I discovered that maybe, SmarterMail incoming gateways are adding a specific header to the mails it relays for passing spam handling results to the main SM server: X-SmarterMail-SmartHostSpam

Could this mean that if our incoming gateways also adds this specific header with the correct value, the information needed for sender verification could be passed to SM ?

For example adding (when all tests passed) and encoded in b64 if required by the new versions of SM:
X-SmarterMail-SmartHostSpam: _SPF=0,Pass|_DK=0,None|_DKIM=0,Pass|_DMARC=0,passed

If my assumptions here are correct, this would be a way to workaround it. I have then the following questions:
- Am I correct about this ?
- If yes, is there some documentation available about all possible _SPF,_DK,_DKIM_DMARC values expected by SM.
- Again, if yes, when SM finds and handle this header, how does it knows that the header was actually added to the mail by a trusted party (for example our incoming gateway) and not added by some 3rd party (let's say an ugly spammer for example).
EDIT2: After some more testing it seems that the 
X-SmarterMail-SmartHostSpam header is only parsed when the mail is received from a SMTP whitelisted host. Well done.

I'll do some tests though but a feedback from ST team would be great.

EDIT1: Huhu.. it works :) And this is great.

 
However, there might be some "security" concern to handle here, as I guess a malicious sender could fake this header but there are possible solutions for this:

- The incoming gateway, of course, could/should always overwrite this header, therefore any forged header would be replaced.
- A security layer could be added with some encryption on the field value with a key known only by both the incoming gateway and the target server.
- As the header is only parsed when the mail is received from a SMTP whitelisted host and if this SMTP trusted incoming gateway is not a SM gateway, it should make sure to remove/overwrite this header on any incoming mail to avoid a possible abuse.
 
Kind regards.
Sébastien Riccio
System & Network Admin

0
Hi Sebastien and Douglas!

If I'm not prying, can you share information about the antispam gateways you're using?

I'm experimenting with ProxMox Mail Gateway, but I think I'll start trying something else too...
Gabriele Maoret - Head of SysAdmins at SERSIS
Currently manages 3 SmarterMail installations (1 in cloud for SERSIS which provides service to a few hundreds 3rd party Mail Domains + 2 on premise to customers)
1
Douglas Foster Replied
I am using customized Declude.   Its SPF module has been replaced by the Python PYSPF module.   DKIM is implemented with the Python DKIMPY module, and DMARC is approximated with logic based on the other two.

My priority was a product that could do multiple-attribute rules.   To explain:  What happens when an SPF lookup for Exmaple.com returns PERMERROR because the domain owner has published two SPF policies?

- Many products allow you to implement a rule that says "ignore SPF for Example.com, and I will hope that malicious impersonators never impersonate Example.com"   That is not acceptable to me.

- Cloud products often say, "You don't need to think about that.   Our AI modules take care of it."   They were too pricey and I did not accept that answer either.

- I wanted to implement this type of rule:   "If host name ends with Outlook.com, and the host name is verified to the Source IP with forward-confirmed DNS, and the SMTP MailFrom domain is Example.com, then treat the message as equivalent to SPF PASS".   Few products can do this because vendors don't understand the problem.

I also knew that SPF errors are much more common than malicious impersonation, so I needed to start by collecting data without blocking messages.   Without data-collect mode, wanted messages will almost always be affected.    Do it enough times and your employment might be affected as well.  Surprisingly few products offer a data-collect-only mode.

Declude allows me to define multiple attribute rules, and it defines Tests independently of Test Actions.  This makes data collection possible.   I kept analyzing my data and configuring rules until SPF problems were miniscule, then I activated the rule to quarantine on any SPF result other than PASS or PASS-equivalent.

The most important attribute is that Declude is fully customizable.   When I realized that my multi-attribute rules were creating an unmanageable number of text files, I moved a lot of the processing into a SQL database.

My preferred product would probably be PostFix on Linux.  PostFix is fully customizable and consequently has lots of freeware plug-ins available.  (The new Declude will be one of those plugins.)   But PostFix and Linux have big learning curves, and I do not have enough of that competence available in my organization.   Declude provides an all-Windows solution that was easy to learn.   

I still use commercial products, downstream from Declude, to do content filtering.   Declude has no proprietary knowledge, so it is not able to say "This looks like a Nigerian advanced-payment scam."   The commercial products still have the advantage there.

Doug Foster

0
Hi all!

It seems that there is a setting under Manage-Domains-Options-Email that do what this post requested.

This is on per-domain basis.

Can someone confirm this, please?

Gabriele Maoret - Head of SysAdmins at SERSIS
Currently manages 3 SmarterMail installations (1 in cloud for SERSIS which provides service to a few hundreds 3rd party Mail Domains + 2 on premise to customers)
0
Sébastien Riccio Replied
Hello,

Yes, I saw this toggle recently too. I think I missed it.

I did not test what it does though, but I guess it would remove the sender verification shield in the webmail.

I'm still evaluating the best way to integrate the sender verification based on the SPF/DKIM/DMARC results of our incoming gateways (not SM-base) though.

Basically I guess it's about how to transmit the info from the gateway to SM. 
Via X-SmarterMail-SmartHostSpam header seems the best way. I wrote a little filter to populate that field at the incoming gateway, but I need to be sure it will handle possible cases/values.

Kind regards.
Sébastien Riccio
System & Network Admin

0
Hi Sebastien!
We have a customer that uses SmarterMail (updated yesterday to the new version) on-premises and a FortiMail gateway for the incoming AntiSpam protection.

Fortimail is very effective as AntiSpam, but it break SmarterMail Sender Verification, so I disabled it with the option above and now the verification shield in webmail is no more...


That said, if you find out how to pass the necessary Sender Verification information from the mail gateway to SmarterMail, please give us some hints so I can try it even with Fortimail.
Gabriele Maoret - Head of SysAdmins at SERSIS
Currently manages 3 SmarterMail installations (1 in cloud for SERSIS which provides service to a few hundreds 3rd party Mail Domains + 2 on premise to customers)
3
Derek Curtis Replied
Employee Post Marked As Answer
Hi, all

We did modify Sender Verification to accommodate the use of incoming gateways, and we also added that setting to disable Sender Verification altogether. 

That "Enable Sender Verification" toggle WILL either turn on, or off, the shield.

To accommodate the use of incoming gateways, simply add the IP(s) of any incoming gateways to the IP Bypass list. Once done, Sender Verification will walk through the "Received" values until it finds an IP that is NOT bypassed, then use that for verification checks.
Derek Curtis
COO
SmarterTools Inc.
(877) 357-6278
0
Sébastien Riccio Replied
Hello Curtis,

Thank you for the info. That's good news and seems a good approach. 

For this to work, it needs that SPF/DKIM/DMARC checks are enabled on SmarterMail too, is that correct ?

Kind regards,
Sébastien
Sébastien Riccio
System & Network Admin

0
Derek Curtis Replied
Employee Post
Sebastien,

Are you asking if the primary server (not the gateway) needs SPF/DKIM/DMARC checks enabled? If so, then no. 
Derek Curtis
COO
SmarterTools Inc.
(877) 357-6278
0
Sébastien Riccio Replied
Hello Derek,

Hmm ok. I guess I must be doing something wrong with my test.

I added the incoming gateway IP to the IP Bypass


And sent a test mail from gmail, but the results are all grayed.


Any idea where could be the issue ?

Thanks!

Sébastien Riccio
System & Network Admin

0
Sébastien Riccio Replied
If I enbale SPF and DKIM spam checks on the SmarterMail server (not the gateway), the results are green for both of these checks.


If I remove the gateway IP from IP Bypass but leave the DKIM/SPF spamchecks on, the SPF now fails.


Looks like it requires SPF/DKIM checks to be enabled on primary mail server.

For DMARC, it always stays gray, but it is enabled.


BTW. Our incoming gateways are not SmarterMail based. If that's maybe the reason for this.


Sébastien Riccio
System & Network Admin

0
Kyle Kerst Replied
Employee Post
Hey Sébastien, I hope you're doing well! :-) I took a look at your configuration above and my theory is that the IP Bypass entry for 127.0.0.1 may be causing it to skip any and all spam check results, as I don't see the same behaviors here. In my tests, with the incoming gateway in the IP Bypass list alone, spam check results are pulled from the incoming gateway as expected. I'm going to work on mirroring your setup identically though and hopefully I can see what you're seeing then. Can we get a ticket opened with you on this so we can take a look in more detail?
Kyle Kerst
Technical Support Specialist
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Kyle Kerst Replied
Employee Post
Hey Sébastien you can hold off on the ticket for now, I believe I have that replicated with my primary doing zero spam checks and the gateway performing them instead. I'm going to get this written up for development.
Kyle Kerst
Technical Support Specialist
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Kyle Kerst Replied
Employee Post
I may have spoken too soon Sébastien. I completed some fresh tests on this using a brand new domain (as I was certain this was working previously when I tested it) and I'm back to seeing this work as expected. First, I deployed a domain called shield.example.com and issued an MX record for it that points to my gateway which is configured to run all standard spam checks, declude, rspamd, RBL/URIBL, SPF/DMARC/RDNS, etc. 

There, I configured an incoming gateway entry (domain forward set up to pass scores) and pointed that to my primary where 1) the actual domain is set up and, 2) the spam checks are completely disabled including SPF and the like. I DO have an IP Bypass in place still for that gateway IP address just so SmarterMail knows its a gateway, but otherwise no further configuration. When I receive an email from the outside via the gateway I find the shield works as expected:
I think we might need to take a closer look at this with you.
Kyle Kerst
Technical Support Specialist
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Sébastien Riccio Replied
Hello Kyle,

Thank you for your tests !

I wonder if it works for you because you're using SmarterMail as the incoming gateway, and that it will add the X-SmarterMail-SmartHostSpam header to the forwarded mail anyway, so your main server uses the results of this header ?

Have you tried the same setup but with a non-SmarterMail gateway which doesn't populate such header ?

Kind regards.
Sébastien Riccio
System & Network Admin

0
We are using FortiMail as a incoming gateway and this is how SmarterMail sees the incoming mail (after a few dozens of messages):

  • DMARC: always not detected (gray)
  • SPF: always OK (green)
  • DKIM: alway fails (red)
The message shield always result as NON VERIFICABLE ADDRESS (grey)
Gabriele Maoret - Head of SysAdmins at SERSIS
Currently manages 3 SmarterMail installations (1 in cloud for SERSIS which provides service to a few hundreds 3rd party Mail Domains + 2 on premise to customers)

Reply to Thread