Re: [exim] Encripted SMTP connection on port 25 or 465

Quoting Luciano Rinetti (l.rine...@movimatica.com): > In the main log file it is possible to recognize an encripted SMTP > connection on port 25 by means of the X= record. > How can i recognize an encripted SMTP connection on port 465 with SMTP over > SSL ? Your most recent questions to this

Re: [exim] SPF issue: acting like -all when ~all

Quoting Jonathan Gilpin via Exim-users (exim-users@exim.org): > 2017-12-14 13:09:26 H=smtp1.galacsys.net [217.24.81.209] > X=TLSv1:DHE-RSA-CAMELLIA256-SHA:256 CV=no > F= rejected RCPT : SPF > check failed Even though this was already tracked back to

[exim] Format error in spool file! Probably local_scan sa_exim.so?

Hi list! Today, vger.kernel.org delivered another one of it's bursts of messages to my mailserver, and one of those got stuck logging 'Format error in spool file'. Saucy! I captured the -D and -H files, the log doesn't show anything special other than that message being delivered and the spool

Re: [exim] av_scanner and panic log...

Quoting Jeremy Harris via Exim-users (exim-users@exim.org): > > But every time clamd have trouble, exim log in panic_log, and so debian > > compain about it. > get put, so that you can notice. Debian is complaining because > clamd is complaining. I wholeheartedly agree with Jeremy here, but if

[exim] Evaluation logic in 'warn' statements?

Hi list, Given this statement in acl_check_rcpt: warn add_header = X-SomeHeader: somevalue recipients = somere...@somedomain.example.tld control = dkim_disable_verify I find that the header is added to -all- messages while i'd expect the 'recipients'-condition to

Re: [exim] Evaluation logic in 'warn' statements?

Quoting Jeremy Harris via Exim-users (exim-users@exim.org): > > I find that the header is added to -all- messages while i'd expect > > the 'recipients'-condition to prevent that. When the add_header and > > recipients line are swapped it does works as i'd expect. > > Is that behaviour ...

[exim] 421 lost input connection, not logged?

Hi, Spent a few minutes today figuring out what happens to a certain client trying to send mail to our Exim 4.93 #3 MTA since no traces of their IP could be found in our logs. But tcpdumping shows the session being terminated after STARTTLS, with Exim sending '421 lost input connection' over the

Re: [exim] 421 lost input connection, not logged?

Quoting Graeme Fowler via Exim-users (exim-users@exim.org): > ...but if the client never managed to actually connect to Exim, there is > nothing to log. But the client was connected! It issued EHLO, STARTTLS and -then- boogered off. > You can already add the log selector "smtp_connection" to

Re: [exim] tainted data issues

Quoting Jeremy Harris via Exim-users (exim-users@exim.org): > It is far to easy for someone to write a matcher which just > untaints everything, disabling the security. Three people > would do that, and one would post it on serverfault. Then > it would be cargo-culted forever. You mean like

Re: [exim] tainted data issues

Quoting Heiko Schlittermann via Exim-users (exim-users@exim.org): > In case you didn't notice. We've added a new but already deprecated main > config option: > allow_insecure_tainted_data = yes Yes, thanks for your hard work, Heiko!! I saw that option being discussed / added. It sure

Re: [exim] Ubuntu 20.04 and CONFDIR

Quoting Elliot Finley via Exim-users (exim-users@exim.org): > Anyone know why CONFDIR wouldn't be honored? I'd advise reading /usr/share/doc/exim4-config/README.Debian.gz and other /usr/share/doc/exim4*/* documentation files on your system with regards to the 'split configuration' setup that

[exim] Stumped on router conditions

Hi there, I have been trying to have one router act when a condition is true, and the other act when that same condition is not true. The conditions are LDAP lookups. I'm omitting the specific lookup for privacy reasons. ;) | > ${lookup ldap{...}{true}{false}} | true The lookup is defined as a

Re: [exim] Stumped on router conditions

Quoting Slavko via Exim-users (exim-users@exim.org): > > So, "! true" must mean "false", right? > No, "! true" is just string, not Boolean negation. Well, yes, if you take that literally. As aparently 'condition' checks in routers do. ;) With my programmer mindset it should "expand" to False

[exim] Exim auth driver dovecot 'LOGIN' fails?

Hello list, Is Exim's dovecot driver for LOGIN auth broken or am i doing something wrong? The PLAIN auth variant is working fine. Attached is the relevant debug logging from both Dovecot auth as well as Exim. This is Exim 4.95-4ubuntu2.2 & Dovecot 1:2.3.16+dfsg1-3ubuntu2.1 from Ubuntu 22.04