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
--
## 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/
