SmarterMail DMARC status?

Question asked by Eric Tykwinski - 4/21/2020 at 11:39 AM

Answered

I know this isn't used heavily, but it's getting there. We have a customer that is prefiltering on AppRiver, which of course breaks DMARC for thier domain. I don't see any way to turn off following policies just for this one client. Is it possible for say AppRiver to sign with an "Authenticated Received Chain" header to bypass DMARC?

4 Replies

Reply to Thread

Matt Petty Replied

4/22/2020 at 9:43 AM

Employee Post Marked As Answer

If it comes in to your server from AppRiver then you should be able to add an "IP Bypass" which will skip over AppRiver's IP and get the next part of the "Received By:" chain.
You can add an IP Bypass in the System Admin > Antispam section. This should hopefully resolve the DMARC issues.

The IP Bypass would be the IP of AppRiver's server that gives you the message.

Matt Petty Senior Software Developer SmarterTools Inc. www.smartertools.com

Eric Tykwinski Replied

4/22/2020 at 10:11 AM

Matt,

Thanks, but I don't feel like managing a huge list of ips for a single customer, they list a bunch of /20's, /24's, et al, on the support page, it's like basically saying spf to +all. Honestly, we can probably do everything that AppRiver can do already, so I'm going to try and have them just go direct to us.

Scratch the ARC deal as well, I just tested this out, and you guys are accepting the emails fine. Gmail is doing a SRS rewrite and resigning with ARC. I just did a forward from GMail to my personal and it's fine.

[2020.04.22] 13:18:29.526 [49227] Spam check args: from: eric@securedomain.com; messageID: 49227; messagePath: M:\SmarterMail\Spool\SubSpool1\191349227.eml; sender: gmail.username+caf_=local.username=domain.com@gmail.com; sendersDomain: gmail.com; sendersIp: 209.85.222.50; returnPath: gmail.username+caf_=local.username=domain.com@gmail.com

[2020.04.22] 13:18:29.526 [49227] [209.85.222.50] Valid reverse DNS entry found: mail-ua1-f50.google.com

[2020.04.22] 13:18:29.588 [49227] Running SPF check

[2020.04.22] 13:18:29.588 [49227] Finished SPF check; result = Pass

[2020.04.22] 13:18:29.588 [49227] [DKIM] Performing DKIM check...

[2020.04.22] 13:18:29.588 [49227] [DKIM] Result: Good.

[2020.04.22] 13:18:30.447 [49227] Spam Checks completed.

[2020.04.22] 13:18:30.447 [49227] SpamCheck Processing Thread Completed

Douglas Foster Replied

4/23/2020 at 10:37 PM

You are right, the exception mechanisms are too limiting. See my soapbox at this link.

https://portal.smartertools.com/community/a93134/discussion-the-uses-and-misuses-of-sender-authentication-spf-dkim-dmarc.aspx

Douglas Foster Replied

3/13/2025 at 4:39 AM

I recommend an upgraded spam filtering structure, combined with a philosophy that 100% authentication is the goal. 100% authentication uses a mixture of SPF/DKIM/DMARC and the upgraded local policy system.

There are two ways to conclude that a message is accurately identified:

One techniques is automated using SPF/DKIM/DMARC. SPF/DKIM/DMARC can only tell you that the message appears to be correctly identified; it cannot tell you that the message is wanted. Even then, these tools make mistakes in both direction.
The other is not automated, and it uses expert inspection. Expert inspection checks identity and acceptability at the same time, and is therefore the more useful result. Once inspection determines that a message is acceptable, you need a way to document this result so that future messages from this mailstream are considered acceptably identified. You may or may not also want to target messages for whitelisting based on this result. This produces some obvious design requirements for your local policy structure. (Since I have not found a commercial vendor who can do this, a custom solution is assumed.)

Options for local policy rules to treat a message as equivalent to SPF PASS, when the normal result is Fail, SoftFail, Neutral, PermError, None, or even TempError)

Helo or Reverse DNS domain name matches the server organization, that name is verified with forward-confirmed DNS, and the SMTP Mail From domain is the one that you want to accept. As long as the domain name is the sever organization and not the ISP organization, it does not matter which name matches.
In the unusual case that the message is wanted but neither name matches, then the rule uses the Source IP and the SMTP Mail From domain. Source IP is assumed true. Of course the Source IP could be fraudulent if bad guys have a NAT device sitting outside your public router, but then you have bigger problems than bad email.
The message has a verified DKIM signature for the SMTP Mail From domain.
The message has a verified DKIM signature from *.gappssmtp.com, which can be mapped to the SMTP Mail From domain. It appears to me that these are only applied when Google has authenticated the submitter, so I consider it a valid proxy for a domain signature.

Options for local policy rules to treat a message as equivalent to DMARC PASS, when the normal result is NO POLICY or PermError

IF the problem is No Policy, apply the DMARC algorithm using default relaxed alignment, and accept a PASS result. I apply the DMARC algorithm to every message and it provides From authentication for the vast majority of messages that do not have a DMARC policy.
SMTP Mail From domain matches an expected value and is verified with SPF PASS or one of the equivalents listed above.

The goal is to get to 100% authentication for many reasons. Fortunately, most messages can be authenticated, so the amount of inspection is not as awful as you might expect. You will end up with a lot of rules, so they need to be in a database where entries are unique and tables are indexed for performance.

I do not blocking on authentication failure, because the failure does not prove malice. I do target those messages for expert review. The review either leads to an allow rule like the ones above or a block rule. Either way, the ambiguity is eliminated for the next message.

100% authentication has cumulative benefits:

You know that your users are not being misled by a fraudulent From address.
You can collect data to reliably distinguish known senders from new senders. Essentially all of your threats will be coming from new senders, so those new senders should be given extra weight in any weight-based scoring system.
You can collect data on Friendly Names, and assess whether an observed value for Friendly Name is reasonable given the provided From address.
You can omit External Sender warnings from messages that are highly vetted, so that the warning is less likely to be ignored on new senders and advertising messages where it may be critical.

Back to Community Threads

Please leave this box unchecked

Reply to Thread

Enter the verification text

4 Replies

Reply to Thread

Tags

Related Knowledge Base Articles