Two questions on mail headers (CIP & SFV:BLK)

%3CLINGO-SUB%20id%3D%22lingo-sub-1415017%22%20slang%3D%22en-US%22%3ETwo%20questions%20on%20mail%20headers%20(CIP%20%26amp%3B%20SFV%3ABLK)%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1415017%22%20slang%3D%22en-US%22%3E%3CP%3EIn%20a%20hybrid%20Exchange%202013%20-%20EXO%20environment%20(with%20MX%20pointing%20on-prem)%2C%20I%20came%20across%20two%20issues%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E1.%20The%20connecting%20IP%20address%20(CIP)%20always%20equals%20one%20of%20the%20on-prem%20relay%20servers%20(not%20the%20original%20external%20mailserver).%20This%20results%20in%3A%3C%2FP%3E%3CP%3E-%20the%20spf%20always%20fails%20for%20inbound%20mails%3C%2FP%3E%3CP%3E-%20because%20of%20the%20connection%20filter%2C%20every%20mail%20gets%20%3CSTRONG%3EIFV%3ACAL%3C%2FSTRONG%3E%20(%3CSPAN%3EThe%20message%20was%20allowed%20through%20the%20spam%20filters%20because%20the%20IP%20address%20was%20specified%20in%20an%20IP%20Allow%20list%20in%20the%20connection%20filter.)%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E2.%20When%20checking%20user%20submissions%20for%20%22Not%20Junk%22.%20We%20see%20in%20the%20headers%20%3CSTRONG%3ESFV%3ABLK%3C%2FSTRONG%3E%20(%3CSPAN%3EFiltering%20was%20skipped%20and%20the%20message%20was%20blocked%20because%20it%20was%20sent%20from%20an%20address%20on%20an%20individual%E2%80%99s%20blocked%20sender%20list%3C%2FSPAN%3E).%20When%20checking%20the%26nbsp%3B%20Get-MailboxJunkEmailConfiguration%20the%20BlockedSendersAndDomains%20is%20(already%3F)%20empty.%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThank%20you%20for%20helping%20me%20out!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1415017%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EHybrid%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1442798%22%20slang%3D%22en-US%22%3ERe%3A%20Two%20questions%20on%20mail%20headers%20(CIP%20%26amp%3B%20SFV%3ABLK)%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1442798%22%20slang%3D%22en-US%22%3EHello%20Bart%2C%3CBR%20%2F%3E%3CBR%20%2F%3EHope%20I%20can%20help%20you%20with%20this%20one%2C%20here%20is%20goes%20%3B)%3C%2Fimg%3E%3CBR%20%2F%3E%3CBR%20%2F%3E1.%20Could%20you%20check%20if%20the%20Hybrid%20connector%20on%20Exchange%20Online%20has%20the%20option%20%22keep%20internal%20Exchange%20message%20headers%22%20set%20to%20ON%3F%3CBR%20%2F%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fprevious-versions%2Fexchange-server%2Fexchange-150%2Fdn910994(v%3Dexchg.150)%3Fredirectedfrom%3DMSDN%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fprevious-versions%2Fexchange-server%2Fexchange-150%2Fdn910994(v%3Dexchg.150)%3Fredirectedfrom%3DMSDN%3C%2FA%3E%3CBR%20%2F%3E%3CBR%20%2F%3EAlso%2C%20do%20you%20have%20a%20SPF%20record%20and%20does%20it%20contain%20the%20WAN%20IP%20of%20your%20Exchange%20server%3F%3CBR%20%2F%3E%3CBR%20%2F%3E2.%20Please%20have%20a%20look%20at%20this%20article%3A%3CBR%20%2F%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fmicrosoft-365%2Fsecurity%2Foffice-365-security%2Fadmin-submission%3Fview%3Do365-worldwide%23view-user-submissions-to-microsoft%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fmicrosoft-365%2Fsecurity%2Foffice-365-security%2Fadmin-submission%3Fview%3Do365-worldwide%23view-user-submissions-to-microsoft%3C%2FA%3E%3CBR%20%2F%3E%3CBR%20%2F%3EI%20think%20your%20users%20submitted%20the%20mails%20directly%20to%20Microsoft%2C%20with%20the%20above%20view%20you%20are%20able%20to%20check%20if%20they%20did%20and%20take%20the%20required%20actions%20(for%20instance%2C%20disable%20user%20submissions%20from%20and%20disable%20the%20Reports%20add-in%20for%20Outlook).%3C%2FLINGO-BODY%3E
Highlighted
Super Contributor

In a hybrid Exchange 2013 - EXO environment (with MX pointing on-prem), I came across two issues:

 

1. The connecting IP address (CIP) always equals one of the on-prem relay servers (not the original external mailserver). This results in:

- the spf always fails for inbound mails

- because of the connection filter, every mail gets IFV:CAL (The message was allowed through the spam filters because the IP address was specified in an IP Allow list in the connection filter.)

 

2. When checking user submissions for "Not Junk". We see in the headers SFV:BLK (Filtering was skipped and the message was blocked because it was sent from an address on an individual’s blocked sender list). When checking the  Get-MailboxJunkEmailConfiguration the BlockedSendersAndDomains is (already?) empty. 

 

Thank you for helping me out!

5 Replies
Highlighted
Hello Bart,

Hope I can help you with this one, here is goes ;)

1. Could you check if the Hybrid connector on Exchange Online has the option "keep internal Exchange message headers" set to ON?
https://docs.microsoft.com/en-us/previous-versions/exchange-server/exchange-150/dn910994(v=exchg.150...

Also, do you have a SPF record and does it contain the WAN IP of your Exchange server?

2. Please have a look at this article:
https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/admin-submission?view=o3...

I think your users submitted the mails directly to Microsoft, with the above view you are able to check if they did and take the required actions (for instance, disable user submissions from and disable the Reports add-in for Outlook).
Highlighted

@PvB91 Thank you!

 

1. "Keep internal Exchange message headers" is enabled for the inbound and outbound connector. When checking the mail headers you can see all the hops, but the spf is not checked against the originating mail server but against an internal relay server. If all hops are retained in the mail headers, why/when is the spf not checked against the first server? Our spf is valid (although currently set to "?all").

 

2. That's were I see those mails. But I found it weird that we see every day at least one user submitting a false positive (not junk) in which we see SFV:BLK . When checking the blocked sender list, the sender is not present (anymore?), was the sender automatically removed from the blocked sender list because the user submitted the mail to MS as not junk? 

 

 

Highlighted
1. The SPF is always checked against the last IP before Office365 receives it so it's strange that EXO presumes it's a local IP.
Are these mails being relayed via the Exchange Server from an application or printer for instance?
Could you maybe post a result of a message trace?

2. Yes that could be the case, Microsoft checks the sender based on reputation and other specifications so if these checks pass the sender is considered safe.
What you could do of course is disable the option to submit the mails by your users but that's something I can't decide of course ;)
Highlighted

@PvB91 I anonymized it slightly

 

What puzzles me most is the spf fail: domain of e.linkedin.com does not designate XX.XX.71.5 as permitted sender, XX.XX.71.5 is a server of ours. Why is spf not checked against the first IP address (199.7.202.92)

 

Received: from VI1PR09MB4096.eurprd09.prod.outlook.com (2603:10a6:209:90::29)
by AM6PR09MB2792.eurprd09.prod.outlook.com with HTTPS via
AM6P194CA0016.EURP194.PROD.OUTLOOK.COM; Wed, 10 Jun 2020 13:22:02 +0000
Received: from AM6PR08CA0041.eurprd08.prod.outlook.com (2603:10a6:20b:c0::29)
by VI1PR09MB4096.eurprd09.prod.outlook.com (2603:10a6:800:121::8) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Wed, 10 Jun
2020 13:22:00 +0000
Received: from AM5EUR03FT028.eop-EUR03.prod.protection.outlook.com
(2603:10a6:20b:c0:cafe::95) by AM6PR08CA0041.outlook.office365.com
(2603:10a6:20b:c0::29) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.19 via Frontend
Transport; Wed, 10 Jun 2020 13:22:00 +0000
Authentication-Results: spf=fail (sender IP is XX.XX.71.5)
smtp.mailfrom=e.linkedin.com; contoso.com; dkim=pass (signature was verified)
header.d=e.linkedin.com;contoso.com; dmarc=pass action=none
header.from=e.linkedin.com;
Received-SPF: Fail (protection.outlook.com: domain of e.linkedin.com does not
designate XX.XX.71.5 as permitted sender) receiver=protection.outlook.com;
client-ip=XX.XX.71.5; helo=relay1.contoso.com;
Received: from relay1.contoso.com (XX.XX.71.5) by
AM5EUR03FT028.mail.protection.outlook.com (10.152.16.118) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.3088.18 via Frontend Transport; Wed, 10 Jun 2020 13:22:00 +0000
Received: from localhost (mcheck1.contoso.com [XX.XX.71.91])
by relay1.contoso.com (Postfix) with ESMTP id 5E60E7619C
for <emmtom.toms@contoso.com>; Wed, 10 Jun 2020 15:22:00 +0200 (CEST)
X-Virus-Scanned: by Contoso DICT
X-Spam-CMAuthority: v=2.3 cv=Eda2v8uC c=1 sm=1 tr=0
a=407tTOkso+zxEghPF3UieQ==:17 a=KqOhe5OoNmIA:10 a=O76VCmqbo-wA:10
a=nTHF0DUjJn0A:10 a=Xg6hxTJYhxMA:10 a=M51BFTxLslgA:10
a=r77TgQKjGQsHNAKrUKIA:9 a=jU4qhlNgAAAA:8 a=YY1ZcqqrI6xR5oziIx0A:9
a=QEXdDO2ut3YA:10 a=SSmOFEACAAAA:8 a=4F_gcz9cAAAA:8 a=P0CS7o0kAAAA:8
a=g2DXbu_dzxOSWhaP4Y8A:9 a=a1La3gOqBzqfoSXu:21 a=gKO2Hq4RSVkA:10
a=frz4AuCg-hUA:10 a=_W_S_7VecoQA:10 a=utKY0mbGk_15_-6maDl2:22
a=xJca28oTcna21abs7k0g:22 a=Sf_sMCSL_WJvxhl3zmRG:22
a=HH7FIXwXL_sUf1zzYxQd:22
Received: from relay1.contoso.com ([XX.XX.71.5])
by localhost (mcheck1.contoso.com [XX.XX.43.40]) (amavisd-new, port 10024)
with ESMTP id 9VyQz8KiaVbs for <emmtom.toms@contoso.com>;
Wed, 10 Jun 2020 15:21:59 +0200 (CEST)
Received: from omp.e.linkedin.com (omp.e.linkedin.com [199.7.202.92])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by relay1.contoso.com (Postfix) with ESMTPS id 41058761D0
for <emmtom.toms@contoso.com>; Wed, 10 Jun 2020 15:21:59 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=linkedin; d=e.linkedin.com;
h=X-CSA-Complaints:MIME-Version:Content-Type:Date:To:From:Reply-To:Subject:
List-Unsubscribe:Message-ID; i=linkedin@e.linkedin.com;
bh=VBYsNAgiDn7YaiIN9cVXM81+g80p3KHLOaF4tKbBfcQ=;
b=FlJXmEzPX/6BGfuuY5NymMAp/uUqFVJufQmDU4e33gwYsb1jE8/zTVhTQdv0ApZzsc6FVzIrTJPu
fPF0cJjRzNyPZqqNTilBCA1Rlvc2fdEaodYbvSsP/NeAOrNI3XGVvMDOFy2U/IIlKBUIpQvEaWxo
5fz57GVjlTRSuBvvCWw=
Received: by omp.e.linkedin.com id hs3f7a2lr0oo for <emmtom.toms@contoso.com>; Wed, 10 Jun 2020 06:21:57 -0700 (envelope-from <linkedin@e.linkedin.com>)
X-CSA-Complaints: whitelist-complaints@eco.de
Content-Type: multipart/mixed; boundary="----msg_border_H19D3aPqbR"
Date: Wed, 10 Jun 2020 06:21:57 -0700
To: <emmtom.toms@contoso.com>
From: =?UTF-8?B?TGlua2VkSW4=?= <linkedin@e.linkedin.com>
Reply-To: =?UTF-8?B?TGlua2VkSW4=?= <donotreply@e.linkedin.com>
Subject: Emma, thanks for being a valued member
Feedback-ID: 50563:15879535:oraclersys
List-Unsubscribe: <mailto:unsubscribe-AQpglLjHJlYQGhEEYGcKT1zfCha0Hrzc09zgRmpHl6t8EHLwjzaSzcT8eDUd3lyTbO6W@imh.rsys5.com?subject=List-Unsubscribe>, <https://e.linkedin.com/pub/optout/UnsubscribeOneStepConfirmAction?YES=true&_ri_=X0Gzc2X%3DAQpglLjHJl....>
X-sgxh1: LuunLLjlQnLLjlkxmnLglQIL
X-rext: 6.interact5.EoGG5EJd2Sx8oHRajXRDF0uiatAlCGaeOrQ1X2CL93KUtP2IwA4
X-cid: linkedin.3752
X-ei: Egbnz3E-LglAP044NUjD3X2Hnhqk1RQC
Require-Recipient-Valid-Since: emmtom.toms@contoso.com; Wed, 8 Apr 2020 19:18:00 -0700
Message-ID: <0.1.21F.3B0.1D63F2A1E020AEE.0@omp.e.linkedin.com>
X-Miltered: at jchkm4 with ID 5EE0DE76.000 by Joe's j-chkmail (http://helpdesk.contoso.com/email/)!
X-j-chkmail-Enveloppe: 5EE0DE76.000 from omp.e.linkedin.com/omp.e.linkedin.com/199.7.202.92/omp.e.linkedin.com/<linkedin@e.linkedin.com>
X-j-chkmail-Score: MSGID : 5EE0DE76.000 on relay1.contoso.com : j-chkmail score : . : R=. U=. O=# B=0.000 -> S=0.083
X-j-chkmail-Status: Ham
Return-Path: linkedin@e.linkedin.com
X-MS-Exchange-Organization-Network-Message-Id: ca920975-ae6a-4b67-5983-08d80d414218
X-EOPAttributedMessage: 0
X-MS-Exchange-Organization-MessageDirectionality: Originating
X-Forefront-Antispam-Report: CIP:XX.XX.71.5;CTRY:BE;LANG:en;SCL:-1;SRV:;IPV:CAL;SFV:SKN;H:relay1.contoso.com;PTR:relay1.contoso.com;CAT:NONE;SFTY:;SFS:;DIR:INB;SFP:;
X-MS-PublicTrafficType: Email
X-MS-Exchange-Organization-AuthSource: AM5EUR03FT028.eop-EUR03.prod.protection.outlook.com
X-MS-Exchange-Organization-AuthAs: Anonymous
X-OriginatorOrg: Contosobe.onmicrosoft.com
X-MS-Office365-Filtering-Correlation-Id: ca920975-ae6a-4b67-5983-08d80d414218
X-MS-TrafficTypeDiagnostic: VI1PR09MB4096:
X-MS-Oob-TLC-OOBClassifiers: OLM:6790;
X-MS-Exchange-Organization-SCL: -1
X-Microsoft-Antispam: BCL:1;
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2020 13:22:00.5392
(UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ca920975-ae6a-4b67-5983-08d80d414218
X-MS-Exchange-CrossTenant-Id: d7811cde-ecef-496c-8f91-a1786241b99c
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d7811cde-ecef-496c-8f91-a1786241b99c;Ip=[XX.XX.71.5];Helo=[relay1.contoso.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR09MB4096
X-MS-Exchange-Transport-EndToEndLatency: 00:00:01.6337616
X-MS-Exchange-Processed-By-BccFoldering: 15.20.3088.011
X-Microsoft-Antispam-Mailbox-Delivery: ucf:0;jmr:0;auth:0;dest:I;ENG:(750128)(520011016)(944506458)(944626604);
X-Microsoft-Antispam-Message-Info:
MIME-Version: 1.0

Highlighted
Could you check if the user exists in Exchange Online with the correct DOMAIN.mail.onmicrosoft.com alias?
And if the user exists in the local Exchange server as a Remote Mailbox?
It looks as if the Exchange does forward the mail but doesn't see the mailbox as a Hybrid mailbox for some sort of reason..
Because the Exchange server is the last hop, Office 365 will check the SPF of the senders domain (linkedin.com) as the originating domain.

Also to make sure, did you run the latest version of the HCW and do you have the latest CU update installed on your Exchange server?