https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7805
Bug ID: 7805
Summary: Mail::SpamAssassin::Plugin::SPF passes the wrong
<Received> headers to MAIL::SPF when helo is initially
invoked at external relay.
Product: Spamassassin
Version: 3.4.4
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P2
Component: Plugins
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: Undefined
Created attachment 5691
--> https://bz.apache.org/SpamAssassin/attachment.cgi?id=5691&action=edit
Example email with local server, recipient and bounce-address redactions.
Still reproduces issue with SPF plugin with and without redactions on 3.4.4.
With certain websites such as wetransfer.com, the Received headers show that
the email is first sent to a third party mail sending service (sendgrid, for
example), before eventually being sent to the recipient mail server.
Headers will therefore look something like this (redacted example excerpt):
===
Return-Path:
<bounces+922094-0e6c-juridico1=redac...@em9713.email.wetransfer.com>
Delivered-To: [redacted]
Received: from [local server, redacted]
by [same local server, redacted] with LMTP
id EIsRK0oghl7LDjkAsPOUtg
(envelope-from
<bounces+922094-0e6c-[redacted]@em9713.email.wetransfer.com>)
for <redacted>; Thu, 02 Apr 2020 17:26:34 +0000
Return-path: <redacted>
Envelope-to: redacted
Delivery-date: Thu, 02 Apr 2020 17:26:34 +0000
Received: from o2.email.wetransfer.com ([192.254.118.54]:28541)
by redacted with esmtps (TLS1.2) tls
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
(Exim 4.93)
(envelope-from
<[email protected]>)
id 1jK3bs-00FhdM-HC
for redacted; Thu, 02 Apr 2020 17:26:34 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=email.wetransfer.com;
h=from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding;
s=s1; bh=1p2PYxSXvi6qePAWGFMzuI6trBOd/BJScAE9vMJg5Fk=; b=q/za1KA
pfOKpTIJV+zmTrGhUiKQXFolNCVst2/dU/4PjhyTZ2HJ47+f8SJNZo0q9usAir5K
poTPN7NV+DkvIQ5q0BDAe5K7j62oVbTC30xPf4lhktEojZcXa08V5BFfg/XYgLKD
9/RxI0EPQpGfizjVEggsimvmDlAIxgVuZtTA=
Received: by filter1969p1mdw1.sendgrid.net with SMTP id
filter1969p1mdw1-26204-5E86201A-1A
2020-04-02 17:25:46.597663144 +0000 UTC m=+66385.574505142
Received: from ba695f3d37e6 (unknown)
by ismtpd0004p1lon1.sendgrid.net (SG) with ESMTP id
NOaf64uIQHK7kDPqITWP7g
for <redacted>; Thu, 02 Apr 2020 17:25:46.417 +0000 (UTC)
Received: from [10.30.65.95] (helo=wetransfer.com)
by ba695f3d37e6 with esmtp (Exim 4.86_2)
(envelope-from <[email protected]>)
id 1jK3b8-0001QE-8R
for redacted; Thu, 02 Apr 2020 17:25:46 +0000
Date: Thu, 02 Apr 2020 17:25:46 +0000 (UTC)
From: WeTransfer <[email protected]>
Reply-To: redacted
To: redacted
Message-ID: <[email protected]>
===
The helo is input to sendgrid's mailservers by the webserver for
wetransfer.com, and sendgrid does not provide a helo of its own when sending
mail inbound to our local server.
This seems a little unusual, but not so much that it should through SPF
checking for a loop and get it to try and check the private IP.
Here are the results of testing the message in question, with or without
redactions:
===
Content analysis details: (16.3 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was
blocked. See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: wetransfer.com]
-0.5 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
0.1 TO_MALFORMED To: has a malformed address
1.0 SURBL_BLOCKED ADMINISTRATOR NOTICE: The query to SURBL was
blocked. See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: wetransfer.com]
8.0 SPF_FAIL SPF: sender does not match SPF record (fail)
[SPF failed: Please see
http://www.openspf.org/Why?s=mfrom;id=noreply%40wetransfer.com;ip=10.30.65.95;r=redacted]
0.0 SPF_HELO_FAIL SPF: HELO does not match SPF record (fail)
[SPF failed: Please see
http://www.openspf.org/Why?s=helo;id=wetransfer.com;ip=10.30.65.95;r=redacted]
0.1 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily
valid
2.0 RDNS_NONE Delivered to internal network by a host with no
rDNS
2.5 UNPARSEABLE_RELAY Informational: message has unparseable relay
lines
1.0 DMARC_QUAR No description available.
2.0 DKIM_INVALID DKIM or DK signature exists, but is not valid
0.2 TXREP TXREP: Score normalizing based on sender's
reputation
===
You'll notice that SPF fails, and indicates it is checking the RFC1918 IP that
wetransfer.com first sends the email from, before it reaches an unknown relay,
and then a sendgrid endpoint.
Here is the debug output of this test:
===
Apr 5 19:35:10.154 [10970] dbg: rules: running head_eval tests; score so
far=-0.499
Apr 5 19:35:10.156 [10970] dbg: rules: run_eval_tests - compiling eval code:
9, priority 0
Apr 5 19:35:10.168 [10970] dbg: spf: checking to see if the message has a
Received-SPF header that we can use
Apr 5 19:35:10.204 [10970] dbg: spf: using Mail::SPF for SPF checks
Apr 5 19:35:10.204 [10970] dbg: spf: checking HELO (helo=wetransfer.com,
ip=10.30.65.95)
Apr 5 19:35:10.205 [10970] dbg: dns: bgsend, DNS servers: [dnsip]:53,
[dnsip]:53, [dnsip]:53
Apr 5 19:35:10.205 [10970] dbg: dns: attempt 1/3, trying connect/sendto to
[dnsip]:53
Apr 5 19:35:10.206 [10970] dbg: dns: providing a callback for id:
21426/IN/TXT/wetransfer.com
Apr 5 19:35:10.207 [10970] dbg: dns: bgread: received 603 bytes from dnsip
Apr 5 19:35:10.208 [10970] dbg: dns: dns reply 21426 is OK, 6 answer records
Apr 5 19:35:10.250 [10970] dbg: dns: bgsend, DNS servers: [dnsip]:53,
[dnsip]:53, [dnsip]:53
Apr 5 19:35:10.251 [10970] dbg: dns: attempt 1/3, trying connect/sendto to
[dnsip]:53
Apr 5 19:35:10.251 [10970] dbg: dns: providing a callback for id:
38194/IN/TXT/servers.mcsv.net
Apr 5 19:35:10.252 [10970] dbg: dns: bgread: received 128 bytes from dnsip
Apr 5 19:35:10.252 [10970] dbg: dns: dns reply 38194 is OK, 1 answer records
Apr 5 19:35:10.257 [10970] dbg: dns: bgsend, DNS servers: [dnsip]:53,
[dnsip]:53, [dnsip]:53
Apr 5 19:35:10.257 [10970] dbg: dns: attempt 1/3, trying connect/sendto to
[dnsip]:53
Apr 5 19:35:10.258 [10970] dbg: dns: providing a callback for id:
10004/IN/TXT/_spf.google.com
Apr 5 19:35:10.258 [10970] dbg: dns: bgread: received 160 bytes from dnsip
Apr 5 19:35:10.259 [10970] dbg: dns: dns reply 10004 is OK, 1 answer records
Apr 5 19:35:10.262 [10970] dbg: dns: bgsend, DNS servers: [dnsip]:53,
[dnsip]:53, [dnsip]:53
Apr 5 19:35:10.262 [10970] dbg: dns: attempt 1/3, trying connect/sendto to
[dnsip]:53
Apr 5 19:35:10.262 [10970] dbg: dns: providing a callback for id:
40838/IN/TXT/_netblocks.google.com
Apr 5 19:35:10.263 [10970] dbg: dns: bgread: received 286 bytes from dnsip
Apr 5 19:35:10.263 [10970] dbg: dns: dns reply 40838 is OK, 1 answer records
Apr 5 19:35:10.269 [10970] dbg: dns: bgsend, DNS servers: [dnsip]:53,
[dnsip]:53, [dnsip]:53
Apr 5 19:35:10.269 [10970] dbg: dns: attempt 1/3, trying connect/sendto to
[dnsip]:53
Apr 5 19:35:10.269 [10970] dbg: dns: providing a callback for id:
23072/IN/TXT/_netblocks2.google.com
Apr 5 19:35:10.270 [10970] dbg: dns: bgread: received 218 bytes from dnsip
Apr 5 19:35:10.270 [10970] dbg: dns: dns reply 23072 is OK, 1 answer records
Apr 5 19:35:10.276 [10970] dbg: dns: bgsend, DNS servers: [dnsip]:53,
[dnsip]:53, [dnsip]:53
Apr 5 19:35:10.276 [10970] dbg: dns: attempt 1/3, trying connect/sendto to
[dnsip]:53
Apr 5 19:35:10.277 [10970] dbg: dns: providing a callback for id:
27898/IN/TXT/_netblocks3.google.com
Apr 5 19:35:10.277 [10970] dbg: dns: bgread: received 275 bytes from dnsip
Apr 5 19:35:10.278 [10970] dbg: dns: dns reply 27898 is OK, 1 answer records
Apr 5 19:35:10.283 [10970] dbg: dns: bgsend, DNS servers: [dnsip]:53,
[dnsip]:53, [dnsip]:53
Apr 5 19:35:10.284 [10970] dbg: dns: attempt 1/3, trying connect/sendto to
[dnsip]:53
Apr 5 19:35:10.284 [10970] dbg: dns: providing a callback for id:
61590/IN/TXT/sendgrid.net
Apr 5 19:35:10.287 [10970] dbg: dns: bgread: received 348 bytes from dnsip
Apr 5 19:35:10.288 [10970] dbg: dns: dns reply 61590 is OK, 3 answer records
Apr 5 19:35:10.292 [10970] dbg: dns: bgsend, DNS servers: [dnsip]:53,
[dnsip]:53, [dnsip]:53
Apr 5 19:35:10.292 [10970] dbg: dns: attempt 1/3, trying connect/sendto to
[dnsip]:53
Apr 5 19:35:10.292 [10970] dbg: dns: providing a callback for id:
8713/IN/TXT/mail.zendesk.com
Apr 5 19:35:10.293 [10970] dbg: dns: bgread: received 190 bytes from dnsip
Apr 5 19:35:10.293 [10970] dbg: dns: dns reply 8713 is OK, 1 answer records
Apr 5 19:35:10.296 [10970] dbg: dns: bgsend, DNS servers: [dnsip]:53,
[dnsip]:53, [dnsip]:53
Apr 5 19:35:10.296 [10970] dbg: dns: attempt 1/3, trying connect/sendto to
[dnsip]:53
Apr 5 19:35:10.296 [10970] dbg: dns: providing a callback for id:
4845/IN/TXT/mailsenders.netsuite.com
Apr 5 19:35:10.342 [10970] dbg: dns: bgread: received 746 bytes from dnsip
Apr 5 19:35:10.343 [10970] dbg: dns: dns reply 4845 is OK, 1 answer records
Apr 5 19:35:10.356 [10970] dbg: dns: bgsend, DNS servers: [dnsip]:53,
[dnsip]:53, [dnsip]:53
Apr 5 19:35:10.356 [10970] dbg: dns: attempt 1/3, trying connect/sendto to
[dnsip]:53
Apr 5 19:35:10.356 [10970] dbg: dns: providing a callback for id:
20832/IN/TXT/_spf.salesforce.com
Apr 5 19:35:10.357 [10970] dbg: dns: bgread: received 108 bytes from dnsip
Apr 5 19:35:10.358 [10970] dbg: dns: dns reply 20832 is OK, 1 answer records
Apr 5 19:35:10.360 [10970] dbg: dns: bgsend, DNS servers: [dnsip]:53,
[dnsip]:53, [dnsip]:53
Apr 5 19:35:10.360 [10970] dbg: dns: attempt 1/3, trying connect/sendto to
[dnsip]:53
Apr 5 19:35:10.360 [10970] dbg: dns: providing a callback for id:
21567/IN/A/10.30.65.95._spf.mta.salesforce.com
Apr 5 19:35:10.361 [10970] dbg: dns: bgread: received 117 bytes from dnsip
Apr 5 19:35:10.362 [10970] dbg: dns: dns reply to
21567/IN/A/10.30.65.95._spf.mta.salesforce.com: NXDOMAIN
Apr 5 19:35:10.364 [10970] dbg: spf: query for /10.30.65.95/wetransfer.com:
result: fail, comment: Please see
http://www.openspf.org/Why?s=helo;id=wetransfer.com;ip=10.30.65.95;r=spamd-server,
text: Mechanism '-all' matched
===
Ideally, it would be able to tell that 192.254.118.54 is the sending IP, or at
least determine that 10.30.65.95 is an RFC1918 IP, and thus very likely part of
the sending mail servers' relay chain (and not in SPF).
I'm sure part of the problem is being caused by their own mail configuration,
and we'll be working around by whitelisting their domain (not something I like
to do), but it's possible there's other sendgrid-leveraging sites with a
similar configuration that makes your SPF plugin collapse like this.
Let me know if you require further info.
--
You are receiving this mail because:
You are the assignee for the bug.
