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

emailemail-servermimespamspf

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

Best Answer

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.

Related Topic