SPF check MIME FROM - how does the header differ and do I want to enable it?

Question

On our email gateway SPF checks are enabled. There is an option though called SPF Check MIME FROM that I am unfamiliar with and what exactly it will do if the box is checked (enabled). I have researched info on MIME extensions and SPF, examined some headers from test emails, but still have not been able to find anything concrete that would tell me what this option does. And unfortunately the gateway help pages glosses right over this one.

In the sample email header below, which "From" field is the MIME from field and why would I want to check/block it? What are the risks associated with blocking the MIME field? Is there potential for blocking/bouncing legitimate emails by enabling this check?

 Delivered-To: user@gmail.com
 Received: by x.x.x.x with SMTP id f76csp774237qgd;
    Sat, 27 Aug 2016 03:29:33 -0700 (PDT)
 X-Received: by 10.36.158.213 with SMTP id p204mr3542807itd.99.1472293773650;
    Sat, 27 Aug 2016 03:29:33 -0700 (PDT)
 Return-Path: <user@yahoo.com>
 Received: from x.x.x.x [x.x.x.x])
    by mx.google.com with ESMTPS id t102si29690279ioi.28.2016.08.27.03.29.33
    for <user@gmail.com>
    (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
    Sat, 27 Aug 2016 03:29:33 -0700 (PDT)
 Received-SPF: pass (google.com: domain of user@yahoo.com designates x.x.x.x  as permitted sender) client-ip=x.x.x.x;
 Authentication-Results: mx.google.com;
   spf=pass (google.com: domain of user@yahoo.com designates x.x.x.x as  permitted sender) smtp.mailfrom=user@yahoo.com
  X-IronPort-AV: E=Sophos;i="5.28,586,1464670800"; 
  d="scan'208,217";a="24231910"
  Received: from unknown (HELO yahoo.com) ([x.x.x.x])
  by x.x.x.x with ESMTP/TLS/AES256-SHA; 27 Aug 2016 05:29:34 -0500
  Received: from x.x.x.x (x.x.x.x) by x.x.x.x
  (x.x.x.x) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Sat, 27 Aug
  2016 05:29:32 -0500
  Received: from x.x.x.x ([x.x.x.x.]) by
  x.x.x.x ([fe80::x.x.x.x]) with mapi id
  15.00.1156.000; Sat, 27 Aug 2016 05:29:32 -0500
  From: Yahoo user <user@yahoo.com>
  To: "user@gmail.com" <user@gmail.com>
  Subject: test
  Thread-Topic: test
  Thread-Index: AQHSAE3msYk8ULUUokONiRFEEXwZWw==
  D ate: Sat, 27 Aug 2016 10:29:32 +0000
  Message-ID: <d6f3858cc3ec40f3aebf654ef7148695@x.x.x.x>
  Accept-Language: en-US
  Content-Language: en-US
  X-MS-Has-Attach:
  X-MS-TNEF-Correlator:   
  x-ms-exchange-transport-fromentityheader: Hosted
  x-originating-ip: [x.x.x.x]
  Content-Type: multipart/alternative;
  boundary="_000_d6f3858cc3ec40f3aebf654ef7148695prodex02corpwan_"
  MIME-Version: 1.0

score 3 · Accepted Answer · answered Aug 27 '16 at 13:20

That is a misleading description. The 'MIME From' is most likely the 'From:' line in that header. That From: line is governed by RFCs related to SMTP, not MIME. Ick.

Anyway, 'From' checking.

There are two FROM fileds on any email, the envelope data, and the one in the headers. The two can be completely unrelated, the (base) RFCs don't care. The original idea was that it's like postal-mail: the return address on the envelope can say one thing, while the address-block on the enclosed letter can say another. The email industry has come to realize this is a bad thing in the 30+ years of SMTP experience we've had.

What "MIME FROM" checking does, is move the SPF DNS check away from SMTP conversation, and to the From: field in the headers. This matches the checking expected by the end-user, rather than the postmasters, and in theory gives a better user experience.

The caveat here is that organizations using a mail service provider that haven't done the right amount of setup will be flagged as FAIL by your system, and their mail my end up in spam or not deliver. The setup is done by the MSP's subscriber, not the MSP. Enabling this will change the deliverability of incoming email to your system in ways that may generate complaints. Be prepared for it, and you should be fine.

Great answer but provokes more questions. What type of additional setup specifically will need to be done for MIME by the MSP's subscriber beyond just having SPF setup for their sending servers? — user53029, Aug 27 '16 at 15:38
And also, I don't think its always a bad thing to have SPF checks moved. Both the MIME field and the return path, would in most cases be the same. So its like SPF is looking at the same data, just in a different header. Would you agree? If that's true then it becomes a matter of which you think is more likely to cause problems as to which one you check. Maybe having an SPF implementation that checks both would be a good thing? — user53029, Aug 27 '16 at 15:45
The change the subscribers have to make is to update the SPF record for their domain to reflect the MSP's information. Most MSPs have a dashboard for checking if this is done or not; they know it needs doing. Take a look at the DMARC standard; it pretty much enforces congruence between envelope-FROM and header-FROM. This setting is a good thing. — sysadmin1138, Aug 28 '16 at 00:20

SPF check MIME FROM - how does the header differ and do I want to enable it?

1 Answers1