Spam Mailheader Analyse
Hallo zusammen,
wir bekommen seit ein paar Tagen immer wieder Spam Mails, die interessanterweise "von unserer" Domain kommen, aber eigentlich nicht...
Hier mal der Mailheader:
Kann mir das bitte jemand erklären?
Hier steht bei FROM und TO unser Mitarbeiter drin. Wir haben SPF und DKIM (leider noch kein DMARC). Aber es wird nicht UNSER SPF geprüft, sondern der von mail.com.
Warum? Ich bin irgendwie bisher davon ausgegangen, das die FROM Adresse relevant ist für den SPF Check. Und der einzige verweis auf mail.com ist im Return-Path, bzw eben der sendende Server mail.com.
Und trotzdem gibt es ja einen SPF Fail gegen mail.com. Warum zum Henker geht die Mail dann trotzdem durch?
Ich versteh das irgendwie grad überhaupt nicht.
Sieht hier jemand mehr als ich?
Gruß Sea
wir bekommen seit ein paar Tagen immer wieder Spam Mails, die interessanterweise "von unserer" Domain kommen, aber eigentlich nicht...
Hier mal der Mailheader:
Received: from HE1PR0402MB2697.eurprd04.prod.outlook.com
(2603:10a6:802:3e::27) by VI1PR04MB5789.eurprd04.prod.outlook.com with HTTPS
via VI1PR07CA0179.EURPRD07.PROD.OUTLOOK.COM; Tue, 5 Nov 2019 05:14:25 +0000
Received: from DB6PR04CA0001.eurprd04.prod.outlook.com (2603:10a6:6::14) by
HE1PR0402MB2697.eurprd04.prod.outlook.com (2603:10a6:3:e1::20) with Microsoft
SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.2408.24; Tue, 5 Nov 2019 05:14:22 +0000
Received: from HE1EUR02FT032.eop-EUR02.prod.protection.outlook.com
(2a01:111:f400:7e05::204) by DB6PR04CA0001.outlook.office365.com
(2603:10a6:6::14) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.20 via Frontend
Transport; Tue, 5 Nov 2019 05:14:22 +0000
Authentication-Results: spf=fail (sender IP is 185.62.190.78)
smtp.mailfrom=mail.com; FIRMA.de; dkim=none (message not signed)
header.d=none;FIRMA.de; dmarc=none action=none
header.from=FIRMA.de;compauth=fail reason=601
Received-SPF: Fail (protection.outlook.com: domain of mail.com does not
designate 185.62.190.78 as permitted sender) receiver=protection.outlook.com;
client-ip=185.62.190.78; helo=mxtoolsboxcom-41.localdomain;
Received: from mxtoolsboxcom-41.localdomain (185.62.190.78) by
HE1EUR02FT032.mail.protection.outlook.com (10.152.10.135) with Microsoft SMTP
Server id 15.20.2387.20 via Frontend Transport; Tue, 5 Nov 2019 05:14:19
+0000
Received: from mail.com (localhost [IPv6:::1])
by mxtoolsboxcom-41.localdomain (Postfix) with ESMTP id 2B31CCDB69
for <MITARBEITER@FIRMA.de>; Tue, 5 Nov 2019 02:51:13 +0000 (GMT)
From: MITARBEITER@FIRMA.de
To: MITARBEITER@FIRMA.de
Subject: Your Computer has been Hacked
Date: 4 Nov 2019 18:51:13 -0800
Message-ID: <20191104185113.07B57E594F77C9D4@FIRMA.de>
MIME-Version: 1.0
Disposition-Notification-To: jay.little@gmx.com
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
Return-Path: collectors2000@mail.com
X-MS-Exchange-Organization-ExpirationStartTime: 05 Nov 2019 05:14:19.9871
(UTC)
X-MS-Exchange-Organization-ExpirationStartTimeReason: OriginalSubmit
X-MS-Exchange-Organization-ExpirationInterval: 1:00:00:00.0000000
X-MS-Exchange-Organization-ExpirationIntervalReason: OriginalSubmit
X-MS-Exchange-Organization-Network-Message-Id:
75daa749-159b-48fc-e81d-08d761af035d
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 77ac2f5c-5d49-4704-9857-96cca033973b:0
X-MS-Exchange-Organization-MessageDirectionality: Incoming
X-Forefront-Antispam-Report:
CIP:185.62.190.78;IPV:NLI;CTRY:NL;EFV:NLI;SFV:SPM;SFS:(10001);DIR:INB;SFP:;SCL:5;SRVR:HE1PR0402MB2697;H:mxtoolsboxcom-41.localdomain;FPR:;SPF:None;LANG:en;CAT:SPOOF;
X-MS-Exchange-Organization-AuthSource:
HE1EUR02FT032.eop-EUR02.prod.protection.outlook.com
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 75daa749-159b-48fc-e81d-08d761af035d
X-MS-TrafficTypeDiagnostic: HE1PR0402MB2697:
X-MS-Exchange-AtpMessageProperties: SA|SL
X-MS-Oob-TLC-OOBClassifiers: OLM:8882;
X-MS-Exchange-Organization-SCL: 6
X-Microsoft-Antispam: BCL:0;
X-MS-Exchange-ATPSafeLinks-Stat: 0
X-MS-Exchange-ATPSafeLinks-Stat: 0
X-MS-Exchange-ATPSafeLinks-BitVector: 100:0x0|0x100;
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Nov 2019 05:14:19.8920
(UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 75daa749-159b-48fc-e81d-08d761af035d
X-MS-Exchange-CrossTenant-Id: 77ac2f5c-5d49-4704-9857-96cca033973b
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0402MB2697
X-MS-Exchange-Transport-EndToEndLatency: 00:00:05.1365744
X-MS-Exchange-Processed-By-BccFoldering: 15.20.2430.004
X-Microsoft-Antispam-Mailbox-Delivery:
ucf:0;jmr:0;ex:0;auth:0;dest:I;ENG:(20160513016)(750127)(520002050)(701014)(944506383)(944626516);
Kann mir das bitte jemand erklären?
Hier steht bei FROM und TO unser Mitarbeiter drin. Wir haben SPF und DKIM (leider noch kein DMARC). Aber es wird nicht UNSER SPF geprüft, sondern der von mail.com.
Warum? Ich bin irgendwie bisher davon ausgegangen, das die FROM Adresse relevant ist für den SPF Check. Und der einzige verweis auf mail.com ist im Return-Path, bzw eben der sendende Server mail.com.
Und trotzdem gibt es ja einen SPF Fail gegen mail.com. Warum zum Henker geht die Mail dann trotzdem durch?
Ich versteh das irgendwie grad überhaupt nicht.
Sieht hier jemand mehr als ich?
Gruß Sea
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 512765
Url: https://administrator.de/forum/spam-mailheader-analyse-512765.html
Ausgedruckt am: 22.12.2024 um 02:12 Uhr
3 Kommentare
Neuester Kommentar
Die RFC zu SPF https://tools.ietf.org/html/rfc7208 sagt das man HELO und FROM vergleicht - vielleicht ist es in dem Mailserver von MS falsch implemetiert?
Der Eintrag für Mail.com:
hat eigentlich einen hard fail -all d.h. der MS Server müsste es wegschmeißen... hm
Zeile 15 deines headers sagt:
Warum eigentlich?
Also checks auch net :D
Der Eintrag für Mail.com:
v=spf1 ip4:213.165.64.0/23 ip4:74.208.5.64/26 ip4:74.208.122.0/26 ip4:212.227.126.128/25 ip4:212.227.15.0/24 ip4:212.227.17.0/27 ip4:74.208.4.192/26 ip4:82.165.159.0/24 ip4:217.72.207.0/27 -all
Zeile 15 deines headers sagt:
action=none
Also checks auch net :D
Moin,
ist doch alles korrekt:
So steht es im RFC 7208 8.4. Das hat der Server, der es festgestellt hat, gemacht. Wo ist das Problem? Ein SPF-Fail heißt nicht, dass der MTA die Mail nicht weiter transportieren darf.
Liebe Grüße
Erik
ist doch alles korrekt:
If the checking software chooses not to reject the mail during the
SMTP transaction, then it SHOULD add a Received-SPF or
Authentication-Results header field (see Section 9) to communicate
this result to downstream message processors. While this is true for
all SPF results, it is of particular importance for "fail" results
since the message is explicitly not authorized by the ADMD.
SMTP transaction, then it SHOULD add a Received-SPF or
Authentication-Results header field (see Section 9) to communicate
this result to downstream message processors. While this is true for
all SPF results, it is of particular importance for "fail" results
since the message is explicitly not authorized by the ADMD.
So steht es im RFC 7208 8.4. Das hat der Server, der es festgestellt hat, gemacht. Wo ist das Problem? Ein SPF-Fail heißt nicht, dass der MTA die Mail nicht weiter transportieren darf.
Liebe Grüße
Erik