(was Re: [exim] Exim always expands sender_rcvhost to unverified IP, new thread for visibility)
In the previous thread it was discovered that SpamAssassin (as of 3.4.6) does not support parsing
the Received: header that exim (as of 4.94.2) generates, causing messages to be mis-scored (usually
penalized, sometimes heavily, as SpamAssassin incorrectly believes the sending host does not have an
FcRDNS entry). This may be fixed in a future version of SpamAssassin, but for now, I'm using the
following Received line which appears to work correctly (mimicking Received lines from other mailers):
received_header_text = Received: \
${if def:sender_helo_name {from $sender_helo_name }}\
${if def:sender_fullhost {(${sg{$sender_fullhost}{.*\\) }{unknown }}) \n\t}}\
by $primary_hostname \
${if def:received_protocol {with $received_protocol }}\
${if def:tls_in_ver {$tls_in_ver }}\
id $message_exim_id\
${if def:received_for {\n\tfor $received_for}}
Note that it does miss some information, notably if there is a non-Fc RDNS entry it will not appear,
and the "envelope-from <>" line is removed entirely. Further, RFC 1413 support is removed, but
presumably that's not really relevant for anyone.
Matt
On 11/18/21 14:10, Bill Cole via Exim-users wrote:
> Subject:
> Re: [exim] Exim always expands sender_rcvhost to unverified IP
> From:
> Bill Cole via Exim-users <exim-users@exim.org>
> Date:
> 11/18/21, 14:10
>
> To:
> Matt Corallo via Exim-users <exim-users@exim.org>
>
>
> 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/
--
## 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/
In the previous thread it was discovered that SpamAssassin (as of 3.4.6) does not support parsing
the Received: header that exim (as of 4.94.2) generates, causing messages to be mis-scored (usually
penalized, sometimes heavily, as SpamAssassin incorrectly believes the sending host does not have an
FcRDNS entry). This may be fixed in a future version of SpamAssassin, but for now, I'm using the
following Received line which appears to work correctly (mimicking Received lines from other mailers):
received_header_text = Received: \
${if def:sender_helo_name {from $sender_helo_name }}\
${if def:sender_fullhost {(${sg{$sender_fullhost}{.*\\) }{unknown }}) \n\t}}\
by $primary_hostname \
${if def:received_protocol {with $received_protocol }}\
${if def:tls_in_ver {$tls_in_ver }}\
id $message_exim_id\
${if def:received_for {\n\tfor $received_for}}
Note that it does miss some information, notably if there is a non-Fc RDNS entry it will not appear,
and the "envelope-from <>" line is removed entirely. Further, RFC 1413 support is removed, but
presumably that's not really relevant for anyone.
Matt
On 11/18/21 14:10, Bill Cole via Exim-users wrote:
> Subject:
> Re: [exim] Exim always expands sender_rcvhost to unverified IP
> From:
> Bill Cole via Exim-users <exim-users@exim.org>
> Date:
> 11/18/21, 14:10
>
> To:
> Matt Corallo via Exim-users <exim-users@exim.org>
>
>
> 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/
--
## 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/