Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. exim>
  3. users
Exim always expands sender_rcvhost to unverified IP
exim-users at exim
Nov 16, 2021, 8:47 AM
Post #1 of 16 (1547 views)
Permalink
Like the title says, for some reason exim 4.94.2-7 (Debian stable) is refusing to ever expand
sender_rcvhost to a verified hostname. The below shows a simple email inbound from github, as well
as the relevant DNS traffic from exim to the DNS server (with spamd stopped to ensure we're not
confusing spamd queries with exim queries).

Possibly-relevant config entries are:

dkim_verify_signers = :
host_lookup = *
dns_dnssec_ok = 1
slow_lookup_log = 250

"options trust-ad" is set in resolv.conf.

Exim log:

Nov 16 16:36:55 mail exim[789201]: 2021-11-16 16:36:55 1mn1S3-003JJ3-Bt spam acl condition: spamd:
failed to connect to any address for 127.0.0.1: Connection refused
Nov 16 16:36:55 mail exim[789201]: 2021-11-16 16:36:55 1mn1S3-003JJ3-Bt spam acl condition: all
spamd servers failed
Nov 16 16:36:55 mail exim[789201]: 2021-11-16 16:36:55 1mn1S3-003JJ3-Bt spam acl condition: all
spamd servers failed
Nov 16 16:36:55 mail exim[789201]: 2021-11-16 16:36:55 1mn1S3-003JJ3-Bt H=out-25.smtp.github.com
(smtp.github.com) [192.30.252.208] Warning: ACL "warn" statement skipped: condition test deferred
Nov 16 16:36:55 mail exim[789201]: 2021-11-16 16:36:55 1mn1S3-003JJ3-Bt <= noreply@github.com
H=out-25.smtp.github.com (smtp.github.com) [192.30.252.208] P=esmtps
X=TLS1.2:ECDHE_X25519__ECDSA_SHA512__AES_256_GCM:256 CV=no S=6196 DKIM=github.com
id=bitcoin/bitcoin/pull/23496/review/807558392@github.com
Nov 16 16:36:55 mail exim[789202]: 2021-11-16 16:36:55 1mn1S3-003JJ3-Bt => btccore
<gh-core-notifications@bluematt.me> F=<noreply@github.com> R=maildrop_router T=maildrop_pipe
Nov 16 16:36:55 mail exim[789202]: 2021-11-16 16:36:55 1mn1S3-003JJ3-Bt Completed

DNS queries, note that the FcRDNS lookup succeeds at 16:36:55.159851.

16:36:55.157242 IP (tos 0x0, ttl 64, id 14817, offset 0, flags [DF], proto UDP (17), length 84)
69.59.18.99.47444 > 69.59.18.0.53: [udp sum ok] 23619+ [1au] PTR? 208.252.30.192.in-addr.arpa.
ar: . OPT UDPsize=1200 DO (56)
16:36:55.157707 IP (tos 0x0, ttl 64, id 1218, offset 0, flags [none], proto UDP (17), length 1225)
69.59.18.0.53 > 69.59.18.99.47444: [bad udp cksum 0xb39f -> 0xb0a2!] 23619 q: PTR?
208.252.30.192.in-addr.arpa. 1/4/17 208.252.30.192.in-addr.arpa. [11m14s] PTR
out-25.smtp.github.com. ns: 252.30.192.in-addr.arpa. [6h54m9s] NS dns2.p04.nsone.net.,
252.30.192.in-addr.arpa. [6h54m9s] NS dns1.p04.nsone.net., 252.30.192.in-addr.arpa. [6h54m9s] NS
dns4.p04.nsone.net., 252.30.192.in-addr.arpa. [6h54m9s] NS dns3.p04.nsone.net. ar:
dns1.p04.nsone.net. [5h27m] A 198.51.44.4, dns2.p04.nsone.net. [5h28m16s] A 198.51.45.4,
dns3.p04.nsone.net. [5h27m39s] A 198.51.44.68, dns4.p04.nsone.net. [5h28m46s] A 198.51.45.68,
dns1.p04.nsone.net. [5h31m24s] AAAA 2620:4d:4000:6259:7:4:0:1, dns2.p04.nsone.net. [5h32m41s] AAAA
2a00:edc0:6259:7:4::2, dns3.p04.nsone.net. [5h31m15s] AAAA 2620:4d:4000:6259:7:4:0:3,
dns4.p04.nsone.net. [5h31m39s] AAAA 2a00:edc0:6259:7:4::4, dns1.p04.nsone.net. [5h27m] RRSIG,
dns1.p04.nsone.net. [5h31m24s] RRSIG, dns2.p04.nsone.net. [5h28m16s] RRSIG, dns2.p04.nsone.net.
[5h32m41s] RRSIG, dns3.p04.nsone.net. [5h27m39s] RRSIG, dns3.p04.nsone.net. [5h31m15s] RRSIG,
dns4.p04.nsone.net. [5h28m46s] RRSIG, dns4.p04.nsone.net. [5h31m39s] RRSIG, . OPT UDPsize=1432 DO (1197)
16:36:55.158465 IP (tos 0x0, ttl 64, id 14818, offset 0, flags [DF], proto UDP (17), length 79)
69.59.18.99.41522 > 69.59.18.0.53: [udp sum ok] 64096+ [1au] AAAA? out-25.smtp.github.com. ar:
. OPT UDPsize=1200 DO (51)
16:36:55.158976 IP (tos 0x0, ttl 64, id 1219, offset 0, flags [none], proto UDP (17), length 176)
69.59.18.0.53 > 69.59.18.99.41522: [bad udp cksum 0xaf86 -> 0x074b!] 64096 q: AAAA?
out-25.smtp.github.com. 0/1/1 ns: github.com. [2m12s] SOA ns-1707.awsdns-21.co.uk.
awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400 ar: . OPT UDPsize=1432 DO (148)
16:36:55.159421 IP (tos 0x0, ttl 64, id 14819, offset 0, flags [DF], proto UDP (17), length 79)
69.59.18.99.35042 > 69.59.18.0.53: [udp sum ok] 36466+ [1au] A? out-25.smtp.github.com. ar: .
OPT UDPsize=1200 DO (51)
16:36:55.159851 IP (tos 0x0, ttl 64, id 1220, offset 0, flags [none], proto UDP (17), length 1211)
69.59.18.0.53 > 69.59.18.99.35042: [bad udp cksum 0xb391 -> 0x4d29!] 36466 q: A?
out-25.smtp.github.com. 1/8/22 out-25.smtp.github.com. [11m14s] A 192.30.252.208 ns: github.com.
[23m34s] NS ns-1283.awsdns-32.org., github.com. [23m34s] NS dns3.p08.nsone.net., github.com.
[23m34s] NS dns1.p08.nsone.net., github.com. [23m34s] NS ns-421.awsdns-52.com., github.com. [23m34s]
NS dns2.p08.nsone.net., github.com. [23m34s] NS dns4.p08.nsone.net., github.com. [23m34s] NS
ns-520.awsdns-01.net., github.com. [23m34s] NS ns-1707.awsdns-21.co.uk. ar: dns1.p08.nsone.net.
[5h46m52s] A 198.51.44.8, dns2.p08.nsone.net. [5h46m54s] A 198.51.45.8, dns3.p08.nsone.net.
[5h46m20s] A 198.51.44.72, dns4.p08.nsone.net. [5h46m15s] A 198.51.45.72, ns-421.awsdns-52.com.
[1d5h26m42s] A 205.251.193.165, ns-520.awsdns-01.net. [1d5h27m1s] A 205.251.194.8,
ns-1283.awsdns-32.org. [1d5h8m37s] A 205.251.197.3, ns-1707.awsdns-21.co.uk. [1d5h27m34s] A
205.251.198.171, dns1.p08.nsone.net. [5h11m4s] AAAA 2620:4d:4000:6259:7:8:0:1, dns2.p08.nsone.net.
[5h12m40s] AAAA 2a00:edc0:6259:7:8::2, dns3.p08.nsone.net. [5h50m18s] AAAA
2620:4d:4000:6259:7:8:0:3, dns4.p08.nsone.net. [5h50m50s] AAAA 2a00:edc0:6259:7:8::4,
ns-421.awsdns-52.com. [1d5h49m59s] AAAA 2600:9000:5301:a500::1, ns-520.awsdns-01.net. [1d5h49m41s]
AAAA 2600:9000:5302:800::1, ns-1283.awsdns-32.org. [1d5h11m18s] AAAA 2600:9000:5305:300::1,
ns-1707.awsdns-21.co.uk. [1d5h50m42s] AAAA 2600:9000:5306:ab00::1, dns1.p08.nsone.net. [5h46m52s]
RRSIG, dns1.p08.nsone.net. [5h11m4s] RRSIG, dns2.p08.nsone.net. [5h46m54s] RRSIG,
dns2.p08.nsone.net. [5h12m40s] RRSIG, dns3.p08.nsone.net. [5h46m20s] RRSIG, . OPT UDPsize=1432 DO (1183)
16:36:55.419515 IP (tos 0x0, ttl 64, id 15076, offset 0, flags [DF], proto UDP (17), length 85)
69.59.18.99.57791 > 69.59.18.0.53: [udp sum ok] 25020+ [1au] TXT? pf2014._domainkey.github.com.
ar: . OPT UDPsize=1200 DO (57)
16:36:55.420095 IP (tos 0x0, ttl 64, id 1221, offset 0, flags [none], proto UDP (17), length 1133)
69.59.18.0.53 > 69.59.18.99.57791: [bad udp cksum 0xb343 -> 0x2097!] 25020 q: TXT?
pf2014._domainkey.github.com. 1/8/19 pf2014._domainkey.github.com. [57m25s] TXT "v=DKIM1; k=rsa;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDaCCQ+CiOqRkMAM/Oi04Xjhnxv3bXkTtA8KXt49RKQExLCmBxRpMp0PMMI73noKL/bZwEXljPO8HIfzG43ntPp1QRBUpn1UEvbp1/rlWPUop3i1j6aUpjxYGHEEzgmT+ncLUBDEPO4n4Zzt36DG3ZcJaLhvKtRkk2off5XD+BMvQIDAQAB"
ns: github.com. [23m34s] NS ns-1283.awsdns-32.org., github.com. [23m34s] NS
ns-1707.awsdns-21.co.uk., github.com. [23m34s] NS dns3.p08.nsone.net., github.com. [23m34s] NS
dns4.p08.nsone.net., github.com. [23m34s] NS dns1.p08.nsone.net., github.com. [23m34s] NS
ns-520.awsdns-01.net., github.com. [23m34s] NS ns-421.awsdns-52.com., github.com. [23m34s] NS
dns2.p08.nsone.net. ar: dns1.p08.nsone.net. [5h46m52s] A 198.51.44.8, dns2.p08.nsone.net. [5h46m54s]
A 198.51.45.8, dns3.p08.nsone.net. [5h46m20s] A 198.51.44.72, dns4.p08.nsone.net. [5h46m15s] A
198.51.45.72, ns-421.awsdns-52.com. [1d5h26m42s] A 205.251.193.165, ns-520.awsdns-01.net.
[1d5h27m1s] A 205.251.194.8, ns-1283.awsdns-32.org. [1d5h8m37s] A 205.251.197.3,
ns-1707.awsdns-21.co.uk. [1d5h27m34s] A 205.251.198.171, dns1.p08.nsone.net. [5h11m4s] AAAA
2620:4d:4000:6259:7:8:0:1, dns2.p08.nsone.net. [5h12m40s] AAAA 2a00:edc0:6259:7:8::2,
dns3.p08.nsone.net. [5h50m18s] AAAA 2620:4d:4000:6259:7:8:0:3, dns4.p08.nsone.net. [5h50m50s] AAAA
2a00:edc0:6259:7:8::4, ns-421.awsdns-52.com. [1d5h49m59s] AAAA 2600:9000:5301:a500::1,
ns-520.awsdns-01.net. [1d5h49m41s] AAAA 2600:9000:5302:800::1, ns-1283.awsdns-32.org. [1d5h11m18s]
AAAA 2600:9000:5305:300::1, ns-1707.awsdns-21.co.uk. [1d5h50m42s] AAAA 2600:9000:5306:ab00::1,
dns1.p08.nsone.net. [5h46m52s] RRSIG, dns1.p08.nsone.net. [5h11m4s] RRSIG, . OPT UDPsize=1432 DO (1105)

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Exim always expands sender_rcvhost to unverified IP [ In reply to ]
exim-users at exim
Nov 16, 2021, 10:47 AM
Post #2 of 16 (1547 views)
Permalink
Hello.

On Tue, Nov 16, 2021 at 11:47:22AM -0500, Matt Corallo via Exim-users wrote:
> Like the title says, for some reason exim 4.94.2-7 (Debian stable) is
> refusing to ever expand sender_rcvhost to a verified hostname.

Your mail passed my relay with Exim 4.94.2-7 (frozen good old version)
and got this header:

Received: from hummus.exim.org ([37.221.193.62]:49438)
by tornado.rdtex.ru with esmtps
(TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
(Exim 4.94.2)
(envelope-from <exim-users-bounces...
...

where I have custom

received_header_text = Received: ${if def:sender_rcvhost {from $sender_rcvhost\n\t}...

So, $sender_rcvhost is expanded as it should be.
Debian package on this host is exim4-daemon-heavy 4.94.2-7 (i386).

> The below
> shows a simple email inbound from github, as well as the relevant DNS
> traffic from exim to the DNS server (with spamd stopped to ensure we're not
> confusing spamd queries with exim queries).

I see no expansion of $sender_rcvhost in your report.
It may be obtained with -d+expand or extracted from "Received" headers.

However, this log line

> Nov 16 16:36:55 mail exim[789201]: 2021-11-16 16:36:55 1mn1S3-003JJ3-Bt <=
> noreply@github.com H=out-25.smtp.github.com (smtp.github.com)
> [192.30.252.208] P=esmtps
> X=TLS1.2:ECDHE_X25519__ECDSA_SHA512__AES_256_GCM:256 CV=no S=6196
> DKIM=github.com id=bitcoin/bitcoin/pull/23496/review/807558392@github.com

have part "H=..." which is very similar to $sender_rcvhost.
Are you expecting anything different?
--
Eugene Berdnikov

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Exim always expands sender_rcvhost to unverified IP [ In reply to ]
exim-users at exim
Nov 16, 2021, 12:11 PM
Post #3 of 16 (1547 views)
Permalink
On 11/16/21 13:47, Evgeniy Berdnikov via Exim-users wrote:
> Hello.
>
> On Tue, Nov 16, 2021 at 11:47:22AM -0500, Matt Corallo via Exim-users wrote:
>> Like the title says, for some reason exim 4.94.2-7 (Debian stable) is
>> refusing to ever expand sender_rcvhost to a verified hostname.
>
> Your mail passed my relay with Exim 4.94.2-7 (frozen good old version)
> and got this header:
>
> Received: from hummus.exim.org ([37.221.193.62]:49438)
> by tornado.rdtex.ru with esmtps
> (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
> (Exim 4.94.2)
> (envelope-from <exim-users-bounces...
> ...
>
> where I have custom
>
> received_header_text = Received: ${if def:sender_rcvhost {from $sender_rcvhost\n\t}...
>
> So, $sender_rcvhost is expanded as it should be.
> Debian package on this host is exim4-daemon-heavy 4.94.2-7 (i386).

Ah, maybe I'm misunderstanding how $sender_rcvhost is expanded (and spamassassin is as well).

The way I was (apparently incorrectly?) interpreting a similar expansion here is that the host was
not verified via FcRDNS due to the presence of the square brackets in the parenthetical. Apparently
that is the way Spamassasin is also interpreting the same received line, marking all mails as "no
verified RDNS".

>> The below
>> shows a simple email inbound from github, as well as the relevant DNS
>> traffic from exim to the DNS server (with spamd stopped to ensure we're not
>> confusing spamd queries with exim queries).
>
> I see no expansion of $sender_rcvhost in your report.
> It may be obtained with -d+expand or extracted from "Received" headers.

Sorry, the received line (or another one from a bit later, same thing though) ended up as:

Received: from out-17.smtp.github.com ([192.30.252.200] helo=smtp.github.com)
by mail.as397444.net with esmtps TLS1.2 id 1mn1TT-003JJr-1l
(envelope-from <noreply@github.com>)
for gh-core-notifications@bluematt.me; Tue, 16 Nov 2021 16:38:23 +0000

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Exim always expands sender_rcvhost to unverified IP [ In reply to ]
exim-users at exim
Nov 16, 2021, 2:03 PM
Post #4 of 16 (1547 views)
Permalink
On Tue, Nov 16, 2021 at 03:11:50PM -0500, Matt Corallo via Exim-users wrote:
> The way I was (apparently incorrectly?) interpreting a similar expansion
> here is that the host was not verified via FcRDNS due to the presence of the
> square brackets in the parenthetical. Apparently that is the way Spamassasin
> is also interpreting the same received line, marking all mails as "no
> verified RDNS".

Sounds strange... Your original mail passed my Spamassasin with this result:

X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Level:
X-Spam-Status: No, score=-0.09 tagged_above=-100 required=4.7
tests=[.BAYES_00=-1.9, DKIMWL_WL_HIGH=-1, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
MAILING_LIST_MULTI=-1, MONEY_CONTENT_02=2, MONEY_CONTENT_02=2,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FOREIGN_FROM=0.01]
autolearn=no autolearn_force=no

Here "MONEY_CONTENT_02" is my own test, it catched two "bitcoin" words
in line "id=bitcoin/bitcoin/pull/23496/review/807558392@github.com"
from your mail. But RDNS is not mentioned, dispite of header
"Received: from hummus.exim.org ([37.221.193.62]:49438)".

Have you X-Spam-Status: records in received mails? Do they mention RDNS?
--
Eugene Berdnikov

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Exim always expands sender_rcvhost to unverified IP [ In reply to ]
exim-users at exim
Nov 16, 2021, 8:25 PM
Post #5 of 16 (1547 views)
Permalink
On 11/16/21 17:03, Evgeniy Berdnikov via Exim-users wrote:
> On Tue, Nov 16, 2021 at 03:11:50PM -0500, Matt Corallo via Exim-users wrote:
>> The way I was (apparently incorrectly?) interpreting a similar expansion
>> here is that the host was not verified via FcRDNS due to the presence of the
>> square brackets in the parenthetical. Apparently that is the way Spamassasin
>> is also interpreting the same received line, marking all mails as "no
>> verified RDNS".
>
> Sounds strange... Your original mail passed my Spamassasin with this result:
>
> X-Spam-Flag: NO
> X-Spam-Score: -0.09
> X-Spam-Level:
> X-Spam-Status: No, score=-0.09 tagged_above=-100 required=4.7
> tests=[.BAYES_00=-1.9, DKIMWL_WL_HIGH=-1, DKIM_SIGNED=0.1,
> DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
> MAILING_LIST_MULTI=-1, MONEY_CONTENT_02=2, MONEY_CONTENT_02=2,
> SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FOREIGN_FROM=0.01]
> autolearn=no autolearn_force=no
>
> Here "MONEY_CONTENT_02" is my own test, it catched two "bitcoin" words
> in line "id=bitcoin/bitcoin/pull/23496/review/807558392@github.com"
> from your mail. But RDNS is not mentioned, dispite of header
> "Received: from hummus.exim.org ([37.221.193.62]:49438)".
>
> Have you X-Spam-Status: records in received mails? Do they mention RDNS?
>

Yes, the relevant mail which kicked off the investigation is available on the spamassassin-users
thread at [0]. The original received line generated by Exim which SA failed to properly parse was:

Received: from o13.mailer.shopify.com ([149.72.221.62])
by mail.as397444.net with esmtps TLS1.3 id 1mmjFb-0034Ki-02
(envelope-from <bounces+11006833-f9b2-vmstfpodc=mattcorallo.com@mailer.shopifyemail.com>)
for vmstfpodc@mattcorallo.com; Mon, 15 Nov 2021 21:10:54 +0000

[0] https://mail-archives.apache.org/mod_mbox/spamassassin-users/202111.mbox/browser

Matt

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Exim always expands sender_rcvhost to unverified IP [ In reply to ]
exim-users at exim
Nov 16, 2021, 9:28 PM
Post #6 of 16 (1547 views)
Permalink
On 2021-11-16 at 17:03:14 UTC-0500 (Wed, 17 Nov 2021 01:03:14 +0300)
Evgeniy Berdnikov via Exim-users <bd4@protva.ru>
is rumored to have said:

> On Tue, Nov 16, 2021 at 03:11:50PM -0500, Matt Corallo via Exim-users
> wrote:
>> The way I was (apparently incorrectly?) interpreting a similar
>> expansion
>> here is that the host was not verified via FcRDNS due to the presence
>> of the
>> square brackets in the parenthetical. Apparently that is the way
>> Spamassasin
>> is also interpreting the same received line, marking all mails as "no
>> verified RDNS".
>
> Sounds strange... Your original mail passed my Spamassasin with this
> result:
>
> X-Spam-Flag: NO
> X-Spam-Score: -0.09
> X-Spam-Level:
> X-Spam-Status: No, score=-0.09 tagged_above=-100 required=4.7
> tests=[.BAYES_00=-1.9, DKIMWL_WL_HIGH=-1, DKIM_SIGNED=0.1,
> DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
> MAILING_LIST_MULTI=-1, MONEY_CONTENT_02=2, MONEY_CONTENT_02=2,
> SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FOREIGN_FROM=0.01]
> autolearn=no autolearn_force=no
>
> Here "MONEY_CONTENT_02" is my own test, it catched two "bitcoin"
> words
> in line "id=bitcoin/bitcoin/pull/23496/review/807558392@github.com"
> from your mail. But RDNS is not mentioned, dispite of header
> "Received: from hummus.exim.org ([37.221.193.62]:49438)".

Whether SA cares about rDNS indicators in a Received header is a
function of whether the local config (internal_networks and
trusted_networks) causes that Received header to be identified by SA as
the last one which records the transfer from an external host to a host
which is "trusted" in the sense that it is believed to write accurate
Received headers.

> Have you X-Spam-Status: records in received mails? Do they mention
> RDNS?

Matt posted a sample in the SpamAssassin Users list:
https://mail-archives.apache.org/mod_mbox/spamassassin-users/202111.mbox/%3c0eca22eb-9c51-becf-579f-ac8017b8c5dd@bluematt.me%3e



--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Exim always expands sender_rcvhost to unverified IP [ In reply to ]
exim-users at exim
Nov 17, 2021, 4:17 AM
Post #7 of 16 (1547 views)
Permalink
Matt Corallo via Exim-users <exim-users@exim.org> (Di 16 Nov 2021 17:47:22 CET):
> Like the title says, for some reason exim 4.94.2-7 (Debian stable) is
> refusing to ever expand sender_rcvhost to a verified hostname. The below

Typo? What do you mean with "sender_rcvhost"?

> shows a simple email inbound from github, as well as the relevant DNS
> traffic from exim to the DNS server (with spamd stopped to ensure we're not
> confusing spamd queries with exim queries).
>
> Possibly-relevant config entries are:
>
> dkim_verify_signers = :
> host_lookup = *
> dns_dnssec_ok = 1
> slow_lookup_log = 250
>
> "options trust-ad" is set in resolv.conf.
>
> Exim log:
>
> Nov 16 16:36:55 mail exim[789201]: 2021-11-16 16:36:55 1mn1S3-003JJ3-Bt
> H=out-25.smtp.github.com (smtp.github.com) [192.30.252.208] Warning: ACL
> "warn" statement skipped: condition test deferred
> Nov 16 16:36:55 mail exim[789201]: 2021-11-16 16:36:55 1mn1S3-003JJ3-Bt <=
> noreply@github.com H=out-25.smtp.github.com (smtp.github.com)
> [192.30.252.208] P=esmtps

Here Exim was able to resolve the client IP to a hostname, as indicated
by H=<name>.

> X=TLS1.2:ECDHE_X25519__ECDSA_SHA512__AES_256_GCM:256 CV=no S=6196
> DKIM=github.com id=bitcoin/bitcoin/pull/23496/review/807558392@github.com
> Nov 16 16:36:55 mail exim[789202]: 2021-11-16 16:36:55 1mn1S3-003JJ3-Bt =>
> btccore <gh-core-notifications@bluematt.me> F=<noreply@github.com>
> R=maildrop_router T=maildrop_pipe
> Nov 16 16:36:55 mail exim[789202]: 2021-11-16 16:36:55 1mn1S3-003JJ3-Bt Completed

All that looks totally fine, so probably I'm missing your point.
If it is the "warn" you're complaining about, then please provide that
part of the ACL.

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -

Attached Files:

Re: Exim always expands sender_rcvhost to unverified IP [ In reply to ]
exim-users at exim
Nov 17, 2021, 8:56 AM
Post #8 of 16 (1547 views)
Permalink
Heiko Schlittermann via Exim-users <exim-users@exim.org> (Mi 17 Nov 2021 13:17:33 CET):
> Typo? What do you mean with "sender_rcvhost"?
Mea culpa. You're talking about the variable to be expanded inside the
Received header.

But given this, I still can't see any issue with the logs you provided.

--
Heiko

Attached Files:

Re: Exim always expands sender_rcvhost to unverified IP [ In reply to ]
exim-users at exim
Nov 18, 2021, 6:53 AM
Post #9 of 16 (1547 views)
Permalink
On 11/17/21 11:56, Heiko Schlittermann via Exim-users wrote:
> Heiko Schlittermann via Exim-users <exim-users@exim.org> (Mi 17 Nov 2021 13:17:33 CET):
>> Typo? What do you mean with "sender_rcvhost"?
> Mea culpa. You're talking about the variable to be expanded inside the
> Received header.
>
> But given this, I still can't see any issue with the logs you provided.


Same, I'd think, but according to the SpamAssassin folks its incorrect. According to them, a
Received line like the following indicates that the host was *not* verified, but Exim seems to have
fully verified the FcRDNS:

Received: from o13.mailer.shopify.com ([149.72.221.62])
by mail.as397444.net with esmtps TLS1.3 id 1mmjFb-0034Ki-02
(envelope-from <bounces+11006833-f9b2-vmstfpodc=mattcorallo.com@mailer.shopifyemail.com>)
for vmstfpodc@mattcorallo.com; Mon, 15 Nov 2021 21:10:54 +0000

Specifically, it seems Spamassassin is looking for something more postfix-esque like
Received: from o13.mailer.shopify.com (o13.mailer.shopify.com [149.72.221.62])

I haven't dug into any relevant RFCs to see who's fault it really is, but it seems Spamassassin and
Exim don't agree on how to communicate validated DNS.

Matt

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Exim always expands sender_rcvhost to unverified IP [ In reply to ]
exim-users at exim
Nov 18, 2021, 7:14 AM
Post #10 of 16 (1547 views)
Permalink
On 18/11/2021 14:53, Matt Corallo via Exim-users wrote:
>
> Received: from o13.mailer.shopify.com ([149.72.221.62])
>     by mail.as397444.net with esmtps TLS1.3 id 1mmjFb-0034Ki-02
>     (envelope-from <bounces+11006833-f9b2-vmstfpodc=mattcorallo.com@mailer.shopifyemail.com>)
>     for vmstfpodc@mattcorallo.com; Mon, 15 Nov 2021 21:10:54 +0000
>
> Specifically, it seems Spamassassin is looking for something more postfix-esque like
> Received: from o13.mailer.shopify.com (o13.mailer.shopify.com [149.72.221.62])
>
> I haven't dug into any relevant RFCs to see who's fault it really is, but it seems Spamassassin and Exim don't agree on how to communicate validated DNS.

RFC 5321, Section 4.4 has the relevant ABNF. Selected bits:

Time-stamp-line = "Received:" FWS Stamp <CRLF>

Stamp = From-domain By-domain Opt-info [CFWS] ";"
FWS date-time

From-domain = "FROM" FWS Extended-Domain

Extended-Domain = Domain /
( Domain FWS "(" TCP-info ")" ) /
( address-literal FWS "(" TCP-info ")" )

TCP-info = address-literal / ( Domain FWS address-literal )
; Information derived by server from TCP connection
; not client EHLO.


I thinks Exim's line fits that with
TCP-info = [149.72.221.62] ; an address-literal
Domain = o13.mailer.shopify.com




You can define the Received line to suit yourself; it is a option in
the Exim config file.
--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Exim always expands sender_rcvhost to unverified IP [ In reply to ]
exim-users at exim
Nov 18, 2021, 11:10 AM
Post #11 of 16 (1547 views)
Permalink
On 2021-11-18 at 09:53:38 UTC-0500 (Thu, 18 Nov 2021 09:53:38 -0500)
Matt Corallo via Exim-users <exmusl@mattcorallo.com>
is rumored to have said:

> Same, I'd think, but according to the SpamAssassin folks its
> incorrect.

I do not think that anyone involved with the SA project said anything
Exim did was "incorrect." If my discussion of this on the SA Users list
sounded like I was saying that, it was unintentional.

The Received header created by Exim in the example that you provided
were *interpreted by SA* as indicating that there was no rDNS for the
SMTP client. That's a bit surprising, given that SA and Exim have
coexisted for many years and the resulting SA rule hits (RDNS_NONE and
others) can be very costly. I have not yet examined this in depth but
given the history of SA in parsing Received headers, I expect that we
will have a fix in the next release.

As always with SA: patches are welcome. Also welcome, short of a patch,
would be clues about how to detect in an Exim-written Received header
when a SMTP client IP has no rDNS or the rDNS name doesn't resolve to
the client IP.


--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Exim always expands sender_rcvhost to unverified IP [ In reply to ]
exim-users at exim
Nov 18, 2021, 2:16 PM
Post #12 of 16 (1547 views)
Permalink
On 18/11/2021 19:10, Bill Cole via Exim-users wrote:
> Also welcome, short of a patch, would be clues about how to detect in an Exim-written Received header when a SMTP client IP has no rDNS or the rDNS name doesn't resolve to the client IP.

It would be more reliable to interpret an Authentication-Results header (cf. RFC 8601),
assuming the Exim config creates one using the intended expansion item

eg:

add_header = :at_start:${authresults {$primary_hostname}}


In either case you would be dependent on an rDNS check having
done; this is not automatic and can be avoided by the config.

Checks of the peer IP against a hostlist item which is a name
will cause one, as will matching the host_lookup option or
an explicit verify=reverse_host_lookup ACL condition.
--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Exim always expands sender_rcvhost to unverified IP [ In reply to ]
exim-users at exim
Nov 18, 2021, 3:05 PM
Post #13 of 16 (1547 views)
Permalink
On 2021-11-18 at 17:16:14 UTC-0500 (Thu, 18 Nov 2021 22:16:14 +0000)
Jeremy Harris via Exim-users <jgh@wizmail.org>
is rumored to have said:

> On 18/11/2021 19:10, Bill Cole via Exim-users wrote:
>> Also welcome, short of a patch, would be clues about how to detect in
>> an Exim-written Received header when a SMTP client IP has no rDNS or
>> the rDNS name doesn't resolve to the client IP.
>
> It would be more reliable to interpret an Authentication-Results
> header (cf. RFC 8601),
> assuming the Exim config creates one using the intended expansion item

Big assumption.

Received headers are more reliably present and we have multiple
functions dependent on parsing them. Since we only care about rDNS for
the last hop from an untrusted host to a trusted one (i.e. Received
header written by a trusted writer) and need to support use cases where
the user trusts but doesn't manage their MTA, I expect we'll need to
keep working with Received if possible.

> eg:
>
> add_header = :at_start:${authresults {$primary_hostname}}
>
>
> In either case you would be dependent on an rDNS check having
> done; this is not automatic and can be avoided by the config.
>
> Checks of the peer IP against a hostlist item which is a name
> will cause one, as will matching the host_lookup option or
> an explicit verify=reverse_host_lookup ACL condition.

So, if none of that happens, what will the Received header look like?
Will the client domain name be just the HELO name or an IP literal or
what? Would there be any apparent difference between cases where the
lookup was never done and where it failed?



--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Exim always expands sender_rcvhost to unverified IP [ In reply to ]
exim-users at exim
Nov 18, 2021, 3:18 PM
Post #14 of 16 (1547 views)
Permalink
On 18/11/2021 23:05, Bill Cole via Exim-users wrote:
>> Checks of the peer IP against a hostlist item which is a name
>> will cause one, as will matching the host_lookup option or
>> an explicit verify=reverse_host_lookup ACL condition.
>
> So, if none of that happens, what will the Received header look like?

The default definition is:

"Received: "
"${if def:sender_rcvhost {from $sender_rcvhost\n\t}"
"{${if def:sender_ident {from ${quote_local_part:$sender_ident} }}"
"${if def:sender_helo_name {(helo=$sender_helo_name)\n\t}}}}"
"by $primary_hostname "
"${if def:received_protocol {with $received_protocol }}"
#ifndef DISABLE_TLS
"${if def:tls_in_ver { ($tls_in_ver)}}"
"${if def:tls_in_cipher_std { tls $tls_in_cipher_std\n\t}}"
#endif
"(Exim $version_number)\n\t"
"${if def:sender_address {(envelope-from <$sender_address>)\n\t}}"
"id $message_exim_id"
"${if def:received_for {\n\tfor $received_for}}"

It's an option in the config, therefore changeable.
I doubt many people do.


The default was changed most recently in 2019, before 4.93 release.

--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Exim always expands sender_rcvhost to unverified IP [ In reply to ]
exim-users at exim
Nov 24, 2021, 4:33 AM
Post #15 of 16 (1541 views)
Permalink
On 19/11/2021 00:18, Jeremy Harris via Exim-users wrote:
>      "Received: "
>      "${if def:sender_rcvhost {from $sender_rcvhost\n\t}"
>        "{${if def:sender_ident {from ${quote_local_part:$sender_ident} }}"
>          "${if def:sender_helo_name {(helo=$sender_helo_name)\n\t}}}}"

One thing I personally patch since back in 2006 is the fact that
$sender_rcvhost is built in src/host.c and has many if()s.

eg. it only prints the helo= if it is different from the PTR. But SA does
not parse any HELO if it is not in the Received with helo=. So I basically
patched host.c to always include helo= in $sender_fullhost and
$sender_rcvhost if $sender_helo_name is available.

The patch is trivial. It comments out HEAD:host.c:627/628

I do not remember if this also "fixed" any other sort of SA parsing of
Received Headers.

Greetings, Wolfgang
--
Wolfgang Breyha <wbreyha@gmx.net> | https://www.blafasel.at/
Vienna University Computer Center | Austria

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Exim always expands sender_rcvhost to unverified IP [ In reply to ]
exim-users at exim
Nov 26, 2021, 2:33 AM
Post #16 of 16 (1539 views)
Permalink
> On 18 Nov 2021, at 16:53, Matt Corallo via Exim-users <exim-users@exim.org> wrote:
>
> Same, I'd think, but according to the SpamAssassin folks its incorrect. According to them, a Received line like the following indicates that the host was *not* verified, but Exim seems to have fully verified the FcRDNS:
>
> Received: from o13.mailer.shopify.com ([149.72.221.62])
> by mail.as397444.net with esmtps TLS1.3 id 1mmjFb-0034Ki-02
> (envelope-from <bounces+11006833-f9b2-vmstfpodc=mattcorallo.com@mailer.shopifyemail.com>)
> for vmstfpodc@mattcorallo.com; Mon, 15 Nov 2021 21:10:54 +0000
>
> Specifically, it seems Spamassassin is looking for something more postfix-esque like
> Received: from o13.mailer.shopify.com (o13.mailer.shopify.com [149.72.221.62])
>
> I haven't dug into any relevant RFCs to see who's fault it really is, but it seems Spamassassin and Exim don't agree on how to communicate validated DNS.

Actually the reason why the rdns value is not parsed by Spamassassin in your case
is because your header does not include "Exim" i.e `(Exim $version_number)\n\t`.

The Spamassassin code has a switch[1] which identifies Exim headers and would be able
to parse your header correctly if your "$received_header_text" didn't strip out the MTA
version `(Exim $version_number)\n\t`.

The default "$received_header_text" should work correctly.

[1] https://github.com/apache/spamassassin/blob/3.4/lib/Mail/SpamAssassin/Message/Metadata/Received.pm#L548

- Andrew


--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal