Re: [exim-dev] user file write permissions

[Andrew C Aitchison via Exim-dev]

On Mon, 24 Apr 2023, exim--- via Exim-dev wrote:


Hi

I am curious as to how exim writes to a users home directory. I have done a 
lot of searching and could not find anything specific.


as exim runs as an unprivileged user as far as I can tell it has no rights to 
modify a users home folder, yet it does.


What part of the puzzle am I missing?


When exim writes to a user's home directory
it first re-exec's itself to regain root privilege.

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk

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

Re: [exim-dev] Help debugging a tls smtp session

[Andrew C Aitchison via Exim-dev]

Thanks, Jeremy and Victor.

As is often the way, once I sent my plea,
the next search of the code found my problem.

I was setting the status value (done) to something other than "continue".
In fact I should not have touched it at all.

On Wed, 29 Mar 2023, Jeremy Harris via Exim-dev wrote:


On 28/03/2023 13:48, Andrew C Aitchison via Exim-dev wrote:


I'm attempting to write CLIENTID support for Exim.

My current attempt is available at
   https://www.aitchison.me.uk/exim/clientid.20230325.patch

I am using the exim test suite. Below is the significant part of
    runtest --keep 3752

When I do STARTTLS -> CLIENTID -> NOOP
the CLIENTID gives the correct response code but the next command
fails (it doesn't have to be a NOOP) in a way suggesting that I have
lost synchronization. Sometimes the TLS connection reports unexpected
commands in the input buffer (which I confirm to match what I expect
the script to send next).


Next step: add "-d+all" to the exim daemon line in the test script, and 
inspect the resulting "test-sterr-server" file.


--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] Help debugging a tls smtp session

[Andrew C Aitchison via Exim-dev]

I'm attempting to write CLIENTID support for Exim.

My current attempt is available at
  https://www.aitchison.me.uk/exim/clientid.20230325.patch

I am using the exim test suite. Below is the significant part of
   runtest --keep 3752

When I do STARTTLS -> CLIENTID -> NOOP
the CLIENTID gives the correct response code but the next command
fails (it doesn't have to be a NOOP) in a way suggesting that I have
lost synchronization. Sometimes the TLS connection reports unexpected
commands in the input buffer (which I confirm to match what I expect
the script to send next).

I do have PIPECONNECT enabled, so I may well be tangled up in that somehow.

Any suggestions on how to proceed ?

Connecting to 127.0.0.1 port 1225 ... connected
Certificate file = 
/home/eximtest/git/Exim/exim/test/aux-fixed/exim-ca/example.org/server2.example.org/server2.examp

le.org.pem
Key file = 
/home/eximtest/git/Exim/exim/test/aux-fixed/exim-ca/example.org/server2.example.org/server2.example.org.u

nlocked.key
??? 220
<<< 220 myhost.test.ex ESMTP Exim x.yz Sat, 25 Mar 2023 17:48:12 +

EHLO tester2a

??? 250-
<<< 250-myhost.test.ex Hello tester2a [127.0.0.1]
??? 250-
<<< 250-SIZE 52428800
??? 250-
<<< 250-8BITMIME
??? 250-STARTTLS
<<< 250-STARTTLS
??? 250 HELP
<<< 250 HELP

STARTTLS

??? 220
<<< 220 TLS go ahead
Attempting to start TLS
Succeeded in starting TLS

EHLO tester2b

??? 250-
<<< 250-myhost.test.ex Hello tester2b [127.0.0.1]
??? 250-
<<< 250-SIZE 52428800
??? 250-
<<< 250-8BITMIME
??? 250-AUTH
<<< 250-AUTH EXTERNAL
??? 250-CLIENTID
<<< 250-CLIENTID
??? 250 HELP
<<< 250 HELP

CLIENTID exim-device client-id-token

??? 250 OK
<<< 250 OK

NOOP

??? 250 OK
Error in the pull function.
Unexpected EOF read

Thanks,

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk

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

[exim-dev] Are bug system emails to exim-dev moderated or slow ?

[Andrew C Aitchison via Exim-dev]

I have noticed that emails from the exim bug system to the exim-dev list
can take well over a day to arrive:

Received: from localhost ([127.0.0.1]:59430 helo=hummus.exim.org)
by hummus.exim.org with esmtp (Exim 4.94.2-31-g503e55a2c)
(envelope-from )
id 1pbzJc-00074E-5o
for e...@aitchison.me.uk; Tue, 14 Mar 2023 07:43:24 +
Authentication-Results: exim.org;
 iprev=pass (hh.schlittermann.de) smtp.remote-ip=213.128.132.49;
 spf=none smtp.mailfrom=bugs.exim.org;
 dkim=pass header.d=bugs.exim.org header.s=d202011 header.a=rsa-sha256;
 dmarc=none header.from=bugs.exim.org; arc=none
Received: from hh.schlittermann.de ([213.128.132.49]:60018)
 by hummus.exim.org with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
 (Exim 4.94.2-31-g503e55a2c) (envelope-from )
 id 1pbPp9-0004TR-6F
 for exim-dev@exim.org; Sun, 12 Mar 2023 17:49:36 +

Are these messages moderated, or is the delay purely something in hummus ?

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk

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

Re: [exim-dev] [Bug 2982] New: Writing logs to standard output

[Andrew C Aitchison via Exim-dev]

On Fri, 10 Mar 2023, admin--- via Exim-dev wrote:


https://bugs.exim.org/show_bug.cgi?id=2982

   Bug ID: 2982
  Summary: Writing logs to standard output
  Product: Exim
  Version: 4.96
 Hardware: x86
   OS: Linux
   Status: NEW
 Severity: wishlist
 Priority: medium
Component: Logging
 Assignee: unalloca...@exim.org
 Reporter: ivano...@riseup.net
   CC: exim-dev@exim.org

Exim cannot write logs to standard output. This creates some problems when Exim
is running as a container process.

I can read container logs when I run the daemon with `-bdf` option, but this
only works with pseudo-TTY allocated to the container. Unfortunately, I can't
collect logs from such containers.

I have searched the web for a solution, but everything that I found is ugly.
First, I can create symlinks to /dev/stdout and /dev/stderr instead of log
files. Another option is to run multiple processes in a container (xtail or a
syslog daemon). That is a wrong way, but even if I do, I need to write simple
process manager and in the case of the syslog daemon, I have to run it as root,
because it has to create /dev/log socket.


It would be great that Exim could write logs to standard output and we could
use someting like log_file_path = stdout in the config to enable this.


Does
log_file_path = /proc/self/fd/1
help ?

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk

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

[exim-dev] Real data wanted for testing

[Andrew C Aitchison via Exim-dev]

I'm looking for exim logfiles and message headers to test
that the new exim_msgdate utility reports the correct time
for all message ids.

I am particularly looking for logfiles and mail folders
a) from systems that use the localhost_number feature
and b)from non-UK time zones.

I only really need the date/time and the message id,
so obfuscated is fine, eg

egrep -h "Completed|<=|=>|^(Date|Message-Id):" logfiles mailfolders |\
sed -e 's/@.*>/@>/'

Thanks,

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk

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

[exim-dev] MAX_LOCALHOST_NUMBER and LOCALHOST_MAX

[Andrew C Aitchison via Exim-dev]

I have been reading about exim message ids (for enhancement
https://bugs.exim.org/show_bug.cgi?id=2956
).

I see that the code has both

src/config.h.defaults:#define MAX_LOCALHOST_NUMBER256

and

src/exim.h-#if BASE_62 == 62
src/exim.h:# define LOCALHOST_MAX  16
src/exim.h-#else
src/exim.h:# define LOCALHOST_MAX  10
src/exim.h-#endif

Am I right in thinking that these are both for the config option
"localhost_number" ?
If so, is the max 256 or 16/10 ?

(16/10 means 16 on caseful filesystems, 10 on case-ignoring filesystems.)

Thanks,

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk

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

Re: [exim-dev] [exim-announce] Exim 4.96-RC0 released

[Andrew C Aitchison via Exim-dev]

On Mon, 25 Apr 2022, Kirill Miazine via Exim-dev wrote:


Beware that the just released RC0 for Exim 4.96 may break your Dovecot
LDA delivery. It did break mine, which is similar to what is described
on https://wiki.dovecot.org/LDA/Exim

Here is the relevant ChangeLog entry:

JH/25 Taint-check exec arguments for transport-initiated external processes.
 Previously, tainted values could be used.  This affects "pipe", "lmtp" and
 "queryprogram" transport, transport-filter, and ETRN commands.
 The ${run} expansion is also affected: in "preexpand" mode no part of
 the command line may be tainted, in default mode the executable name
 may not be tainted.



• Jeremy Harris via Exim-announce [2022-04-23 20:23]:

Notable removals since 4.95:

  - the "allow_insecure_tainted_data" main config option and the
"taint" log_selector.  These were previously deprecated.


That isn't a good combination. Please could we keep the option to
allow_insecure_tainted_data if there are new taint features ?

That way we can continue to run live systems while we resolve
these sort of problems.

Thanks,

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] Exim security mailing list

[Andrew C Aitchison via Exim-dev]

I was surprised to discover that secur...@exim.org
is a *moderated* list.

Whilst the traffic is low, so the signal-noise ratio may be poor,
I would guess that most list members are also moderators, so the
benefit of moderation is low. Also security issues can be urgent
so the moderation delay may matter more than usual.

Of course I am not on the security list, so I don't get a vote.

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk

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

Re: [exim-dev] CVE-2021-38371 (allows response injection during MTA SMTP sending)

[Andrew C Aitchison via Exim-dev]

On Tue, 4 Jan 2022, Harry Mills via Exim-dev wrote:


Hi Jeremy,

Thanks for the swift reply. Here is the (anonymised) output of the test tool 
for reference. It looks like exim 4.94.2 (Centos 8) is not vulnerable:


python3 ./command-injection-tester --smtp 


As I understand https://nostarttls.secvuln.info/
command-injection-tester only tests for bugs when exim is receiving email;
to test for the *response* injection bugs in CVE-2021-38371, when exim is 
sending email, you need to use

   https://github.com/Email-Analysis-Toolkit/fake-mail-server
which looks more involved to me.

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk

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

Re: [exim-dev] CVE-2021-38371 (allows response injection during MTA SMTP sending)

[Andrew C Aitchison via Exim-dev]

I guess we should also try to turn the appropriate fake-mail-server
scripts into exim test scripts.

I'd like to see which test shows the vulnerability and your results.

Jeremy, Heiko, is it OK to be discussing this here ?

On Wed, 5 Jan 2022, Harry Mills via Exim-dev wrote:


Hi Andrew,

You are correct. I have setup a test network with the fake-mail-server 
running in a VM and I am liaising with the SecVuln guys at the moment to see 
if I can reproduce the test they say shows the vulnerability when Exim is 
sending email.


Best wishes,

Harry

On 04/01/2022 19:33, Andrew C Aitchison wrote:

On Tue, 4 Jan 2022, Harry Mills via Exim-dev wrote:


Hi Jeremy,

Thanks for the swift reply. Here is the (anonymised) output of the test 
tool for reference. It looks like exim 4.94.2 (Centos 8) is not 
vulnerable:


python3 ./command-injection-tester --smtp 


As I understand https://nostarttls.secvuln.info/
command-injection-tester only tests for bugs when exim is receiving email;
to test for the *response* injection bugs in CVE-2021-38371, when exim is 
sending email, you need to use

   https://github.com/Email-Analysis-Toolkit/fake-mail-server
which looks more involved to me.


--
Harry Mills Tel: 01749 812100
Managing Director   Mob: 07815 848818
Opendium Ltd.   www.opendium.com


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




--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] Restricted bugs and dev mailing list - was Re: [Bug 1895]

[Andrew C Aitchison via Exim-dev]

On Fri, 31 Dec 2021, admin--- via Exim-dev wrote:


https://bugs.exim.org/show_bug.cgi?id=1895

--- Comment #13 from Jeremy Harris  ---

... content removed as a security precaution ...

This morning I have received two comments on exim bug 1895 via the
exim-dev mailing list, but when I try to view the bug at the above 
link I get the failure message

 You are not authorized to access bug #1895.

Should bugs.exim send comments on restricted bugs to the dev list ?

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk

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

[exim-dev] PCRE(2) and 4.95.1 - was Re: buildfarm animals

[Andrew C Aitchison via Exim-dev]

On Sun, 3 Oct 2021, Andreas Metzler via Exim-dev wrote:


On 2021-10-02 Jeremy Harris via Exim-dev  wrote:

On 02/10/2021 20:00, Andrew C Aitchison wrote:

Will 4.95.1 (if such happens) use pcre or pcre2 ?



Pcre2. Pcre is dead, as I said.


Hello,

4.95.1 would presumably be a security release. I do not think making
the pcre change (33 files changed, 498 insertions(+), 384 deletions(-))
part of a security release would be good practise.


The library change would be bad form too.

Can we have a 4.95.1 with pcre2 "now", then the security fix wont include 
this change ?


--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk

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

Re: [exim-dev] buildfarm animals

[Andrew C Aitchison via Exim-dev]

On Sat, 2 Oct 2021, Jeremy Harris via Exim-dev wrote:


On 12/09/2021 16:33, Jeremy Harris via Exim-dev wrote:
The 4.next branch is now expecting the pcre2 library, replacing the 
original

pcre library; the latter having gone end-of-life.

Buildfarm animal maintainers, please check that the required packages
are installed to support this.  The buildfarm status page entry for
your animal will go red if not.

https://buildfarm.exim.org/cgi-bin/show_status.pl


Now the 4.95 has been released, HEAD has merged in the
4.next branch and so now needs pcre2.  No branches
using pcre are now active for the buildfarm.


Will 4.95.1 (if such happens) use pcre or pcre2 ?

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] servers expansion

[Andrew C Aitchison via Exim-dev]

On Sat, 12 Jun 2021, Jasen Betts via Exim-dev wrote:



I'm wanting to be able to use expansion variables in the servers=
parameter of query-style lookups.

I can use variables if I put servers= inside the query, but if
servers= is used there I can't use tainted variables in the query.

I crawled around looking at the source code trying to
backtrace to the caller code and finally came up with this patch:

--- a/build/exim/src/lookups/lf_sqlperform.c
+++ b/build/exim/src/lookups/lf_sqlperform.c
@@ -129,7 +129,7 @@ else
uschar * ele;
for (int sep = ','; ele = string_nextinlist(, , NULL, 0); )
  if (Ustrncmp(ele, "servers=", 8) == 0)
-   { serverlist = ele + 8; break; }
+   { serverlist = expand_string( ele + 8 ); break; }
}

  if (!serverlist)
---

This seems to work for simple variables which is enough for me.  Full
brace expansion does not work (I think the parser gets confused).

As I understand it this is not going to cause a memory leak.

a few lines down from this serverlist is checked to be taint-free so
this feels safe to me.


Isn't the idea to check a string is taint-free *before* expanding it ?

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk

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

Re: [exim-dev] [Bug 2737] New: $mime_filename considered as Tainted

[Andrew C Aitchison via Exim-dev]

On Thu, 6 May 2021, admin--- via Exim-dev wrote:


As per the documentation
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-content_scanning_at_acl_time.html#SECTscanmimepart
the option 'decode = $mime_filename' can be used however within the MIME ACL.
This now fails due to the filename being tainted.

... ...


Using 'decode = default' solves the issue and the documentation also does
mention "However, you should keep in mind that $mime_filename might contain
anything.". So not sure how this should be dealt with. I can only see 2
options:

1. Remove the ability to use decode = $mime_filename or
2. Remove the taint check on $mime_filename and warn the OP that this is
dangerous  (this is probably not a good idea)


Is there an alternative approach?


Yes. Detaint in the usual way, probably with a lookup.

If you are decoding the mime file with its real name you must
have a reason, perhaps to make them available on a web page.
It would then be reasonable to check that the filename was
sensible in that context.
I wouldn't see a database looking as the mot obvious way to sanitize
the filename, but we do already have the tools to turn a pattern
matching into a lookup, so the flexibility is there.

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk

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

Re: [exim-dev] [Bug 2724] Email Address Internationalization Support Bug Report

[Andrew C Aitchison via Exim-dev]

On Mon, 3 May 2021, admin--- via Exim-dev wrote:


https://bugs.exim.org/show_bug.cgi?id=2724

Graeme Fowler  changed:

  What|Removed |Added

CC||gra...@graemef.net

--- Comment #2 from Graeme Fowler  ---

From the PDF:


"Exim is a widely used open source mail server that provides an MSA and MTA. We
installed it on a test host and configured it with several EAI addresses in IDN
domains. Exim provides both Phase 1 and Phase 2 EAI support and passed most
tests.

Exim???s developers consider an EAI message to be one with UTF-8 envelope
addresses and an ASCII message to be one without UTF-8 envelope addresses, even
if the message???s headers include UTF-8. While we disagree with their
interpretation, we think it is unlikely to cause problems in practice since
messages with ASCII envelopes and UTF-8 headers are uncommon.

Exim does not provide a POP or IMAP server. It is typically used with the
Dovecot or Cyrus IMAP/POP servers neither of which currently has EAI support."


That text (or similar) appears in both attachment 1379 "Exim.pdf" and the 
linked document "UASG030-en-digital.pdf". While UASG030-en-digital.pdf has 
little detail, the attachment does at least list the tests that failed:

   MSA Tests Failed
  1. EAI messages sent to non-SMTPUTF8 server are rejected or transformed
   MTA Tests Failed
  1.  Trace information includes domain in U-label form
  2.  Trace information indicates SMTPUTF8 protocol
  3.  EAI reverse path values are transmitted to SMTPUTF8 server
  4.  EAI messages sent to non-SMTPUTF8 server are rejected

These tests are described in UASG021B-en-digital-EAI-Pilot-Test-Cases.xlsx

I am not convinced that rejecting or transforming mail is better
than relaying it to a non-SMTPUTF8 server.


I see that John Levine contributed the EAI test software
https://github.com/jrlevine/eaitesttools
and mentioned exim in the equivalent fetchmail bug
https://gitlab.com/fetchmail/fetchmail/-/issues/14


I do tend toward's Jeremy's viewpoint however: if the bug report is not itself
clear, and requires extra legwork on behalf of the small maint and dev team,
this is not an optimal way to report a bug.

There is nothing technical in the PDF report to work with, simply the above
statement that interpretations differ.

If you'd like to offer more technical detail, please feel free otherwise this
is likely to be closed as INVALID.


--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk

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

Re: [exim-dev] [Bug 2671] Consider integration of localscan_dlopen patch

[Andrew C Aitchison via Exim-dev]

On Fri, 6 Nov 2020, admin--- via Exim-dev wrote:


https://bugs.exim.org/show_bug.cgi?id=2671

--- Comment #2 from Jeremy Harris  ---
I had some hope that dlmopen() might help with the lookup-modules conflict.
But I still can't see a way of getting the combination
- dl{,m}open()'d local_scan code can only see the defined local_scan API
 symbols of the main exim program, enforced by the linker
- dl{,m}open()'d lookup modules can see the larger range of (non-C-static)
 symbols, ditto

The discussions I find around these features seem to be only in terms of
protecting the DSO symbols from the calling program, so as to enforce the API
of the DSO.  Our problem is the opposite, and we have two classes of API -
with one being a subset of the other.


Could exim provide two libraries, one for each type of module and
have all interface between exim and the module code via the libraries ?

If the lookup library doesn't have an local_scan interface, then
someone writing a local_scan library would not need or want to link 
against the lookup library.


(Yes it is open source so they can do whatever they want,
but we have already established that they do not wish to 
relink exim to include their module.)




Twenty years ago the XFree86 project (and possibly the Xorg project today) 
had operating system independent hardware driver modules

(I built a driver on linux and someone else used it on an OS/2 machine).

To do that we wrapped *every* system and (IIRC) library call that the 
drivers were allowed to use.

However, IIRC, we did *not* use dlopen.

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk

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

[exim-dev] Static Analysis - was Re: [Bug 2648] Use of $authres

[Andrew C Aitchison via Exim-dev]

On Wed, 28 Oct 2020, admin--- via Exim-dev wrote:


https://bugs.exim.org/show_bug.cgi?id=2648

--- Comment #6 from Jeremy Harris  ---
This is the sort of thing that static analysis ought to find; we probably have
an uninitialized variable.  Unfortunately my ability to build for Coverity has
died.  The only other decent way requires getting a coredump.  Any hope of
that?


I don't know who instigated it, or how recently it ran, but
https://lgtm.com/projects/g/Exim/exim/
is an online static analysis of exim.

I am willing to go through the alerts in a general way if it
will be useful, though I'm not sure how to give useful feedback.

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk

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

Re: [exim-dev] [Bug 2601] Taint for $sender_address_domain?

[Andrew C Aitchison via Exim-dev]

On Wed, 17 Jun 2020, admin--- via Exim-dev wrote:


https://bugs.exim.org/show_bug.cgi?id=2601

--- Comment #2 from marty...@mc2.dev ---
Yes, but why do we trust message body then? Like:
if $message_body matches ""
then
 seen finish
endif

The thing I don't get - why is $message_body safer than $sender_address_domain
?


As I understand it, the result of "matches" is untainted,
since the answer is effectively a boolean.

Your system filter line
if $sender_address_domain: is
is not a complete statement.
"is" comes between two arguments and its result is also untainted.

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk

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

Re: [exim-dev] [Bug 2594] New: CNAME handing can break TLS certificate verification

[Andrew C Aitchison via Exim-dev]

On Mon, 8 Jun 2020, admin--- via Exim-dev wrote:


https://bugs.exim.org/show_bug.cgi?id=2594

   Bug ID: 2594
  Summary: CNAME handing can break TLS certificate verification



Component: TLS
 Assignee: jgh146...@wizmail.org
 Reporter: ch...@paulson-ellis.org
   CC: exim-dev@exim.org

... ... ...

Here is the smtp transport debug output:

smarthost_smtp transport entered
 r...@juno.edesix.com
hostlist:
 'mail.edesix.local' IP 192.168.1.6 port -1
checking status of mail.edesix.local
locking /var/spool/exim/db/retry.lockfile
locked  /var/spool/exim/db/retry.lockfile
EXIM_DBOPEN: file  dir 
flags=O_RDONLY
returned from EXIM_DBOPEN: 0x5635b371d370
opened hints database /var/spool/exim/db/retry: flags=O_RDONLY
dbfn_read: key=T:mail.edesix.local:192.168.1.6
dbfn_read: key=T:mail.edesix.local:192.168.1.6:1jiFk5-0006UE-9S
EXIM_DBCLOSE(0x5635b371d370)
closed hints database and lockfile
no message retry record
mail.edesix.local [192.168.1.6] retry-status = usable
192.168.1.6 in serialize_hosts? no (option unset)
delivering 1jiFk5-0006UE-9S to mail.edesix.local [192.168.1.6]
(r...@juno.edesix.com)
set_process_info: 25033 delivering 1jiFk5-0006UE-9S to mail.edesix.local
[192.168.1.6] (r...@juno.edesix.com)
192.168.1.6 in hosts_require_dane? no (option unset)
Connecting to mail.edesix.local [192.168.1.6]:25 ... 192.168.1.6 in
hosts_try_fastopen? yes (matched "*")
TFO mode sendto, no data: EINPROGRESS
connected
read response data: size=72
 SMTP<< 220 aulus.edesix.com ESMTP Exim 4.80.1 Mon, 08 Jun 2020 13:31:02 +0100
192.168.1.6 in hosts_avoid_esmtp? no (option unset)
 SMTP>> EHLO juno.edesix.local
cmd buf flush 24 bytes
read response data: size=134
 SMTP<< 250-aulus.edesix.com Hello juno.edesix.local [192.168.1.10]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-STARTTLS
250 HELP
192.168.1.6 in hosts_avoid_tls? no (option unset)
 SMTP>> STARTTLS
cmd buf flush 10 bytes
read response data: size=18
 SMTP<< 220 TLS go ahead
192.168.1.6 in hosts_require_ocsp? no (option unset)
192.168.1.6 in hosts_request_ocsp? yes (matched "*")


Is 192.168.1.6 in hosts_require_ocsp? Is this a red herring ?

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk

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

Re: [exim-dev] callout message patches, bug #423

[Andrew C Aitchison via Exim-dev]

On Fri, 1 May 2020, Simon Arlott via Exim-dev wrote:


On 2020-04-30 14:31, Jeremy Harris via Exim-dev wrote:

As usual for our run-up to release, new features are still being
accepted at this early stage.


I'm still waiting for my patches for callout messages,
https://bugs.exim.org/show_bug.cgi?id=423 to be looked at.


Assuming that the "gateway" smtp server has raised access to the 
call-forward host, what sort of internal information could be leaked

or probed with this new feature ? Does this risk need to be documented ?

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk

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

Re: [exim-dev] Mailop list: exim and google fighting over DKIM

[Andrew C Aitchison via Exim-dev]

On Sun, 28 Apr 2019, Andrew C Aitchison via Exim-dev wrote:


Do the DKIM exim experts subscribe to the mailop list ?


In https://bugs.exim.org/show_bug.cgi?id=2394 Simon Arlott suggests that the answer is 
"no".

In that case (and especially since the links below are on a server which
has an out of date certificate), I need to answer his questions carefully;
I will do so, either here or in that bug, when I can do so without causing 
more heat.



There is an ongoing discussion on the mai...@mailop.org
about a snafu with DKIM which implicates exim and google.


The original report of the snafu (google rejections caused the list to 
auto-unsubscribe over a hundred subscribers of the list):

https://chilli.nosignal.org/cgi-bin/mailman/private/mailop/2019-April/013974.html

A description of the sending system that caused the issue:
https://chilli.nosignal.org/cgi-bin/mailman/private/mailop/2019-April/013991.html

A suggestion for the exim developers:
https://chilli.nosignal.org/cgi-bin/mailman/private/mailop/2019-April/013994.html



I believe that the list archive links above are member only,


--
Andrew C. Aitchison Cambridge, UK
and...@aitchison.me.uk

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

[exim-dev] Mailop list: exim and google fighting over DKIM

[Andrew C Aitchison via Exim-dev]

Do the DKIM exim experts subscribe to the mailop list ?

There is an ongoing discussion on the mai...@mailop.org
about a snafu with DKIM which implicates exim and google.

The original report of the snafu (google rejections caused the list to 
auto-unsubscribe over a hundred subscribers of the list):

https://chilli.nosignal.org/cgi-bin/mailman/private/mailop/2019-April/013974.html

A description of the sending system that caused the issue:
https://chilli.nosignal.org/cgi-bin/mailman/private/mailop/2019-April/013991.html

A suggestion for the exim developers:
https://chilli.nosignal.org/cgi-bin/mailman/private/mailop/2019-April/013994.html

Basically a user with a stock debian exim setup (version number yet given)
sent a message to the list with some signed non-existent headers; when the
list passed the message on it generated these headers and google 
failed on the signature discrepancy.


I believe that the list archive links above are member only,

--
Andrew C. Aitchison Cambridge, UK
and...@aitchison.me.uk


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

Re: [exim-dev] [Bug 1895] Default groups for DH possibly backdoored

[Andrew C Aitchison via Exim-dev]

On Tue, 19 Mar 2019, Viktor Dukhovni via Exim-dev wrote:


On Tue, Mar 19, 2019 at 02:43:04AM +, admin--- via Exim-dev wrote:


--- Comment #9 from Phil Pennock  ---
IMO yes we're ready to drop support for older OpenSSL.  We set a clear policy,
it's over a year (or two?) after that point, and other projects have adopted
similar policies.


https://lists.exim.org/lurker/message/20170102.153501.d4c71d99.en.html
(January 2017) says that we are dropping support for openssl v1.0.1
and below.

https://www.openssl.org/policies/releasestrat.html says:
  With regards to current and future releases the OpenSSL
  project has adopted the following policy:
The next version of OpenSSL will be 3.0.0.
Version 1.1.1 will be supported until 2023-09-11 (LTS).
Version 1.1.0 will be supported until 2019-09-11.
Version 1.0.2 will be supported until 2019-12-31 (LTS).
Version 1.0.1 is no longer supported.
Version 1.0.0 is no longer supported.
Version 0.9.8 is no longer supported.

Is it time to announce when exim will drop support for
openssl 1.0.2 and 1.1.0 ?


FWIW, Postfix 3.4, released a few weeks ago no longer supports OpenSSL 
versions prior to 1.0.2.

Though folks on this list probably don't care, Postfix support
covers and the current and 3 previous stable releases, so we're
still supporting Postfix 3.1, 3.2 and 3.3 which build with older
OpenSSL releases, all the way back to 0.9.7, but DANE support
requires at least OpenSSL 1.0.0. So users who're stuck with
OpenSSL 1.0.2 can continue to use it, with a slightly older
Postfix release, until 3.4 becomes the oldest supported stable
release.


Not sure from that whether Postfix 3.4 supports OpenSSL 1.0.2 ?

Red Hat Enterprise Linux 6 is stuck with OpenSSL 1.0.1, but is on its
last legs (entered "Maintenance Support 2 Phase" May 2017 and will be
retired November 30, 2020) so I hope that its users will be moving the OS on
and not in great need for the latest exim features.

--
Andrew C. Aitchison Cambridge, UK
and...@aitchison.me.uk

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

Re: [exim-dev] [Bug 2368] Exim 4.91-RC4 compile warning for unused result

[Andrew C Aitchison via Exim-dev]

On Sat, 2 Feb 2019, admin--- via Exim-dev wrote:


https://bugs.exim.org/show_bug.cgi?id=2368

Jeremy Harris  changed:

  What|Removed |Added

Resolution|--- |WONTFIX
  Assignee|ni...@exim.org  |jgh146...@wizmail.org
Status|NEW |RESOLVED

--- Comment #1 from Jeremy Harris  ---
This is a matter for choosing compiler switches to avoid doing such static
analysis.  We refuse to endlessly chase such things by using more-and-more
convoluted coding.  Even the cast-to-void could be regarded as such an
attempt, but it least its heritage goes back over thirty years.


This patch makes the code clearer,
and makes it explicit that we know what we are doing.
If it makes that the compiler happy at the same time,
then we can leave the switches set in a way that helps us avoid writing 
new bugs.


I agree that this is not the time to put this fix into the next release,
but we could have a general code cleanup bug depend in this for the
next code clean up.

--
Andrew C. Aitchison Cambridge, UK
and...@aitchison.me.uk

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

Re: [exim-dev] Enable enable_prdr by default

[Andrew C Aitchison via Exim-dev]

On Fri, 11 Jan 2019, ?  via Exim-dev wrote:


Hello,

the last discussion about PRDR 
http://www.eric-a-hall.com/specs/draft-hall-prdr-00.txt on ietf-s...@ietf.org 
was in
March 2014.

https://www.ietf.org/mail-archive/web/ietf-smtp/current/msg07655.html

The question was if PRDR will make any progress.  One of the answers was that 
nobody uses it, despite being implemented
in exim:
 https://www.ietf.org/mail-archive/web/ietf-smtp/current/msg07658.html

To make progress with PRDR please switch the default for enable_prdr to True.  
As exim is the only software that
implements this, only the compatibility exim ? exim has to be tested and this 
has been done.


https://www.ietf.org/mail-archive/web/ietf-smtp/current/msg07656.html 
(Wed, 5 Mar 2014) suggests that MeTA1 (http://www.meta1.org/) also 
implements PRDR.


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

Re: [exim-dev] [Bug 2358] outbound ratelimit support

[Andrew C Aitchison via Exim-dev]

On Thu, 27 Dec 2018, admin--- via Exim-dev wrote:


https://bugs.exim.org/show_bug.cgi?id=2358

--- Comment #2 from Jeremy Harris  ---
It depends how complex you want it; for the simplest case place this class
of messages in an alternate named queue, set up the queue-runner to run M
times per hour and have a queue_run_stop router triggering after n/M 
messages.


Thanks. I understand the proposal now.

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

Re: [exim-dev] C99 coding features

[Andrew C Aitchison via Exim-dev]

On Thu, 16 Aug 2018, Jeremy Harris via Exim-dev wrote:


Since f2ed27cf5f (between 4.89 & 4.90) we've documented
a requirement on C99-capable compilers.  This was the
introduction of specified-initialiser use in the Exim code.

How do people feel about other more-modern C features?

This was triggered by the Postgres hackers ML pointing out
that C99 permits variable declaration embedded in "for"
statements, eg:

for (int i = 0; ...) { ... }

Ref:
  6.8.5  Iteration statements

  Syntax

  iteration-statement:
  while ( expression ) statement
  do statement while ( expression ) ;
  for ( expr-opt ; expr-opt ; expr-opt ) statement
  for ( declaration ; expr-opt ; expr-opt ) statement


I'm tempted by that one.



I don't like mixing declarations with code.


To me the first is an example of the second.
OK, the variable declared in the for goes out of scope after the loop,
which makes it safer, but I am not sure that I can justify one
and not the other.
One of the projects I actually code for requires that variables are
instantiated when they are declared and it is clearer to give a new 
variable a value just before it is used than several pages up ...





Other possibilities mentioned include:
- variadic macros
- compound declarations:  function((struct x) {1, 2})


Comments?


I don't know enough about C99 to comment on its features.

---

Red Hat / CentOS / Scientific Linux 6 is too old to be a big worry
(especially as they have OpenSSL v1.0.1 which will be a bigger issue)
but on SL6 "man gcc" says
   c99
   c9x
   iso9899:1999
   iso9899:199x
   ISO C99.  Note that this standard is not yet fully supported;
   see  for more
   information.  The names c9x and iso9899:199x are deprecated.

Further, gcc v4.7, v4.8, v4.9, v5, v6 and v7 are available for these OSes 
from Red Hat / CentOS / Scientific Linux, which can be installed alongside

the default compilers and object code compiled with different versions
can be trivially linked together.

We may need to document compilation on RHEL6 and friends,
but I see no reason for it to stop the use of C99 features.

--
Andrew C. Aitchison Cambridge, UK
and...@aitchison.me.uk

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

Re: [exim-dev] [Bug 1523] DANE support under GnuTLS

[Andrew C Aitchison via Exim-dev]

On Sat, 3 Mar 2018, admin--- via Exim-dev wrote:


https://bugs.exim.org/show_bug.cgi?id=1523

Jeremy Harris  changed:

  What|Removed |Added

Status|ASSIGNED|RESOLVED
Resolution|--- |FIXED

--- Comment #5 from Jeremy Harris  ---
DKIM was moved to mainline by c0635b6dfe and will be in 4.91



DKIM or DANE ?


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