DMARC fails "on behalf of" outbound messages - categorized as spam

[David Chivers]

Scenario: IronPort C-170 adding DKIM signatures and relaying outbound mail from Exchange 2010. SPF and DMARC configured correctly in DNS.
Problem: When user1@senderdomain.aaa sends on behalf of user2@fromdomain.bbb, Yahoo and Gmail categorize the message as spam.

Headers appear like...
Sender: user1@senderdomain.aaa
From: user2@fromdomain.bbb
Return-Path: <prvs=12345abcd=user1@senderdomain.aaa>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=senderdomain.aaa; ...

Yahoo and Gmail apparently check SPF of the Return-Path address. SPF and DKIM for senderdomain.aaa are both correct, but DMARC fails because fromdomain.bbb has neither a valid SPF check nor a valid DKIM signature.

By the way, if the receiving server bothered to check the equivalent SPF or DKIM entries for fromdomain.bbb it would find that they are identical to senderdomain.aaa. Ensuring that SPF records and DKIM signatures are aligned for the two domains is not the answer, because mine already are.

If the Sender header is stripped using Outbound Content Filters, the IronPort applies the DKIM-Signature header with "d=fromdomain.bbb" and DMARC passes, so Yahoo and Gmail are happy. The Return-Path header is unchanged though, so receiving servers still check SPF against senderdomain.bbb instead of fromdomain.aaa. This seems like a kludge though, especially since it is only a problem for a few dozen accounts.

Ideally we would like the IronPort to always generate Return-Path and DKIM-Signature header values based on the From address, instead of preferring the Sender address when it exists. Can this be configured?

[David Chivers]

I just got off the phone with Cisco support on this. They will call me back next week after testing a few things, and may create a feature request. I'll keep this forum post updated accordingly.

[Hrvoje (Harry) Dogan · Accepted solution]

Hi David,

Seems that we already have a feature request to cover this use case, CSCzv27747. It is currently Postponed until AsyncOS 10.0. Please keep an eye on the feature request and keep using the workaround (stripping the Sender header) until we have a fix available.

Thank you!

[David Chivers]

Fixed in 9.7.2-047 - Thanks Harry.

[Hrvoje (Harry) Dogan]

Hi David,

Thanks for pointing out this problem - I'm in the process of collecting caveats of our DMARC/DKIM/SPF implementation.

Just to discuss other possible options to correct this - DMARC would actually pass if we inserted a DKIM signature for *both* Sender and From addresses, right? Instead of having configurable Return-Path address (which may be problematic and probably not as practical), this would probably be a much simpler enhancement to implement.

Changing Return-Path value has the same effect as removing the Sender header - you are losing part of authenticity information for the message. I guess it would be one of those "only do this if you know what you're doing" features.

Finally, could you please send me the TAC ticket number, so I can check out the discussions TAC had with Engineering on this? Thank you!

[David Chivers]

Hi Hrvoje,

I'm glad to hear this is being reviewed. The TAC ticket number is 636114577. Nasir was very patient in talking through the problem and explaining some details for me, so I'm confident he understands our situation. Thanks for looking into it.

We wouldn't have a problem if Yahoo and Gmail could be bothered checking SPF with the From address; surely checking multiple DKIM certificates would be more expensive.

Do ESAs check SPF using the From address?

Also, do ESAs currently check multiple DKIM certificates? If so, how does it prevent DKIM checks from being a DOS vulnerability?

[Hrvoje (Harry) Dogan]

Hi David,

Actually, I think even if Yahoo/Gmail checked Header From SPF, DMARC would fail because Envelope From is the actual sender, so you would have Mail From user1@senderdomain.aaa and Header From user2@fromdomain.bbb which would never align. Usage of "Sender" headers is specifically not used for DMARC verification (https://tools.ietf.org/html/rfc7489#appendix-A.3)

The only way would be to align using DKIM, meaning you have to have a DKIM signature in the email with d=fromdomain.bbb, or a superior domain of fromdomain.bbb in case of relaxed matching...

In case of multiple DKIM signatures, that could potentially be a DoS threat, but not just yet :) We have a known deficiency on the current AsynOS releases where ESA will only check the first DKIM signature in an email, thus potentially falsely invalidating some messages, and  invalidating DMARC  verification if SPF does not align. We have an enhancement request filed to fix this. In case of multiple signatures, I'm guessing an easy way for it to not cause a DoS would be to limit the number of signatures to not exceed number of hops in Received: headers. 

I will check on the ticket progress, and also have a chat with Engineering about how easy it would be to fix our DKIM signing behavior.