Re: [exim-dev] Administrivia: this should be munged

[Phil Pennock via Exim-dev]

On 2017-02-05 at 14:43 +, Phil Pennock wrote:
> Mailman on @exim.org should now be DMARC-munging, including for p=none
> domains where failure to munge is a privacy breach.

You know, that would have been a better test if I hadn't used my
@exim.org address for the send.

Hopefully the last spam, folks.

-Phil

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

Re: [exim-dev] DNSSEC / log spam

[Phil Pennock via Exim-dev]

On 2018-06-29 at 20:16 -0500, Larry Rosenman via Exim-dev wrote:
> Greetings,
> I have my DNS Zone DNSSEC enabled, but some of my dynamic
> sub-domains are NOT DNSSEC due to HE.net not supporting DNSSEC yet.
> can we suppress/change exim to not spam the logs with:
> 
> Jun 29 20:12:53 thebighonker exim[37649]: gethostby*.gethostanswer: asked for 
> "borg.lerctr.org IN ", got type "RRSIG"
> Jun 29 20:12:53 thebighonker exim[37649]: gethostby*.gethostanswer: asked for 
> "borg.lerctr.org IN A", got type "RRSIG"

Those messages are being generated by libc, so although it's from the
Exim process, it's not from the Exim codebase.

AFAIK there's nothing we can do from our side, as long as going through
that interface.

I'm guessing that this is a Router using hostname resolution; those all
have options to change how DNS resolution is done, IIRC.  Post on
exim-users if you need help reconfiguring, but it should be setting
route_data/route_list to use `bydns`.  Of course, there might be a
_reason_ to not do that ... in which case, see if you can get libc built
without DEBUG enabled, or comment out the log-message and recompile
libc.

On FreeBSD, it's: /usr/src/lib/libc/net/getaddrinfo.c

-Phil

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

Re: [exim-dev] DNSSEC / log spam

[Phil Pennock via Exim-dev]

On 2018-06-30 at 00:01 -0400, Viktor Dukhovni via Exim-dev wrote:
>  So there is a potential solution, if you're
> willing to change how manage _res.options.

No.  Messing with _res was always dangerous and since NetBSD went and
made incompatible changes, life became hell.

If we're going to do anything more sophisticated, or any surgery at all,
then my inclination would be to rip out all support for _res and libc
DNS handling and go straight to the getdns API.

We're past breaking point on any more vendor stupidity in _res.

-Phil

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

[exim-dev] OpenSSL revamp work (WIP, nowhere near ready)

[Phil Pennock via Exim-dev]

Nowhere near complete yet, but:

  https://git.exim.org/users/pdp/exim.git/shortlog/refs/heads/openssl_revamp
  git://git.exim.org/users/pdp/exim.git   branch openssl_revamp

What's there so far is a WIP commit showing how I think things should
look from a parsing PoV and how the settings are validated and a
function to apply the settings to an SSL_CTX* or SSL*.

This has not been compiled.  There are probably syntax bugs.
There are no new tests.
There are no documentation changes.
The new functionality is not used anywhere.

This does, however, show roughly how things will look, I think.
All of the above missing pieces will come, with time.  Before I merge to
master.

One change from my original proposal: we're using the usual Exim "key =
value" syntax, rather than just "key value".

I abstracted out a couple of names so that they could be stubbed in with
our own logic for backwards compatibility with LibreSSL but there's a
whole bunch of flags which are _not_ in our namespace, so I don't think
that's going to work so well.  My initial focus is on working with
OpenSSL 1.0.2/1.1.0/1.1.1.

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

Re: [exim-dev] [Bug 2235] New: CVE-2018-6789

[Phil Pennock via Exim-dev]

On 2018-02-09 at 15:32 +, Vsevolod Stakhov via Exim-dev wrote:
> It seems that FreeBSD is no longer considered in CVE early disclosure,
> isn't it?

There has been no change from Exim's side in how this was communicated.
We have an exim-maintainers mailing-list which has vetted people from
any interested OS project as members and that list received early
notification.  I strongly suspect that the OpenWall distros mailing-list
received early notification (but am not on that list and haven't asked
Heiko; I only saw the public notifications on oss-security later).

Our process is documented at:
  https://github.com/Exim/exim/wiki/SecurityReleaseProcess

So: we have a documented process, we have resources for OS folks to use,
nothing has changed here.  If FreeBSD had missed the notification, then
that's unfortunate.  I don't think I've done anything special in the
past to notify you beyond our documented process.  If I did, then that's
on me for not documenting it for Heiko (or having any recollection of it
now).

What would you like us to have done differently?
-Phil


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

[exim-dev] Bugzilla maintenance (security upgrade); old mail sent

[Phil Pennock via Exim-dev]

Bugzilla had a security release today; I have upgraded bugs.exim.org to
4.4.13.

Part of the pre-flight checklist involved running a sanity check, which
found two bugs with unsent mail.  I sent those mails out.  This sent out
messages dated 2017-03-07 for bugs 1294 and 1998.

Sorry; if I'd known they were so old, I'd have nuked them instead (if I
could figure out a sane and safe way to do so).

We're all back and running fine now.

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

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

[Phil Pennock via Exim-dev]

Anyone have strong feelings on how Exim should handle UTF-8 with
operators such as ${length_1:STR} ?

Document that the current operators work on bytes and add ulength_1 for
being UTF-8 aware?  Look at the top-bit being set and assume UTF-8, or
will that break too much with all the places which are still ISO-8859-1?

-Phil

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

[Phil Pennock via Exim-dev]

On 2018-08-17 at 10:36 -, Jasen Betts via Exim-dev wrote:
> > and add ulength_1 for being UTF-8 aware?
>
> Would also need utf8-aware also substr and strlen.

Yes, I was using length as an exemplar, not as an exhaustive list.  :)

I favored ulength too, but didn't want to just add a slew of new
expansion operators, items and conditions without at least mentioning it
somewhere first.

> is it going to count code-points or glyphs?

Code-points.  Exim has no business knowing about how a layout engine
might or might not choose to render code-points to glyphs.  I could see
a possibility for normalization handling as another function, for
correct SASLprep for authentication.

I'd really rather not, though.  Exim is setuid root and the main system
for handling such things, ICU, does lots of tricky sensitive stuff with
a history of security problems.

> > Look at the top-bit being set and assume UTF-8, or
> > will that break too much with all the places which are still ISO-8859-1?
> 
> Just looking at that bit won't tell you enough to count code-points or
> glyphs.

I know, this was a suggestion for determining if the string should be
treated as UTF-8 for changing the current expansion o/i/c features; it
sucks but it was the only viable alternative I could think of and I
wanted to at least present an _idea_ of something else, for inciting
feedback.

I know a fair bit about UTF-8 internals and how to work with the various
aspects in multiple programming languages. :)

> parts of ${utf8clean can probably be re-used.

Yes, I thought of that, when pondering a new `utf8valid` expansion
condition.

> "${lc" "${uc" and "${if eqi" need consideraton too

Only if we go the ICU route and include normalization forms.  Which ...
is more bloat than I'm happy with in Exim's current architecture.

-Phil

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

[exim-dev] build-farm / macOS

[Phil Pennock via Exim-dev]

For awareness,

I've applied on behalf of Exim to
 to get a free VM to be used as
a build animal.

If we're approved, we'll get rote paperwork every six months to confirm
that we're actually still using it.

I'd like to get macOS/Darwin builds back on the officially supported
list.

Regards,
-Phil

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

[exim-dev] GnuTLS 3.6.3 / TLS 1.3

[Phil Pennock via Exim-dev]

FWIW, if anyone is working on the GnuTLS integration these days:

} From: Nikos Mavrogiannopoulos
} Subject: gnutls 3.6.3
}
} Hello,
}  I've just released gnutls 3.6.3. This is the first release which adds
} full support of TLS1.3 (draft28), and several other features on the
} 3.6.x branch.
}
} * Version 3.6.3 (released 2018-07-16)
}
} ** libgnutls: Introduced support for draft-ietf-tls-tls13-28. It includes 
version
}negotiation, post handshake authentication, length hiding, multiple OCSP 
support,
}consistent ciphersuite support across protocols, hello retry requests, 
ability
}to adjust key shares via gnutls_init() flags, certificate authorities 
extension,
}and key usage limits. TLS1.3 draft-28 support can be enabled by default if
}the option --enable-tls13-support is given to configure script.
[...]


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

Re: [exim-dev] [Bug 2266] TLS SNI should default set

[Phil Pennock via Exim-dev]

On 2018-04-20 at 19:16 -0400, Viktor Dukhovni via Exim-dev wrote:
> In Postfix we have a notion that is the "next-hop" domain,
> which is normally the envelope recipient domain, but when
> a smarthost (or domain whose MX records are used for routing)
> is specified, then the next-hop domain is the smarthost.
> 
> This provides a "secure" name for TLS policy lookup, and is
> not subject to insecure DNS downgrades.  This is available
> for peer name matching, and will also be available for 
> client-side SNI when I get that implemented (shortly).
> 
> Is there anything similar in Exim?

Yes: when you define a "smarthost" Router, you use "manualroute" as the
driver, and choose the Transport to go with it.

It's absolutely reasonable and normal in Exim to:

1. Have two similar Transports, referenced by different drivers (you can
   use one with expansion options but that can increase complexity,
   often it's most maintainable to have a clean separation)
2. Define a remote_smtp_smarthost Transport which just sets
"tls_sni = $host" in that case.

None of which is deriving an insecure value from DNS.  But yes this does
complicate the issue of "default", since it's a minor layering violation.

I think then that, to minimize insecure configs, we should:

A. Set the default tls_sni to be $domain, accept the layering issue.
B. Update the default supplied Exim configuration to set tls_sni in the
   smarthost example
C. Include a warning in README.UPDATING about the change and encouraging
   people to make the change for smarthost configuration, explicitly
   noting that this is a safe change to make before upgrading.

-8< untested exim fragments >8--
begin routers

smarthost:
  driver = manualroute
  domains = ! +local_domains
  transport = remote_smtp_smarthost
  route_data = smarthost.isp.example
  no_more

begin transports

remote_smtp_smarthost:
  driver = smtp
  hosts_require_tls = *
  tls_sni = $host
  tls_require_ciphers = something:stronger:than:normal
-8< untested exim fragments >8--


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

Re: [exim-dev] [Bug 2266] TLS SNI should default set

[Phil Pennock via Exim-dev]

On 2018-04-20 at 20:09 -0400, Viktor Dukhovni via Exim-dev wrote:
> Question about this "$host".  Are smarthost settings ever subject to
> MX lookups, so that the actual remote SMTP server is one of the MX
> hosts of the smarthost domain?

Not with the format specified in the example configuration.  It would
require explicit configuration action to subject them to MX.

The SMTP Transport is given a list of valid hostnames to try.  It knows
nothing about MX lookups.

The `dnslookup` Router driver knows about MX lookups and is how they're
normally done.  Here though, we're using the `manualroute` Router
driver.



It's possible to follow the specified hostname with `/MX` to enable MX
lookups.  That doesn't make much sense for smarthost.  We can consider
adding some text explicitly warning people against that.

-Phil

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

Re: [exim-dev] Preliminary dane_require_tls_ciphers support

[Phil Pennock via Exim-dev]

On 2018-03-29 at 10:33 +0100, Jeremy Harris via Exim-dev wrote:
> I'm unsure about the philosophy of the interface; having one option
> override another.  You mentioned "complex expansions" before in the
> discussion but without detail.  I assume that's the same consideration
> as "lots of conditional logic" above.  Was that discarding the solution
> of dnsdb-lookup expansions selecting values for the original
> tls_require_ciphers option?

We already just ignore so many TLS options when DANE is determined to be
in effect, so it seemed cleanest to make it easier to have a different
option, both for the code-base and for postmasters maintaining configs.
Otherwise, we're looking at a new variable exposed once DANE is seen.

The Exim on my laptop has remote_smtp using:

  tls_require_ciphers = ${extract{tlshigh}{$address_data}{${if 
eq{$value}{yes}{TLS_CLIENT_HIGHSEC_CIPHERSPEC}{TLS_CLIENT_DEFAULT_CIPHERSPEC}}}{TLS_CLIENT_DEFAULT_CIPHERSPEC}}

(full transport at end)

There, `tlshigh` is a possible key from a "K1=V1 K2=V2 K3=V3" list
populated from other sources, letting me say "gmail.com: tlshigh=yes"
and so forth.

Clearly, I am capable of changing that to use a variable, but ... this
is security, and complexity is the enemy of security.  If we require
everyone to do this, then an uncomfortably large percentage of installs
will get it wrong.

If we say "DANE will use this other option by preference, just set that
to something strong", that's much harder to get wrong.  We can have an
easy win for most people, while those who want manually
configured/derived per-domain properties can continue to do so.

It's a judgement call, but I think here, DANE-specific is the way to go.
Off-list, there was a suggestion of renaming it to not mention DANE but
be for whenever TLS is mandatory.  I think leave that for a future
reconfig, because at present the Exim way would be to either have two
Routers, with distinct smtp Transports, with different TLS configs on
the two transports, the "hosts_require_tls = *" one requiring better
ciphers, or to use address_data for dynamic property binding, as I do.

> I'd prefer testing was in place before merge if at all possible.
> Certainly in place before it hits a release.

We have improved here, mostly thanks to you.  Thank you.  :)

> I'll have a go, planning to push into the dane_require_tls_ciphers
> branch.

Thanks!
-Phil

---8< pdp laptop exim remote_smtp >8
remote_smtp:
  driver = smtp
  port = ${extract{port}{$address_data}{$value}{25}}
  hosts_require_auth = ${extract{authreq}{$address_data}{${if 
eq{$value}{yes}{*}{$value}}}{}}
  hosts_require_tls = ${extract{tls}{$address_data}{${if 
eq{$value}{yes}{*}{$value}}}{}}
  hosts_avoid_tls = ${extract{tls}{$address_data}{${if eq{$value}{no}{*}{}}}{}}
  tls_sni = ${extract{tlssni}{$address_data}{$value}{}}
  tls_require_ciphers = ${extract{tlshigh}{$address_data}{${if 
eq{$value}{yes}{TLS_CLIENT_HIGHSEC_CIPHERSPEC}{TLS_CLIENT_DEFAULT_CIPHERSPEC}}}{TLS_CLIENT_DEFAULT_CIPHERSPEC}}
  tls_verify_certificates = 
${extract{tlsverify}{$address_data}{/usr/local/etc/openssl/certs}fail}
  hosts_try_dane = *
  dane_require_tls_ciphers = TLS_CLIENT_HIGHSEC_CIPHERSPEC
  no_multi_domain
  no_delay_after_cutoff
  helo_data = ${extract{helo}{$address_data}{$value}{$primary_hostname}}
  hide socks_proxy = ${extract{socks}{$address_data}{<; 8

8< pdp laptop smtp client TLS macros >8-
TLS_CLIENT_DEFAULT_CIPHERSPEC=DEFAULT:!SSLv2:!LOW:aNULL:!eNULL
TLS_CLIENT_HIGHSEC_CIPHERSPEC=TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:!3DES:!DSS:!aNULL:!eNULL
8< pdp laptop smtp client TLS macros >8-

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

Re: [exim-dev] Exim 4.91 RC1

[Phil Pennock via Exim-dev]

On 2018-03-18 at 00:47 -0400, Viktor Dukhovni via Exim-dev wrote:
> You may find the notes for the below commits to OpenSSL 1.1.0 and upcoming
> 1.1.1 useful for building alternate versions of OpenSSL "on the side":
> 
> https://github.com/openssl/openssl/commit/822b5e2645a99bea15329bd66c9723c7e7119cdb
> https://github.com/openssl/openssl/commit/e6f38fb817d831ed093f7d7140325783b5556d8f

Thanks, but I'm hoping that's unnecessary.  For ours, the only concern I
had was libmysqlclient, used for Bugzilla integration, but that doesn't
reference openssl.  So the existing Exim hints on installing OpenSSL
have worked to date and I'd hope they'd continue to work: if they break,
that would be a frustrating regression.

https://git.exim.org/exim.git/blob/HEAD:/doc/doc-txt/openssl.txt

This is what we supply to postmasters as documentation and is designed
to play nice with OpenSSL's policies, while dealing with people
complaining about Exim breaking support for OpenSSL 0.9.8 or whatever.
(I think we're still probably compatible, but it's absolutely not a bug
if we break compatibility).

The only thing I'd really like is for pkg-config to support RPATH
stamping sanely, without our needing the additional override. :)

-Phil

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

Re: [exim-dev] Exim 4.91 RC1

[Phil Pennock via Exim-dev]

On 2018-03-17 at 15:00 +, Jeremy Harris via Exim-dev wrote:
> >  Enabling DMARC without enabling
> >SPF led to a build failure almost at the very end.
> 
> Compile-time or link-time failure?   Do you think we need
> a specific check early in the build?

I think it was compile-time, but am not 100% sure.  I did also have a
link-time failure, but that was my fault and led to my commit to
openssl.txt: the EXPERIMENTAL_DMARC coming above the TLS config meant
that using `LDFLAGS=` instead of `LDFLAGS+=` stomped on the DMARC
library.  Oops.

Shame there's no `.pc` file for opendmarc.

Oh: any preferences around OpenSSL 1.1.X for exim.org box?  We currently
"drink our own champagne" when it comes to advice around OpenSSL
libraries and deprecation, with 1.0.2n in /opt/openssl/.

I'm tentatively thinking that we can wait for OpenSSL 1.1.1 to reach
Beta status, then have /opt/openssl111/ for that, and have port-25 Exim
use 1.0.2 and port-26 Exim use 1.1.1, just skipping 1.1.0 entirely.  But
I've not been doing the recent maintenance work on TLS in Exim, you
have, so I'll (probably) defer to your preference here.

-Phil

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

Re: [exim-dev] Exim 4.91 RC1

[Phil Pennock via Exim-dev]

On 2018-03-15 at 21:31 +, Jeremy Harris via Exim-dev wrote:
> I have built and uploaded Exim 4.91 RC1 to:
> 
> https://ftp.exim.org/pub/exim/exim4/test/

Building for `next-exim` on the exim.org box, the port-26 listener:

 * `EXPERIMENTAL_ARC` is not given with `=yes` in `src/EDITME`, which is
   inconsistent at least
 * First build attempt failed:

---8< first build attempt failure >8
gcc malware.c
malware.c: In function ‘malware_init’:
malware.c:2150:6: error: ‘ava_re_clean’ undeclared (first use in this function)
 if (!ava_re_clean)
  ^
malware.c:2150:6: note: each undeclared identifier is reported only once for 
each function it appears in
malware.c:2151:37: error: ‘ava_re_clean_str’ undeclared (first use in this 
function)
   ava_re_clean = regex_must_compile(ava_re_clean_str, FALSE, TRUE);
 ^
malware.c:2152:6: error: ‘ava_re_virus’ undeclared (first use in this function)
 if (!ava_re_virus)
  ^
malware.c:2153:37: error: ‘ava_re_virus_str’ undeclared (first use in this 
function)
   ava_re_virus = regex_must_compile(ava_re_virus_str, FALSE, TRUE);
 ^
malware.c:2156:6: error: ‘fprot6d_re_error’ undeclared (first use in this 
function)
 if (!fprot6d_re_error)
  ^
malware.c:2157:41: error: ‘fprot6d_re_error_str’ undeclared (first use in this 
function)
   fprot6d_re_error = regex_must_compile(fprot6d_re_error_str, FALSE, TRUE);
 ^
malware.c:2158:6: error: ‘fprot6d_re_virus’ undeclared (first use in this 
function)
 if (!fprot6d_re_virus)
  ^
malware.c:2159:41: error: ‘fprot6d_re_virus_str’ undeclared (first use in this 
function)
   fprot6d_re_virus = regex_must_compile(fprot6d_re_virus_str, FALSE, TRUE);
 ^
make[1]: *** [malware.o] Error 1
make[1]: Leaving directory `/root/src/exim-4.91_RC1/build-Linux-athlon'
make: *** [all] Error 2
---8< first build attempt failure >8

   + I had disabled most of the scanners as unnecessary, since we use
 just one.  I left just SOPHIE/CLAM/SOCK/CMDLINE un-disabled.
   + I commented back out: `DISABLE_MAL_FFROT6D=yes`,
 `DISABLE_MAL_AVAST=yes` and the code compiled.
 * While the `DISABLE_DNSSEC=yes` option has the comment `Enabling
   SUPPORT_DANE unconditionally overrides this setting.`, other options
   are "you must have this other thing turned on or build will fail",
   which might be worth reconsidering.  Enabling DMARC without enabling
   SPF led to a build failure almost at the very end.

If you can see this message, then mail is flowing through Exim 4.91-RC1
(not yet configured to use the DMARC support).

-Phil

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

Re: [exim-dev] "25 lost" is giving me useful clues

[Phil Pennock via Exim-dev]

On 2018-08-30 at 12:27 +0200, Mark Elkins via Exim-dev wrote:
> What this is telling me is someone at 157.0.116.189 is making
> connections to my mail server - presumable to see if they can detect the
> accounts of users on my machine?

This really belongs on exim-users, not exim-dev (bcc'd) because it's not
about the development of Exim itself.

What else do the logs show?  It could just be network reliability issues
or dumb clients which don't send QUIT and instead just drop connections.

The following not-enabled-by-default `log_selector` options might be of
interest:

 smtp_connection  incoming SMTP connections
 smtp_incomplete_transaction  incomplete SMTP transactions
 smtp_no_mail session with no MAIL commands
 smtp_protocol_error  SMTP protocol errors
 smtp_syntax_errorSMTP syntax errors

Eg, `smtp_no_mail` will add a log-line for connections which are ended
without an SMTP mail transaction.  Thus my monitoring probes for DANE
log (censored):

2018-09-03 00:09:00 [19598]
  no MAIL in SMTP connection from XYZ (smtpdane.invalid) [2001:db8::1]:35490
  I=[2001:db8::2]:25 D=0s
  X=TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256 CV=no SNI="mx.spodhuis.org"
  C=EHLO,STARTTLS,EHLO,QUIT

Without more detail, you can't assert what the cause or reason for
non-QUIT connections might be.

-Phil

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

[Phil Pennock via Exim-dev]

On 2018-09-21 at 00:15 +0200, Heiko Schlittermann via Exim-dev wrote:
> Heiko Schlittermann via Exim-dev  (Mi 19 Sep 2018 11:46:52 
> CEST):
> > I'll do so this evening (roughly UTC).
> Almost ….
> 
> I made the changes, pushed it and pulled it into macstadiums
> /opt/buildfarm/home/code and started ./invoke.buildfarm
> 
> But I do not see how you use test_configure_env or test_configure_args
> in your build-farm.cnnf.

I can't reach the box right now :\  Did you do anything like reboot it?
Otherwise, it's support ticket time if it doesn't come back.

Going from memory: the normal location is assignment within a hash, and
I couldn't remember the guarantees around order of assignment and
referencing other keys in the hash while still constructing the hash; so
if you look just _below_ the normal declaration, there's a small block
of statements which populate those keys.  Feel free to improve as you
see fit, since you touch the test suite far more often than I do.

-Phil

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

[Phil Pennock via Exim-dev]

On 2018-12-20 at 20:50 +, Jeremy Harris via Exim-dev wrote:
> The wording "should be" could be relaxed slightly, maybe, since it isn't
> required by Exim's parsing.  "It is simplest to", perhaps?

Didn't we used to require it?  I forget.  Feel free to update it.

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

No: I removed a documentation claim which was false.

The spec.xfpt doc claimed that the configure.default file included
"hosts_try_prdr = *" on the remote_smtp Transport.  That was not
present.  I can find no evidence that it has ever been present.
(`git log --patch src/src/configure.default` and search for
`hosts_try_prdr`)

So I made the documentation consistent with reality.

If you want PRDR in the default config, talk with Heiko then go ahead
and add it, to the config and the docs both?

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

Might be worth calling out in a comment?  Or comment-out the directive
and include it as a suggestion for "If your smarthost is able to do so."

I thought, but could well be wrong, that Google did as you say for their
listening MX services, but not for Submission services.  For MX, it
makes some sense when you have per-domain policies on spam-handling and
no good way to handle (without PRDR) what should be done there.  For
Submission, enforcing a single domain per message strikes me as ...
Quirky.  At best.

-Phil

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

[Phil Pennock via Exim-dev]

On 2018-12-16 at 10:42 +, Jeremy Harris via Exim-dev wrote:
> 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?

I think that I just missed that we might adapt `$host` during the life
of the Transport.


30.2

Absent `hosts_override` or `hosts` directly on the Transport, Round
Robin A records have no cause to change the host _name_.  So the only
issue should be CNAME records?

If we're changing `$host` based upon CNAMEs in DNS, then yes this will
do The Wrong Thing.  It might be a security problem then, because the
normally-insecure DNS changes the name we validate the certificate
against.  We can't rely upon DNSSEC for this default example config.

It's an example, which can be fixed, so it's not major.  This isn't the
built-in default for the option, but the default example configuration.

Short of messing with `$address_data`, the only fix I can immediately
think of would be to record `$router_host` or `$original_host` as the
value of `$host` when the Transport is entered, and then make that the
configured example.  That's some more coding changes.

Is this enough of a problem in real world scenarios to be worth the
coding work?  More code for hypothetical problems is complexity to debug
and maintain.  I'm inclined to have our example configuration gently
push back against that and encourage people to reduce CNAMEs, or accept
that this will require explicit configuration.

But this is a taste issue; if it's a big problem then I strongly suspect
we'll accept a codebase patch upstream to add `$router_host` and use
that as the example config default, or some other appropriate solution
if someone spots something good which I've missed.  Which is possible,
because I missed the CNAME issue at the time.

The cop-out would be to change to using a macro at the top of the file,
`SMARTHOST_NAME`, and .ifdef guards to define the Router only if that
macro is defined, and then reuse `SMARTHOST_NAME` as the default for
`tls_sni`.  That would be more secure, but perhaps a little harder to
talk people through changing.  But hey, we can uncomment the Router by
default, in that case.  Just leave the macro commented-out by default.
So a small win?

Hrm.  Perhaps the macro approach for the imminent release, and consider
a new variable for the next release?  Heiko's discretion at this point.

-Phil

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

[exim-dev] Exim website: logos for testers

[Phil Pennock via Exim-dev]

Folks,

I'm setting up macOS buildfarm stuff for Exim using hosting provided for
free by MacStadium.  They ask that their logo be on our web
landing-page, which seems eminently fair and "normal practice" to me.
But at present, there are no such logos.

The fix is to say: if you are providing a member of the buildfarm for
Exim testing and would like your company/organization logo in the
credits, please reply in-thread here.  Replying publicly will help
encourage others and will make sure there's no stuff hidden up sleeves.

Please keep it "well under" 100KiB and let's aim for "probably around
150px wide"; web design gurus can correct me with better guidance for
what's "normal" I'm sure.

We will require the logo to be hosted within our website; no third-party
tracking allowed.  The files get committed into our git repo for the
website.

Thanks,
-Phil, making up shiny new policy on the fly based solely upon "seems
   reasonable, let's make it fair for everyone; if I'm wrong, folks
   can figure out a better approach later".


For reference, `mac-stadium-logo.png` is 54KiB and 600x244; I'm choosing
to believe that this is retina-scaled :) and so am shrinking it to
something "tasteful and proportionate such as to be more likely to
engender good-will in our community".

$ convert -resize 150x mac-stadium-logo.png mac-stadium-logo-small-x.png
$ zopflipng -m mac-stadium-logo-small-x.png mac-stadium-logo-small.png
$ ls -ld mac-stadium-logo*
-rw-r--r--  1 pdp  staff   8019 Sep 14 14:03 mac-stadium-logo-small-x.png
-rw-r--r--  1 pdp  staff   6313 Sep 14 14:04 mac-stadium-logo-small.png
-rw-r--r--@ 1 pdp  staff  55443 Sep 14 13:32 mac-stadium-logo.png

6KiB and 150x61px should be good.


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

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

[Phil Pennock via Exim-dev]

I've made the buildfarm repos visible† on git.exim.org since there's
nothing secret in them and we point folks to them on public wiki pages,
and all the repos can be cloned without authentication.

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

This is the code currently running on macstadium.testing.exim.org and
"something like this" was needed to get tests to run.  macOS lacks
OpenSSL headers, so I installed OpenSSL (1.1.1) via HomeBrew
(with `brew install openssl@1.1`).  This is not in the normal paths, to
avoid interfering with System OpenSSL (actually LibreSSL).

The first pass was just messing directly with %ENV in the client config,
but that will leak into the Exim build steps, which I was Reluctant to
leave in place.  So after getting some tests to pass the first time,
this is the change I made to have something with better isolation moving
forward.

I think this should be reviewed by someone more regularly involved in
the buildfarm and merged if acceptable, rather than my just pushing to
master.

-Phil

† /etc/gitweb.conf sets `$projects_list = "/home/git/.index.aux";` and
  that file can be replaced by anyone with a user account on the server

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

[Phil Pennock via Exim-dev]

On 2018-09-16 at 12:49 +0100, Jeremy Harris via Exim-dev wrote:
> The code addition looks reasonable on the surface.  Go head and
> push it to master.

I'm going to let Heiko make his suggested improvements.

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

PKG_CONFIG_PATH defined in Local/Makefile instead.


On 2018-09-17 at 10:17 +0200, Heiko Schlittermann via Exim-dev wrote:
> This should have the same result, but is more reliable in restoring the
> old %ENV when leaving the scope.

If there had been an exception option, yes.  Frankly, the problem here
is that I haven't written new Perl in 10+ years so have forgotten many
of the idioms.  I loathe letting things inside other languages go near
shell, but wanted to minimise the scope of changes, so went for escaping
instead.

Your proposals all look sane to me.  Please go ahead and fix.

I've also just sorted out access to the Mac Mini testing box for you
Heiko; I'll email you details off-list.

-Phil

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

[Phil Pennock via Exim-dev]

On 2018-12-17 at 18:44 -, Jasen Betts via Exim-dev wrote:
> What does DANE say we shoud ask for? I remember it being non-obvious but
> easily explained. However I don't however remember the detail.

RFC 7672 section 2.2.2.

If DNSSEC is available for every step along the way, for all CNAMEs in
the chain, then the final target.  Otherwise, only the original name.

On 2018-12-17 at 19:57 +0100, Andreas Metzler via Exim-dev wrote:
> I only recognized the problem because we have had to workaound/document
> around it in Debian for ages. - We have been using ${lookup{$host} in
> smtp authentication.
> 
> CNAME for smarthost is very common, the biggest players (office365,
> gmail and yahoo) use it.

Heiko: I've pushed a new branch to the main repo: "ifdef_smarthost".

As well as making the recommended change, it adds a few more comments
and brings the documentation up-to-date.  I recommend merging this in
the RC series, rather than trying to add new code features after RC
start.

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.

I've built spec.pdf locally, it seems sane when I look at the areas
I just changed.  Hrm, perhaps some different wording now makes sense for
the start of the main configuration docs after the new macros text?

We'd probably want to explicitly warn packagers, because of default
config rewrites done by some packaging systems (FreeBSD comes to mind).

-Phil

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

[Phil Pennock via Exim-dev]

On 2019-04-28 at 16:42 +0100, Andrew C Aitchison via Exim-dev wrote:
> Do the DKIM exim experts subscribe to the mailop list ?

I do, but I just started a new job and am behind on public
mailing-lists.

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

It looks like an instance of this:

  https://bridge.grumpy-troll.org/2014/04/dmarc-stance/

but for p=none, not p=reject.  It's been five years since I wrote that.
DMARC breaks mail for domains sending non-transactional non-bulk mail,
becauase DMARC breaks mailing-lists.

The only "out" is to implement ARC and hope that the receiving domain
does too.  Gmail does, but you need to send enough mail for them to
decide to trust you as an ARC sender.

For the @exim.org mail-hub, we run with

8< exim.conf snippets >8
# This file is renewed daily by cron as user _exim:
.ifdef _HAVE_DMARC
dmarc_tld_file = /var/cache/exim/opendmarc.tlds
.elifdef _HAVE_ARC
dmarc_tld_file = /var/cache/exim/opendmarc.tlds
.endif

### ACLS section

acl_check_content:
  # Outbound ARC-sign is disabled by default because people can auth to us
  warn  set acl_m_should_arcsign = false

  # Do add Message-ID: and Date: headers
  warn  condition = ${if !def:h_Message-ID: {1}}
message = Message-ID: 
  warn  condition = ${if !def:h_Date: {1}}
message = Date: $tod_full

  # If there's an AAR (ARC-Authentication-Results) header which claims to be
  # from us, but we're not receiving the mail from Mailman or other local
  # system or authenticated user, then we consider it to be fraudulent or a
  # mail-loop.
  #
  # We need to allow authenticated users for when someone is bouncing onwards
  # a received message; OUTSIDE->exim.org->f...@exim.org, reads, bounces
  # onwards for processing elsewhere, but being sent from f...@exim.org gets
  # routed back via us (for DKIM/SPF alignment), so we appear in the AAR
  # headers already.
  #
  # Does not need to be _HAVE_ARC-guarded, this is pure Exim logic and safe
  # even when we're not signing.
  deny  message= Mail-loop or fraudulent headers: found ourselves in 
ARC-Authentication-Results:
!hosts = +relay_from_hosts
!authenticated = *
condition  = ${if def:h_ARC-Authentication-Results: {yes}}
condition  = ${if inlist{ADMD}{<; $h_ARC-Authentication-Results: }}

  warn  hosts = <;  ; 127.0.0.1 ; ::1
condition = ${if def:h_X-Exim-Org-Should-ARC-Sign: {yes}}
set acl_m_should_arcsign = $h_X-Exim-Org-Should-ARC-Sign:
remove_header = X-Exim-Org-Should-ARC-Sign

  # Bypass the content scanning for stuff injected from mailman etc
  accept  hosts = <;  ; 127.0.0.1 ; ::1

### THERE ARE MORE STEPS HERE IN THIS ACL (unrelated to ARC)

  # list stuff & authenticated
  accept  hosts = +relay_from_hosts
  accept  authenticated = *

  # Insert DMARC headers for non-authenticated non-local senders
  warndmarc_status   = accept : reject : quarantine : none : norecord : 
nofrom : temperror : off
  log_message= DMARC DEBUG: $dmarc_status $dmarc_used_domain
  warncondition  = ${if !eq{$dmarc_status}{accept}}
  log_message= DMARC DEBUG: not-accept '$dmarc_status' for 
$dmarc_used_domain
  warncondition  = ${if eq{$dmarc_status}{quarantine}}
  set acl_m_quarantine = 1
  denycondition  = ${if eq{$dmarc_status}{reject}}
  message= Message from $dmarc_used_domain failed sender's 
DMARC policy, REJECT

.ifdef _HAVE_ARC
  # and ARC chaining
  warnverify = arc/pass:none:fail
  logwrite   = ARC: state=<$arc_state>${if def:arc_state_reason{ 
reason=<$arc_state_reason>}}
.endif

### TRANSPORTS SECTION

remote_smtp:
  driver = smtp
  rcpt_include_affixes
  # hosts_try_chunking =
  dnssec_request_domains = *
  hosts_try_dane = *
  tls_require_ciphers = TLS_OUTBOUND_DEFAULT
  dane_require_tls_ciphers = TLS_OUTBOUND_HIGHSEC
  dkim_domain = ${domain:$sender_address}
  dkim_selector = ${lookup 
{$dkim_domain}lsearch{/etc/exim/dkim/domains-mapping} {$value}{SKIP}}
  dkim_private_key = ${if 
eq{$dkim_selector}{SKIP}{false}{/etc/exim/dkim/rsa.private.$dkim_selector.$dkim_domain}}
  dkim_strict = 1
.ifdef _HAVE_ARC
  arc_sign = ${if bool{$acl_m_should_arcsign}{${lookup 
{ADMD}lsearch{/etc/exim/dkim/domains-mapping}{ADMD : $value : 
/etc/exim/dkim/rsa.private.$value.ADMD }fail}}fail}
.endif

.ifdef WANT_MAILMAN
mailman_transport:
envelope_to_add
driver = pipe
command = MM_WRAP \
  '${if def:local_part_suffix \
{${sg{$local_part_suffix}{-(\\w+)(\\+.*)?}{\$1}}} \
{post}}' \
  $local_part
headers_add = X-Exim-Org-Should-ARC-Sign: $acl_m_should_arcsign
current_directory = MM_HOME
home_directory = MM_HOME
user = MM_UID
group = MM_GID

.endif
8< exim.conf snippets 

Re: [exim-dev] dnsdb lookup question

[Phil Pennock via Exim-dev]

On 2019-10-14 at 12:28 +0100, Graeme Fowler via Exim-dev wrote:
> Am I (missing something) or am I about to head deep into the codebase
> to work out how to extend the dnsdb code?

If someone is volunteering :D then ripping out all of the system
resolver usage and replacing it with a libgetdns dependency would solve
a large number of problems for us.

It would add a packaging dependency.  But that's what package managers
are for.

I estimate the workload as "three bottles of whiskey and a new liver".

-Phil

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

Re: [exim-dev] DANE support in Exim with OpenSSL

[Phil Pennock via Exim-dev]

On 2020-07-06 at 01:07 -0400, Viktor Dukhovni via Exim-dev wrote:
> I would like recommend that when convenient, Exim should probably do the
> same.  The documentation for the OpenSSL DANE API is at:

LibreSSL.

-Phil

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

[Phil Pennock via Exim-dev]

On 2020-07-16 at 00:07 -0400, Dennis Roellke via Exim-dev wrote:
> I’d like to understand better how exim processes EHLO messages. Ideally, I 
> could use gdb to set a breakpoint and step through from wherever I want. 
> Unfortunately, exim just ignores any breakpoints... it hits them for sure, bc 
> I see the print stmts. It must have to do with exims threading. I tried 
> detach-on-fork off,  but no luck.

Exim doesn't thread.  It does fork some processes.

More likely, you have a setuid binary, which is disabling ptracing.

-Phil

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

Re: [exim-dev] Default received_headers_max should be increased dramatically

[Phil Pennock via Exim-dev]

First up: looks like we had a moderation backlog, and new subscribers
are moderated by default, so your message was stuck in moderation for
far longer than normal.  Sorry about that.  Your moderation bit has been
cleared.

On 2020-11-27 at 15:13 +, Ian Jackson via Exim-dev wrote:
> ++
> |received_headers_max|Use: main|Type: integer|Default: 30|
> ++

> I suggest that the limit should be raised to, let us say, 100.

RFC 5321 section 6.3 agrees with you.

30 has served us well for some time and I don't think it's scaling quite
that pessimistically: mail routing tends to be _simpler_ in many flows
than it was years ago, as borders mail directly to each other, while
chained mailing-lists are rare.  Thus there's usually two administrative
domains to care about, or three with a mailing-list in there.

Your points about the increased complexity _within_ an ADMD,
particularly with outsourcing of some components, are sound.

I myself have only ever seen 30 reached when there's been a loop, but
raising the default to 100 is reasonable IMO.

Anyone object?  Basis for objection?  If objecting, alternative
proposal?

-Phil

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

[Phil Pennock via Exim-dev]

On 2020-10-31 at 18:34 +0200, Mark Elkins via Exim-dev wrote:
>[quoting:]
> Of course, when you change your DKIM key pair, the public key in the DKIM
> record needs to be changed as well.

That is very poorly phrased.

One selector corresponds to one DNS record.  There is no way to safely
change the public key in a given selector's DNS record: there will
always be races.

If you wish to change the public key, then you use a new selector.

Anyone advocating for changing which key one selector corresponds to,
without a major downtime/rest-period between values, does not understand
distributed caching or distributed coherency.  If you read such advice,
run away from it.

You pre-publish the new selector and wait for at least the zone SOA's
TTL field to expire: this is because if you use a predictable naming
scheme, then someone could pre-populate caches with the NXDOMAIN for
your new record, so you need to wait for negative cache entries to
expire.

Once your public key has been in DNS, in the new selector, for longer
than the previous update's SOA record's TTL, it's safe to start using.

You then need to wait for long enough for all mails stuck in queues
elsewhere to make their way through, for the validation to happen.

>create the domain.pem & domain.pub parts, create and publish the
>DKIM DNS record with the PUB data as "mail.__domainkey" (where
>"mail" is my selector).

No, single underscore for "_domainkey", not two.

[snip system based upon poorly worded advice]
> Is this fine?

No.

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

There are two fundamental approaches to rotating selectors:

 1. Date-stamp
 2. Set of candidates (typically three)


### Date-stamp

I use the date-stamp approach: if this were coming with a From: of my
spodhuis.org domain, it would be dual-signed with the "d202008" and
"d202008e2" selectors (RSA, Ed25519).  A week from today, as the first
Saturday of "every three months", I have a calendar reminder to go ahead
and generate the d202011 family of keys for my domains, and publish them
in DNS.  Then on Monday, I should go ahead and switch the selector used
by Exim for signing email.

As a very complicated example, the SMTP Transport in Exim has:

  dkim_domain   = ${domain:$acl_m_dkim_sender_address}
  # CDB has: domain.tld: dMM=rsa dMMe2=ed25519
  dkim_selector = ${sg{${sg{${lookup 
{$dkim_domain}cdb{CDBMAILTABLES/dkim.selectors.hermes.cdb} 
{$value}{OOPS}}}{\N=\w+\N}{}}}{\N\s+\N}{:}}
  dkim_private_key = ${if 
eq{$dkim_selector}{OOPS}{false}{DKKEYDIR/${extract{$dkim_selector}{${lookup 
{$dkim_domain}cdb{CDBMAILTABLES/dkim.selectors.hermes.cdb.private.$dkim_selector.$dkim_domain}}
  dkim_strict   = ${if eq{$dkim_selector}{OOPS}{0}{1}}
  dkim_sign_headers = SPODHUIS_DKIM_SIGNHEADERS
# timestamps are Exim 4.92+; seconds to add to current time; 2 weeks == 1209600 
seconds
  dkim_timestamps = 1209600

This is way overkill for you, but that's about as complicated as it
gets, and that's handling extracting two different selectors from the
value of a CDB lookup.  Very _very_ few people dual-sign with two
algorithms.  You can write something simpler.


### Set of candidates

I don't use this, but you see this used by mail service providers who
provide mail-sending for various companies, where they want to be able
to DKIM sign for their customers.

The MSP declares that three selectors may exist; to avoid the risk of
collisions, the sensible ones use a prefix which varies by MSP.  Thus
Fastmail have "fm1", "fm2", "fm3".  Mailchimp uses "k1", "k2", "k3".
(Some providers willing to vary selector per-customer let the customer
choose the selectors).

Assume "x1"/"x2"/"x3":

 1. Your customer sets up CNAMEs for all three inside their domain, so
that they have to touch DNS once, to set up the CNAMEs, then never
have to change DNS again.  You can rotate freely without having to
coordinate with different DNS zones.
 2. You start with x1.  You publish it.  You use s=x1 in the DKIM
signatures.  Leave x1/x2 empty, perhaps a TXT record `""`.  As long
as no mails are sent using those selectors, no validators will look
them up in DNS, so you don't need to care.  Just have something so
that DNS control panels which check for "something exists for this
CNAME" won't make life hard for your customers.
 3. Later, you publish x2 in DNS.  After a TTL wait, you can start using
s=x2 in signatures.
 4. You leave x1 in DNS.  Let older signatures continue to validate.
 5. Somewhere between "some time later" and "when you publish x3", you
stop publishing x1 in DNS.  Signatures made with that will no longer
validate.
 6. You publish x3.  You unpublish x1 if it's still published.  Follow
the usual dance.
 7. After x3, circle back around to x1.

The three selectors form a ring, which conceptually have