Re: [exim-dev] SASL error message

[Jeremy Harris via Exim-dev]

On 26/04/2023 13:18, Peter Rindfuss via Exim-dev wrote:

I use Debian 11 Exim 4.94.2 (exim4-daemon-heavy), which has Cyrus SASL support 
compiled in. My configuration does not use any SASL features, though. Since I 
installed some SASL components for reasons unrelated to Exim, I see the 
following error messages in auth.log for every received message:

... exim4: ldapdb_canonuser_plug_init() failed in sasl_canonuser_add_plugin(): 
invalid parameter supplied
... exim4: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb

This causes no problems, but I still wonder why it happens. Exim, in my 
opinion, should not try to initialize anything that is not used.


None of the strings "ldapdb_canonuser_plug_init", "_sasl_plugin_load" or
"sasl_plugin_load" appear in the current exim git head.  While I've
not checked 4.94 release explicitly, I don't recognize them either.

I don't know why they've turned up in the exim binary.

I'd suggest taking the question to Debian bugs.
--
Cheers,
  Jeremy


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

Re: [exim-dev] user file write permissions

[Jeremy Harris via Exim-dev]

On 24/04/2023 02:43, exim--- via Exim-dev wrote:

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?


Traditional installations of Exim have the binary as setuid root.
Given that, it can set it's UID to the user's when needing to
deliver to file.

It runs for most of the time at non-root (eg. an "exim" user), to reduce
the security footprint, and re-execs to regain root at transport time.
--
Cheers,
  Jeremy


--
## 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

[Jeremy Harris via Exim-dev]

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).

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


That's not getting involved, here (your exim is not advertising it for the
connection).


Any suggestions on how to proceed ?

Connecting to 127.0.0.1 port 1225 ... connected


So this is the testsuite "client" output.

...

??? 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


The client was expecting some more TLS input, but (probably; it's the most 
likely
cause for that) the server closed the TCP connection.

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

--
Cheers,
  Jeremy


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

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

[Jeremy Harris via Exim-dev]

On 14/03/2023 08:17, Andrew C Aitchison via Exim-dev wrote:

Are these messages moderated

Yes.  Blame spammers.
--
Cheers,
  Jeremy


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

Re: [exim-dev] MAX_LOCALHOST_NUMBER and LOCALHOST_MAX

[Jeremy Harris via Exim-dev]

On 05/01/2023 11:49, Andrew C Aitchison via Exim-dev wrote:


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_NUMBER    256

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



MAX_LOCALHOST_NUMBER appears to be historical and redundant.
The only mentions are config.h.defaults and comments in two
makefiles for no-longer-supported platforms.

It's use went away in 4.14 (about January 2003) when the
message-id stuff started tracking time resolution rather
than "how many IDs are probably safe in a slot",
and it wasn't properly cleaned out.

[ I have a git repo made-up from old releases; if anyone
needs to spelunk I'll work out how to make it visible again.
If anyone knows how to safely *prefix* versions to a git
repo history, they could appear in the main repo -
but I doubt that can be done. ]

Now would be a good time, since you've noticed it.
--
Cheers,
  Jeremy


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

Re: [exim-dev] [Bug 2911] New: setting dns_again_means_nonexist to a list containing @mx_ lookups causes segfault

[Jeremy Harris via Exim-dev]

On 23/08/2022 20:12, Viktor Dukhovni via Exim-dev wrote:

Note that if this also potentially applies to TLSA lookups, then
downgrading SRVFAIL (try again) to NXDOMAIN breaks the downgrade
resistance of DANE.


Yup, it would be too easy to write a configuration that did that.
I'll add code to ignore that option for TLSA lookups.
--
Thanks,
  Jeremy


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

Re: [exim-dev] [Bug 2954] New: tls_eccurve (>= OpenSSL 3.0.0) dysfunctional

[Jeremy Harris via Exim-dev]

On 02/01/2023 04:16, Viktor Dukhovni via Exim-dev wrote:

Mind you, things are a bit complicated with TLS 1.3, where ECDHE groups
and FFDHE groups are unified and always negotiated, and setting the
grouplist to just ECDHE groups will disable FFDHE.


Is there any particular advantage, or behaviour difference, in
FFDHE vs. ECDHE?

Is it mostly "EC keys are smaller, for equivalent protection"?
--
Cheers,
  Jeremy


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

Re: [exim-dev] Build failure since commit 4e9ed49f8f12eb331b29bd5b6dc3693c520fddc2

[Jeremy Harris via Exim-dev]

On 01/09/2022 10:46, Martin D Kealey via Exim-dev wrote:

it appears that the build consistently fails as of:
commit 4e9ed49f8f12eb331b29bd5b6dc3693c520fddc2


Give 32da632 a go?

I think I'll change the build-time auto-WITH_CONTENT_SCAN
when you have EXPERIMENTAL_DCC into a hard error; I'd not
spotted it so my build checks were not doing what I thought.
--
Cheers,
  Jeremy


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

Re: [exim-dev] dsearch erroneously requires directory "read" permission

[Jeremy Harris via Exim-dev]

On 15/08/2022 10:21, Martin D Kealey via Exim-dev wrote:

Even though lstat alone would work (proving the existence of the parent
directory, the ability to traverse it, and the existence of the target
filename), dsearch_open calls exim_opendir, and then immediately closes it,
and then fails because the directory lacks 'r' permission. Natch!

The comment above dsearch_open says "We open the directory to test whether
it exists and whether it is searchable", but that's not actually true,
because "readable" and "searchable" are two different things.


Seems a reasonable request for change; please open an item
at https://bugs.exim.org/


Is there any reason why dsearch_open shouldn't simply be an empty function
that always succeeds?


The error message that it can return. Admittedly, we should probably modify
that to something like "cannot find dir %s" if we just lstat rather than
exim_opendir().  And we'll need an explicit taint check, like exim_opendir() 
does.
--
Cheers,
  Jeremy

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

Re: [exim-dev] add routing to external MX

[Jeremy Harris via Exim-dev]

On 06/08/2022 12:07, Jan Willem Stegink via Exim-dev wrote:

   *   When a domain is created to be moved while testing and setting up:
Mail from another domain on the shared server goes to the preparated site 
unable to receive mail.


   *   When a domain has MS Exchange:
originaldomain.com -> forwardingdomain.com (exists on same shared server)-> 
externalmxdomain.com returns with No such recipient here.

You can also read my web page 
https://webhostingtech.nl/monitoring-email/solve-exim-issues/

Proposed for exim.conf:
domainlist external_mx_domains = lsearch;/etc/virtual/external_mx_domains
routing: domains = +external_mx_domains : ! +local_domains


What you decide is right for your Exim configuration file is up to you.
There's no change implied in the Exim codebase.
That's why the configuration is a file.
--
Cheers,
  Jeremy

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

[exim-dev] heimdal_gssapi authenticator

[Jeremy Harris via Exim-dev]

Does anyone out there use the above?  Build with it?

My initial attempts to build (having not found an obvious
fedora library package for heimdall, yet) are tripping over
a possibly incompatible /usr/include/krb5.h

There's also no testsuite coverage.

Finding out if there are actually any users would be
interesting.  Perhaps it is moribund and should be withdrawn.
--
Cheers,
  Jeremy

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

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

[Jeremy Harris via Exim-dev]

On 30/04/2022 09:34, Andreas Metzler via Exim-dev wrote:

(requirement for quoting in
query-style lookups


Those are not hard-fails as currently implemented.


and taint-check exec arguments for
transport-initiated external processes).


These are.
--
Cheers,
  Jeremy

--
## 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

[Jeremy Harris via Exim-dev]

On 26/04/2022 08:28, Andrew C Aitchison via Exim-dev wrote:

• 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.



The trouble with that is that it means the coverage of tracking
tainted data use can never be extended.

The commit for that removal is fairly extensive:

$ git log --stat 8f2cf8f5ad^1..8f2cf8f5ad
commit 8f2cf8f5adaa08ef84b47bf9bc2f71e39236c22d
Author: Jeremy Harris 
Date:   Tue Mar 1 23:12:53 2022 +

Revert introduction of alloc_insecure_tainted_data

tidy log.c

(cherry picked from commit 0327b6460eec64da6b0c1543c7e9b3d0f8cb9294)

(cherry picked from commit 8021b95c2e266861aba29c97b4bb90dc6f7637a2)

This reverts commit f9a3fcddba223133019368e7cd6d51449fc54e7b.

This reverts commit 8fc13e4adcdf5d0cec382c401ce72592569084fe.
This reverts commit 2382cd3e81838709abd3b0c1b410f65274d90e25.
This reverts commit ace68726852d08deec815a37f369a4e31be77813.
This reverts commit 4a2bd5dc2f157c50b7e4e7491eac1c930efd2100.
This reverts commit e8b8b133c685e7b09f672016d117c7d8b49e70b1.
This reverts commit f7509ba6fb5e1033c1406b87f057c9c48a217d27.
This reverts commit dbac5a049acbe645a816b4a5e895c5be0de53483.
This reverts commit f7da81e789e2f20b00f46f07260488f337984b84.
This reverts commit f7c791b769a3a5395d92d29d27aa58f9d442373c.
This reverts commit 0fa46a83a55054c65ffc539405f62bf86aac5b44.
This reverts commit ec7e44dc9134307d74afa4b07f09afbdd019282c.
This reverts commit ee4924bc711f54a751448fb5cee5ec4fc9c96196.
This reverts commit 951b668a191ef510a4e27d8204c5fa82ca957a07.
This reverts commit 18d243312bf3a23bd0f464fac44797e2720e03ec.
This reverts commit 16c884a4818594069253de460bf9926f69d50fe5.
This reverts commit 368ecb000c58995c5f61443d45d43942f1f431d0.
This reverts commit 331817e995b05793ec840476fac67e8f7c638a47.
This reverts commit 07343a5b1968f4f5e41664c15fd636bdb6a6cc48.
This reverts commit 060cf1e3c9a0a6960b771cdff6f0a5a2ca9b114c.
This reverts commit 28d2eab1414ef8d20ff0fde7026aa52fd01ef795.
This reverts commit b6b4b129892a99747a586e5d4acb68fe7176ab4b.
This reverts commit 77b478579a0029def01d1b3a4ea591eac447832a.
This reverts commit 0103b34645278151851c31cf1c1976150d907bb4.
This reverts commit f94ca3e3ed2bc5a68ac54c5487e0216ea8db8470.
This reverts commit 7a33a3fc2c1ae4df30eaabaf25fc59e2d6ab5d6c.
This reverts commit 305c0579ab4286b464c2cd589843a7e60f59dfaf.

 doc/doc-docbook/spec.xfpt |  28 
 doc/doc-txt/ChangeLog |   3 ++
 src/src/EDITME|   7 ---
 src/src/acl.c |  38 +++--
 src/src/config.h.defaults |   2 -
 src/src/dbstuff.h |   6 ++-
 src/src/deliver.c |  16 +++
 src/src/directory.c   |   4 +-
 src/src/expand.c  | 212 
+--
 src/src/functions.h   |  54 ++-
 src/src/globals.c |  10 -
 src/src/globals.h |   4 --
 src/src/log.c | 130 
+++-
 src/src/lookups/lf_sqlperform.c   |  14 +++---
 src/src/macros.h  |   3 --
 src/src/parse.c   |   6 ++-
 src/src/rda.c |   4 +-
 src/src/readconf.c|   3 --
 src/src/routers/rf_get_transport.c|   4 +-
 src/src/search.c  |   8 +++-
 src/src/smtp_out.c|   7 ++-
 src/src/transports/appendfile.c   |  11 -
 src/src/transports/autoreply.c|  21 -
 src/src/transports/pipe.c |   9 ++--
 src/src/transports/smtp.c |   5 ++-
 test/aux-fixed/0990/example.com   |   1 -
 test/confs/0990   |   2 -
 test/log/0608 |   2 +-
 test/paniclog/0608|   2 +-
 test/scripts/0990-Allow-Tainted-Data/0990 |   7 ---
 test/scripts/0990-Allow-Tainted-Data/REQUIRES |   1 -
 test/stderr/0608  |   2 +-
 test/stderr/0990  |   

Re: [exim-dev] exim 4.95: Remote host closed connection in response to end of data

[Jeremy Harris via Exim-dev]

On 04/01/2022 17:21, Zakaria via Exim-dev wrote:

 tls_verify_certificates = 
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
 hosts_require_tls =  host_list

The solution it might be just with my case. Also, I noticed LMTP server IP must 
be exposed to internet via port, in your case 2026.


If I read Axel's obfuscation correctly (sigh), he's not using TLS.


archiveopteryx_delivery:
  driver = smtp
  protocol = lmtp
  hosts = {{ lr_exim_imap_server }}
  port = 2026
  hosts_avoid_tls = {{ lr_exim_imap_server }}


--
Cheers,
  Jeremy

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

Re: [exim-dev] exim 4.95: Remote host closed connection in response to end of data

[Jeremy Harris via Exim-dev]

On 04/01/2022 17:24, Axel Rau via Exim-dev wrote:

Disabling pipelining on the transport stops the issue.


Sounds like you've found a sufficient workaround, but you
should raise a bug against the imap server for failing to
understand TCP.

--
Cheers,
  Jeremy

--
## 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)

[Jeremy Harris via Exim-dev]

On 05/01/2022 15:46, Andrew C Aitchison via Exim-dev wrote:

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


I'm ok with it, as the CVE is already public.
If you are concerned, I'm happy with offline mail too.
--
Cheers,
  Jeremy

--
## 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)

[Jeremy Harris via Exim-dev]

On 04/01/2022 11:11, Harry Mills via Exim-dev wrote:

We are running exim 4.94.2-2 from EPEL on Centos8.


Specific code protecting against the alleged attack appeared in Exim in 2011.

That was for release 4.76 .  Unless the reporter is claiming a regression...

--
Cheers,
  Jeremy

--
## 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)

[Jeremy Harris via Exim-dev]

On 04/01/2022 11:11, Harry Mills via Exim-dev wrote:

We have a PCI DSS compliance failure for CVE-2021-38371, the details page 
(linked from mitre.org site) gives a 404 and we cannot find any other details 
on what this CVE refers to, or whether or not a fix is available.

We are running exim 4.94.2-2 from EPEL on Centos8.

Any information would be very welcome.


https://nostarttls.secvuln.info/ claims Exim is vulnerable, and that this
was reported to us.  However, I'm not aware of any such report nor evidence.

You could try the test tool linked from that page.
--
Cheers,
  Jeremy

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

Re: [exim-dev] [Bug 2822] Issues with DHE ciphers - problems with GnuTLS implementation?

[Jeremy Harris via Exim-dev]

On 19/10/2021 20:40, Viktor Dukhovni via Exim-dev wrote:

Though my comment likely won't make it into the ticket log


You could always comment on the bug, using the bugzilla web interface.
The link was in the mail you replied to.
--
Cheers,
  Jeremy

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

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

[Jeremy Harris via Exim-dev]

On 03/10/2021 12:19, Andrew C Aitchison via Exim-dev wrote:

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


The whole point of making the library change early in the dev cycle
is to get operational experience *before* making a release.  This
can be done be people interested enough to be on the bleeding edge
and does not involve the project asserting that the results are of
release quality.

I don't know if there are any such people apart from myself, because
I get zero feedback.

--
Cheers,
  Jeremy

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

Re: [exim-dev] buildfarm animals

[Jeremy Harris via Exim-dev]

On 03/10/2021 06:23, Andreas Metzler via Exim-dev wrote:

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.


Possibly you are correct.  We can decide if and when the
case arises.

--
Cheers,
  Jeremy

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

Re: [exim-dev] buildfarm animals

[Jeremy Harris via Exim-dev]

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.
--
Cheers,
  Jeremy

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

Re: [exim-dev] buildfarm animals

[Jeremy Harris via Exim-dev]

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.
--
Cheers,
  Jeremy

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

Re: [exim-dev] buildfarm animals

[Jeremy Harris via Exim-dev]

On 14/09/2021 12:57, Jeremy Harris via Exim-dev wrote:

On 14/09/2021 12:49, Fabian Groffen wrote:

Is it possible to first check for PCRE2_CONFIG and then bark when
PCRE_CONFIG is found?  papua has both installed, but since I cannot
change config per branch, if I could set both PCRE2_CONFIG and
PCRE_CONFIG, both old and new strategies could run.


Per-branch config can be done in the config file.  Just before the last line
add something like:


if ($branch eq '4.next')
{
     # $conf{makefile_add}{CFLAGS} .= ' -std=c99 -D_BSD_SOURCE 
-D_POSIX_SOURCE';
}




Further, unless you are doing something unusual you don't
need to specify either PCRE_CONFIG or PCRE2_CONFIG; the
default EDITME has it enabled as appropriate for the branch.

Both should "just run".

--
Cheers,
  Jeremy

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

Re: [exim-dev] buildfarm animals

[Jeremy Harris via Exim-dev]

On 14/09/2021 12:49, Fabian Groffen wrote:

Is it possible to first check for PCRE2_CONFIG and then bark when
PCRE_CONFIG is found?  papua has both installed, but since I cannot
change config per branch, if I could set both PCRE2_CONFIG and
PCRE_CONFIG, both old and new strategies could run.


Per-branch config can be done in the config file.  Just before the last line
add something like:


if ($branch eq '4.next')
{
# $conf{makefile_add}{CFLAGS} .= ' -std=c99 -D_BSD_SOURCE 
-D_POSIX_SOURCE';
}


--
Cheers,
  Jeremy

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

[exim-dev] buildfarm animals

[Jeremy Harris via Exim-dev]

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

--
Cheers,
  Jeremy

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

Re: [exim-dev] DANE library for Exim + OpenSSL and upcoming OpenSSL 3.0.0 release.

[Jeremy Harris via Exim-dev]

On 12/08/2021 21:30, Viktor Dukhovni via Exim-dev wrote:

Perhaps you mean OpenBSD,  FreeBSD 12 dropped LibreSSL and went back to
OpenSSL.


Nope.  There's a buildfarm animal listed as "FreeBSD latest"
showing as building with LibreSSL 3.3.3

--
Cheers,
  Jeremy

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

Re: [exim-dev] DANE library for Exim + OpenSSL and upcoming OpenSSL 3.0.0 release.

[Jeremy Harris via Exim-dev]

On 12/08/2021 15:30, Viktor Dukhovni via Exim-dev wrote:

You'd be able to drop the "danessl" library.


You mean, the three source files.  No library involved.



then let it do all the work.


And lose the observability we currently have.  I bet the library
implementations don't expose that.



No, there's no DANE support in LibreSSL.  My advice would be to drop
LibreSSL support.


Can't; the FreeBSD guys like it.
--
Cheers,
  Jeremy

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

Re: [exim-dev] DANE library for Exim + OpenSSL and upcoming OpenSSL 3.0.0 release.

[Jeremy Harris via Exim-dev]

On 12/08/2021 05:06, Viktor Dukhovni via Exim-dev wrote:

The upcoming OpenSSL 3.0.0 release is now in beta and should ship some time in 
the next few months.
This brings some low level changes to the library, that don't affect most 
applications, but may require
changes in the legacy standalone DANE library I wrote for OpenSSL 1.0.0+.

While the changes look largely manageable, I'd rather not continue to maintain 
the legacy
DANE library in perpetuity, given that OpenSSL 1.1.0 and later have built-in 
DANE support.

With OpenSSL 1.0.2 long EOL, is there any chance that newer versions of Exim 
could set the
floor OpenSSL version to 1.1.1 and migrate to use the built-in DANE support?  
I'd can offer
some help to get you there, and then retire the standalone library for good...


I tried (rather briefly) to reactivate my openssl build environmentm so as to 
see
what works and doesn't under the current nearly-3.0.0 OpenSSL.  But it seems to
be bust, and it's one of those things that is far too convoluted to work on.

I'm quite expecting Exim to start breaking horribly, when 3.0.0 appears on real
systems.


I've occasionally considered working on a move to the native DANE support, under
both OpenSSL and GnuTLS (which we officially support).  But I expect it to be a 
whole
bunch of work, and invasive to the point of horribly complexifying the Exim
codebase.
(Likewise, so will fixing whatever 3.0.0 breaks for us, since we cannot drop 
support
for earlier versions.)

You might guess that my enthusiasm is rather low, here.

The there's the LibreSSL question.  I've never found any decent docs for it; we
only discover issue where it differs from OpenSSL one-at-a-time.  Currently we
manage this with a raft of feature-macros just like we have to for OpenSSL 
versions.
Do you know if LibreSSL has the same DANE APIs as OpenSSL?


As far as dropping support for earlier OpenSSL versions goes: there is at least
one system in the buildfarm not operated by me and running with OpenSSL 1.0.1s
- a Solaris 10.  I assume that means there is at least one person out there 
still
interested in operating Exim on systems of that vintage, even though the OpenSSL
project calls it End Of Life.
--
Cheers,
  Jeremy

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

Re: [exim-dev] [PATCH] Docs: fix cross-reference for $spf_received

[Jeremy Harris via Exim-dev]

On 20/07/2021 12:19, Andreas Metzler via Exim-dev wrote:

the existing cross-reference point is broken, also the description is
unnecessary short, imho.


Patch committed; thanks.
--
Cheers,
  Jeremy

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

Re: [exim-dev] Junk in repo: doc/doc-docbook/spec.xfpt.readsock

[Jeremy Harris via Exim-dev]

On 20/07/2021 10:30, Andreas Metzler via Exim-dev wrote:

doc/doc-docbook/spec.xfpt.readsock seems to have been accidentally added
to the repository.


Thanks; removed

--
Cheers,
  Jeremy

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

Re: [exim-dev] 4.95 - superfluous HELO check in ACL

[Jeremy Harris via Exim-dev]

On 17/07/2021 13:45, Andreas Metzler via Exim-dev wrote:

require message   = nice hosts say HELO first
 condition = ${if def:sender_helo_name}

This should be superfluous due to:

++
|hosts_require_helo|Use: smtp|Type: host list*|Default: *|
++


Yup, seems reasonable to drop that now.
Anyone changing the deafault presumably knows what they're
doing.
--
Cheers,
  Jeremy

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

Re: [exim-dev] Mail boincing back to bounces@servername instead of sender

[Jeremy Harris via Exim-dev]

On 11/06/2021 21:01, Rowney, Dion via Exim-dev wrote:

If my replacement system I see the bounces are returning 
toboun...@myeximserver.com

And I see the following in the logs:

Jun  7 17:28:52 test  exim[32705]: 2021-06-07 17:28:52.615 [32705] 1lqOfs-0008VV-Jb <= <> 
H=mailtestmta.test.domain.com (mail.test.domain.com) [123.123.215.233]:48218 I=[123.123.215.121]:25 P=esmtps L. 
X=TLS1.2:ECDHE-RSA-AES256-SHA384:256 CV=no K S=34927 M8S=0 
RT=0.005sid=e1lqofo-000vfk...@list.domain.com  T="Mail 
delivery failed: returning message to sender" from <> for 
boun...@test.domain.com


So are you sending with an envelope-from of
boun...@test.domain.com
?

If so, and you are not accepting that as a valid address, you
need to change one or the other.

Please don't obfuscate.  It makes it harder to help you.
--
Cheers,
  Jeremy

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

Re: [exim-dev] servers expansion

[Jeremy Harris via Exim-dev]

On 12/06/2021 20:56, Andrew C Aitchison via Exim-dev wrote:

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.


This immediately sounds dangerous.

[suggested code change]


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 ?


Precisely.  Consider what an attacker might present you with to get
expanded, and the extensive facilities that Exim expansion offers.
--
Cheers,
  Jeremy

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

Re: [exim-dev] Patch on exim-4.94+fixes applied after EOL

[Jeremy Harris via Exim-dev]

On 12/05/2021 19:08, Andreas Metzler via Exim-dev wrote:

On 2021-05-09 Heiko Schlittermann via Exim-dev  wrote:

Andreas Metzler via Exim-dev  (So 09 Mai 2021 08:06:11 CEST):

Thanks, seems to have happened again with
c1faf04b865465894c7ca41ab4585fb69d4a5936. How about closing this branch
e.g. with a commit deleting all files?


You do realise that c1faf04 was only pushed about twenty minutes
before your mail?

I think I'll give up bothering to cherry-pick to
a +fixes branch at all, given the level of thanks we get.
--
  Jeremy

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

Re: [exim-dev] [Bug 2730] New: EAI trace information doesn't log domains as U-labels

[Jeremy Harris via Exim-dev]

On 04/05/2021 23:59, Viktor Dukhovni via Exim-dev wrote:

On May 4, 2021, at 2:48 PM, admin--- via Exim-dev  wrote:

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


RFC 6531 says you SHOULD do this.  In IETF-ese "SHOULD" means MUST unless there
is a compelling technical reason not to do it, not do this if you feel like it.
(That's MAY.)

It's not a huge bug but it looks easy to fix.


It seems you're referring to:


[offlist]

Could you copy that to the bugzilla entry?
--
Cheers,
  Jeremy

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

Re: [exim-dev] [Bug 2702] New: XCLIENT ESMTP extension

[Jeremy Harris via Exim-dev]

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/ ##

Re: [exim-dev] [Bug 2702] New: XCLIENT ESMTP extension

[Jeremy Harris via Exim-dev]

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: [exim-dev] On Channel Binding over SMTL/TLS

[Jeremy Harris via Exim-dev]

On 10/01/2021 11:47, Дилян Палаузов via Exim-dev wrote:

RFC 5929 Channel Bindings for TLS defines the tls-unique channel
binding, stating that there was an old tls-unique, which was bad.  The
new tls-unique uses the most recent TLS Finished message sent in the
token, whereas the old tls-unique used the first TLS Finished message.

Commit b1a32a3ce673 adds channel binding to openssl/exim,


2019/11.  Actually only adds the OpenSSL support; channel binding
under GnuTLS was already there (since the introduction of the gsasl
driver, 2012/02).


using the
function SSL_get_peer_finished().  Compare this to the OpenLDAP
implementation, where libldap/tls_o.c:tlso_session_unique() uses
SSL_session_reused(s) ^ !is_server ? SSL_get_finished(s) :
SSL_get_peer_finished().


Exim only calls SSL_get_peer_finished() on the server side.
The client side calls SSL_get_finshed().



https://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_gsasl_authenticator.html
says for server_channelbinding: “However, Channel Binding in TLS has
proven to be vulnerable in current versions. Do not plan to rely upon
this feature for security, ever, without consulting with a subject
matter expert (a cryptographic engineer). ”.  Is this vulnerability
addressed in RFC 5929?


The docs warning was added in 2018/07.  RFC 5979 was published 2010/07.
Draw your own conclusion.
I'm not a cryptographic engineer, and my advice is worth what you're
paying for it.

For reference, RFC 8446 (TLS 1.3) was published 2018/08.  The situation
might be different in 1.3 vs. previous TLS versions.  There appears to
have been recent work on the subject:
  
https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls13/

- which mentions a "triple-handshake" vulnerability found for RFC 5929
(I infer, for TLS 1.2) which in turn can be mitigated by using Extended
Master Secret.  See RFC 7627; Exim enforces the requirements of
https://tools.ietf.org/html/rfc7677#section-4 (in short, if TLS Resumed
then require Extended Master Secret).

   NOTE: I do not know if this is the concern that warranted the warning
 in the Exim docs.
 You should, as it says, consult a crypto expert.



Would you mind implementing Channel Binding also using Cyrus SASL and
doing interoperability test


The Cyrus SASL documentation is a disaster zone, from my memory of the
last time I tried to look.  I'm not enthusiastic about doing anything
with that library.


Have you done any interoperability tests for the channel binding


No.
--
Cheers,
  Jeremy

--
## 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

[Jeremy Harris via Exim-dev]

On 07/11/2020 21:57, Andrew C Aitchison via Exim-dev wrote:

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


I don't see how, without radically changing what both types of module
(I assume you're talking about module type A, the local_scan, and type
B, the lookups) are permitted to do.  But perhaps you've thought of
something I have not.
--
Cheers,
  Jeremy

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

Re: [exim-dev] DKIM Signing and renewing DKIM certificates

[Jeremy Harris via Exim-dev]

On 31/10/2020 16:34, Mark Elkins via Exim-dev wrote:
If I have to have a different selector for a new DKIM key pair - and I'm 
signing about 40 domains - is there a suggested way to manage the 
currently hard coded line in exim.conf of:-


remote_smtp:
   driver = smtp
   dnssec_request_domains = *
   hosts_try_dane = *
   return_path = ${address:$reply_address}
   message_size_limit = ${if > {$max_received_linelength}{998} {1}{0} }
   dkim_domain = ${lc:${domain:$h_from:}}


It's expanded and can use $dkim_domain, says the docs.  Why not pull
it from a file?
--
Cheers,
  Jeremy

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

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

[Jeremy Harris via Exim-dev]

On 28/10/2020 09:58, Andrew C Aitchison via Exim-dev wrote:

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.


Looks like it runs continuously; it references the current tree head.

I don't like static analysers in general - they tend to not understand
enough context, they tend to display the biasses of the analyzer writer
rather than the actual sourcecode language definition, and they throw
up so much cruft as a result that wading through it is a major timesink.

For instance, with Coverity I had to dismiss just about every whine re.
memory leaks.  Exim's process-handling releases memory by terminating
processes.  The tool just didn't grok the possibility; fortunately it
let me tag each whine position as accepted.

This one looks pretty limited, from the alerts it is displaying.
--
Cheers,
  Jeremy


OpenPGP_0xBCE58C8CE41F32DF.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] Will you accept a new acl_smtp_auth_unadvertised ?

[Jeremy Harris via Exim-dev]

On 15/09/2020 16:19, u34--- via Exim-dev wrote:
> In general, will you incoporate something like that in the code?

You could do that purely coded in ACL, using quit/notquit ACLs,
$smtp_command_history, ratelimit, and connect ACL.

I'm not convinced there's enough need for a new ACL type.
-- 
Cheers,
  Jeremy

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

Re: [exim-dev] ulong in exim_monitor/em_menu.c

[Jeremy Harris via Exim-dev]

On 12/09/2020 19:47, Richard Clayton via Exim-dev wrote:
> in exim_monitor/em_menu.c
> 
>  635   text_showf(text, "Format error in spool file %s: size=%lu\n", 
> buffer,
>  636 (ulong)statbuf.st_size);
> 
> sadly, when I compile with clang on FreeBSD "ulong" does not exist

Thanks for finding this.  I obviously need to add eximon to the
FreeBSD buildfarm animal I have.  I foresee a world of library pain...

Unless you fancy setting one up, so that the specific configuration
you are interested in is certain to get regression tests?
-- 
Cheers,
  Jeremy

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

Re: [exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients

[Jeremy Harris via Exim-dev]

On 17/08/2020 23:33, Viktor Dukhovni via Exim-dev wrote:
> The Exim case should be somewhat simpler since nothing is persisted
> out of process

Not so.
-- 
Cheers,
  Jeremy

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

Re: [exim-dev] GDB step by step exim

[Jeremy Harris via Exim-dev]

On 16/07/2020 05:07, Dennis Roellke via Exim-dev wrote:
> I’d like to understand better how exim processes EHLO messages.

Most people don't need to deal at that level of detail.

Why?
-- 
Cheers,
  Jeremy

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

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

[Jeremy Harris via Exim-dev]

On 09/06/2020 18:33, Viktor Dukhovni via Exim-dev wrote:
> Perhaps so, but in the context of everything else in RFC6125, and the
> specs for other protocols, ... it is fairly clear (to me anyway) that
> the intent is to match the SMTP server name prior to CNAME expansion,
> just like the HTTP/IMAP/... cases.

Given that HTTP/IMAP don't do MX lookups, the argument-by-analogy
is dubious.
You could as easily use it to justify the first of my three options.

I'm not saying I think you've chosen then wrong thing, only that
the lawyering is weak.
-- 
Cheers,
  Jeremy

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

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

[Jeremy Harris via Exim-dev]

On 08/06/2020 14:51, Viktor Dukhovni via Exim-dev wrote:
> On Mon, Jun 08, 2020 at 12:48:22PM +, admin--- via Exim-dev wrote:
> 
>> https://bugs.exim.org/show_bug.cgi?id=2594
>>
>> --- Comment #1 from Jeremy Harris  ---
>> Can you locate a standards document specifying the name that should be 
>> checked
>> against the certificate?
> 
> Yes:  https://tools.ietf.org/html/rfc6125#appendix-B.4
> 
> The original reported is right.

No, it's worse.  If you take that RFC 3207 wording strictly:

  -  A SMTP client would probably only want to authenticate an SMTP
  server whose server certificate has a domain name that is the
  domain name that the client thought it was connecting to.

it could mean the domain part of the recipient email address,
pre-MX-lookup.  Thanks to the word "domain".

Or it could mean that, again, but only when there is no MX record
and an A /  is being used... but pre-CNAME.

Or it could mean post-CNAME, because that "client" SMTP agent surely
thought it was connecting to a name that A/ resolved to the IP for
the connect() syscall.


It really is not well specified.

-- 
Cheers,
  Jeremy

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

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

[Jeremy Harris via Exim-dev]

On 08/06/2020 14:51, Viktor Dukhovni via Exim-dev wrote:
> On Mon, Jun 08, 2020 at 12:48:22PM +, admin--- via Exim-dev wrote:
> 
>> https://bugs.exim.org/show_bug.cgi?id=2594
>>
>> --- Comment #1 from Jeremy Harris  ---
>> Can you locate a standards document specifying the name that should be 
>> checked
>> against the certificate?
> 
> Yes:  https://tools.ietf.org/html/rfc6125#appendix-B.4

So, actually RFC 3207 - and only "probably".  Not even SHOULD.
Ho hum.
-- 
Cheers,
  Jeremy

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

Re: [exim-dev] Documentation build

[Jeremy Harris via Exim-dev]

On 02/06/2020 22:33, Simon Arlott via Exim-dev wrote:
> Version 2.0202 stops loading HTML entities by default.
> Fix here: 
> https://github.com/Exim/exim-website/compare/master...nomis:perl-xml-libxml-2.0202-fix

Thanks.  Is this a stable interface to the library,
and usable across a range of platforms some of which
will have earlier versions?

It does seem to work on both f31 & f32.

> There are also currently syntax errors in master on GitHub:
> https://github.com/Exim/exim/compare/master...nomis:doc-fix

I know, hence my frustration.
-- 
Cheers,
  Jeremy

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

[exim-dev] Documentation build

[Jeremy Harris via Exim-dev]

Any XML experts in the house?

The nicely-complex and fragile house of cards that is
the Exim documentation build no longer functions on
my main build system, thanks to an upgrade from Fedora 31
to 32.

Checking on VMs confirms.  F32: broken.

The symptom bites during the build of the website,
presumably generating html from xml: multiple errors
of the form

/tmp/exim-packaging-vswB/tmp/spec.xml:789: parser error : Entity 'ndash'
not defined
messages in its queue  that is, those that it is in the process of

- for several different, but basic-looking, entity types.
ndash, copy and nbsp.  According to wikipedia these are known things;
just single glyphs.

The build process then bombs out and wipes its results area.
The die line is:
 my $xml = XML::LibXML->new()->parse_file($xml_path) or die $!;


Anyone feel motivated to work on this?  It's beyond me, and if
it doesn't get some love then we'll soon be in the situation
of not being able to generate output versions of the docs.

I already can't easily check changes, and it's showing.
-- 
Cheers,
  Jeremy

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

[exim-dev] exim 4.94 RC2 published

[Jeremy Harris via Exim-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I have built, and placed on the FTP site, Release Candidate 2 for
exim release 4.94

ftp://ftp.exim.org/pub/exim/exim4/test/

The commit for RC2 is ef546e7882, at git://git.exim.org/exim.git

No further new features will be accepted for 4.94; developers
please use the 4.next branch for feature commits.
Bug fixes are still in order on the master branch.

- -
I forgot to call out one important change between RC0 and RC1
(thanks to Andreas Metzler for spotting this!) :-

- - The $local_part_verified variable introduced since 4.93 has
  been consolidated into $local_part_data (for parity with
  $domain_data).  $local_part_data can be used wherever
  $local_part_verified was.

New features since RC1:

- - New main config option spf_smtp_comment_template to customise the
  $spf_smtp_comment variable

Changes since RC1:

- - SPF: Remove parameters of the link to www.open-spf.org in the
  default comment template


- --

Checksums for RC2:

SHA256 (exim-4.94-RC2.tar.bz2) =
00036623db5d71d0d1c3815f2da81f6e6b5274cf0b513b498675d55809925de5
SHA256 (exim-4.94-RC2.tar.gz) =
10d5c9681f4acd6027677e760a07a64aefbaf99a51cfbdc2f76ef7bac6abecc8
SHA256 (exim-4.94-RC2.tar.xz) =
7a7a2f2d8c0f96a0fc3d6443a6b223f319d46e428a151f1305dff53c3d57301c
SHA256 (exim-html-4.94-RC2.tar.bz2) =
4c3c4ede83447b44bd004e47daeb2a969b681dcc27a422a5f54ddc6bd3652413
SHA256 (exim-html-4.94-RC2.tar.gz) =
28b31949a10d2094ef924dbaa7bc2e860567515a87eb722274cc52ea34029909
SHA256 (exim-html-4.94-RC2.tar.xz) =
a83b453ceb6f350fb0500d1ef8cb288b2ee32eb39808a483dec561ec5122b44f
SHA256 (exim-pdf-4.94-RC2.tar.bz2) =
17cb126b13651ecf50724abf44d048ee4d24cb9534cfb9da9ff9d0895326d7ae
SHA256 (exim-pdf-4.94-RC2.tar.gz) =
38858e17782435b7191f20bc400ad8dc52f4aaa3afe89344cafc0a118949f591
SHA256 (exim-pdf-4.94-RC2.tar.xz) =
d9f176d437cc2db527eac1fb97392034cf3571f251d1ef0d593db071b0e1c7b9
SHA256 (exim-postscript-4.94-RC2.tar.bz2) =
bf1464bb408994f89c09ab795cdc05bc63b83f5f01546152108852882a17ac0e
SHA256 (exim-postscript-4.94-RC2.tar.gz) =
6260046b290632b3f19ffdabc8352e7dd72ef4fb5ba9fb7a71d66c1a5e61f070
SHA256 (exim-postscript-4.94-RC2.tar.xz) =
53dbe471576d61aa5d7e9f9c5f72ef240950d25fe6382b4e9639e82e715bc55e



There are PGP signature files in the same ftp directory, signed by me
using
key A986F3A6BD6377D8730958DEBCE58C8CE41F32DF.


- -- 
Cheers,
  Jeremy
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEqYbzpr1jd9hzCVjevOWMjOQfMt8FAl7JMMsACgkQvOWMjOQf
Mt/Gxgf+J0ALJM5bR8hwULdoG+DV0AV90Lgfx/qyz/NvThG300arljBP/lZnWW65
iesrTrGuyFJN4IgZMAFMNGEDiSstQVK7PSh3e1OYvohg38jYvgqGOYCKQkW/YS/u
N1DomHvTsELDXtJvgVmNSZZYu9n8LSMHykYB7xGgDFCggakqFQbWOvoksdmOkNsx
RMrtT9PtVjEmmvVQDuZU/ow5VjOQo7oaMGqKuPXpQYdNofYuelQJDfhDWHLtWjwY
B0vzca0+OjN0QzHguQ0io1aP+obeoF65qIwn8xmkmiq/UEf+T+47meQhY+Sd58t0
+DVB11trHNw7JIRR1Rh88UISjAIgeg==
=62RR
-END PGP SIGNATURE-

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

Re: [exim-dev] exim 4.94 RC1 published

[Jeremy Harris via Exim-dev]

On 14/05/2020 17:42, Andreas Metzler via Exim-dev wrote:
>> Changes since RC0:
> 
> - $local_part_verified has been dropped again. $local_part_data should
>   work where $local_part_verified worked.

Doh.  Thanks.  I'll try to remember to point it out
in the next RC announcement also.
-- 
Cheers,
  Jeremy

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

[exim-dev] exim 4.94 RC1 published

[Jeremy Harris via Exim-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I have built, and placed on the FTP site, Release Candidate 1 for
exim release 4.94

ftp://ftp.exim.org/pub/exim/exim4/test/

The commit for RC1 is 632b9f8daa, at git://git.exim.org/exim.git

- -
New features since RC0:

- - An option on all single-key lookups, to return (on a hit) a de-tainted
  version of the lookup key rather than the looked-up data.

- - $domain_data and $localpart_data are now set by all list-match
  successes.
  Previously only list items that performed lookups did so.
  Also, matching list items that are tail-match or RE-match now set the
  numeric variables $0 (etc) in the same way os other RE matches.

- - bounce_message_file and warn_message_file are now expanded before use.

Changes since RC0:

- - Fix a memory-handling bug: when a connection carried multiple messages
  and an ACL use a lookup for checking either the local_part or domain,
  stale data could be accessed.  Ensure that variable references are
  dropped between messages.

- - Fix SPA authenticator.  Running as a server, an offset supplied
  by the client was not checked as pointing within response data before
  being used.  A malicious client could thus cause an out-of-bounds read and
  possibly gain authentication.  Fix by adding the check.

- - Internationalisation: change the default for downconversion in the smtp
  transport to be "if needed".  Previously it was "as previously set" for
  the message, which usually meant "if needed" for message-submission but
  "no" for everything else.  However, MTAs have been seen using SMTPUTF8
  even when the envelope addresses did not need it, resulting in forwarding
  failures to non-supporting MTAs.  A downconvert in such cases will be
  a no-op on the addresses, merely dropping the use of SMTPUTF8 by the
  transport.  The change does mean that addresses needing conversion will
  be converted when previously a delivery failure would occur.

- - Fix possible long line in DSN.  Previously when a very long SMTP error
  response was received it would be used unchecked in a fail-DSN, violating
  standards on line-length limits.  Truncate if needed.

- --

Checksums for RC1:

SHA256 (exim-4.94-RC1.tar.bz2) = 
24718d7b9354c3cdf65a6b261fcb5102d67163220dddc346caa1fe6bd3cc40b5
SHA256 (exim-4.94-RC1.tar.gz) = 
0c6bb17cd0ee12fbb3ca3ebbfccbbb1462f8d111d36d49385946e354614fd508
SHA256 (exim-4.94-RC1.tar.xz) = 
85c24cbcb3142934083fb492774fdedd5bfa814a850b47b3a75d3bedf03c562e
SHA256 (exim-html-4.94-RC1.tar.bz2) = 
4be463206f9f404f88a484ea7d7d597d4249e387c39b82a333618e9514a9f450
SHA256 (exim-html-4.94-RC1.tar.gz) = 
f1466910671299d883ada2f4c7d2e319b9f6f10ff19bcc19b7eb477730883c93
SHA256 (exim-html-4.94-RC1.tar.xz) = 
52dddc5f159ed4e709bc4b1f3c8c84c0039fb21df6b11095474512db4702ae7f
SHA256 (exim-pdf-4.94-RC1.tar.bz2) = 
12bbb769f233156a2107e6c55731b960f172a55746dbdc926bbd0e758f30cd5d
SHA256 (exim-pdf-4.94-RC1.tar.gz) = 
6c5835b5b8f7367e6a7e00ebea0ceb146a6c8e8deef998c007886652423c46fc
SHA256 (exim-pdf-4.94-RC1.tar.xz) = 
f2005e65929dcdf5d42e2ce63ad8b03fced85208e484b0e0995c81c3db27c2ea
SHA256 (exim-postscript-4.94-RC1.tar.bz2) = 
bc7c39bb7fdea1c1cf0b5a7d22ea9f76858c9be736ac490eadbcb6eef4592e99
SHA256 (exim-postscript-4.94-RC1.tar.gz) = 
f55b3753178f3fc351294f047251400a4f9cd044ae551a5886a37ae9ed35415f
SHA256 (exim-postscript-4.94-RC1.tar.xz) = 
b594a4980f6bf04589f6cba8f08305df16ce076f0ca10b4995258d6e768ea6fc

There are PGP signature files in the same ftp directory, signed by me using
key A986F3A6BD6377D8730958DEBCE58C8CE41F32DF.

- -- 
Cheers,
  Jeremy
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEqYbzpr1jd9hzCVjevOWMjOQfMt8FAl69KbcACgkQvOWMjOQf
Mt8CoAgAoKwAbbupYg5tItEF9ehwHoTF3KgroPnkWDxA7ww8nQxAWynAE59gQ7xd
LIVucNyAZvfKcuPI4FVeXuzUiIs5icqAaz+XvHQfTYFwD0KYJWuUvr1t+iD3Xf+o
xhTCpc7EfZBU7iozWnbZIqi+6VV6WHdzWfTJYk8JTRCoz1IhHC2Ubwbmuo1jXmAb
kmsOed7SFlvME4ucVqRTltLUtBo56jJTDOSjjiZS/m8MKqK257NsEzYkoO3wEpL1
6OLrZbAxgT63Oztrela+mcGPFonKqCsBBjT8M78KFAfy5Oeuz97wJ1Xj6N2Cdw4Y
yooc776MAR2KlxxhRmTPchGeNUZumw==
=/eyZ
-END PGP SIGNATURE-

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

Re: [exim-dev] [Bug 2571] Out-of-bound buffer read leads to Authentication Bypass in Exim SPA authentication method

[Jeremy Harris via Exim-dev]

On 07/05/2020 16:57, admin--- via Exim-dev wrote:
> https://bugs.exim.org/show_bug.cgi?id=2571
> 
> --- Comment #4 from Andreas Metzler  ---
> Should this get a CVE?

Possibly.

Pro:  people who watch for CVEs get a heads-up they should pull in the
  fix.

Con:  because of the publication of the bug, there was no pre-annouce
  notifying the issue and giving time for the major distros to
  pick up the bug before the issue went public.

I'm not sure I have the energy.
-- 
Cheers,
  Jeremy

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

Re: [exim-dev] headers_rewrite

[Jeremy Harris via Exim-dev]

On 30/04/2020 13:49, Anderson Ouverney | Gk2 Cloud via Exim-dev wrote:
> We are currently using exim on some cPanel servers we have, we are
> implementing a central relay to improve email management and sending speed.
> This relay only allows previously registered, authorized and authenticated
> domains (SPF, DKIM) to send new messages.
> 
> My problem is with forwarders, when a person creates a forwarder, eg:
> 
> 1- xx...@gmail.com - Original Sender
> 2- x...@mydomain.com - Original Recipient
> 3- xx...@hotmail.com - Forward Recipient
> 
> We have a problem relaying, because domain 1 is not on the list of allowed
> domains in the relay.

You don't say in which sense "not allowed", nor if you
are referring to envelope or header infomation, but if
you're talking about SPF then...


> We have also tried SRS, but it did not work on re-transmission.

... SRS is the right band-aid to be slapping on top of the
SPF breakage.
-- 
Cheers,
  Jeremy

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

[exim-dev] Next release starting; will be 4.94; RC 0 published

[Jeremy Harris via Exim-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

It's time for another release.

This will be mostly bugfixes content; for details please read
the ChangeLog file.  As far as features go:

There is a major introduction of parallel-operations in 2-phase
queue runs.  This is expected to help a) sites that dump a
large number of messages into spool in a very short time
(think: mailinglists and mailshots)  and b)  secondary MX's
for large sites, after a primary outage.

For other introductions of interest, please read the NewStuff file.
Incompatabilities are noted in the README.UPDATING file.


As usual for our run-up to release, new features are still being
accepted at this early stage.  I am aware of at least one which
I'm hoping will be.  A later Release Candidate will also announce the
change to bugs-only.

A 4.next git branch will become active for work that is not intended
to go into the 4.94 release.  As always, git://git.exim.org/exim.git
is the reference repo.  The commit for RC0 is 1e1ddfac79.



The ftp site, at ftp://ftp.exim.org/pub/exim/exim4/test/
now has the RC0 release candidate.

SHA256 (exim-4.94-RC0.tar.bz2) =
8f4f65f09d13b9cd53ff8000517635e7bc62d60b10011a0babbc7fb4b4236dcd
SHA256 (exim-4.94-RC0.tar.gz) =
2d581cc338600b03f2b22a26a36d6f7b321448f398df4ca6845942b672d7f42d
SHA256 (exim-4.94-RC0.tar.xz) =
7168496b9b4edafc724c64cca03e907e7a2d8cf412e76d3bff960e8e3e88f303
SHA256 (exim-html-4.94-RC0.tar.bz2) =
c7abc0c6ff84df2e413cb6873d5e832507e5c728b920c84e79092a2c6c3b0dce
SHA256 (exim-html-4.94-RC0.tar.gz) =
83836bfab4265d1072b21c3906a440d0c9db42d4fa2861c059c77b2008ab
SHA256 (exim-html-4.94-RC0.tar.xz) =
6abf50e7e8678daf6a5c6aa84de456cf13443c0a50192c546f5628eed394649f
SHA256 (exim-pdf-4.94-RC0.tar.bz2) =
d208604ae381547e940a49d2b449962f3bb013460719d39c436630972d50d27b
SHA256 (exim-pdf-4.94-RC0.tar.gz) =
bc5146ea0ae8c42315316d61314665dd6c6fc353b2e94679354cef184aca217e
SHA256 (exim-pdf-4.94-RC0.tar.xz) =
b06738ef7a345bb63987a70c1b09d690f18658eff841dcf872ef89ce2da74458
SHA256 (exim-postscript-4.94-RC0.tar.bz2) =
48e09bd6382a76a1d3679b38c4f62ce994be38a031483c521b6c64a386915bf6
SHA256 (exim-postscript-4.94-RC0.tar.gz) =
3424b13ec96db15c77aa8ca3c043bfd80d42e17fff9294000d78614c2ff0d63c
SHA256 (exim-postscript-4.94-RC0.tar.xz) =
81b00aa5e932e3d720d906601bd7f50b19a555325e929de981e5d0e5255ba9af

There are PGP signature files there also, signed by me using
key A986F3A6BD6377D8730958DEBCE58C8CE41F32DF.
- -- 
Cheers,
  Jeremy
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEqYbzpr1jd9hzCVjevOWMjOQfMt8FAl6q0zIACgkQvOWMjOQf
Mt//SAf/bOqQ6RqO9AdvNlJyNpp0WGXSQRo0k5lNQlxGZlTksOe/WDHT30lqKcbN
JN+e/eJb/mg/jCNoqbyETF65cMQR+ZH3twJBfahlhyL/9UWZj1Ip16BU7QHaqAZO
z272riCtXR+KuBXAwFZdE9aUDTmrnSFh5jKbwQvjK7DxU3EIEVPDuxkaG7N+tj5z
QHBRVmOenIEKA+ubnl/C0LXgiKOtb+pJYS+szsCoEATLIAS4PcNo21DhiFU7Dngu
y+uMuygAhjRoOSqN5ZjqczvbH2SpCwBz3vdfIMQ2DRTsZctPpMJepu95T4XywGqh
mLGHvwHDW1o+eu0xq30aeHz7NarlfA==
=nkHh
-END PGP SIGNATURE-

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

Re: [exim-dev] More taint fun (now 4.93.0.4/FreeBSD)

[Jeremy Harris via Exim-dev]

On 25/02/2020 02:15, Larry Rosenman via Exim-dev wrote:
> What's a good work-around for this?

First, check that your distro includes later fixes than that release.
-- 
Cheers,
  Jeremy

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

Re: [exim-dev] Taint Issues: 4.93/FreeBSD port

[Jeremy Harris via Exim-dev]

On 20/02/2020 17:31, Larry Rosenman via Exim-dev wrote:
> I tried to upgrade to 4.93 today, and had to roll back to 4.92.3.

> Help?

exim-4.93+fixes branch
-- 
Cheers,
  Jeremy

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

Re: [exim-dev] Recipient information

[Jeremy Harris via Exim-dev]

On 19/02/2020 20:32, Ygor Fernandes via Exim-dev wrote:
> I have the following doubt, is it possible within acl_check_rcpt, the total
> number of recipients?
> 
> I try to use the variables $ rcpt_count and $ recipients_count but these do
> not have the full value right away, but when forwarded to acl_check_data.

The docs say:

"When a message is being received by SMTP, this variable contains the
number of RCPT commands received for the current message. If this
variable is used in a RCPT ACL, its value includes the current command."

Given that in the rcpt acl you are still receiving the list of
recipients, you cannot have the full list yet so you cannot
know how many the eventual total will be.  On the last call
to the rcpt acl, the value will be the eventual total... but
you cannot know at that point that it will be the last one.

-- 
Cheers,
  Jeremy

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

Re: [exim-dev] SPF not working properly

[Jeremy Harris via Exim-dev]

On 19/12/2019 10:54, David Saez Padros via Exim-dev wrote:
> On the new release i get a lot of spf failures that make me have to
> disable spf.

Thanks for the debug info.  This looks like a variant of
bug 2499.
-- 
Cheers,
  Jeremy

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

Re: [exim-dev] exim-4.93 crash with SMTP AUTH (pam)?

[Jeremy Harris via Exim-dev]

On 10/12/2019 16:54, Fabian Groffen via Exim-dev wrote:
> Exim seems to crash when using SMTP AUTH.  I've reproduced this locally.
> Before I triage any further, is anyone able to use SMTP AUTH (using PAM)
> with 4.93? 

Ugh.  Could a problem with our talking to the PAM library.
Are you up for a one-liner sourcecode change experiment?
-- 
Cheers,
  Jeremy

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

Re: [exim-dev] [Bug 2458] 4.93rc0 - invalid prototypes in local_scan.h

[Jeremy Harris via Exim-dev]

On 24/11/2019 11:07, Magnus Holmgren via Exim-dev wrote:
> Similar but different issue: I just now noticed that smtp_printf(), which is 
> part of the local_scan API, was changed two years ago with the addition of a 
> second, BOOL argument related to pipelining. I'm not sure how to know when to 
> pass true or false. The documentation hasn't been updated.

Arghh.  I'll add a note in docs, but I think we may be too
late to properly (however that's decided) fix it for the upcoming
release.  Heiko is the release master.

(The BOOL is for indicating that further data will be passed
imminently, so the data from this call can be buffered to save
syscalls/packets.  False to write/flush immediately.)

> Maintaining a stable API is *hard*.

As I'm finding :(

Obviously very few people use the API, or care to raise bugs...
or test (preferably early) RCs.  Thanks for doing the latter.
-- 
Cheers,
  Jeremy

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

Re: [exim-dev] dnssec_request_domain router option in default config

[Jeremy Harris via Exim-dev]

On 19/10/2019 12:52, Andreas Metzler via Exim-dev wrote:
> HS/06 Change the default of dnssec_request_domains to "*"
> 
> The default config file still has a (single) explicit
> "dnssec_request_domains = *", though. - That is an oversight, isn't it?

Yes.  No bad effect, but can (and will) be removed).
-- 
Cheers,
  Jeremy

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

Re: [exim-dev] misleading indent

[Jeremy Harris via Exim-dev]

On 19/10/2019 13:26, Andreas Metzler via Exim-dev wrote:
> gcc (correctly) warns about two instances of misleading indentation.

Correctly?  I think not.  Neither is associated with a flow-control;
they are both purely blocks for the restriction of local-variable
scope.  Your suggested changes would break function-head identification
for editors.
-- 
Cheers,
  Jeremy

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

Re: [exim-dev] dnsdb lookup question

[Jeremy Harris via Exim-dev]

On 14/10/2019 12:28, Graeme Fowler via Exim-dev wrote:
> I have a requirement to specify a nameserver for a specific query, using 
> dnsdb. I don't think I can do that without adding the specific nameserver 
> address to /etc/resolv.conf, unless I'm missing some configuration option 
> that's either blindingly obvious or ludicrously esoteric. Unfortunately 
> that's not possible in the specific situation I'm in.
> 
> Am I (missing something) or am I about to head deep into the codebase to work 
> out how to extend the dnsdb code?

You're not missing anything.  Exim just uses the system resolver library
and doesn't currently use any interface to specify a particular
nameswerver.  I don't even know if there is such an API, and I'd
suggest not going looking; the resolver interface is IMHO particularly
badly documented.

Perhaps there's some perl library that does its own dns lookups, not
using the system libraries?  That would be an alternate route, assuming
you're willing to use a ${perl } expansion.
-- 
Cheers,
  Jeremy

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

Re: [exim-dev] Debugging SMTP transport crash

[Jeremy Harris via Exim-dev]

On 27/09/2019 22:03, Florian Weimer via Exim-dev wrote:
> How do I debug this?

First try with debug commandline options.


> Alternatively, I guess I could capture a coredump somehow, but that
> might prove difficult as well due to the use of setuid etc.

Yup.  The /proc setuid-dump things.  One to set the dumpability,
one to set the filename.  And also, ulimit -c.
-- 
Cheers,
  Jeremy

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

Re: [exim-dev] Excursus Retry 451 452 Strategies

[Jeremy Harris via Exim-dev]

On 29/07/2019 15:30, Дилян Палаузов via Exim-dev wrote:
> imagine, a mail envolope contains many recipient,  The server accepts the 
> first recipients and rejects the last
> recipients, meaning “Too many recipients in this transaction”.

> How can Exim be tweaked to retry immediately:
> • Does Exim interpret 4.5.3 anyhow special?

No.

> • Does it handle 451 and 452 differently by default?

Not by default.  However, specific handling can be
done by adding items in the "retry" configuration.

-- 
Cheers,
  Jeremy

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

Re: [exim-dev] proactive exploit mitigation patches

[Jeremy Harris via Exim-dev]

On 25/07/2019 17:16, Ryan Castellucci via Exim-dev wrote:
> I welcome any feedback on these proposed changes.

Without denying the possible value of such restrictions,
a more general protection against this class of exploits
has been developed, and hit the git repo yesterday:

  f3ebb786e Track tainted data and refuse to expand it

-- 
Cheers,
  Jeremy

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

Re: [exim-dev] Use transport_filter

[Jeremy Harris via Exim-dev]

On 25/07/2019 16:01, Ygor Fernandes via Exim-dev wrote:
> It works perfectly, but when I put this question in an IF as below:
> transport_filter = '${if eq{$a}{$b}{/etc/exim/test.sh ${message_id}{}}'
> 
> It always generates the following log back to me:
> transport filter process failed (127): unable to execute command

"The string is parsed by Exim in the same way as a command string for
the pipe transport: Exim breaks it up into arguments and then expands
each argument separately"

-- 
Cheers,
  Jeremy

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

Re: [exim-dev] [exim-announce] CVE-2019-13917

[Jeremy Harris via Exim-dev]

On 25/07/2019 11:01, Fabian Groffen via Exim-dev wrote:
> Is there an ETA for the sources to appear on the download servers?
> I need those in order to update the package for Gentoo.

Should be on the ftp site now; apologies for the delay.
-- 
Cheers,
  Jeremy

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

Re: [exim-dev] Relate Message_ids

[Jeremy Harris via Exim-dev]

On 04/07/2019 15:07, Ygor Fernandes via Exim-dev wrote:
> I would like to know if they could help me, I have an environment where my
> client connects to a server that I call RELAY this authenticates the data
> and then fire the message to the server that I call SEND.
> 
> The sending occurs perfectly well, however I realize that in RELAY after
> sending a message it generates a new ID, this new ID that SEND follows
> using to complete the process of sending the message.
> 
> My need would be to relate these IDs because I work with the database in my
> environment. I can in SEND use the variable, $ message_id, and get the ID
> that is currently running, however I need to relate to the ID that was
> previously used in my RELAY.
> 
> Would you have any suggestions?

A properly-formed message should have a Message-ID: header, and this
will be logged on all the reception lines (ones with "<=") in the "id="
field.  Use this for tracking the message across systems. in logfiles.

If you're wanting to track via some other means that you are coding
in your configuration, use $h_Message-ID:

Naturally, messages that arrive without the header make your life
difficult.  The development tip has some help for this (log_selector
"msg_id_created"), but that probably isn't what you are running.

-- 
Cheers,
  Jeremy

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

Re: [exim-dev] [exim] spool format error: size

[Jeremy Harris via Exim-dev]

On 02/05/2019 23:06, Magnus Holmgren via Exim-dev wrote:
> That code is from SA-Exim, which implements a local_scan() function. What I 
> mean is: is there something wrong with this code, or has something been 
> broken 
> in Exim so that the permanent pool doesn't work?

It looks right per the exim docs.   However, the local_scan facilities
are not something the exim testsuite exercises; quite possibly something
has been broken.  They're also not something I've ever explored.

I doubt the permanent-pool is broken as a general thing; all
sorts of odd things would be visible in general operation.


There's a couple a memory-related debug facilities it might be
possible for you to try:

- a main-section option "debug_store", boolean.
  Set true to add checks on whether any memory being used
  by an active exim $variable is covered by a blob being
  freed.

- run under the test-harness; freed memory is overwritten
  by a distinctive pattern.

-- 
Cheers,
  Jeremy

-- 
## 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

[Jeremy Harris via Exim-dev]

On 29/04/2019 20:06, Graeme Fowler via Exim-dev wrote:
> On 29 Apr 2019, at 19:26, Andrew C Aitchison via Exim-dev  
> wrote:
>> I will do so, either here or in that bug, when I can do so without causing 
>> more heat.
> 
> The gist of the discussion (I’m a mailop subscriber) is manyfold:
> 
> 1. Google accept messages over IPv6 but require stricter verification over 
> IPv6 than IPv4
> 2. mailop.org has no SPF record
> 3. mailop.org can deliver to Google over IPv6
> 4. Signed messages inbound to mailop.org (and other lists!) from 
> Debian-derived and other setups using the default macro defined in pdkim.h 
> can have headers added which have been declared signed when they’re not 
> present*
> 5. Adding them invalidates the signature, and if the MLM software doesn’t 
> remove or re-sign the message, that can be problematic if a receiving system 
> is taking extra care with respect to verification

Bzzt.

Stop right there.

The ML adds body content.  This will invalidate the signature.

The header thing, even if you do game it, will not help that.

> 6. It appears Google will reject messages that combine elements 1 thru 5
> 
> * this is the bit I’m confused by; I have a large historical pile of messages 
> to lists from me and I can’t see a signature with those headers included 
> despite me using the defaults for a long period.
> 
> RFC4871 stated that a suggested list of headers SHOULD be signed, if existing.
> RFC6376 dropped the SHOULD and provided an example of what constitutes the 
> “core” of a message.
> 
> So *either* the Debian-derived configuration (of which the original poster 
> mentioned they were using unaltered for DKIM purposes, inheriting defaults) 
> does something different to what is expected by defaukt, or Exim’s behaviour 
> changed somewhere after 4.86/4.87 (still trying to pinpoint that) but I can’t 
> see or replicate the issue.
> 
> Puzzled, perplexed… and given that this has only just been raised, I’m even 
> more puzzled by it. There must be receivers out there who have insanely 
> strict validation policies who would have seen this before!
> 
> Graeme
> 


-- 
Cheers,
  Jeremy

-- 
## 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

[Jeremy Harris via Exim-dev]

On 29/04/2019 20:33, Brielle Bruns via Exim-dev wrote:
> Heya, original cause of the havoc on mailop here!
> 
> I'll try and answer whatever questions I can.  See below.
> 
> 
> On 2019-04-29 19:06, Graeme Fowler wrote:> So *either* the
> Debian-derived configuration (of which the original poster mentioned
> they were using unaltered for DKIM purposes, inheriting defaults) does
> something different to what is expected by defaukt, or Exim’s behaviour
> changed somewhere after 4.86/4.87 (still trying to pinpoint that) but I
> can’t see or replicate the issue.

4.87 introduced support for oversigning.

> Version: 4.92-2~bpo9+1
> 
> My configuration files are ancient.  IIRC, I originally built them from
> the debian config back around 2005 or 2006 (We've actually been using
> exim since 2003).  They got updated over the years as needed and include
> a bunch of special stuff that is integrated with my DNSbl work.
> 
> So, the DKIM section is based on what I found in Debian's config.  Under
> the remote_smtp transport, I have the following:
> 
> dkim_domain = DKIM_DOMAIN
> dkim_selector = DKIM_SELECTOR
> dkim_private_key = DKIM_PRIVATE_KEY
> dkim_canon = DKIM_CANON

You'll get the default headers signed, then.  That includes signing
the lack-of-presence of a header in the set.

However: it's irrelevant.  The ML adding a header making the signature
bad does not matter.  The ML also appends to the body... making your
signature bad.  That's what signatures are for (I'm sure you know this,
just wanting to be clear in case...)

So.  DKIM signatures do not survive transmission through a ML.
(Sometime phrased as "DKIM breaks mailinglists").

The DKIM RFCs say "do not treat a lack of verifiable DKIM signature as
cause for rejecting a message".  Google is ignoring that, and the
brou-ha-ha is not really, IMHO, Exim's problem.  It's a 800Kg gorilla
problem.

-- 
Cheers,
  Jeremy

-- 
## 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

[Jeremy Harris via Exim-dev]

On 28/04/2019 16:42, Andrew C Aitchison via Exim-dev wrote:
> 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.


Most mailinglists, including mailop, append to the body of submissions
distributed as non-digests, so DKIM signatures will become invalid due
to that (assuming the mostly-deprecated DKIM bodylength feature is not
used).

Trying to game the adding of list headers would be applying lipstick to
a pig.

The snafu is Google's fault for ignoring the part of the DKIM standard
that says "a lack of verifiable signature should not be grounds for
rejection" (my paraphrase, RFC 6376 Section 6.3), and DKIM's fault for
being an enabler of breaking traditional uses of email (mailinglists,
in this case).

-- 
Cheers,
  Jeremy

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

Re: [exim-dev] Bug 2369: single-key lookup type based on libcorkipset

[Jeremy Harris via Exim-dev]

On 26/02/2019 18:23, Ian Zimmerman via Exim-dev wrote:
>   So at least this is a documentation bug.

Notes added; 52af443324 and c77d3d85fe.

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

Re: [exim-dev] Bug 2369: single-key lookup type based on libcorkipset

[Jeremy Harris via Exim-dev]

On 26/02/2019 16:17, Ian Zimmerman via Exim-dev wrote:
> On 2019-02-26 11:21, Jeremy Harris wrote:
> 
>>> And bingo, it seems to not work as documented:
> 
>   devuan-205f!35 exim$ cat strange-iplist
>  "::::::0102:0203" : data
>  ":::102:203" : also_data
>  1.2.3.4 : more_data


>   devuan-205f!38 exim$ ./src/build-Linux-aarch64/exim -C 
> /home/itz/exim/exim.conf -be 
> '${lookup{::::::0102:0203}iplsearch{/home/itz/exim/strange-iplist}{good}{bad}}'
>  bad
>   devuan-205f!39 exim$ ./src/build-Linux-aarch64/exim -C 
> /home/itz/exim/exim.conf -be 
> '${lookup{:::102:203}iplsearch{/home/itz/exim/strange-iplist}{good}{bad}}'
>  bad

The address being looked up, :::102:203, is an ipv6-mapped ipv4
and we'd expect it to match 1.2.2.3 in the file.  But you only have
1.2.3.4


>> So far, I see you giving a dot-group-hex ipv6 to an iplsearch
>> lookup, which is wrong per docs:
>> "key for an iplsearch lookup must be an IP address".
> 
> Huh?  Both commands 38 and 39 (2nd and 3rd from the end in my up thread
> post) try looking up a colon-separated IPv6 address which is present in
> the file -- in fact the same address in both the abbreviated and full
> forms -- and do not find it.

I was looking at your last test, with
......0102.0203

-- 
Cheers,
  Jeremy

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

Re: [exim-dev] Bug 2369: single-key lookup type based on libcorkipset

[Jeremy Harris via Exim-dev]

On 26/02/2019 02:19, Ian Zimmerman via Exim-dev wrote:
> And bingo, it seems to not work as documented:

Which bit are you saying doesn't match docs?

So far, I see you giving a dot-group-hex ipv6 to an iplsearch
lookup, which is wrong per docs:
"key for an iplsearch lookup must be an IP address".

That's distinct from the use of dots in an iplsearch file.
-- 
Cheers,
  Jeremy

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

Re: [exim-dev] Bug 2369: single-key lookup type based on libcorkipset

[Jeremy Harris via Exim-dev]

On 24/02/2019 19:17, Jeremy Harris via Exim-dev wrote:
> I don't know if a lookup done via the list-syntax
>   "hosts = corkipset:/filename"
> will be different.  Probably it will, sigh.

Dots, and always seven.

I tested by adding

   "pipeline_advertised_hosts = net-corkipset;DIR/aux-var/TEST.ipset"

to the config, some "exim -bh" to the script and some
debug_printf() in the code.  I didn't look at actual
results of the lookups though.
-- 
Cheers,
  Jeremy


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

Re: [exim-dev] Bug 2369: single-key lookup type based on libcorkipset

[Jeremy Harris via Exim-dev]

On 24/02/2019 18:52, Jeremy Harris via Exim-dev wrote:
> On 24/02/2019 18:11, Ian Zimmerman via Exim-dev wrote:
>>> I'd expect conversion to unabbreviated form to have been done too.
>>
>> Do you mean I can expect an IPv6 address (mapped or not) to have exactly
>> 7 separators, whatever these might be?  If yes, there is no ambiguity.
> 
> That is my hope.  But hope is all it is.  This is why I say you need to
> test.  And leave the testcases in the testsuite.

I gave in and ran some tests myself.

My optimism was misplaced, but it doesn't matter.  Your code gets
given the raw string from the user; it is _not_ colon-to-dot
translated - it can have any format of ipv6 or ip4 address
(and possibly also just be bogus).

This is with a direct ${lookup } call as per your testcases.

I don't know if a lookup done via the list-syntax
  "hosts = corkipset:/filename"
will be different.  Probably it will, sigh.

More testing needed.
-J

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

Re: [exim-dev] Bug 2369: single-key lookup type based on libcorkipset

[Jeremy Harris via Exim-dev]

On 24/02/2019 18:11, Ian Zimmerman via Exim-dev wrote:
>> I'd expect conversion to unabbreviated form to have been done too.
> 
> Do you mean I can expect an IPv6 address (mapped or not) to have exactly
> 7 separators, whatever these might be?  If yes, there is no ambiguity.

That is my hope.  But hope is all it is.  This is why I say you need to
test.  And leave the testcases in the testsuite.

> 
> I think I must keep in mind 2 cases:
> 
> 1. Addresses coming from exim itself, for example $sender_host_address.
> Unfortunately the spec doesn't say what format this is in (if it is
> IPv6).  Can you enlighten me about this?

That specific expansion returns whatever the library inet_ntop()
does.  The Linux manpage says, for ipv6, "the most appropriate ...
format".  I think that means "abbreviated".  It does note that
ipv6-mapped ipv4 addresses are converted to ipv6, which I assume
means "no dotted tail section" (it lists that as a bug, so it could
change sometime).

> 2. Addresses explicitly written into the configuration by user.  This
> one is about what I can require from users.  I need to document that in
> the experimental documentation file.

I'm hoping it turns out that you can handle all reasonable input
representations with minimal effort, so placing few restrictions
on the user.
-- 
Cheers,
  Jeremy


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

Re: [exim-dev] Bug 2369: single-key lookup type based on libcorkipset

[Jeremy Harris via Exim-dev]

On 24/02/2019 07:47, Ian Zimmerman via Exim-dev wrote:
> On 2019-02-10 23:03, Jeremy Harris wrote:
> 
>> If you can reliably detect the ipv6-ness, yes, that sounds like the
>> minimally intrusive way.
> 
> How are the IPv4-mapped IPv6 addresses written in Exim?
> 
> The straight translation to dots instead of colons would be ambiguous,
> wouldn't it?   Say, ...1.2.3.4 could mean either the mapped address
> or the normal IPv6 address 0:0:0::0001:0002:0003:0004 .

You can write them either way; both are acceptable and the number-base
of the dotted-portion gets translated ( .234 does _not_ become :0234 ).

But that's ipv6 addresses given to exim, not how they are given to
the place you're coding.  I think you need to check, given that a
colon-to-dot translation has been done by the time it hits you.
I'd expect conversion to unabbreviated form to have been done too.
-- 
Cheers,
  Jeremy

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

Re: [exim-dev] Test suite unusable?

[Jeremy Harris via Exim-dev]

On 24/02/2019 02:23, Ian Zimmerman via Exim-dev wrote:
> Do you have a suggestion for the version mismatch?

Ignore it.
-- 
Cheers,
  Jeremy




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

Re: [exim-dev] Test suite unusable?

[Jeremy Harris via Exim-dev]

On 24/02/2019 01:16, Ian Zimmerman via Exim-dev wrote:
>  devuan-205f!2 test$ ls -l aux-fixed/0037*
> -rw-rw-r-- 1 itz eximtest 1660 Feb 23 13:33 aux-fixed/0037.f-1

Thanks!  You found a testsuite bug; the message has been
wrong since I first wrote it (and you're the first to
notice!).  It should say "group".  You presumably are
not running the README guidance of an 022 umask;
fix by "chmod -R g-w aux-fixed".

-- 
Cheers,
  Jeremy

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

Re: [exim-dev] Test suite unusable?

[Jeremy Harris via Exim-dev]

On 23/02/2019 22:44, Ian Zimmerman via Exim-dev wrote:
> the 2nd complaint is probably not a showstopper, but the only
> world-writeable files are as follows:
> 
>  eximtest@devuan-205f:~/exim/test$ ls -lRa aux-fixed/ | grep 'w[-xsS] '
>  lrwxrwxrwx 1 itz eximtest   15 Feb 23 13:33 9ec80de3.0 -> ../../CA/CA.pem
>  lrwxrwxrwx 1 itz eximtest   19 Feb 23 13:33 d89e5358.0 -> ../../CA/Signer.pem

What does "ls -l aux-fixed/0037*" tell you?
-- 
Cheers,
  Jeremy


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

Re: [exim-dev] [Bug 2376] New: log_message doesn't log if connection is interrupted (which is quite unexpected) while other rules in the same acl are applied

[Jeremy Harris via Exim-dev]

On 20/02/2019 12:25, Arkadiusz Miśkiewicz via Exim-dev wrote:
> Is there a way to do ratelimit counting but make it return true, so
> entire acl will fire?

Have a very large limit (so it never exceeds it) and negate the
condition.

I suggest this rather than a zero limit as I cannot recall whether
the first-ever value is zero. You'd need "strict" for that, too.
-- 
Cheers,
  Jeremy

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

Re: [exim-dev] Bug 2369: single-key lookup type based on libcorkipset

[Jeremy Harris via Exim-dev]

On 10/02/2019 22:42, Ian Zimmerman via Exim-dev wrote:
> Turns out the underlying library wants IPv6 addresses colon separated;
> but in contexts where a host address is being tested for list
> membership, exim passes it to the lookup as dot-separated.  This is of
> course documented in the Spec, section 10.12.
> 
> Since IP addresses are the only things worth testing by this lookup,
> maybe I should internally translate them from dot to colon, before I
> pass them to libcork?

If you can reliably detect the ipv6-ness, yes, that sounds like the
minimally intrusive way.
-- 
Cheers,
  Jeremy



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

Re: [exim-dev] Bug 2369: single-key lookup type based on libcorkipset

[Jeremy Harris via Exim-dev]

On 04/02/2019 15:53, Ian Zimmerman via Exim-dev wrote:
> Is there a document about the preferred project style?

I've done a quick writeup here:

  https://github.com/Exim/exim/wiki/Exim-coding-style
-- 
Cheers,
  Jeremy

-- 
## 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

[Jeremy Harris via Exim-dev]

On 13/01/2019 10:06, Дилян Палаузов via Exim-dev wrote:
> Anyway, implementing Sieve’s ereject will make it very easy to do rejecting 
> per recipient without explicit ACLs.  Just
> let the user upload Sieve.

I suggest you try that before implying it will interwork with PRDR.
I don't think it will.
-- 
Cheers,
  Jeremy

-- 
## 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

[Jeremy Harris via Exim-dev]

On 11/01/2019 09:59, Дилян Палаузов via Exim-dev wrote:
> To make progress with PRDR please switch the default for enable_prdr to True. 

Although doing so would be safe (a missing prdr ACL is defaulted to
"accept"), it would be pointless from the point of view of the receiving
end and somewhat disingenuous.  To be useful the admin configuring Exim
has to write ACL code implementing the per-user filters.

I accept that it would publish the facility more widely, perhaps
encouraging the big providers to also implement it.  I'm dubious
if they listen to anything though.

There is a small amount of boilerplate ACL code which I can add
to the example config provided with the Exim distribution.  Perhaps
that will encourage packagers (eg. Debian) to consider supporting
PRDR.  Unfortunately, deciding what you want to support with per-
user filters is not a small task.
-- 
Cheers,
  Jeremy

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

Re: [exim-dev] tls_sni = $host in default configuration file

[Jeremy Harris via Exim-dev]

On 04/01/2019 01:02, Florian Zumbiehl via Exim-dev wrote:
>  may I suggest you put that on the
> website somewhere?

It was already there, at https://bugs.exim.org/enter_bug.cgi
-- 
Jeremy

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

Re: [exim-dev] tls_sni = $host in default configuration file

[Jeremy Harris via Exim-dev]

For the record, if you have a sensitive security issue, please mail
secur...@exim.org

-- 
Cheers,
  Jeremy

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

Re: [exim-dev] Tests with TLS 1.3?

[Jeremy Harris via Exim-dev]

On 24/12/2018 09:54, Andreas Metzler via Exim-dev wrote:> did anybody
yet test exim with TLS 1.3?
> 
> Server side (exim/GnuTLS accepting messages from swaks or mutt) seems to
> work (see header), however I have yet to find a public SMTP server who
> offers TLS 1.3, to test outgoing deliveries.

There aren't any specific tests in the regression suite for TLS1.3 -
but I did have to force a few tests to use 1.2 and make other tolerant
of 1.3-specific output in logs etc.  I think only OpenSSL builds
showed up needing such changes though.

At least we know OpenSSL builds have been seen to talk 1.3 - mail me
offlist if you want to use one of my systems as a target.
-- 
Cheers,
  Jeremy


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

Re: [exim-dev] tls_sni = $host in default configuration file

[Jeremy Harris via Exim-dev]

On 19/12/2018 00:51, Phil Pennock via Exim-dev wrote:
> I think this change is generally useful, in having a cleaner setup for a
> very common use-case, and showing exactly where new macros should be
> defined, which can reduce some of the pain encountered by newcomers to
> Exim.

The wording "should be" could be relaxed slightly, maybe, since it isn't
required by Exim's parsing.  "It is simplest to", perhaps?


I see you quietly removed prdr.  Has it been seen to cause problems?


On multi_domain - some really stupid hosts (hi, Google!) can't handle
it, and will _always_ temp-reject any RCPT after the first domain
(G gives an explicit text error saying it can't hack it).

-- 
Cheers,
  Jeremy

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

Re: [exim-dev] tls_sni = $host in default configuration file

[Jeremy Harris via Exim-dev]

On 16/12/2018 10:20, Andreas Metzler via Exim-dev wrote:
> 4.92rc1 adds this to the smarthost_smtp transport:
> 
> tls_sni = $host
> 
> I do not think that always works as expected. Depending on the DNS setup
> (CNAME, round robin) $host will not contain the name of the selected
> smarthost anymore but a different value.

Phil - that went in at 26739076ae in the example config; could you
comment?
-- 
Thanks,
  Jeremy

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

Re: [exim-dev] [exim] Exim 4.92-RC1

[Jeremy Harris via Exim-dev]

On 14/12/2018 15:24, Paul Hecker via Exim-dev wrote:
> can no longer compile this version with my current Makefile as there is 
> 
> WITH_CONTENT_SCAN=yes
> 
> enabled and all other scanner interfaces disabled (as DISABLE_MAL_CLAM=yes, 
> DISABLE_MAL_AVAST=yes etc.).
> 
> The error at compile-time is
> 
> gcc -DMACRO_PREDEF malware.c
> malware.c:52:2: error: empty enum is invalid
>   } scanner_t;

Thanks for the report; the next RC will have a dummy enum value added
just before that line.

> Getting the following error when disabling the complete WITH_CONTENT_SCAN 
> setting.
> 
> main option "spamd_address" unknown

I can't duplicate this.  Possibly you need a "make clean" before that
"make" ?
-- 
Cheers,
  Jeremy

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

Re: [exim-dev] buildfarm client proposal: tests configure support

[Jeremy Harris via Exim-dev]

On 9/15/18 2:34 AM, Phil Pennock wrote:
> I've pushed to buildfarm-client.git a new branch `test_configure_tuning`
> with one additional commit:
> 
> https://git.exim.org/buildfarm-client.git/shortlog/refs/heads/test_configure_tuning
> https://git.exim.org/buildfarm-client.git/commitdiff/0ce98df83e53cc21a25d98f95e431803a398742c

The code addition looks reasonable on the surface.  Go head and
push it to master.

I'm not going to spend time trying to duplicate your work...
An additional comment in the template, saying exactly what
syntax is needed, would be good.

I'm not going to spend time trying to duplicate your work...
once you're up and running, a potted recipe would be
useful for posterity.  I can't guess how you managed
to do a main exim build without those headers... presumably
you're not limiting yourself to a no-ssl exim (if so,
perhaps we need a no-ssl testsuite build option).
-- 
Cheers,
  Jeremy

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

Re: [exim-dev] [Bug 2311] New: DANE verify fails with a TA-mode TLSA and a selfsigned sever cert

[Jeremy Harris via Exim-dev]

On 9/9/18 5:54 PM, Viktor Dukhovni via Exim-dev wrote:
> This does not appear to be the right description.

https://lists.exim.org/lurker/message/20180904.122640.3cbadefb.en.html

The subject says "self signed".
If it's not expected to work, perhaps you could explain why (on-list,
to the originator)?
-- 
Cheers,
  Jeremy

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

Re: [exim-dev] UTF-8 and Exim string operations

[Jeremy Harris via Exim-dev]

On 08/18/2018 08:38 AM, Heiko Schlittermann via Exim-dev wrote:
> And a new addtional main option
> 
> string_encoding = ascii | utf8  (default: ascii)
> 
> which can then switch ${strlen:…} to be equivalent to ${ustrlen:…}

I'm not particularly happy about global mode-switches.  Too much
scope for "oops!".


Doing it as an option would look like ${strlen/utf8:...}
modulo choice of the option separator.  We don't currently
have any expansion operators that use options, which is
a mark against going that way.
-- 
Cheers,
  Jeremy

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