Mailing List Archive

[Bug 2702] New: XCLIENT ESMTP extension
https://bugs.exim.org/show_bug.cgi?id=2702

Bug ID: 2702
Summary: XCLIENT ESMTP extension
Product: Exim
Version: 4.94
Hardware: x86
OS: Linux
Status: NEW
Severity: wishlist
Priority: low
Component: Mail Receipt
Assignee: unallocated@exim.org
Reporter: jgh146exb@wizmail.org
CC: exim-dev@exim.org

A fork of the Exim project is carrying (among others) a patch adding XCLIENT
support, per http://www.postfix.org/XCLIENT_README.html . We might consider
doing
the same. This is an inbound proxy method, like Proxy Protocol but triggered
by
an SMTP command.

The patch

https://github.com/SpamExperts/exim/commit/3798d48d73c89f7835726d31f096851f7f7fca2a
isn't immediately usable:

- Proper handling of the proxy address/port details, for logging
- We should consider re-calling the connect ACL, after deciding to accept the
XCLIENT command, to give the chance to re-evaluate connect-time decisions
with the proxy-supplied info for the connection
- Ditto re-call the helo ACL, with the HELO attribute value
- We could consider a dedicated ACL for the command, separate from the
allowed-hosts list (still needed for advertise)
- It should be a compile-time option, initially Experimental
- duplicated code: xclient_xtextdecode() vs. auth_xtextdecode()
- (nit) coding style

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [Bug 2702] New: XCLIENT ESMTP extension [ In reply to ]
> On Feb 22, 2021, at 12:23 PM, admin--- via Exim-dev <exim-dev@exim.org> wrote:
>
> - Proper handling of the proxy address/port details, for logging
> - We should consider re-calling the connect ACL, after deciding to accept the
> XCLIENT command, to give the chance to re-evaluate connect-time decisions
> with the proxy-supplied info for the connection

I'd put it more strongly than *consider*, the purpose of XCLIENT is *specifically*
to reevaluate ACLs, so that the proxy acts on behalf of its upstream client. If
one merely wants an audit trail, that'd be the XFORWARD extension instead.

> - Ditto re-call the helo ACL, with the HELO attribute value
> - We could consider a dedicated ACL for the command, separate from the
> allowed-hosts list (still needed for advertise)

Yes, highly recommended. Giving all hosts allowed to relay the right to
impersonate other hosts is surely too liberal. Also make sure that the
the right to send XCLIENT again is not retained once the initial XCLIENT
command happens (or is at least reevaluated per the upstream IP address,
which would generally not have that right).

--
Viktor.


--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [Bug 2702] New: XCLIENT ESMTP extension [ In reply to ]
On 22/02/2021 14:23, admin--- via Exim-dev wrote:
> https://bugs.exim.org/show_bug.cgi?id=2702
>
> Bug ID: 2702
> Summary: XCLIENT ESMTP extension
> Product: Exim
> Version: 4.94
> Hardware: x86
> OS: Linux
> Status: NEW
> Severity: wishlist
> Priority: low
> Component: Mail Receipt
> Assignee: unallocated@exim.org
> Reporter: jgh146exb@wizmail.org
> CC: exim-dev@exim.org
>
> A fork of the Exim project is carrying (among others) a patch adding XCLIENT
> support, per http://www.postfix.org/XCLIENT_README.html . We might consider
> doing
> the same. This is an inbound proxy method, like Proxy Protocol but triggered
> by
> an SMTP command.
>
> The patch
>
> https://github.com/SpamExperts/exim/commit/3798d48d73c89f7835726d31f096851f7f7fca2a
> isn't immediately usable:
>
> - Proper handling of the proxy address/port details, for logging
> - We should consider re-calling the connect ACL, after deciding to accept the
> XCLIENT command, to give the chance to re-evaluate connect-time decisions
> with the proxy-supplied info for the connection
> - Ditto re-call the helo ACL, with the HELO attribute value
> - We could consider a dedicated ACL for the command, separate from the
> allowed-hosts list (still needed for advertise)
> - It should be a compile-time option, initially Experimental
> - duplicated code: xclient_xtextdecode() vs. auth_xtextdecode()
> - (nit) coding style
>

(Resending from the correct email for this ML)

Is it anyhow different from a patch I have proposed some (long) time
ago?
https://mta.org.ua/exim-4.76-conf/packages/ports-freebsd/exim-4.83_2/core/files/extra-patch-xclient

I have stopped to support it because the Exim developers were too
reluctant to include that into the main distribution, so I have also
removed it from the FreeBSD port. The code looks quite familiar from
what I see...

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [Bug 2702] New: XCLIENT ESMTP extension [ In reply to ]
On 22/02/2021 22:53, Vsevolod Stakhov via Exim-dev wrote:
> I have stopped to support it because the Exim developers were too
> reluctant to include that into the main distribution, so I have also
> removed it from the FreeBSD port. The code looks quite familiar from
> what I see...

Looks similar to me, too. But, as I say in this bug, I
think it's not quite complete.
--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [Bug 2702] New: XCLIENT ESMTP extension [ In reply to ]
On 22/02/2021 22:53, Vsevolod Stakhov via Exim-dev wrote:
> I have stopped to support it because the Exim developers were too
> reluctant to include that into the main distribution, so I have also
> removed it from the FreeBSD port. The code looks quite familiar from
> what I see...

I should have said - if you feel like filling it out along the lines
I think are needed, I'll happily work with you to get it integrated.
--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##