Re: [exim] Exim always expands sender_rcvhost to unverified …

Top Page
Delete this message
Reply to this message
Author: Bill Cole
Date:  
To: Jeremy Harris via Exim-users
Subject: 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 +0000)
Jeremy Harris via Exim-users <jgh@???>
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@??? or billcole@???
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire