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