Re: [exim] Exim always expands sender_rcvhost to unverified IP
> On 18 Nov 2021, at 16:53, Matt Corallo via Exim-users > 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 > ) >for vmstfp...@mattcorallo.com; Mon, 15 Nov 2021 21:10:54 + > > 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/
Re: [exim] Exim always expands sender_rcvhost to unverified IP
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 | 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] Exim always expands sender_rcvhost to unverified IP
On 2021-11-18 at 17:16:14 UTC-0500 (Thu, 18 Nov 2021 22:16:14 +)
Jeremy Harris via Exim-users
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
b...@scconsult.com or billc...@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] Exim always expands sender_rcvhost to unverified IP
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] Exim always expands sender_rcvhost to unverified IP
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] Exim always expands sender_rcvhost to unverified IP
On 2021-11-18 at 09:53:38 UTC-0500 (Thu, 18 Nov 2021 09:53:38 -0500) Matt Corallo via Exim-users 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 b...@scconsult.com or billc...@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] Exim always expands sender_rcvhost to unverified IP
On 11/17/21 11:56, Heiko Schlittermann via Exim-users wrote: Heiko Schlittermann via Exim-users (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 ) for vmstfp...@mattcorallo.com; Mon, 15 Nov 2021 21:10:54 + 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] Exim always expands sender_rcvhost to unverified IP
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
)
for vmstfp...@mattcorallo.com; Mon, 15 Nov 2021 21:10:54 +
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
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] Exim always expands sender_rcvhost to unverified IP
Heiko Schlittermann via Exim-users (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 signature.asc Description: PGP signature -- ## 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] Exim always expands sender_rcvhost to unverified IP
Matt Corallo via Exim-users (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 <=
> nore...@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=.
> X=TLS1.2:ECDHE_X25519__ECDSA_SHA512__AES_256_GCM:256 CV=no S=6196
> DKIM=github.com id=bitcoin/bitcoin/pull/23496/review/807558...@github.com
> Nov 16 16:36:55 mail exim[789202]: 2021-11-16 16:36:55 1mn1S3-003JJ3-Bt =>
> btccore F=
> 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 -
signature.asc
Description: PGP signature
--
## 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] Exim always expands sender_rcvhost to unverified IP
On 2021-11-16 at 17:03:14 UTC-0500 (Wed, 17 Nov 2021 01:03:14 +0300) Evgeniy Berdnikov via Exim-users 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/807558...@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-ac8017b8c...@bluematt.me%3e -- Bill Cole b...@scconsult.com or billc...@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] Exim always expands sender_rcvhost to unverified IP
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/807558...@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 ) for vmstfp...@mattcorallo.com; Mon, 15 Nov 2021 21:10:54 + [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] Exim always expands sender_rcvhost to unverified IP
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/807558...@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] Exim always expands sender_rcvhost to unverified IP
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 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 ) for gh-core-notificati...@bluematt.me; Tue, 16 Nov 2021 16:38:23 + -- ## 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] Exim always expands sender_rcvhost to unverified IP
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 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 <= > nore...@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/807558...@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/
[exim] Exim always expands sender_rcvhost to unverified IP
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 <= nore...@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/807558...@github.com Nov 16 16:36:55 mail exim[789202]: 2021-11-16 16:36:55 1mn1S3-003JJ3-Bt => btccore F= 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] 2620:4d:4000:6259:7:4:0:1, dns2.p04.nsone.net. [5h32m41s] 2a00:edc0:6259:7:4::2, dns3.p04.nsone.net. [5h31m15s] 2620:4d:4000:6259:7:4:0:3, dns4.p04.nsone.net. [5h31m39s] 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] ? 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: ? 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,
