Failing to parse some office 365 authentication results.

[The-Nutty]

Describe the bug
When using the AuthenticationResults.TryParse/Parse method the following authentication results generated by office 365 fail to parse spf=temperror (sender IP is 1.1.1.1) smtp.helo=tes.test.ru; mydomain.com; dkim=none (message not signed) header.d=none;mydomain.com; dmarc=none action=none header.from=;

Platform (please complete the following information):

• .NET Framework: .net core 2.2
• MimeKit Version: 2.4.1 and 2.4.1.2

To Reproduce
Steps to reproduce the behavior:

1. Create a console application and run the following code

            if (AuthenticationResults.TryParse(Encoding.UTF8.GetBytes(
                "spf=temperror (sender IP is 1.1.1.1) smtp.helo=tes.test.ru; mydomain.com; dkim=none (message not signed) header.d=none;mydomain.com; dmarc=none action=none header.from=;"), out var authRes))
            {
                Console.WriteLine("Parsed");
            }
            else
            {
                Console.WriteLine("Failed to parse");
            }

Expected behavior
It should pass the Auth Results and output Parsed accordingly.

[jstedfast]

Why can't developers properly adhere to the specs? 😢😭

[jstedfast]

This is related to #490

In both bug reports, there are multiple domain tokens that are unattached to anything, they are just hanging around in the value.

I was thinking that the "mydomain.com" after the spf=temperror ... was the authserv-id token, but then we have this as well:

dkim=none (message not signed) header.d=none;mydomain.com

If the first "mydomain.com" is the authserv-id, wtf is the second instance!?!?!?

issue #490 has the exact same problem...

[jstedfast]

Anyway, the reason this particular header value fails is due to an empty property value (header.from=;) that I can and will work around, but my fix for issue #490 is probably wrong and may need adjusting as well?

I've emailed a few devs that I know are on the Office365 team, so we'll see what they say - but in case they don't, how are you handling this? What makes the most sense?

[The-Nutty]

It worse than i though... In my particular use case we only really care about the dkim/spf/dmarc status and we get the other bits of information from other sources. On monday im goingto check through my logs just to be sure that there is not other O365 auth results that are not parsing but fingers crossed this is it.

[jstedfast]

@The-Nutty Just to verify, but can you confirm that the domain tokens ("mydomain.com") that appear in those 2 locations are both the same domain? I'm assuming they are.

My guess is you probably don't have the email (or original header) for issue #490 anymore so probably can't verify that the domains were the same there, but if you miraculously still have that, it would be nice if that were confirmed as well.

Based on the modified header that was included in the bug report:

Authentication-Results: spf=fail (sender IP is 1.1.1.1) smtp.mailfrom=eu-west-1.amazonses.com;
 recevingdomain.com; dkim=pass (signature was verified) header.d=domain.com;domain1.com;
 dmarc=bestguesspass action=none header.from=domain.com;

... my guess is that "receivingdomain.com" was not identical to "domain1.com", but that would be useful info if you've got it.

What I'm wondering is if the O365 code that constructs this header is maybe generating multiple (mostly? valid) Authentication-Results headers and then concatenating them together. For example, maybe each of SPF, DKIM and DMARC validators are independently creating Authentication-Results headers:

SPF (missing an authserv-id token):

spf=fail (sender IP is 1.1.1.1) smtp.mailfrom=eu-west-1.amazonses.com;

DKIM:

recevingdomain.com; dkim=pass (signature was verified) header.d=domain.com;

DMARC:

domain1.com; dmarc=bestguesspass action=none header.from=domain.com;

And then some other code is just concatenating them together, not taking into consideration that each subroutine can/does/might add an authserv-id token, thereby making it invalid to blindly concatenate them.

I don't know, it's just a theory... but seems plausible?

P.S. The Office365 guys got back to me this past Friday with some follow-up questions, so it seems like they are looking into this.

[jstedfast]

Another possibility is that the code that generates the Authentication-Results header was written to conform to an early draft of the spec that was changed before being accepted by the IETF.

[jstedfast]

Okay, so just read thru issue #490 again and you already explained that domain.com/domain1.com were the domains that the message was DKIM signed by, so in that particular case (i.e. the dkim method token), at least, the multi-domain value separated by the ; makes sense (even if syntactically invalid?), but that doesn't explain either of these:

dkim=none (message not signed) header.d=none;mydomain.com

(If it wasn't signed, why does it have 2 domains?)

spf=temperror (sender IP is 1.1.1.1) smtp.helo=tes.test.ru; mydomain.com;

(How would SMTP "HELO" from 2 different domains?)

spf=fail (sender IP is 1.1.1.1) smtp.mailfrom=eu-west-1.amazonses.com; recevingdomain.com;

(How would there be 2 different MAIL FROM domains?)

[The-Nutty]

Sorry for not getting back sooner,

@The-Nutty Just to verify, but can you confirm that the domain tokens ("mydomain.com") that appear in those 2 locations are both the same domain? I'm assuming they are.

Yes they are the same domain

... my guess is that "receivingdomain.com" was not identical to "domain1.com", but that would be useful info if you've got it.
I dont have that anymore, and i cant rember if they are or not

As for your theory it seems valid....

Hopefully you get something useful from the O365 team....

I cant see anything else that looks more broken than the examples i have given, if it would use useful to have some un redacted versions i can privately email them to you.

[jstedfast]

@The-Nutty thanks for getting back to me.

[jstedfast]

I've added a new property to stick the receivingdomain.com tokens into that appear between the method tokens.

You'll now be able to do this to get that value:

string srvid = authres.Results[1].Office365AuthenticationServiceIdentifier;