https://bugs.exim.org/show_bug.cgi?id=2596
--- Comment #3 from Jeremy Harris <jgh146exb@???> ---
(In reply to Sergey from comment #2)
> (In reply to Jeremy Harris from comment #1)
> > Could you clarify what you mean by "authorization", and show what is broken?
>
> I mean the following case.
> Exim server configured as a smart host to send letters via external smtp.
> If several emails from different users of the same external smtp get to this
> server at the same time, then the first email opens a smtp session, and the
> next ones try to go to an already open session.
> This works well if emails are sent without authorization, or with
> authorization under the same smtp user.
> But if the users of the smtp are different, the emails get into the already
> open smtp session under the wrong login.
> In the log, it looks like this:
>
> 17:47:13 1jiJ3O-0004Q3-Oy => F=<first@???> H=smtp.example.com A=login
> C="250 2.0.0 OK 10sm7101118qkv.136"
> 17:47:14 1jiJ1k-0003ZP-Jj => F=<second@???> H=smtp.example.com C="250
> 2.0.0 OK 1591627634 10sm7101118qkv.136"
>
> The first email went authorized (A = login), the next one was simply
> transferred to the smtp server without authorization.
Well, the connection used authentication, in SMTP term.
If you're using authentication to infer authorization, despite
them being slight different concepts, you are free to change the
hosts_noproxy_tls so as to force (under current exim architecture)
a new TLS connection per message. That's why there is an option.
The same goes for if you're really only using authentication, but do want
it to be tied to the message (rather than the client system).
I'm not convinced there's a bug here, even if the change does affect your use
case.
--
You are receiving this mail because:
You are on the CC list for the bug.
