On 16/04/2023 11:44, Jeremy Harris via Exim-users wrote:
> On 15/04/2023 23:31, Sebastian Arcus via Exim-users wrote:
>>> you might be able to use cutthrough delivery from the front-end to the
>>> real server, which might allow you to reject rather than bounce some
>>> of the time; it might even help with your SPF dilemma ?
>>
>> That was my intention - so that the back-end machines can verify if
>> the recipient exists. Are you saying that when using cutthrough
>> delivery, this doesn't add an extra header to the email message - so
>> this way it wouldn't mess up the SPF checks on the back-end machine
>
> No. A Received: header is always added, cutthrough or store-and-forward.
>
>> (I was assuming that the front-end machine would add another header to
>> the incoming email, which would make it appear to be one of the
>> sending servers - which I then assumed would fail the SPF checks on
>> the back-end machines)
>
> (The original) SA presumably relies on Received: headers to get the
> sending IP; there's
> no setting in the API being used to call it.
One thing I have to try and figure out is how Spamassassin does the SPF
checks. Does it look at all the Received: headers, and if at least one
of them matches one of the SPF records, then it's all fine? Because if
that's how it works, SA checks should pass even if done on the back-end
Exim server.
>
> The RSPAMD variant call does, however - so if there were enough call for it
> a feature could be added to Exim to set that from the config; that in turn
> could use on the backend Exim info added to the message by private
> agreement with the
> frontend (eg. an A-R header).
>
> OR:
> you could use the SA feadture "ignore_received_spf_header", do the SPF
> checks on the
> frontend, and add that header to transfer the info
>
> you could use the rspamd feature
> https://www.rspamd.com/doc/modules/external_relay.html
>
> OR:
> you could just run SA on the frontend
>
