On Mon, 16 Dec 2024, Kirill Miazine via Exim-dev wrote:
• Andrew C Aitchison via Exim-dev [2024-12-15 23:19]:
On Sun, 15 Dec 2024, Exim Bugzilla via Exim-dev wrote:
https://bugs.exim.org/show_bug.cgi?id=3071
--- Comment #3 from [email protected] ---
(In reply to Jeremy Harris from comment #2)
The cutthrough facility uses the verify callout machinery (recipient, with
the use_sender option) to place the ongoing connection.
Changing the envelope sender would be a breaking change. I think supporting
this will need an option on the ACL control=cutthrough_delivery -
perhaps "/sender=transport", with "original" signifying the existing
behaviour of using the received envelope-from?
Docs don't mention anything about the sender address, do they? There are some
limitation mentioned, but non of them apply to the sender address.
I'd assume that people using cutthrough_delivery with SRS would expect SRS to
be applied with cutthrough_delivery, and myself I'd certainly appreciate a way
to set envelope sender upon cutthrough_delivery.
I would not expect to use SPF or SRS with cutthrough-delivery,
just as i would not expect a secondary MX to do SPF.
But if you _did_ use SRS, would you expect cutthrough to use the
rewritten envelope sender?
I guess it depends on the use case.
SRS is mostly relevant for doing forwarding so some external sites, such
as to gmail in my case, and gmail in particular requires valid SPF or
DKIM for all senders (for bulk senders, I think, they require SPF, DKIM
and DMARC).
Hmm. IIUC cutthrough is intended for use between organisationally
closely connected machines, such as from secondary to primary MX
or firewall host to mail server.
If your email domain is not hosted by gmail I don't see why you would
want a cutthrough connection to them.
The idea of having a close organisational email connection with gmail
is stretching my imagination ... I would not have thought of
having a cutthrough connection to gmail.
-----
(I'm also somewhat allergic to SRS, since I cannot prove to myself that it
doesn't produce a, restricted, open relay. I failed to read
https://srs-discuss.v2.listbox.narkive.com/H5TyyIKg/the-open-relay-problem-is-not-a-problem
when it first appeared :-(
)
--
Andrew C. Aitchison Kendal, UK
[email protected]
--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-dev.lists.exim.org/
## unsubscribe (doesn't require an account):
## [email protected]
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
