Re: QR phish missed

On 2024-08-16 at 08:03:05 UTC-0400 (Fri, 16 Aug 2024 08:03:05 -0400)
Alex <[email protected]>
is rumored to have said:

> It says that SPF failed, but SPF_PASS was hit, presumably from our
> connection to Microsoft, not their connection to the spammer client:

Correct. You can only check SPF on the first SMTP transaction guided by 
an MX record and recorded by a trusted server.

> Received-SPF: Fail (protection.outlook.com: domain of toppersrvs.com 
> does
> not
>  designate 35.230.39.135 as permitted sender) receiver=
> protection.outlook.com;
>  client-ip=35.230.39.135; helo=[127.0.0.1];
>
> Received-SPF: Pass (mailfrom) identity=mailfrom; 
> client-ip=52.100.167.207;
> helo=nam12-mw2-obe.outbound.protection.outlook.com; envelope-from=
> [email protected]; receiver=buckknives.com
>
> ARC also failed:
> ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=fail (sender 
> ip is
>  35.230.39.135) smtp.rcpttodomain=buckknives.com smtp.mailfrom=
> toppersrvs.com;
>  dmarc=none action=none header.from=toppersrvs.com; dkim=none (message 
> not
>  signed); arc=none (0)
>
> Should I also somehow be checking these SPF failures?

You really can't with SA, because it is not generally safe to trust the 
Received headers written by systems you don't control or have some sort 
of explicit relaying arrangement with. Because the initial submission of 
messages CANNOT be subjected to SPF tests, you don't want to test 
transactions that are not following an MX record.



-- 
Bill Cole
[email protected] or [email protected]
(AKA @[email protected] and many *@billmail.scconsult.com 
addresses)
Not Currently Available For Hire