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

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.

EDIT2: After some more testing it seems that the 

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.

- 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.

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...

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

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?

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.

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.

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

Sebastien,

Are you asking if the primary server (not the gateway) needs SPF/DKIM/DMARC checks enabled? If so, then no. 

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!

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.

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?

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.

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.

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.

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

The message shield always result as NON VERIFICABLE ADDRESS (grey)