On Sun, 16 Apr 2023, 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.
>
> 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:
I think ARC (RFC8617) is supposed to help here.
If your backend trusts the frontend machine (an explicit choice you make),
SPF/DKIM/DMARC passed on the frontend
and the ARC headers in mail received from the frontend are correctly signed,
then the backend will accept the message "because ARC".
> OR:
> you could just run SA on the frontend
Probably the simplest option.
--
Andrew C. Aitchison Kendal, UK
andrew@???
