On 2023-10-31 Tomas Pospisek <tpo_...@sourcepole.ch> wrote: > On Tue, 31 Oct 2023, Salvatore Bonaccorso wrote: [...] >> Fixes for CVE-2023-42117 and CVE-2023-42119 are right now considered >> no-dsa (see comment on the security-tracker about it), and are going >> to be fixed in the next point releases.
> The notes say: > *** > [bookworm] - exim4 <no-dsa> (Only an issue if Exim4 run behind an > untrusted proxy-protocol proxy) [...] > So I think I can parse from those that CVE-2023-42117 is only critical when > exim is run behind a "untrusted proxy-protocol proxy". > Questions if you will: > * what does "no-dsa" mean? DSA seems to mean Debian Security Announce. > Does it mean there is no DSA for that problem yet? What does it mean > when a CVE is considered "no-dsa" then? That no DSA will be released for > it? Hello Thomas, Exactly. The severity was judged to be very low, not "worth" the effort of a DSA. > * what is a "untrusted proxy-protocol proxy" in the context of a mail > transport agent? So exim shouldn't be used behind an untrusted socks > proxy? Well I have no real control who connects how to a public MTA... > anybody can connect to it to try his luck sending me email. That > includes untrusted socks proxies... This https://www.exim.org/exim-html-current/doc/html/spec_html/ch-proxies.html or more precisely part "1. Inbound proxies". You need to explicitely configure exim to tell it that specific hosts are acting as load-balancing proxy sitting in front of exim. I cannot think of a szenario where these load-balancing proxies would not be trusted machines. The issue is about weakening the chain a little bit - take over the proxy first and then do something to the exim machines behind. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'