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 

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

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

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

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

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

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

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

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

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

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

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

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] Buganizer mails lost after Exim 4.90 upgrade

[Phil Pennock]

Folks,

We experienced a regression in Exim with the 4.90 upgrade, which
affected exim.org mail.  As a result, all mail generated by the exim.org
box which was sent out from a domain other than exim.org itself was not
sent.

Instead, the mail was queued as having a temporary problem, and then
eventually bounced.

This affects:
 * buganizer
 * cron job output
 * probably other things
since Exim was updated to 4.90 on December 22nd, 2017.

The regression is that "dkim_private_key" being set to false does not
currently override "dkim_strict" and so instead of being sent unsigned,
the mail sending fails.

I have:
 * added a DKIM signing key for bugs.exim.org;
 * changed the configuration so that dkim_strict is based upon the same
   logic as dkim_private_key, so that it's only set to '1' if we will be
   signing;
 * filed bug 2220 about this regression in Exim
   ;

I'm currently recovering from fever so am not diving into the Exim
codebase to fix this myself.  That's my excuse and I think it's a good
one.  *coughcoughhack*  (I was honestly apprehensive about changing
system configs, or logging in as root, in my current state.)

For elucidation, this is our current remote_smtp configuration on the
exim.org box:

remote_smtp:
  driver = smtp
  rcpt_include_affixes
  tls_require_ciphers = ALL:-SSLv3:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
  # hosts_try_chunking =
  dnssec_request_domains = *
  hosts_try_dane = *
  hosts_try_fastopen = *
  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 = ${if eq{$dkim_selector}{SKIP}{0}{1}}

Regards,
-Phil


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

Re: [exim-dev] [Bug 2092] Should support dual-key configuration with lists of keys/certs

[Phil Pennock]

On 2017-11-02 at 18:00 +, Viktor Dukhovni wrote:
> IIRC, the last chain file loaded was used to provide the issuer
> certificates for all the public key types.  The work-around is to
> make sure that all the issuer certificates needed by *any* leaf
> cert are present in *each* chain file.

Presumably this is covered under the OpenSSL CHANGES file item in the
list under "Changes between 1.0.1l and 1.0.2 [22 Jan 2015]":

} *) Use algorithm specific chains in SSL_CTX_use_certificate_chain_file():
}this fixes a limiation in previous versions of OpenSSL.
}[Steve Henson]

-Phil

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

Re: [exim-dev] [patch] exim 4.90_RC1 SOURCE_DATE_EPOCH build error / missing parts

[Phil Pennock]

On 2017-10-28 at 13:08 +0200, Andreas Metzler wrote:
> Thanks for introducing SOURCE_DATE_EPOCH support to exim. Due to a typo
> 4.90_RC1 FTBFS with non-BSD date if SOURCE_DATE_EPOCH is set. Also the
> change applied to exim needs to be copied over to exim_monitor.

You're welcome, and sorry.  I neglected to become a heathen using
non-BSD date in testing. ;)

I don't have any X11 systems (and haven't had for years) so testing the
monitor changes would be problematic here.  I _suspect_ that to fix the
missing vars it's sufficient to just `#include "version.h"` at the top
of em_version.c because the build system symlinks the monitor source
files into the same build-foo dir as the Exim source files.

-Phil

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

Re: [exim-dev] feature request for exim: query DNSBL providers' DNS servers directly

[Phil Pennock]

On 2017-09-12 at 09:45 +0100, Jeremy Harris wrote:
> On 11/09/17 23:35, Phil Pennock wrote:
> > So there's some value in having an optional, EXPERIMENTAL_FOO feature,
> > for more advanced DNS handling.
> 
> As an alternate implementation, a standard (but custom-configured)
> resolver packaged with Exim in a container?
> 
> Would that suffice, or would the libresolv API still be insufficiently
> rich to do the Very Handy odd queries forseen fr apam-fighting?

Probably suffice for Rob, but the point around the "NS above the cut" is
that it's something no normal resolver ever asks for.  The libresolv
portable API provides no interface for choosing which IPs to send
messages to.

It's easy enough in Go, Python, Perl although in no case with the core
language or stdlib, only with "very common" ecosystem libraries.  For C,
we'd be looking at the same solution.  The people who created the getdns
API know what they're doing and so it's solidly worthy of consideration,
but I haven't done anything with it to be able to endorse it as "the
right way".  Only "the way I kept meaning to find time to look at."

-Phil

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

[exim-dev] rspamd APIs and Exim

[Phil Pennock]

Vsevolod,

You wrote:
} However, the current integration between Rspamd and Exim is not very
} good so far (legacy proto which I have to support in Rspamd just for
} Exim, absence of interaction on before-data stages and so on). Perhaps,
} it is a topic of some separate discussion at some point...

I don't use rspamd, although I did set it up once (a decade ago?).  I
was unaware that there is a problem here.

What's going on?  What would you _like_ to see?

Thanks,
-Phil


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

Re: [exim-dev] feature request for exim: query DNSBL providers' DNS servers directly

[Phil Pennock]

On 2017-09-11 at 20:58 +0200, Heiko Schlittermann via Exim-dev wrote:
> I'm not sure if I got it. You want to re-invent a caching name service
> inside Exim?

No, just a resolver which can be custom-configured.  There's a lot of
value for spam-fighting in being able to do custom DNS queries, although
whether that belongs in Exim vs rspamd or whatever is a different
question.

Example query: "nameservers for this domain as registered in the parent
zone".  NS records are authoritative below the cut and normal APIs will
always return the below-cut answer.  Fast-flux DNS abusing spammers,
pointing NS records at compromised hosts, use this and have done for
years.  Having the ability to look up the records registered in the
parent zone and use _those_ in an RBL-style lookup ... that would be
Very Handy.

So there's some value in having an optional, EXPERIMENTAL_FOO feature,
for more advanced DNS handling.  We have pseudo-RRtypes for dnsdb
already, but adding "NS at parent" couldn't be done with the current
libresolv API.  I've been repeatedly disgusted at the hoops we have to
go through with the `_res` symbol and handling it cleanly, including on
NetBSD which is Different From Everyone Else To Be More Correct.
Replacing all of the DNS lookups with getdns-based handling, if built
with EXPERIMENTAL_GETDNS, and then adding a few more features too, could
be sensible.  For the DNSSEC folks, being able to affirm validation
without trusting across-the-wire that AD bit is tamper-proof is nice.

I think it's worth noting here that Rob _runs_ a commercial RBL (I'm
actually a paying customer of his) and so is in a good situation to be
able to make the call about load and caching.

-Phil

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

Re: [exim-dev] feature request for exim: query DNSBL providers' DNS servers directly

[Phil Pennock]

On 2017-09-11 at 12:25 -0400, Rob McEwen wrote:
> (1) I noticed the following (patch? or fork?):
> "DNS for exim.org" by Nigel Metheringham
> ...could that be related or similar to anything I'm trying to accomplish?

Entirely different repository.  That's for configuring the zonefile for
exim.org itself, back when it was Lua-based and using
GitHub/webhooks/LuaDNS before we switched to something which would
support DNSSEC.

> (2) while your suggestions are excellent - they quickly go beyond my
> specific skills/expertise. (I'm not a C programmer - and I'm not even very
> good at C++). Is there any way I could commission or pay someone (as a
> contractor) to implement this? Do you have any suggestions?

Sure, we're open to people posting looking for contractors for Exim
development.

My own schedule is tight for the next couple of months (minimum) so I
can't take this on.

 is where most of these
are listed; the page is open to editing by anyone with a GitHub account,
so these aren't vetted.  I will note that "Heiko Schlittermann" is one
of the two people (together with Jeremy) currently doing most of the
Exim development work, so if I were looking to hire, I'd start there.

-Phil

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

Re: [exim-dev] feature request for exim: query DNSBL providers' DNS servers directly

[Phil Pennock]

On 2017-09-11 at 10:45 -0400, Rob McEwen wrote:
> (5) It doesn't sound like this is possible in Exim. THEREFORE - What would I
> need to do to build this as a fork (or addon?) to Exim - If I try to provide
> a custom build of Exim - would I need to maintain multiple versions for
> different OS's? Or could I just provide one single download for my
> customers? What would be involved for them to install it - yet without
> overritting their existing Exim settings... as a sort of drop-in upgrade?
> What language is Exim written in?

We'd take patches, no need to maintain your own version.  It's written
in C.

https://git.exim.org/exim.git
https://github.com/Exim/exim/wiki/EximDevelopment

The git repo, for historical reasons to do with combining multiple other
repositories into one at the time of git conversion, is one level
"higher" than the layout seen in release tarballs, thus `src/src/` to
get to the source code.  Alas.  (We should get around to fixing that,
one of these decades).

The core DNS logic is in dns.c and for the dnslists ACL condition, see
verify_check_dnsbl() in verify.c.  That function is responsible for
parsing out the configure syntax (see
)
and delegates work to one_check_dnsbl() defined just above it.

So you'd need a syntax to specify nameservers, unambiguous and distinct
from the existing syntax; see the docs link just above and the following
sections for what syntax is currently handled.  There are other ways of
suppling "connection"-style information used for stuff like database
connections, but nothing really consistent.

You'd need a custom resolver routine which can be given an explicit
nameserver; I don't know of a way to do this with current system
resolver routines.  A while back I wondered about moving away from the
mess that is this underdocumented system API towards something modern,
like getdns.  .  That's probably the sanest
portable route to doing anything other than "system resolver" with DNS,
even though the project is currently only declaring itself
known-to-work-with Linux, FreeBSD, OSX, and MS Windows.

It looks like getdns includes package-conf support, `getdns.pc` is
bundled.  Unfortunately all the current package-conf support is
lookup-specific and in src/scripts/lookups-Makefile.

Ignore the Exim build integration side of things.  If you get code
working which works if you manually slap getdns in CFLAGS in the
Makefile, I can find time to make sure it's feature-guarded and that the
build-system works with it.

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

Re: [exim-dev] feature request for exim: query DNSBL providers' DNS servers directly

[Phil Pennock]

On 2017-09-09 at 14:59 -0400, Rob McEwen wrote:
> I have a feature request for Exim. Or, since Exim is clearly one of the
> world's most flexible/configurable MTAs, is... what I'm about to describe...
> already be possible with existing features?

Not quite possible, but could be a fairly small modification to the
dnsdb lookup type.  But a bad idea because of Exim's architecture.

> (Ideally, Exim would internally cache the answer for the NS lookups... so
> that it wouldn't have to do this NS lookup with every single DNSBL lookup.
> But technically, that part is a bit more exotic.)

Exim forks a new process for every accepted connection and every
outbound delivery.  Exim's lookup system isn't really designed for any
kind of programmable write-back caching (redis/whatever).

For the short lifetime of the process, lookup results are remembered in
an LRU, but that's about it.

Further, Exim is currently using OS native libresolv-style interfaces
and knows nothing except how to issue a query using those.

The normal approach for postmasters running mail-servers is to install a
dedicated DNS resolver either on the box, or serving the boxes, so that
all the DNS traffic from the mail-system doesn't push out of cache the
lookups which outbound query folks care about.

Then if a particular zone needs to be handled specially, that can be
configured in the DNS resolver's setup accordingly.  Encapsulate the
special DNS logic in the DNS resolver.

If someone really wants something special but can't run a separate DNS
server (personal development box in colocation somewhere) then I'd look
at using pf/iptables user-based filtering to divert DNS traffic to the
resolver on port 53 to port 63 instead and run a second DNS resolver on
port 63, which is configured with a tiny cache, to forward most traffic
to the main resolver and handle the special zones accordingly.

-Phil

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

Re: [exim-dev] [Bug 2104] TLS wrong version number on connection reuse

[Phil Pennock]

On 2017-04-23 at 00:55 -0400, Viktor Dukhovni wrote:
> I find that rather perplexing.  Over a single TCP connection it is not valid
> to issue a second STARTTLS.  I am misreading the above?

If you tear down TLS, the standards are silent about what happens next.

Exim's current model, which Jeremy is working on changing, has all TLS
state in the process which delivers one message.  Delivering multiple
messages in one connection requires passing an open file descriptor to
another Unix process, but TLS libraries generally don't make their
internal state serializable for passing around in such a manner, so Exim
has no choice but to tear down TLS and see if the remote server is happy
to have TLS re-established again.  For some remote MTAs it works, for
others it doesn't.

Jeremy is doing the hard work of trying to change this, partially based
on a crazy idea of mine; this is not yet released, it's part of Exim
4.90 (I think J slightly mis-spoke in his phrasing around 4.89).  In the
new model, the TLS client is capable of being a process proxy for other
delivery processes, via a Unix socket, so TLS never needs to be torn
down.  Performance should be significantly better, despite the extra
copies and extra process locally.

There's some bug-fixing and cleanup required though, around things as
basic as "what gets logged", since this isn't how Exim was designed.

-Phil

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

Re: [exim-dev] [exim] Exim 4.89 RC7

[Phil Pennock]

On 2017-02-28 at 22:48 -0500, Phil Pennock wrote:
> I have uploaded Exim 4.89 RC7 to:
> 
> https://ftp.exim.org/pub/exim/exim4/test/

No replies.  I don't know whether to be ecstatic or very very afraid.

Unless I hear of issues, I intend to cut Exim 4.89 on Tuesday 7th March,
sometime in the morning in US/Eastern timezone.

It would still be nice to see "yes, this has fixed all the issues we've
been seeing", but I understand that for intermittent failures, folks
want to give it enough time to have confidence that the issues really
are gone, not just doing a better job of hiding.

-Phil

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

[exim-dev] Exim 4.89 RC7

[Phil Pennock]

I have uploaded Exim 4.89 RC7 to:

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

Over RC6, this fixes a few different crash bugs and fixes ${extract }
corrupting an enclosing ${reduce } $value.

Please note that we are seeing OpenSSL issues which require 1.0.2
minimum build up in our backlog for fixing after Exim 4.89, so if you
are intending to stick with older OpenSSL releases for the time being,
then Exim 4.89 is probably the last Exim release which will work with
your unsupported-by-OpenSSL-project OpenSSL libraries.  You thus have a
Very Strong Interest in ensuring that 4.89 works for you.
Please test this RC.

If you are testing and experience a segfault still, then after I finish
crying like a baby, I'm going to ask for debugging information.

So please build with  CFLAGS+=-ggdb  and do not strip the binary; if you
experience crashes, look into what's needed to enable setuid programs to
generate core files on your platform, and then we'll want, minimally, a
backtrace.

Additionally, if you experience issues, then setting the new
main-section configuration option "debug_store", which is a bool, may
turn some issues into assertion failures (so Exim will still crash, but
closer to the root cause).

At this point, we're really close; some of the issues fixed in 4.89 are
issues introduced in 4.88, others are potentially long-standing issues.

https://git.exim.org/exim.git/blob/exim-4_89_RC6:/src/README.UPDATING
https://git.exim.org/exim.git/blob/exim-4_89_RC6:/doc/doc-txt/ChangeLog
https://git.exim.org/exim.git/blob/exim-4_89_RC6:/doc/doc-txt/NewStuff
https://git.exim.org/exim.git/blob/exim-4_89_RC6:/doc/doc-txt/openssl.txt

The files are signed with the PGP key 0x4D1E900E14C1CC04, which has a
uid "Phil Pennock <p...@exim.org>".  Please use your own discretion in
assessing what trust paths you might have to this uid.  Note that I have
two signing sub-keys and have signed with both; if you have an ancient
GnuPG release, you should get unimplemented warnings for one signature.
If this causes you inability to verify, please let me know; but if you
can verify with the other signature then that's expected behavior.

Checksums below.  Detached PGP signatures in .asc files are available
alongside the tarballs.

Please report issues in reply to this email.

Thank you for your testing and feedback,
-Phil Pennock, pp The Exim Maintainers.


SHA256(exim-4.89_RC7.tar.bz2)= 
5231996bc3e5ac46ab16322f3fa4e2cc75f4d24e83ce5b30fa4395ab9dad71fb
SHA256(exim-4.89_RC7.tar.gz)= 
4fa8b0cfef6487229b27a24fbc55b28bef561d013681261a219028f844ccc5ef
SHA256(exim-4.89_RC7.tar.xz)= 
0cffd4b7afa45523fc2f2f5fecf8056d098abcb3f8608a1b8688ffb1f350f137
SHA256(exim-html-4.89_RC7.tar.bz2)= 
afc71c46a9a19727a63ce60a5410b6bcced27c6643f67290655cde8439e5d0b7
SHA256(exim-html-4.89_RC7.tar.gz)= 
228a0c863d6a8346b25f57268062f1b6e7ada5374cd41bbe644be50e5fdb18d7
SHA256(exim-html-4.89_RC7.tar.xz)= 
ccc9dba152de57676a7d5e3421d0534346098da44e11f22a626961dceb9778cc
SHA256(exim-pdf-4.89_RC7.tar.bz2)= 
e654f1c07bd9fc3018721d67bc8156df2b6fd452d7b8392c1bc1277a0ad63243
SHA256(exim-pdf-4.89_RC7.tar.gz)= 
9edd0d853224fe61428f7de25605ff0382c53ec52d95088c77bd814b8bd5ce44
SHA256(exim-pdf-4.89_RC7.tar.xz)= 
a9dbbd1f7f7310c21171cfc93c9359583030515936a4a91991b7675431cb459b
SHA256(exim-postscript-4.89_RC7.tar.bz2)= 
e997f059e6f4c3c810f726a35a209e0b490d7514ed3551297d0ede1f597975a0
SHA256(exim-postscript-4.89_RC7.tar.gz)= 
8261457a94a29ae962a3a14860c80f063896841b2135be00ef99db64609de660
SHA256(exim-postscript-4.89_RC7.tar.xz)= 
e44698bf11695b890d3cd88c1f399b271a2501ea1b455dc318bd6dad184a67f1

SIZE(exim-4.89_RC7.tar.bz2)= 1843600
SIZE(exim-4.89_RC7.tar.gz)= 2331545
SIZE(exim-4.89_RC7.tar.xz)= 1686524



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

Re: [exim-dev] [exim] Exim 4.89 RC6 uploaded: one remaining known issue

[Phil Pennock]

On 2017-02-23 at 18:44 +0100, Andreas Metzler wrote:
> BTW, there is a new rather ugly warning in RC6:
> | receive.c: In function 'read_message_bdat_smtp':
> | receive.c:947:9: warning: implicit declaration of function 'bdat_ungetc' 
> [-Wimplicit-function-declaration]
> |  bdat_ungetc('\n');
> |  ^~~

Already fixed; since it's taking an int type, I decided that the
implicit would do and didn't re-cut, but left it and fixed immediately
after finishing the publication.

(A function got used in a second file, so I just moved the declaration
to a header).

(As part of release, I'm signing, building, deploying to two boxes, and
then pushing the signed git tags and publishing the tarballs; the two
boxes are one with clang on FreeBSD 10.3 and one with gcc on Ubuntu
14.04.5; between them, these have done a decent job of letting me trim
down the warnings a fair chunk during RC.  So I can stop and recut
trivially if I see anything which warrants it)

-Phil

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

[exim-dev] Exim 4.89 RC6 uploaded: one remaining known issue

[Phil Pennock]

Folks, we really need your help tracking down one last issue with a
crashing Exim; _please_ try this Exim some place, to see if you can help
expose it.

I have uploaded Exim 4.89 RC6 to:

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

Over RC5, this fixes a problem where a message received via CHUNKING
could be missing the final newline, and so never make it out of the Exim
queue; provides a util script for fixing any such messages found in the
queue, and provides a main option for debugging memory usage.

We have one issue remaining, which is a crash bug.  We think that it's a
long-standing issue of memory mis-use which has been exposed by some
memory management cleanups, which has worrying security implications.
So this is not new, only the surfacing is; on the other hand, it might
only have become possible to trigger it with the 4.88/4.89 code.  I am
extremely reluctant to release with this issue in the code.

We need a usable core-file, which means _full_ GDB debugging
information, so please build with  CFLAGS+=-ggdb  if you think that you
might be able to trigger a crash.

Additionally, you can now set the new main-section configuration option
"debug_store", which is a bool.  This adds a couple of assertions to the
code, making a crash more likely, but exposing where those issues are.

*PLEASE TEST* -- we need your help.

The important text-format documents for this release can be reviewed at:

https://git.exim.org/exim.git/blob/exim-4_89_RC6:/src/README.UPDATING
https://git.exim.org/exim.git/blob/exim-4_89_RC6:/doc/doc-txt/ChangeLog
https://git.exim.org/exim.git/blob/exim-4_89_RC6:/doc/doc-txt/NewStuff
https://git.exim.org/exim.git/blob/exim-4_89_RC6:/doc/doc-txt/openssl.txt

The files are signed with the PGP key 0x4D1E900E14C1CC04, which has a
uid "Phil Pennock <p...@exim.org>".  Please use your own discretion in
assessing what trust paths you might have to this uid.  Note that I have
two signing sub-keys and have signed with both; if you have an ancient
GnuPG release, you should get unimplemented warnings for one signature.
If this causes you inability to verify, please let me know; but if you
can verify with the other signature then that's expected behavior.

Checksums below.  Detached PGP signatures in .asc files are available
alongside the tarballs.

Please report issues in reply to this email.

Thank you for your testing and feedback,
-Phil Pennock, pp The Exim Maintainers.

SHA256(exim-4.89_RC6.tar.bz2)= 
22adfa9eec3e0ec36df1d6948f337fcee2747440f807d9de47324ead7ef55585
SHA256(exim-4.89_RC6.tar.gz)= 
be0b62277d52c3f4c1751104f3b74bec374a7197ffbfe5e18a18a5bab929ccd0
SHA256(exim-4.89_RC6.tar.xz)= 
2e0e2a8e25ecdc25eadd5553ffc0a403aa5280bfedc9344a5f43cae014ba71d7
SHA256(exim-html-4.89_RC6.tar.bz2)= 
93296566f8fcefa955906f035ef47df8076a9650564726da9a9ee45d0dad959e
SHA256(exim-html-4.89_RC6.tar.gz)= 
479a4e74d8eddf98d0f76902c1439712b23aae33b2c1381fed4372529eb45034
SHA256(exim-html-4.89_RC6.tar.xz)= 
b6f033ccd94c2c80f05ddf72a1f9a41ab005c8ae9438fa7386d3056175512967
SHA256(exim-pdf-4.89_RC6.tar.bz2)= 
f102ac4f887c43be194385515b30e2e673d0cd46e0da8d4ed2ec278a8ea82faf
SHA256(exim-pdf-4.89_RC6.tar.gz)= 
31017411fe289d67b7039e2686de2a4f7b6b2fbdf817f1321f7a313136985c36
SHA256(exim-pdf-4.89_RC6.tar.xz)= 
f27bb917ce4e158c277bb0a029184e4f00df24b81001264c68709ee913c8a17e
SHA256(exim-postscript-4.89_RC6.tar.bz2)= 
4093d30be7bbb0b435474b4b59fa74130b6407d7923521f559d2827f88be46cb
SHA256(exim-postscript-4.89_RC6.tar.gz)= 
2e574a70026a579994533ee29808d3d9ba0fac4a579b4265b1fae54f5dec0747
SHA256(exim-postscript-4.89_RC6.tar.xz)= 
2a6d41adae2b2c8670e109301af7049add84ab7c1d8c18bee2c1868a5668832b

SIZE(exim-4.89_RC6.tar.bz2)= 1843883
SIZE(exim-4.89_RC6.tar.gz)= 2331323
SIZE(exim-4.89_RC6.tar.xz)= 1686368


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

Re: [exim-dev] [exim] Exim 4.89 RC6 tomorrow (Wednesday)

[Phil Pennock]

On 2017-02-15 at 03:40 +, Phil Pennock wrote:
> We have one outstanding report of message segfaults, on one system.  I
> don't believe these have been reproduced by anyone else, but I'm waiting
> for more feedback from the reporter: if there is a bug in Exim here,

There's something real here, and I don't see a point in doing RC6
without it.  If you're running RCs, please disable advertising chunking
until RC6.

> So we should have RC6 sometime on Wednesday.

Nope, that was optimistic.

It seems likely that final release will _not_ happen on Monday.  My
availability over the next two (or more) days is "highly constrained"
because of non-computer life events; I won't be around online.  So
unless Heiko and Jeremy debug the crash problem and cut RC6 in my
absence, the schedule is now pushed back.

-Phil

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

[exim-dev] Exim 4.89 RC6 tomorrow (Wednesday)

[Phil Pennock]

We have fixes for SMTP CHUNKING handling messages sent without a final
newline, to be part of 4.89.  We fix the messages as received, and have
a Perl script to fix up broken messages stuck in your queue.

We have one outstanding report of message segfaults, on one system.  I
don't believe these have been reproduced by anyone else, but I'm waiting
for more feedback from the reporter: if there is a bug in Exim here,
I'll try and get it into RC6.

So we should have RC6 sometime on Wednesday.

-Phil

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

[exim-dev] [exim] Exim 4.89 RC5 uploaded: Fast & Furious Weekend

[Phil Pennock]

I know it's three RCs in as many days, but we think each is a step
better and if we can ensure that people who start their RC testing
during the work-week can have a week to bake and find any remaining
issues, that's good.

I have uploaded Exim 4.89 RC5 to:

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

Over RC4, we have *fixed a crash bug in receiving email with DKIM
disabled*, fixed a bug I introduced for some platforms, and made
building Exim return to working state on versions of FreeBSD not
currently supported by that project.

*PLEASE TEST* -- we want to make 4.89 Final the best it can be and
currently plan to release on Monday February 20th.

The important text-format documents can be reviewed at:

https://git.exim.org/exim.git/blob/exim-4_89_RC5:/src/README.UPDATING
https://git.exim.org/exim.git/blob/exim-4_89_RC5:/doc/doc-txt/ChangeLog
https://git.exim.org/exim.git/blob/exim-4_89_RC5:/doc/doc-txt/NewStuff
https://git.exim.org/exim.git/blob/exim-4_89_RC5:/doc/doc-txt/openssl.txt

The files are signed with the PGP key 0x4D1E900E14C1CC04, which has a
uid "Phil Pennock <p...@exim.org>".  Please use your own discretion in
assessing what trust paths you might have to this uid.

Checksums below.  Detached PGP signatures in .asc files are available
alongside the tarballs.

Please report issues in reply to this email, on exim-users.

Thank you for your testing and feedback,
-Phil Pennock, pp The Exim Maintainers.

SHA256(exim-4.89_RC5.tar.bz2)= 
08587e46f5a108184dff5be5d78c38e74e4355c14195762c3068f78c2104a971
SHA256(exim-4.89_RC5.tar.gz)= 
ca3487652747cce4aa0203111f0bd8ba8215bb7794c925dd4bfbb5cab33b666a
SHA256(exim-4.89_RC5.tar.xz)= 
f219983fb196b83ae3951ca169949d9232e30e287b6923645e2d8886a5cef5b5
SHA256(exim-html-4.89_RC5.tar.bz2)= 
c9011833f001bf351efbea650ab99a85ff9cc8285e72d89ff621b1bcbf53795e
SHA256(exim-html-4.89_RC5.tar.gz)= 
ec59e0c4c728c616e613d7fd4a5b1b0abf2ed2e0958d9e6efd48069aa936
SHA256(exim-html-4.89_RC5.tar.xz)= 
d475fd09d5b567676c4c912ac2ec3581e40c073f532f54b7b8abdf396623fdf2
SHA256(exim-pdf-4.89_RC5.tar.bz2)= 
e97f86455b53936e78d2e6c363d658b64f705a367a5466cddba939efc35da9a7
SHA256(exim-pdf-4.89_RC5.tar.gz)= 
22d4e685224e34ed4372bff469925123566cbf05e3c4db508c1079bdd875c471
SHA256(exim-pdf-4.89_RC5.tar.xz)= 
3ccf249a74f63948fa849b3a801dadbf0cfd6d9a1282b4c23eb2aad6e69c6484
SHA256(exim-postscript-4.89_RC5.tar.bz2)= 
9020f83b2e91c0f9d5f22526d6590213f155ae21ea38d4b6edb72e127303c31c
SHA256(exim-postscript-4.89_RC5.tar.gz)= 
fbd2bdd95c7fe83ecca2e9694c07cf89464d5df59e4c1ff638e32726ed2face2
SHA256(exim-postscript-4.89_RC5.tar.xz)= 
c510fd7820c874026b3eebbb6c2aba231b3024898b531d9963ad87d8a1a26a0b

SIZE(exim-4.89_RC5.tar.bz2)= 1841006
SIZE(exim-4.89_RC5.tar.gz)= 2328790
SIZE(exim-4.89_RC5.tar.xz)= 1683924


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

Re: [exim-dev] Popping '.' from @INC

[Phil Pennock]

On 2017-02-12 at 11:30 +0100, Heiko Schlittermann wrote:
> I saw, that '.' now gets pop()ed from @INC in various Perl scripts.
> 
> Is there a special reason doing so? If we'd deal with security in mind,
> we should use Perl's taint mode to make the scripts more secure.

Root invokes these scripts, often for messing with queue analysis.
Invoking them in /tmp is entirely reasonable.  Other people can write to
/tmp, so letting people have code be run as root because root invoked an
Exim tool while in /tmp is poor form.

Taint mode deals with when the invoker's environment is not trusted.
It's excellent for daemons, CGIs, network protocol clients, etc.  It's
less useful for CLI tools which don't talk to untrusted services.  I'm
not opposed to it I just don't see the point here.

Taint mode doesn't really protect against @INC being stupid.

Other scripting languages have things like "the directory where the
script was found is also in sys.path/whatever"; AFAIK only Perl puts the
_current_ directory into @INC.

See: https://bugs.exim.org/1864

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

[exim-dev] Exim 4.89 RC4 uploaded

[Phil Pennock]

I have uploaded Exim 4.89 RC4 to:

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

This is a few minor fixes over RC3 but increases my confidence that this
will be identical, bar version-numbers, to the final release if nothing
else is revealed.  *Please Test*.

Since RC3: the version number in Release Candidate packages once more
properly declares the code to be an RC; all Perl scripts now strip '.'
from @INC; some compilation warnings under Clang have been cleaned up;
FreeBSD builds now try to use iconv from base libc; test_dbfn now builds
once more, per instructions in doc/dbm.discuss.txt; release tarballs now
encode all files as owned by 0:0 (for less confusing results if you
extract them as a root user).

The .xz tarball variants appear to be popular with users, so those are
now "standard" for all releases going forward.

The important text-format documents can be reviewed at:

https://git.exim.org/exim.git/blob/exim-4_89_RC4:/src/README.UPDATING
https://git.exim.org/exim.git/blob/exim-4_89_RC4:/doc/doc-txt/ChangeLog
https://git.exim.org/exim.git/blob/exim-4_89_RC4:/doc/doc-txt/NewStuff
https://git.exim.org/exim.git/blob/exim-4_89_RC4:/doc/doc-txt/openssl.txt

The files are signed with the PGP key 0x4D1E900E14C1CC04, which has a
uid "Phil Pennock <p...@exim.org>".  Please use your own discretion in
assessing what trust paths you might have to this uid.

Checksums below.  Detached PGP signatures in .asc files are available
alongside the tarballs.

Please report issues in reply to this email, on exim-users.

Thank you for your testing and feedback,
-Phil Pennock, pp The Exim Maintainers.


SHA256(exim-4.89_RC4.tar.bz2)= 
e9de49cd7b874f944f827adbe2981fd3ea8eb000461856e94f5b7c859dde3df1
SHA256(exim-4.89_RC4.tar.gz)= 
6a63182280381de82310c396362acd049cd51a190b345ea6a5dd2352a3409119
SHA256(exim-4.89_RC4.tar.xz)= 
2cd10b8299e548d252245743418326ee0909aadb4f7d18191ee9a27688c3ba2c
SHA256(exim-html-4.89_RC4.tar.bz2)= 
44cf736039a4cf3b701aaccaddf7ecb43eb1cee7232284d75aa187df0ab058ba
SHA256(exim-html-4.89_RC4.tar.gz)= 
626a3e2907c427b538b5d8081569cf0173bd9cb09a76f0e42f91da02a48972bb
SHA256(exim-html-4.89_RC4.tar.xz)= 
5c471e430df854d8d8a2571bf015990b484206512e46020ac05e2f1f8fe51fc4
SHA256(exim-pdf-4.89_RC4.tar.bz2)= 
4b98d52873541e6675b3e7f6e433080033b0b2e0dece41ad273afedb6a6e17c0
SHA256(exim-pdf-4.89_RC4.tar.gz)= 
bb8215589ab3712449e81588f877d35a71cabc585e18bfc995df806abba938a0
SHA256(exim-pdf-4.89_RC4.tar.xz)= 
caf376d35cdaf6a6b0883ab66b5e57aaf42b67ef837825dae660fb87cff1db7d
SHA256(exim-postscript-4.89_RC4.tar.bz2)= 
2f8c6af6bf21f78a984633b56646cf693ae3626937b044f0880926ac1346b361
SHA256(exim-postscript-4.89_RC4.tar.gz)= 
23483a0bfcc3e8583aee8ffa7541156939150e746c18d2262889c9e0c419e49f
SHA256(exim-postscript-4.89_RC4.tar.xz)= 
5a02ca35e6572262b8977e24ba1e1115e150a3cb99afc89219e64add575b083d

SIZE(exim-4.89_RC4.tar.bz2)= 1840364
SIZE(exim-4.89_RC4.tar.gz)= 2328562
SIZE(exim-4.89_RC4.tar.xz)= 1683828


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

Re: [exim-dev] [Bug 1864] New: CVE-2016-1238: Important unsafe module load path flaw

[Phil Pennock]

On 2017-02-10 at 12:57 +, Andrew C Aitchison wrote:
> This is about a perl security issue that was not accepted directly into exim
> in July/August 2016.

Hrm.  This isn't about Perl embedded inside Exim and thus setuid, but
instead scripts bundled, which run without elevated privilege, on the
basis that someone might theoretically invoke exim scripts while in a
directory to which untrusted users can write.

Also, where other scripting languages default to "same directory as
script, or current directory if we can't figure that out", Perl uses
"current directory" is is anomalous.

I suppose the odds are pretty high that someone might invoke it while in
/tmp and we should protect against it.

I don't see any harm from the patch for our scripts; it's an annoying
extra hoop to jump through, but that's about it.

I'll apply this change to all our Perl scripts.  I will however place it
after warnings/strict, there's no reason to exempt executing Perl from
basic sanity checks.

I'm classifying this as "stupid and annoying of Perl and we shouldn't
have to do it, but reality sucks, changing the behavior is non-trivial
and so in the meantime we either deal with it in Perl or stop using
Perl".

Changed all; "perl -c" applies; also caught a couple of shell scripts
with embedded Perl.

Cherry-picked into the release branch.  This means that there is likely
to be an RC4.

-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] Exim 4.89 RC3 uploaded

[Phil Pennock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I have uploaded Exim 4.89 RC3 to:

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

RC2 was claimed to be OpenSSL-only.  Further investigation revealed that
the problems observed were not Exim-specific but GnuTLS, affecting all
applications using the API in certain circumstances, only known to apply
to Fedora.

RC3 fixes, beyond RC2:

 * crash in transport re-using bad $sender_ip_address from callout
 * CHUNKING: fix transport crash on temp-reject of pipelined
   non-first chunk
 * some added DKIM paranoia
 * non-SSL builds fixed
 * various minor documentation fixes

The .xz tarball variants appear to be popular with users, so those are
now "standard" for all releases going forward.

I need to fix something about the uids in the tarballs, but if nothing
substantive is found, I expect RC3 to be the last RC and otherwise
identical to final release, on or around Monday 20th February.  Note
that the release-branch was recut from master for RC3.

The important text-format documents can be reviewed at:

https://git.exim.org/exim.git/blob/exim-4_89_RC3:/src/README.UPDATING
https://git.exim.org/exim.git/blob/exim-4_89_RC3:/doc/doc-txt/ChangeLog
https://git.exim.org/exim.git/blob/exim-4_89_RC3:/doc/doc-txt/NewStuff
https://git.exim.org/exim.git/blob/exim-4_89_RC3:/doc/doc-txt/openssl.txt

The files are signed with the PGP key 0x4D1E900E14C1CC04, which has a
uid "Phil Pennock <p...@exim.org>".  Please use your own discretion in
assessing what trust paths you might have to this uid.

Checksums below.  Detached PGP signatures in .asc files are available
alongside the tarballs.

Please report issues in reply to this email, on exim-users.

Thank you for your testing and feedback,
- -Phil Pennock, pp The Exim Maintainers.


SHA256(exim-4.89_RC3.tar.bz2)= 
f9db70feb2dfd074c407cc2960b21e63d57575fdc262f618322e247803f260fc
SHA256(exim-4.89_RC3.tar.gz)= 
4e3cade6dca9cc145bd638a5cc76c5117fa85c1cb1a4c2e8d53a34d5b0457cef
SHA256(exim-4.89_RC3.tar.xz)= 
fc869babaee323b30a7aa359e38a20109210f1d677278a0f3b95caa0e74e3774
SHA256(exim-html-4.89_RC3.tar.bz2)= 
81a06f2244f7392233cd4034ba90278d4d2b4c7902fde981d8aa16b8a8eddbf4
SHA256(exim-html-4.89_RC3.tar.gz)= 
20cf426d29bac15017c51eec51c841371700bd3381a0f762b35769cdc8ea316d
SHA256(exim-html-4.89_RC3.tar.xz)= 
887bf665eec8ef138bf8cc403f521353d6188e3b67bad5e7a5ccc8b146d87a87
SHA256(exim-pdf-4.89_RC3.tar.bz2)= 
93a34399096e1272ee8e4dcb6e3ec5bd09a7b084b14876e97e7685d97fa2c4bf
SHA256(exim-pdf-4.89_RC3.tar.gz)= 
b676b5b6d9f4762733e23233a79fc5d751870ebd00c2b15b40592810bdb221a1
SHA256(exim-pdf-4.89_RC3.tar.xz)= 
b86566e060e3501998690d107ea1fd341d1e139c1f7b892760e83a0c3b06ff09
SHA256(exim-postscript-4.89_RC3.tar.bz2)= 
c4dba4043536c02b2c78ecfe9e82b59bbcef377cd94c2a38178b55e8fb70e6fa
SHA256(exim-postscript-4.89_RC3.tar.gz)= 
14bdf1fab13454d2e19d0af4e1276da0fb56d4029ec45d8f7682ab622babc572
SHA256(exim-postscript-4.89_RC3.tar.xz)= 
2199755a5cad68670d52b8e58647c5ce89acd57a11530a43495dea205e973983

SIZE(exim-4.89_RC3.tar.bz2)= 1840554
SIZE(exim-4.89_RC3.tar.gz)= 2327629
SIZE(exim-4.89_RC3.tar.xz)= 1683112
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEExpOgNOHtbulUyuLaE9rZnH5BUZwFAlidMigACgkQE9rZnH5B
UZwNsQ//caZoj0SFDKvdQ/yfoOdHsJ6nhTXeyTHaFbcOHWkE2UefZ/QqhEKUWibx
sZQaqVEt2uL2xlXjCjqwTMTHdj+/eg4jqO589fW1MJ9Z4Be7ANG1tf/xVovA671X
pb0JWpiXTLr/fDv6nfEa+RuX6rakSmLeDu4CtSd6zk14Jq9S7F7lUSwMY9vHfxnw
z46jFZecGKQMcthhyS6236hOll4iQsUEv2KB6oGiMD3240kQfKd/Qb4SCugLKTRN
uWOVMn3ByTbZ0cUeNCYfsDWXUMvjnYMfKoE09MYpJsJQsopOFGNBn+9NIQQuJkkq
YJRX6hLW3yDfrciWUu5ODRD5vRHefMJ+EYWaJuPiaS5G3JVd5OG3MX3XxJM3SR3O
oE9lIORChTvey+7Xuu5CtxolvxkCuZyRCjCXanCFyw7LpgDE4Lguy/JMNT7Zpl3U
nbA7xhZ1KOoKnPRBmOLehS8Z14QR0xUCKXgCaOSXO5qfTTWhkCTLU27LywpdrvkR
Jf7LgH0Ss33whpd+zKU6nChzKOTOa7SdSBPW0fC8Nf1lxWPXrJeXq3BrwFOdyA+P
MUsdlh3RnKWyHsRuRAElfKyBOkYK21ZYl7PrVViLSBv65V1QinUMvuB2WBuSvhYQ
JSUfjP5PxN0f63Gam5msX8XAvSdUi1D+dDmMT55ZK9KP48u6h0I=
=nOWl
-END PGP SIGNATURE-

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

[exim-dev] Re-cutting 4.89 release branch

[Phil Pennock]

Enough good fixes have gone into master, with nothing disruptive, that
I'm going to re-cut the release branch from current master.


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

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

[exim-dev] Administrivia: this should be munged

[Phil Pennock]

Mailman on @exim.org should now be DMARC-munging, including for p=none
domains where failure to munge is a privacy breach.

See:
  
https://bridge.grumpy-troll.org/2012/02/how-private-is-your-mailing-list-subscriber-list/
  
https://bridge.grumpy-troll.org/2012/07/mailing-list-recipient-disclosures-with-dmarc-redux/
for why that matters.

So if this mail flows through, with From: munged, and I receive it also
in a gmail inbox, then the mailman upgrades are complete, CGI install
fixes are complete and we're good to go.

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

Re: [exim-dev] FYI: hummus SMTP going down

[Phil Pennock]

On 2017-02-05 at 13:40 +, Phil Pennock wrote:
> Switching mailman installs, I've scripted the next steps enough that
> things shouldn't be too bad.  Back soon!

If you can see this message, things are back.

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

[exim-dev] FYI: hummus SMTP going down

[Phil Pennock]

Switching mailman installs, I've scripted the next steps enough that
things shouldn't be too bad.  Back soon!

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

[exim-dev] Exim 4.89 RC2 uploaded (openssl-only)

[Phil Pennock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I have uploaded Exim 4.89 RC2 to:

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

This is a stabilization release containing a number of bug-fixes; the RC
process for 4.89 will be accepting bug-fixes only, with a release-branch
in git so that any developments need to be explicitly carried across.

RC2 has known issues with GnuTLS; folks using Exim with GnuTLS are
currently best advised to hold off on the RC series until RC3.  For
folks using Exim with OpenSSL, RC2 should be considered a full release
candidate.

My current expectation is that RC3 will include fixes for the known
GnuTLS issues and if no issues are reported, will be the last Release
Candidate.  I expect to release Exim 4.89 somewhere around Monday
February 20th, if RC3 (or an RC4) is the last RC.

RC2 is believed to fully fix Proxy Protocol support, v1 and v2, with
TLS-on-connect supported; the "spec.txt" and "filter.txt" files are
non-empty (always a plus); small fixes for callout verify/random and
also some logging details.

As an experiment, this release includes tarballs in .xz compressed
format.  If this is helpful to you, please do let me know.  While we
can check transfer logs from ftp.exim.org, we can't see figures from the
many mirrors which people use.

The important text-format documents can be reviewed at:

https://git.exim.org/exim.git/blob/exim-4_89_RC2:/src/README.UPDATING
https://git.exim.org/exim.git/blob/exim-4_89_RC2:/doc/doc-txt/ChangeLog
https://git.exim.org/exim.git/blob/exim-4_89_RC2:/doc/doc-txt/NewStuff
https://git.exim.org/exim.git/blob/exim-4_89_RC2:/doc/doc-txt/openssl.txt

The files are signed with the PGP key 0x4D1E900E14C1CC04, which has a
uid "Phil Pennock <p...@exim.org>".  Please use your own discretion in
assessing what trust paths you might have to this uid.

Checksums below.  Detached PGP signatures in .asc files are available
alongside the tarballs.

Please report issues in reply to this email, on exim-users.

Thank you for your testing and feedback,
- -Phil Pennock, pp The Exim Maintainers.


SIZE(exim-4.89_RC2.tar.bz2)= 1840130
SIZE(exim-4.89_RC2.tar.gz)= 2326329
SIZE(exim-4.89_RC2.tar.xz)= 1681708

SHA256(exim-4.89_RC2.tar.bz2)= 
1c73a672986d7f77ea1257e166b0c44553dc17c64f4f7386cd5b5cdeb572dd01
SHA256(exim-4.89_RC2.tar.gz)= 
9a7fa49725211e4eaeecb6111e4c1f2e3cf578b8569f44aea79a2f4d9086f409
SHA256(exim-4.89_RC2.tar.xz)= 
71bfce9a50a34c2e00acf87bffaaff6d50939ef317a26e145cde13f66a057358
SHA256(exim-html-4.89_RC2.tar.bz2)= 
1c07f88d28bdad4084c6200a834ae97dce264f7a87ce5d92df0d53088972926b
SHA256(exim-html-4.89_RC2.tar.gz)= 
5b1ba7cc655244215d23d592447b04288818db7d55e471c90fb868f2741166a4
SHA256(exim-html-4.89_RC2.tar.xz)= 
b5ea9e407cc9ae72c89d4761499194e9266ec0200da4c8333e7096095a1214d6
SHA256(exim-pdf-4.89_RC2.tar.bz2)= 
b1e5c91e4244971d8dea1af8163bc9b630f398abdc469de993505e35e695ee53
SHA256(exim-pdf-4.89_RC2.tar.gz)= 
7ea97f610a304e8d3d3a21a9856f32c9e1d9b54ac65fa9f9a2e013f06f436a46
SHA256(exim-pdf-4.89_RC2.tar.xz)= 
ce365a5eb6119e12721b70683b508efa47da591f237c51903f8670a0905c27cf
SHA256(exim-postscript-4.89_RC2.tar.bz2)= 
f89e7c5999824f727177c5c64d98c31b9fc46a21afe47387bdbe16e1b4e81c87
SHA256(exim-postscript-4.89_RC2.tar.gz)= 
4e05dd44532d8b324d781ec47a1d64b5376c2cb72eb84a527e5c9edade07c68b
SHA256(exim-postscript-4.89_RC2.tar.xz)= 
bb8bd1093085d13c37d22366157711e009975f24320ad870f4f9d0f2f9e60196

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEExpOgNOHtbulUyuLaE9rZnH5BUZwFAliT0YoACgkQE9rZnH5B
UZzneQ//QpLbdOnad79NiQvjz+gCUxPXMZcHnF+FUpj3LFTOzui6x27uI4r4ANEi
XNjT8CPeiJDJjNXj3B4ZAqgD3W6xPv/G0gkXauM+K/xSeHkI/ZSxlaGuj3QVIdi2
sD+iv3rOSbMc4TaeDETIQ6ti24JkpTvoh4LOQ1WvRhtJgriwCynf3F1N+kTS5sIK
W5kAhGSsCPLn5jIruCn3PB13/24gHLGRjxCFPjEyz+BbieRHgN8gcFuMiNcoYv1U
YdF8TuBrm/GV9Dql0Ilsv0MNI4lYpcn6qNocSyy7mqe6/ksyZ+H0kZ//36oqATSr
3eiqkse7DJsV+EhxdIHECKAncAZwrQAuc1XMKOPSk+zS0Niz+8lJ95v3UVuotTjh
UuZTskSkB1CjZzLUkWB1OL/DMcA+aGKit9BM7j2OJ2DveJzjM4wBqQf6DRU/ymw0
igZF2gHo1rJ1aLwjp4hfxduUIhR+vXajO+PZB94pM40Hp6ePiXVtO7Gt6aLJe9Wv
KeIR32/aRVdndHNJA4HuwT0vomBovr+aiO5djkq9Xty2RyIibmekNqCIrYRg0PRF
UpUUHWK0XeRMaELNKXfumg26RizgPO1hmd0dVK0c7SO3XD61oicrt6g+SBXzPHW5
FseukeMtNDYhKU5dRLjOXndrg68nbVtfi/YPOOHFUHOwxe/3I9A=
=qaD9
-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] Exim 4.89 RC1 uploaded

[Phil Pennock]

On 2017-01-31 at 22:27 -0500, Phil Pennock wrote:
> RC2 will be cut either on Wednesday or Thursday of this week.

Jeremy is working on some GnuTLS problems which should be fixed for
4.89; there's not much point deliberately cutting a Release Candidate
which isn't really a candidate.

So RC2 will be delayed.

-Phil

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

Re: [exim-dev] [exim] Exim 4.89 RC1 uploaded

[Phil Pennock]

On 2017-01-30 at 22:54 -0500, Phil Pennock wrote:
> Tentatively thinking of an RC2 on Thursday, unless something less
> cosmetic comes up in the mean-time.

Known regression: Proxy Protocol v2 broken in RC1.  Fixed in master,
will be cherry-picked into RC2.

In unbreaking TLS-on-connect in combination with Proxy Protocol (had
never worked) I fixed PPv1 but did not look closely enough at PPv2; I
not only didn't fix TLS-on-connect for PPv2 but also introduced a
regression which stopped PPv2 from working at all.

Folks may be heartened to know that this was caught by our build farm
test suite doing CI testing of the master branch.

RC2 will be cut either on Wednesday or Thursday of this week.

If all goes smoothly, I currently expect to cut 4.89 release on Monday
20th February.  If no major issues crop up with RC2, that will give us a
week of baking.

-Phil


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

Re: [exim-dev] [exim] Exim 4.89 RC1 uploaded

[Phil Pennock]

On 2017-01-30 at 21:51 -0500, Phil Pennock wrote:
> I have uploaded Exim 4.89 RC1 to:
> 
> https://ftp.exim.org/pub/exim/exim4/test/
> 
> This is a stabilization release containing a number of bug-fixes; the RC
> process for 4.89 will be accepting bug-fixes only, with a release-branch
> in git so that any developments need to be explicitly carried across.
> 
> As of RC1, I have not yet done a full sweep to ensure that documentation
> correctly marks new features; the binary appears to identify itself as
> "4.89" not "4.89RC1".  All bugs so far identified as critical are
> believed to have been fixed.

The files in the tarball are created with too tight a umask; that has
been fixed for the next RC.

The `spec.txt` and `filter.txt` in the tarball are empty.  I missed
that, so I'll chase down why this error didn't abort the release
process, and fix the root cause too.

Tentatively thinking of an RC2 on Thursday, unless something less
cosmetic comes up in the mean-time.

-Phil

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

[exim-dev] Exim 4.89 RC1 uploaded

[Phil Pennock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I have uploaded Exim 4.89 RC1 to:

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

This is a stabilization release containing a number of bug-fixes; the RC
process for 4.89 will be accepting bug-fixes only, with a release-branch
in git so that any developments need to be explicitly carried across.

As of RC1, I have not yet done a full sweep to ensure that documentation
correctly marks new features; the binary appears to identify itself as
"4.89" not "4.89RC1".  All bugs so far identified as critical are
believed to have been fixed.

IDNA2008 support is now available; a number of DKIM, CHUNKING and Proxy
Protocol fixes have gone in; TCP Fast Open is a little more cautious
such that binaries may run better on older Linux kernels.  As we are
into 2017, the oldest OpenSSL supported by the OpenSSL project is 1.0.2,
so that is now the oldest version which the Exim Maintainers formally
"support" for Exim.  As of yet, I do not believe that any changes have
been merged which would break support for older OpenSSL, but you are on
your own if you try to use such.  We do have a new document describing
how to build and install a recent OpenSSL for use by Exim without
interfering with any system packages.

While I am Release Engineer for 4.89, I want to note that Jeremy Harris
has so far done the lion's share of the work, jumping on every issue
identified.  I've done just enough to start lubricating the rust off the
joints of my maintainership.

The important text-format documents can be reviewed at:

https://git.exim.org/exim.git/blob/exim-4_89_RC1:/src/README.UPDATING
https://git.exim.org/exim.git/blob/exim-4_89_RC1:/doc/doc-txt/ChangeLog
https://git.exim.org/exim.git/blob/exim-4_89_RC1:/doc/doc-txt/NewStuff
https://git.exim.org/exim.git/blob/exim-4_89_RC1:/doc/doc-txt/openssl.txt

The files are signed with the PGP key 0x4D1E900E14C1CC04, which has a
uid "Phil Pennock <p...@exim.org>".  Please use your own discretion in
assessing what trust paths you might have to this uid.

Checksums below.  Detached PGP signatures in .asc files are available
alongside the tarballs.

Please report issues in reply to this email, on exim-users.

Thank you for your testing and feedback,
- -Phil Pennock, pp The Exim Maintainers.


SHA256(exim-4.89_RC1.tar.bz2)= 
4e64927665c83aa9d18b1edc3cc73b1113c886925f71bd72eb3d598eb72ad573
SHA256(exim-4.89_RC1.tar.gz)= 
ab136923916b4c57906daa325c70ca67f94a8e13395c3fdc36f275134258ad8e
SHA256(exim-html-4.89_RC1.tar.bz2)= 
3a8990f4b2d3ff74ce368db52b82548e95db442d84848f86c44bedf14eb68201
SHA256(exim-html-4.89_RC1.tar.gz)= 
6ae981f08a897076e991605509f94092a2fb063b7850e1f20e1047f21d64fa4b
SHA256(exim-pdf-4.89_RC1.tar.bz2)= 
83e3ed3bd2ccf460c629ed2967148be03d0bdef408d9908be90a78cb86b572c9
SHA256(exim-pdf-4.89_RC1.tar.gz)= 
bc50da9dc931ef12e0018c83cd7a273d964c332a497d2b2ca3bc40fa0b3c770d
SHA256(exim-postscript-4.89_RC1.tar.bz2)= 
9d48d06034b920a156333f40e6a8993dfef7563af5a356e6266ee3b714458d17
SHA256(exim-postscript-4.89_RC1.tar.gz)= 
4499c0d1040c5b5ee14a9858668260acef7f2aea9c31c22ce7768ba639ae174b
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEExpOgNOHtbulUyuLaE9rZnH5BUZwFAliP+7IACgkQE9rZnH5B
UZy1bA//el2loHOIQTVjvFSDKRH01gAE2oO9MuQIlqElHtjnju//8QPUIScLwaoE
0v+6EOzJicH3nzaJMpjuOywxisgC7konUUras/X7++vL/WSEarcKxN634ONQd+kg
z1dI161XPMCHdossJZWbhSEOiY7EI8x6/Usf2dkxly/SyzbqYgvpJxqiGYBu5T7m
aQfu6iWTXzH+2+e18VGJjwk3Qbh77dZnr1/d1WHKCiPirMgFhapXtUbwrHZuwnu0
ay5ua+3RHmw4SMy318fb7r+sNy77xIKawXjXKRXVNlcRr0z3CW+V4gRf0rmiOxIU
WAkcJh1b4Jq+87jQ0KcG5uKKc7OhCW/38qS1aJZ3cXDCd001rftrfWkUarRycs9/
U32IXUp8aLJqp1Xuhj7wCrMm3UopNsa/uVoIX8PjhzqnGRouwG6ieO4Rfs6f6wkz
uJTDbwxcUQClZ0gUmIcqtHHlrUXD4wrjgPL9Vwja1mdZ8F6lpkh0AErtCfUWnPSJ
wskGWhMkKW42Rf+u4UMBs/0D2syg1Nn6YxIoKOVORXSikNqxadHYNN5MPF2LCOx7
HzcpjE++RLLc4pgFAEsC2q8d2LEgkjBq8DuatOItq//lplLh0atgEdYZw0yAtQ6p
bNqB3qALvAIUHmWRjK7twGDqSJJfoFxH3DFx5gbsBAgRGKOrCzU=
=PkOJ
-END PGP SIGNATURE-

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

[exim-dev] testdns.exim.org zone

[Phil Pennock]

I just realized, belatedly, that with exim.org fully under our control,
and DNSSEC-signed, I could include the DS glue for testdns.exim.org,
making it much more useful.

I'll aim to move the zone to be authoritative on the exim.org server, at
the same time that DNS moves over, but in the meantime: as it always has
been, "testdns.exim.org" is open-AXFR from "nlns.globnix.net".

For DNSSEC in particular, compare/contrast:

 mx.valid254.testdns.exim.org
   mx.invalid254.testdns.exim.org

The latter has a DS for the delegation but the zone is unsigned, so any
validating resolver should SERVFAIL the entire zone.  Dig with +cd to
"checking disable" to see it.


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] Exim 4.89 release process starts Jan 30

[Phil Pennock]

Folks,

I'm going to pick up the Release Engineer hat for the next Exim release.
The last few releases have been fairly big and ambitious and a few of us
think that a stabilization release is called for.

Jeremy and Heiko have a fix for the DKIM/chunking issues in soak-testing
now, it'll go in soon.

I expect to start the RC process on Monday 30th January.

This will be a strict RC series with no new features after RC1 is cut
unless critical to fixing known bugs.  New features might still go in
before then, but please don't rush things in!

I'll probably branch git for 4.89 and let folks continue to commit to
master and merge in anything relevant for the release.

I'll look at Bugzilla a fair bit next week to try to triage issues; for
anything that's a feature, it will be punted to 4.90 at the earliest.
If you are tracking dev and know what's in git master already, and think
that there's an open issue which hasn't been fixed but should be before
the next release, then please reply off-list to me with ticket numbers
and explanation.

Thanks,
-Phil


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

Re: [exim-dev] [Bug 2018] proxy protocol is not supported on smtps (direct SSL/TLS) connections

[Phil Pennock]

On 2017-01-18 at 16:06 +, Jeremy Harris wrote:
> To expand: Exim's implementation of Proxy Protocol
> is currently hooked in after the TLS start done for
> tls-on-connect.
> 
> It turns out that the protocol spec document is ambiguous
> and the other way about (proxy-protocol handling done
> in-clear, then TLS) is the preferred way for HAproxy.
> 
> Is anyone using and relying on the current Exim implementation
> ordering?   Or shall I just swap them round?

I think that Jeremy knows my opinion here, but so that others know what
is likely to happen if nobody speaks up:

I strongly favour swapping them around, putting a note in
README.UPDATING and avoiding adding yet another knob.

So if you are relying upon something which speaks Proxy Protocol
initiating its _own_ TLS connection to an Exim TLS-on-connect backend,
_then_ speaking PP within that, _before_ passing off to hand-off from
the origin client, then you need to speak up with some details so that
we can understand and weigh the cost of the added complexity, and make
sure that we can then handle it without ending up with TLS tunnelled
inside TLS.

-Phil

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

[exim-dev] test, ignore

[Phil Pennock]

Ignore please.

Exim admin host reboot for updates, double-checking list mail is
flowing.

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

[exim-dev] https://git.exim.org -- mandate?

[Phil Pennock]

Since Monday morning, we've had https://git.exim.org available.
http://git.exim.org is still available.

Does anyone have strong opinions over whether or not http://git should
force-redirect to https://git ?

For FTP site contents, it doesn't make much sense, since ftp:// remains
available and all retrievable code objects have signatures.

For git ... as far as I know, we don't have cloneable resources
available over http/https, so there's no repo breakage to risk.  We also
don't currently have authenticated access and so the risk of private
repo access.  So there's nothing too significant to risk.

But on the principle of "encrypted by default", we could do it, and
perhaps set some HTTP security headers.

Any opinions from those involved in dev?

-Phil

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

Re: [exim-dev] Administriva: Bugzilla spam

[Phil Pennock]

On 2016-11-24 at 22:33 +, Nigel Metheringham wrote:
> We have had a few cases of someone deciding to spam bugzilla with spammy
> content bug reports.  Bugzilla is not very good at defending against
> these, and unfortunately Bugzilla feeds into the exim-dev list.
> 
> I have put some additional measures in place to block this, stripped the
> spam bugs, and removed the trust between the exim-dev list and bugzilla.

I didn't check here before responding to mail from maintainers and so in
addition to Nigel's actions: account creation in the Exim Bugzilla is
currently disabled.

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

[exim-dev] base64url (& base32hex) operators; build fixes

[Phil Pennock]

I've pushed to master a build fix for handling the hash split spreading
the dependencies upon OpenSSL headers; I handled the pkg-config cases,
it's possible that `src/EDITME` should be updated to note that CFLAGS
will need updating, not just TLS_INCLUDE.

I also updated for GnuTLS but that's untested.

This is bug 1906.

Per an idea on exim-users, I've added new expansion operators; this is
in the rfc4648 branch of the main repo.  Since we're into RC I'm not
merging a feature addition myself.  Please feel free.

Note that I've added test cases but not invoked them: recent system
reinstalls leave me currently without the test suite available.  See
what happens with the build farm?

This adds base64url/base64urld to use the URL & Filename Safe Alphabet,
so that `/` does not appear in the results.

While in there, I added base32hex/base32hexd; I'm not too sure about
this, since we're using numbers-only in a way which isn't the normal
text-encoding system (eg, `0` encodes to empty string, etc).  But since
in there, I went for it.  I'm not wedded to this, we could strip it out
again.  If this handled non-numbers then the use-case would be simple:
it preserves sort-order.

Shockingly, the reference for the alphabets is ... the RFC named in the
branch-name, RFC 4648.

-Phil

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

Re: [exim-dev] Exim4 spool directory symlink local root escalation - does this apply to 4.87?

[Phil Pennock]

On 2016-09-11 at 22:41 +0100, Jeremy Harris wrote:
> There's a minor complication in that the -J file is opened in two
> places (as it happens, in a single routine: deliver_messsage()).

Why is the journal ever being opened as root, instead of as the Exim
run-time user?  That seems like a flaw, and a root-cause to be
addressed.

> - Finally, the first open should be done with an O_NOFOLLOW
> flag (at least, on platforms supporting that.  Linux does;
> apparently FreeBSD also).   This closes the main hole.
> (Where O_NOFOLLOW is not we could shorten the hole to a large
> extent by a stat-check of the file right next to the open -
> but it seems hard to totally close that way.  Perhaps a stat
> and an fstat both after open, comparing the ino?  Is it
> worth coding that?)

IMO:

* Use `O_NOFOLLOW` where available
* Stop trying to open the journal as root

Platforms which don't support `O_NOFOLLOW` have bigger issues.  It's a
good guard to use to protect, where available.

But if the journal, in the Exim run-time spool area, is only ever
_opened_ as the Exim user, then there is no vulnerability.  The root
cause is that root is doing something in an area where it's unsafe for
root to be acting in such a manner, and if that's true, then there's a
process flow bug in Exim.

> I've coded that (attached) but due to the sensitive nature,
> both re. security and data-integrity I'm reluctant to commit
> it without review by other developers.
> 
> Comments?

> diff --git a/src/src/deliver.c b/src/src/deliver.c
> index 48ef2ab..fe2fc6d 100644
> --- a/src/src/deliver.c
> +++ b/src/src/deliver.c
> @@ -5513,26 +5513,15 @@ Otherwise it might be needed again. */
>uschar * fname = spool_fname(US"input", message_subdir, id, US"-J");
>FILE * jread;
>  
> -  if ((jread = Ufopen(fname, "rb")))
> +  if (  (journal_fd = Uopen(fname, O_RDWR|O_APPEND
> +#ifdef O_NOFOLLOW
> + |O_NOFOLLOW
> +#endif
> + , SPOOL_MODE)) >= 0
> + && lseek(journal_fd, 0, SEEK_SET) == 0
> + && (jread = fdopen(journal_fd, "rb"))
> + )

% view $(fgrep -rl Ufopen .)

Some of those are for user-supplied files (`bounce_message_file`,
`${readfile...}`) but a few others are not.

Look also at parse.c:parse_forward_list() where there's an
EXIM_HAVE_OPENAT ifdef block for logic to defend against symlinks.
And `O_NOFOLLOW` is already being used in there.

The above is a decent mitigation for this incident, but perhaps the
OPENAT logic needs to be encapsulate into a `safe_fopen()` wrapper and
used in more places?

-Phil

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

Re: [exim-dev] [Bug 1837] small subgroup attack

[Phil Pennock]

On 2016-05-29 at 02:10 -0400, Viktor Dukhovni wrote:
> But, (broken record), do yourself a favour and just drop these groups...

We can change the default.  We can add new groups.

We won't remove documented values, exposed to configuration, short of a
release where we are accepting non-backwards-compatible changes.  We
particularly can't immediately remove a value which was documented as
the default.

We should "fix" the groups present even if they're no longer the
default, so that they're less dangerous.

nb: my crypto knowledge is mostly at the "dangerous" level, not skilled.
I didn't know that the addition of 'q' made DH stored values into DSA
values.  This is why, for a long time, we refused to put crypto policy
into Exim and tried to just use OpenSSL defaults.  We're being bitten
here because in 2012 I tried to do the safest thing possible to make DH
work for everyone, reliably.

-Phil

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

[exim-dev] Test message, ignore please

[Phil Pennock]

(post-maintenance probe that mail is flowing through list manager)

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

[exim-dev] Exim git repo maintenance

[Phil Pennock]

I've ensured that all the Exim repos on Hummus directly in /srv/git have:

  sharedRepository = 0002

A couple of newer repos were missing it.  I've also done a chgrp/chmod
so that their content is all in group `eximdev` and has group-write
permission.

I've run the periodic maintenance task:

  git fsck && git gc && git repack -Ad

For the Exim repo itself, the `-d` might have been a mistake and made
things slower for those doing a `git pull` the next time.  Still, quite
a bit faster for those doing a fresh checkout and not too bad for an
incremental (and after the first incremental after this change, you're
back to normal).

We might consider a cron job to `git repack -A` each main repo on a
monthly basis?

-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] Debian CI testing of Exim

[Phil Pennock]

The tests run appear to be very limited right now, but it might be worth
figuring out if Exim can make it easier to use more of the current test
suite:

  https://ci.debian.net/packages/e/exim4/unstable/amd64/

-Phil

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

Re: [exim-dev] El Capitan devs wanted

[Phil Pennock]

On 2015-12-02 at 14:43 +, Jeremy Harris wrote:
> Do we have anybody out there doing development work on MacOS?
> (Come to that, do we have any users?)

Me, though not MacOS-specific.  Golang work with Mac as my local system.
I've occasionally built Exim for laptops, but usually log into other
systems.

I've yet to make the jump to El Capitan.  Waiting for 10.11.1 or 10.11.2
before I do.

> I hear via another project that OX 10.11 El Capitan has removed
> the OpenSSL header files, presumably as part of Apple's apparent
> push to get all Mac software to use *their* security.  This presents
> an issue for continued Exim development.  One option would be to
> add a third supported TLS package to the two (OpenSSL, GnuTLS)
> currently supported - but this will be a fairly large effort and
> one I think best done by a dev who has a need for it (which means,
> not me).  Another would be to note that you have to install your
> own OpenSSL headers.
> 
> Or, we could abandon MacOS for the future.

Viktor is right, this isn't a big deal.  We just declare "we depend upon
either OpenSSL or GnuTLS, install one first".

It means that those who haven't already done so run `brew install
openssl`.

Witness:
  https://github.com/Homebrew/homebrew/blob/master/Library/Formula/exim.rb
- already depends upon the brewed variant of OpenSSL.

I haven't installed brew'd Exim before, I normally build from source/git
when I want one locally, I have a Local/Makefile and template configure
file checked into git somewhere.

Apple's change makes it _easier_ for us, because we'll have less dealing
with people who build against one set of headers but link against a
different library.  They'll have to be specifying a header include path
so are more likely to be specifying a library path too.

-Phil

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

Re: [exim-dev] exim .editorconfig -- any objections?

[Phil Pennock]

On 2015-08-28 at 23:01 +0200, Heiko Schlittermann wrote:
> Phil Pennock <p...@exim.org> (Fr 28 Aug 2015 20:59:16 CEST):
> > I'm not inclined to rush to bulk-edit every file for a New World Order.
> > I'd rather see people get comfortable with this approach and then, if
> > there's consensus, we might strip later.
> 
> I'd vote for a bulk-edit and a single commit. Because otherwise I'd be
> afraid that we start mixing code changes with stripping these vi(im):
> lines, creating a mess of commits.

Yes, sorry, I couldn't figure out the right way to express this.  A
bulk-edit is right, so that there's one change, but I don't want to
force this through immediately.

People might scream and we'd revert .editorconfig or something.

I try to be cautious about forcing my views on others, unless I'm the
one writing the code, in which case y'all can suck it.  :-D

-Phil

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

Re: [exim-dev] exim .editorconfig -- any objections?

[Phil Pennock]

On 2015-08-28 at 15:40 +0200, Heiko Schlittermann wrote:
 Jeremy Harris j...@wizmail.org (Fr 28 Aug 2015 15:12:22 CEST):
   I _think_ that it reflects what's as close to common practice as we
   come.
  
  If it works with whatever vi-de-jour I happen to be using, I guess
  it's ok.  I see vim is specifically noted on the website as requiring
  a plugin to work with it, along with a lot of other editors.

It's one common spec, so instead of littering the source files with
per-editor configs, we can at least get the very basics down in one
common place.

  Can it handle the other things I commonly set in a vi: config line;
  autowrite, autoindent?

No, it just covers the basics.  Common indent amounts, sw=2 etc.  Even
this initial file includes:

  # vim users try: cinoptions=1s,{1s

That's just something I grabbed from my ~/.vimrc as applying to exim
paths, which I couldn't map, so I figured a comment in this file was the
right place for it.

 For vim I'm using now that plugin (via pathogen) and it seems to work.
 Changes in .editorconfig override settings from my global ~/.vimrc and
 settings via modeline in turn override the .editorconfig settings.

Please note: I'm not trying to force anyone to install editorconfig
plugins; it's a useful system which is entirely optional, and doesn't
impact on people not using it, but provides a nice readable common
source for settings.

I will probably keep, in my ~/.vimrc, this:

if has(autocmd)
  au BufNewFile,BufRead */*exim*/src/* set noai nosmartindent expandtab cindent 
sw=2 cinoptions=1s,{1s
endif

 This means, we should strip the modlines from all source files, shouln't
 we?

Not all.  Some, especially on Perl files, set different shift-widths.
There were only a couple of files affected at all ... but now I see that
I only grep'd for `vim:`, not for `vi:`.  Oops.

Looking at `vi: aw ai sw=2` ... I think that `autowrite` is
inappropriate to share in a common source tree, as that's a mode of
working, so belongs in a personal .vimrc; `ai` is nice to help people
lay things out right, but again is around what the editor does for
you, not what the code must look like.  Which leaves just `sw=2`.

(Sorry Todd, I hadn't realized those were so prevalent back when I
 reviewed your Python interpreter work)

We can add comments to the `.editorconfig` file with suggestions for many
text editors, as just one common place which exists.  I'll do so, for my
.vimrc suggestion above.

I'm not inclined to rush to bulk-edit every file for a New World Order.
I'd rather see people get comfortable with this approach and then, if
there's consensus, we might strip later.

-Phil

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

[exim-dev] 4.86-rc4 issues / notes

[Phil Pennock]

In 4.86-RC4 setting the DISABLE_PRDR compile-time option results in
inability to compile.  There are also a number of complaints from my
compiler which might be of interest.  At this point in the RC process,
given that I'm not driving things, I'm keeping myself to _just_ fixing
the two compilation errors.

First the patch which I'm going to commit:
8 cut here 8--
--- acl.c.old   2015-07-12 19:06:24.683723864 -0400
+++ acl.c   2015-07-12 19:15:16.613686692 -0400
@@ -3372,7 +3372,11 @@ for (; cb != NULL; cb = cb-next)
break;
 
case CONTROL_CUTTHROUGH_DELIVERY:
+#ifndef DISABLE_PRDR
if (prdr_requested)
+#else
+   if (0)
+#endif
  /* Too hard to think about for now.  We might in future cutthrough
  the case where both sides handle prdr and this-node prdr acl
  is accept */
--- smtp_in.c.old   2015-07-12 19:17:46.360676653 -0400
+++ smtp_in.c   2015-07-12 19:19:38.245668910 -0400
@@ -1515,7 +1515,9 @@ sender_verified_list = NULL;/* N
 memset(sender_address_cache, 0, sizeof(sender_address_cache));
 memset(sender_domain_cache, 0, sizeof(sender_domain_cache));
 
+#ifndef DISABLE_PRDR
 prdr_requested = FALSE;
+#endif
 
 /* Reset the DSN flags */
 dsn_ret = 0;
8 cut here 8--

Installing on FreeBSD 10.1/amd64 with CLang as the compiler;
  % cc --version
  FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
  Target: x86_64-unknown-freebsd10.1
  Thread model: posix

8 cut here 8--
clang acl.c
acl.c:3375:6: error: use of undeclared identifier 'prdr_requested'
if (prdr_requested)
^
acl.c:3531:19: warning: passing 'const uschar **' (aka 'const unsigned char 
**') to parameter of type 'uschar **'
  (aka 'unsigned char **') discards qualifiers in nested pointer types 
[-Wincompatible-pointer-types-discards-qualifiers]
  rc = demime(arg);
  ^~~~
./functions.h:140:32: note: passing argument to parameter here
extern int demime(uschar **);
   ^
1 warning and 1 error generated.
*** Error code 1
8 cut here 8--

My persisted (from 4.84) Local/Makefile for this box contains:
  DISABLE_PRDR=yes
  DISABLE_OCSP=yes

Fixing that error, then:
8 cut here 8--
clang deliver.c
deliver.c:3964:28: warning: expression result unused [-Wunused-value]
!tp-expand_multi_domain || (deliver_set_expansions(next), 1),
 ^  ~
1 warning generated.

clang dns.c
dns.c:998:7: warning: add explicit braces to avoid dangling else 
[-Wdangling-else]
  else if (namesuff - 4  name  strcmpic(namesuff - 4, US.ip6.arpa) == 
0)
  ^
1 warning generated.

clang exim.c
exim.c:2248:43: warning: passing 'uschar **' (aka 'unsigned char **') to 
parameter of type 'const uschar **'
  (aka 'const unsigned char **') discards qualifiers in nested pointer 
types [-Wincompatible-pointer-types-discards-qualifiers]
  while((filename = string_nextinlist(list, sep, big_buffer,
  ^
./functions.h:424:49: note: passing argument to parameter here
extern uschar *string_nextinlist(const uschar **, int *, uschar *, int);
^
exim.c:3413:46: warning: add explicit braces to avoid dangling else 
[-Wdangling-else]
  if (++i  argc) log_oneline = argv[i]; else
 ^
exim.c:5379:11: warning: add explicit braces to avoid dangling else 
[-Wdangling-else]
  else
  ^
3 warnings generated.
clang expand.c
expand.c:6658:3: warning: add explicit braces to avoid dangling else 
[-Wdangling-else]
else
^
1 warning generated.

clang parse.c
parse.c:556:5: warning: add explicit braces to avoid dangling else 
[-Wdangling-else]
else
^
1 warning generated.

clang readconf.c
readconf.c:3757:7: warning: add explicit braces to avoid dangling else 
[-Wdangling-else]
  else
  ^
1 warning generated.

clang smtp_in.c
smtp_in.c:1518:1: error: use of undeclared identifier 'prdr_requested'
prdr_requested = FALSE;
^
smtp_in.c:3016:5: warning: add explicit braces to avoid dangling else 
[-Wdangling-else]
else
^
1 warning and 1 error generated.
8 cut here 8--

8 cut here 8--
clang tls.c
In file included from tls.c:120:
./tls-openssl.c:423:17: warning: implicit declaration of function 
'X509_check_host' is invalid in C99
  [-Wimplicit-function-declaration]
  if ((rc = X509_check_host(cert, name, 0,
^
./tls-openssl.c:711:13: warning: passing 'char [26]' 

Re: [exim-dev] Exim 4.86 RC2 uploaded

[Phil Pennock]

On 2015-06-17 at 20:09 +0200, Andreas Metzler wrote:
 On 2015-06-15 Jeremy Harris j...@wizmail.org wrote:
 [rc2]
  Please report issues here in exim-dev, or in
  the exim-user mailinglist, or by raising bugs
  on http://bugs.exim/org
 
 Hello,
 
 I have just uploade to rc2 to Debian/experimental.
 
 What I stumbled upon while browsing the diff to rc2 is that
 doc/doc-txt/ChangeLog was not updated since rc1.

Possibly a mis-communication on my part of what it means to be a build
cutting monkey, not this iteration's release engineer and Jeremy
thought I would do it and I thought Jeremy had done it.

Sorry.

Jeremy, please fix before RC3.  :-D

/me runs
-Phil

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

[exim-dev] git.exim.org SSH fingerprints public statement

[Phil Pennock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2015-05-01 at 20:18 +0100, Nigel Metheringham wrote:
   - Git access over ssh will have a different host key

This statement should be signed by a PGP key in the strong set, to let
you verify the trust assertions herein.

Of my own direct knowledge, I hereby affirm that these hostkeys are
correct for `git.exim.org` (this format suitable for inclusion in
known_hosts unless you prefer entries to be hashed):

- 8 cut here 8--
git.exim.org,131.111.8.88,2001:630:212:8::e:f0e ecdsa-sha2-nistp256 
E2VjZHNhLXNoYTItbmlzdHAyNTYIbmlzdHAyNTYAAA4UK+P4SAgUqS1A7IzpnfXvnCC4LAgJFCfqlF4tHiCIvrlXWbs82XShyiqTQKArSi8t/ekYpaZmOlaQW1KAki8=
git.exim.org,131.111.8.88,2001:630:212:8::e:f0e ssh-ed25519 
C3NzaC1lZDI1NTE5IC+mDJL1Uzv6SwERrxdyLig5ZRG6vzOYJYWDi3q7p3z2
git.exim.org,131.111.8.88,2001:630:212:8::e:f0e ssh-rsa 
B3NzaC1yc2EDAQABAAABAQC4ut9NVD1t1jt26fEoMQo8R0n0HbSr4L52WcdHP70W4kHQFXi2oyCaMjMNQdbAykIciIRBpky3zqW9leiDu6ACyWt9FKHhSKp90Mh0yB0Gnq0adWA0S4TQbb2qBjttp/d/+6CpjVYMFnLBJumA11cvWWR9p9rVZRYbdusCS1UKLogdg/SnVQ/EPg89MlXLr0Sn/ZwAx0ybc95RTeiOu/Wj1RMeObxSv9vrUCGcaH25eLxIaVaNp3GUu35INDVxeTg7nkMtG53FW++0nVOeJHlVucvGkPk3np2kxMHb/RJV2lPK9Dp/VI3FkB4ec/H+j79qC+Du8AEK/QK7ble7O943
- 8 cut here 8--

These are the old-style digests; note that hummus is the name of the
machine behind `git.exim.org`:

  256 a5:0f:67:fa:91:79:7a:e9:b4:21:ab:dc:07:c3:65:62  root@hummus (ECDSA)
  256 21:d2:70:9c:59:43:5d:c9:dd:1d:f7:a6:a9:9f:bc:c3  root@hummus (ED25519)
  2048 51:71:e6:5f:6e:06:83:ed:cb:72:be:4f:3f:c7:11:fb  root@hummus (RSA)

As of OpenSSH 6.8 a newer format is used by default (not based on MD5!)
and you should expect to see one of these:

  256 SHA256:IPuTfrm4euxWbf8Kl7MZY6P13Xy7qeIFV068Z26ELf8 root@hummus (ECDSA)
  256 SHA256:v0uTdvX//itZoJSGON87TXfQLaLLjETLyQ0L8XTyLl4 root@hummus (ED25519)
  2048 SHA256:1exf8JxvQQ7Oaxyxdme6rsTfzfD3C9kELf3FvtGuAE8 root@hummus (RSA)


Basis for direct knowledge assertion: I did the SSH setup on this box
some time back; after the initial connection, I have never blindly
accepted the hostkey, but have consistently connected to the same box
(purportedly in Cambridge, UK).  I generated some of the hostkeys.  We
use etckeeper to control these files and it has not seen any changes,
while one of the backups of etckeeper is to a box under my personal
administrative control.  (Yes, that means that I could set up a box
which fraudulently claims to be the new one).  I pulled the fingerprints
above from the files in `/etc/ssh` just now.

On the old box, we had RSA and DSA keys, both 1024 bits.  There is no
DSA key on the new box.

The IP addresses can be seen in
https://github.com/Exim/exim-dns/blob/master/exim.org.lua and note
that commit `67657780` by me (in 2013) set the IP addresses.

- -Phil Pennock, p...@exim.org
-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJVR+/yAAoJEE0ekA4UwcwELJ4P/3lFHL1yH0e1nWphymQRAco7
SL18aV3afvKLaSpqixeENXEIWjb7iCiKWbdiKK5KI4pFpzo3ERcDy7+4xlBfxayf
WINTbdzQR6JNzc4yKTv06EGdTmsvijOn0JGiKwwIHYb7C6Qb5I8KkGv7Mpq5W/6d
+DX3kpkPbf2fE4QnisCtyl5BJLSN1Rp8xNJ02wE+azGDQRw+qXU9/3ObsEwldnUF
cXJMTC6qFdygsV5ryhVb6ewM0B5pw5Aw/IsXO7NB/8sn1GLGm4S9UCtQqQttPr3V
AtjAiq5RLYDxLyMV5jkZkQGdVQPraEQOTHmqTMwkHZfqZv/JHALp+y9i8RGty9oA
AS9CJwQ4L8W2zRRTuSCKNKCSJpbB77pHaoRiyTIYkD2nEjCI0AeRolfY3F3dAkUJ
/KkHU2os0y8SJQnRTSmnWn93PMT+1bkc2JVypcVJZ8EDKiqoJAKqHrcDD+z0VpND
IXeG1TCagRKg0vanFrycvYLl6IGNYCMGyVMBFYkksXS0rrDmtOUneduwLw+m1T+P
EiB+MoBjetSCpVT5y/qxkJhDMoMAufY1JNjoDP+Vd2D+dYXLPBd5nJVETvJCNRlI
aFJwENN1zuaeysLR1rCc8pX4jh8TTRwZw9ObFchmzuMOEWOOymMUtbsPwawZ+q27
8YPZi7igtEi0S0WvJxKq
=c40b
-END PGP SIGNATURE-

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

[exim-dev] [Bug 1623] macro expansion in -be '...'

[Phil Pennock]

--- You are receiving this mail because: ---
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1623

Phil Pennock p...@exim.org changed:

   What|Removed |Added

 CC||p...@exim.org




--- Comment #1 from Phil Pennock p...@exim.org  2015-04-28 23:12:18 ---
Beware setups which use macros for hiding semi-secrets, such as signing tokens;
might want to make this macro-expansion something which requires that the
invoker be in the admin users/groups list.


-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

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

[exim-dev] [Bug 1623] macro expansion in -be '...'

[Phil Pennock]

--- You are receiving this mail because: ---
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1623




--- Comment #2 from Phil Pennock p...@exim.org  2015-04-28 23:16:31 ---
Supporting context for that assertion: this require admin user priv is the
trade-off I made when adding macro support to exim -bP:

If invoked by an admin user, then macro, macro_list and macros are
available, similarly to the drivers. Because macros are sometimes used for
storing passwords, this option is restricted. The output format is one item
per line.

So using the same filter here makes sense.


-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

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

[exim-dev] Fwd: Fix mobile usability issues found on http://www.exim.org/

[Phil Pennock]

This seems to be a new set of analysis tools, got warnings like this for
my own site too.  I don't recall off-hand who has access to the account
for the Google Webmaster stuff for managing www.exim.org; if there's
anyone who wants to handle website stuff who doesn't have that access,
but think you should, then drop a reply here and we'll look at getting
that fixed.

-Phi

- Forwarded message from Google Webmaster Tools Team -

From: Google Webmaster Tools Team
Subject: Fix mobile usability issues found on http://www.exim.org/
Date: Wed, 18 Mar 2015 09:19:50 -0700 (PDT)
Message-ID: 
defea099739210a4.1426695565304.558701.451500.en.cb66e02bdab1e...@google.com

To: webmaster of http://www.exim.org/

Google systems have tested 345 pages from your site and found that 79% of them
have critical mobile usability errors. The errors on these 271 pages severely
affect how mobile users are able to experience your website. These pages will
not be seen as mobile-friendly by Google Search, and will therefore be
displayed and ranked appropriately for smartphone users.


Fix this now:

1. Find problematic pages
View a report of the non-mobile-friendly pages found on your site, and the
issues discovered:
https://www.google.com/webmasters/tools/mobile-usability?siteUrl=http://www.exim.org/

2. Learn about mobile-friendly design
There are a variety of techniques you can use to make your site
mobile-friendly. Specifically, look for information about the issues brought
up in Webmaster Tools:
https://developers.google.com/web/fundamentals/

3. Fix mobile usability issues on your site
Fix the issues preventing your site from being mobile-friendly.


Not sure how to proceed?

* If your site is built with software like Wordpress or Joomla (also known as
Content Management System or CMS), read the easy steps to make a CMS
mobile-friendly:
https://developers.google.com/webmasters/mobile-sites/website-software/

* Read more about building mobile-friendly websites on our Developer site:
https://developers.google.com/webmasters/mobile-sites/get-started/

* Ask a question in our forum for more help - mention message type
[WNC-451500].
https://support.google.com/webmasters/go/community

- End forwarded message -

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

[exim-dev] [Bug 1598] The 'inlist' expansion condition does not expand a named list

[Phil Pennock]

--- You are receiving this mail because: ---
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1598

Phil Pennock p...@exim.org changed:

   What|Removed |Added

 CC||p...@exim.org
 Status|NEW |RESOLVED
 Resolution||INVALID




--- Comment #2 from Phil Pennock p...@exim.org  2015-03-09 09:48:36 ---
It's deliberate that inlist not handle named lists, and it's documented that
way.

The problem is that using the more powerful generic lists mechanisms led to
lookups being used, which led to people writing exploitable configurations
because they'd put data extracted from emails into the list of things being
matched.

-
inlist {string1}{string2}, inlisti {string1}{string2}

Both strings are expanded; the second string is treated as a list of simple
strings; if the first string is a member of the second, then the condition
is true.
-

The documentation states that it's a list of simple strings and provides
examples.  The documentation is correct.  This is the desired state.


-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

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

[exim-dev] [Bug 1590] outbound SOCKS proxy support

[Phil Pennock]

--- You are receiving this mail because: ---
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1590




--- Comment #1 from Phil Pennock p...@exim.org  2015-02-23 01:01:35 ---
Authentication is going to be necessary for any of the real-world scenarios
where I'd have wanted this feature.

Agreed SOCKS5.

The big issue is that SOCKS is often used to defer DNS resolution to the SOCKS
proxy.  I think that we just say no, DNS resolution is too intrinsic to how an
MTA operates, we resolve all DNS in Exim; if Exim can't resolve a hostname, it
couldn't resolve anything else which was needed too.  I think that this ties
into your Destination by name? question.

My tentative thinking was SMTP Transport, and a `socks_url` option; I'm open to
the idea of `socks_user` and `socks_password` as separate options which _can_
be used to override information from the `socks_url`.  Primarily so that an
admin can write `hide socks_password = wibble` to use the `hide` functionality
of Exim's configuration.

The option should be either a single URL or something identifying a list of
servers; we should look at how things like spam-scanning servers are identified
to figure out our current best practice for define a set of remote servers and
the failover policy for them.

I also would not be averse to the idea of being able to write
`${environ{SOCKS_URL}fail}` to grab the value from the environment, which is
more in keeping with a lot of modern application deployment, but I think that
this is orthogonal (just useful in many of the same deployment scenarios).


-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

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

Re: [exim-dev] EXPERIMENTAL_PROXY clarification

[Phil Pennock]

On 2015-02-10 at 14:58 +, matthew.schlos...@thomsonreuters.com wrote:
 The why without? question is answered with a long litany of security 
 regulations, privacy laws and way too much privileged detail to make public.
 
 We currently use Sendmail, but as you may know, it doesn't scale well hence 
 the existence of a zillion other MTAs.
 
 If Socks support is not possible I'll keep hunting unless someone feels 
 really excited to take a crack at it and let me play Beta Tester.
 
 Thanks for the consideration and good work.  I've used Exim at ISPs and 
 enterprise shops for years.  I even built a RESTful interface to 
 programmatically manage the MTA config and queue.
 
 Here's to hoping flattery will get me everywhere,

I fully understand why SOCKS, it's one of those things which I'd need to
implement to be able to use Exim in a certain project for $work, but I
haven't had time, so I haven't put in the development work.

If the code is written and contributed, I'd be happy to review, but at
this time I'm not likely to be writing it myself.

-Phil

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

[exim-dev] [Bug 1580] 【remote exec vulnerability】

[Phil Pennock]

--- You are receiving this mail because: ---
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1580




--- Comment #2 from Phil Pennock p...@exim.org  2015-01-28 18:54:16 ---
In particular, for the record so that folks know why this is being dismissed so
readily:

http://www.openwall.com/lists/oss-security/2015/01/27/9

http://arstechnica.com/security/2015/01/highly-critical-ghost-allowing-code-execution-affects-most-linux-systems/

Also, there is an Exim-Announce mail warning of the issue and including
mitigation factors which can be applied, as exposing this vulnerability
requires turning on specific Exim configuration options, so turning them off
again will help; see:

https://lists.exim.org/lurker/message/20150127.200135.056f32f2.en.html
http://permalink.gmane.org/gmane.mail.exim.announce/162
(same post, two different archives)


-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

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

[exim-dev] [Bug 1578] Solaris 8 build with TLS failed due to undefined setenv/unsetenv

[Phil Pennock]

--- You are receiving this mail because: ---
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1578

Phil Pennock p...@exim.org changed:

   What|Removed |Added

 AssignedTo|p...@exim.org|jgh146...@wizmail.org




--- Comment #1 from Phil Pennock p...@exim.org  2015-01-27 00:08:41 ---
Appears to have been introduced with commit e9477a08 2014-11-10 with the
restore_tz() function for bug 1541 Handle UTC vs specified-timezone for
certificate extractors.

SUSv4 text for setenv says First released in Issue 6. Derived from the IEEE
P1003.1a draft standard.

There's a minor robustness problem with the current code, since I don't _think_
unsetenv() is guaranteed to remove _all_ instances of a given environment
variable name from environ; the FreeBSD unsetenv(3) documents that it does so,
the Linux man-pages document does not, SUSv4 does not.  So starting Exim with
[TZ=a, TZ=b] may result in unsetenv not entirely removing TZ as expected.


-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

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

Re: [exim-dev] XCLIENT patch to Exim; Cambridge

[Phil Pennock]

On 2015-01-16 at 00:52 +, Jeremy Harris wrote:
 We need, I think:
 - project sponsor

If Tony, at Cam, can handle it, that would be ideal; otherwise, I seem
to have already done more work than we usually do for any feature being
merged from a submitted patch.  ;)

(Of course, we also need more committers ...)

 -- delivery positioning (experimental?)

Yes.  At least until we have tests, which means figuring out how to
test, a test framework, etc etc.  None of which is trivial, so this is
the sort of thing which goes in as EXPERIMENTAL_XCLIENT as a this code
exists, we might break it still bucket.

 -- legal chasing

We appear to have approval to include, so done.

 - coder/architect
 --  builds, testcases, documentation
 --  security review (coding, operational constraints, logging)
 --  feature-incompatibility (proxy-protocol?  TLS?  X509 certs?)
 --  coding standards
 --  feature spinoffs (xcode string expansions?)

This should just be incompatible with proxy protocol, but with a note
that there's no _useful_ interaction with TLS, as you're only verifying
the connection from the loadbalancer, not from the end-client, and
XCLIENT does not support passing on attributes of the TLS session,
not even that there is one.  So this limits authentication restriction
to TLS and makes it impossible for gsasl users to set up channel binding
information (which, currently, is not a loss since the current channel
binding data turns out to be a security hole resulting from TLS
problems).

We have coding standards?  I mean, that's cool, but that's also new.  We
should have them.  What's the proposal?  Are we also looking at using a
decent code-review tool?

 [ I'm hoping you're setting yourself up for both roles... ]

I can do a security review and one-time merge, but can't commit to more
than that; I haven't even found time to look at the DANE work. :(
There's also hummus/tahini stuff to do first, on my plate for when I
have Exim time.

I mostly just blinked at seeing XCLIENT in the list of build options on
FreeBSD for a system where I stick to Ports, after the recent work added
to the build-options so I got reprompted during a poudriere run.

-Phil

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

[exim-dev] XCLIENT patch to Exim; Cambridge

[Phil Pennock]

FreeBSD is carrying a local patch to Exim, adding XCLIENT support.

The ticket requesting its addition is at:
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=133891
and there's no indication given there about why this was aimed directly
at one OS's packaging, rather than at upstream.

The feature documentation is:
  http://www.postfix.org/XCLIENT_README.html
The patch can be found at:
  
https://github.com/freebsd/freebsd-ports/blob/master/mail/exim/files/extra-patch-xclient

This should probably be considered as a parallel to the proxy protocol
support which we have.

Aside from security review, the biggest issue is likely to be that the
patch wasn't given to us and is currently a standalone work without a
license statement, so we'd need to chase down the original author and
ask about permission to include as part of Exim, under GPL.

In 2008 there was discussion on exim-users, subject XCLIENT supported
by exim?; Nigel summarized the state as zero previous discussion, no
patches, so no apparent interest.  The tone of the response I see was
generally oh that's a Postfix thing, we just connect Exim directly to
the Internet without anything in front of it.

One of the last posts referenced an existing patch by Vsevolod Stakhov:
  http://cebka.pp.ru/blog/2007/12/xclient-exim.html
  http://cebka.pp.ru/blog/patch-exim-xclient
but there's no longer any DNS for that host; however, the initial report
in the FreeBSD PR #133891 referenced
http://cebka.pp.ru/blog/2009/01/-eximxclient.html so it seems that the
history of this patch in FreeBSD traces back to then, even though the
FreeBSD patch has been maintained as it's patched for more recent Exim
releases.

I think that the biggest problem is that most postmaster folks back then
didn't see the benefit of siting an Exim behind a front-end proxy,
especially since this was presented as a security proxy adding features,
where all the features _could_ be done in Exim already.  Since then,
with the widening spread of protocol-generic front-end loadbalancers,
we've seen the haproxy Proxy Protocol take off, the approach of setting
normally-from-getsockopt vars based upon remote data _if_ the connecting
host passes an ACL has been validated and seen not to be a security
issue (well, unless someone allows the extension from the open Internet,
instead of just from the local trusted proxies) and I think that this is
_much_ less controversial.

It looks like the Vsevolod Stakhov from the original report is
probably the gentleman by that name now at the University of Cambridge
(oh, it's the same guy who did the cool libucl config library stuff,
that's why the name was familiar :) ).

On this basis, I'm going to explicitly CC Tony, also at UoC who could
perhaps chat with Vsevolod, and the address found on
https://github.com/vstakhov.

Guys, okay to pull this patch into Exim?

-Phil

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

Re: [exim-dev] cmdline scanner checks pclose() output, this breaks existing deployments

[Phil Pennock]

On 2014-12-01 at 02:39 +, Viktor Dukhovni wrote:
 On Mon, Dec 01, 2014 at 12:48:47AM +0100, Heiko Schlittermann wrote:
  the above line needs to be:
  
  av_scanner = cmdline:{ /bin/scan %s || true; }:trigger:re
  
  which is quite ugly. At least it should find it's way into the spec
  that we're using popen() and /bin/sh and that such commands will work.
  
  (I'm not sure about security implications from using popen() and
  /bin/sh).
 
 It largely boils down to what might be substituted for '%s'.  Instead of
 true I would use the : shell built-in:
 
 /bin/may_only_appear_to_fail || : ignore

The `%s` is  directory-name created by Exim and is not influenced by
anything in the email; it's safe.

  scan_filename = string_sprintf(%s/scan/%s/%s.eml,
spool_directory, message_id, message_id);

The result of that gets truncated at the last `/` to get the
directory-name to pass to the cmdline scanner.

Since Exim configuration files must be owned by root, or a trusted user
_other_ than the Exim runtime user, `spool_directory` can't be coerced
to be a malicious value unless someone does something especially stupid
with macros.  Meanwhile, `message_id` is the _Exim_ message-id, such as
`1XvGum-000F7a-TQ`, not anything from the received mail.


As to `:` vs `true` -- it's a non-issue.  Syntactically they're the
same, they make no difference to parsing or safety.  The only difference
between `:` and `true` is that POSIX requires `:` to be a built-in,
while `true` is only de-facto built-in.  So the issue comes down to
what should be documented as a guide for people to use; humans not
trained in pedantry tend to not treat punctuation as significant and
colon vs semi-colon is hard to observe for said non-pedants.  In this, I
am labelling anyone who is adept in shell as a de-facto pedant.  This
includes myself.

So while I tend to use the : ${foo:=default} idiom myself, and think
colon makes sense for code, I _don't_ think that it makes sense to use
it in documentation of walk-through examples.  We'll spend too much time
correcting peoples' problems where they slightly messed up the
punctuation.

Documentation should be as easy to comprehend as is practical, with the
least amount of subtlety in examples as is practical.  Thus if we are
going to document how to work around return value checking, then I
strongly endorse using `true` not `:`.


That said: unless there's a reason to break working configurations, we
should be extremely reluctant to do so absent a major version bump or a
security motivation.

We may need to consider either `cmdline-checked:` or
`cmdline/options/here:` as syntaxes (syntaces?) and, for historical
compatibility reasons, default a bare `cmdline:` to return code
ignored.

I can't help but think about the `ignore_status` and `temp_errors`
options on pipe transports and wonder if there's something there we can
use as a naming convention.  `cmdline/no_ignore_status:` ?

-Phil

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

[exim-dev] [Bug 1141] remote_smtp reuse when should not be

[Phil Pennock]

--- You are receiving this mail because: ---
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1141




--- Comment #8 from Phil Pennock p...@exim.org  2014-11-14 12:21:16 ---
I disappeared into a day job where the closest I come to running mail systems
is having admin privs in a Google Apps domain.

http://git.exim.org/exim.git/shortlog/refs/heads/bug_1141 has the git branch
with the proposed fix, but I never did write a test case for this.  Only the
latest commit is specific to that branch.

http://git.exim.org/exim.git/commit/9d38e6c3845871c8774cd6494163b1625235080a

So this needs to be cherry-picked into the current Exim code-base, and tested
to see if it works as expected.

Julian, are you able to help with testing, or writing test-cases for Exim's
test-suite?

Todd, Jeremy, we should probably try to get this in before the first RC cut for
the new Exim release?

-Phil


-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

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

[exim-dev] [Bug 1536] GPL does not cover modifications that aren't distributed

[Phil Pennock]

--- You are receiving this mail because: ---
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1536




--- Comment #10 from Phil Pennock p...@exim.org  2014-11-04 21:12:12 ---
The content of attachment 759 has been deleted by
Phil Pennock p...@exim.org
who provided the following reason:

Posted by other than the copyright owner, leaking a secret key

The token used to delete this attachment was generated at 2014-11-04 21:11:57.


-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

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

[exim-dev] [Bug 1536] GPL does not cover modifications that aren't distributed

[Phil Pennock]

--- You are receiving this mail because: ---
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1536




--- Comment #6 from Phil Pennock p...@exim.org  2014-11-04 00:21:39 ---
Two clarifications following some discussion between the maintainers:

(1)

Exim provides an explicit interface to custom code via the local_scan
facility, through local_scan.c; it is the explicit intent that this provides a
boundary between what is Exim and what is being integrated into Exim and is
an explicit API boundary.

Any changes to Exim which work _solely_ through local_scan.c do not have to be
provided under the GPL.  Binary images of Exim built with local_scan.c
modifications may be distributed without having to provide the source code for
local_scan.c.  While publication of those changes would obviously incur good
will from the community and the maintainers, it is not explicitly required.

(2)

In comment #1 I wrote A change to the Affero GPL would mean that an ISP or
university could not maintain custom patches which they support themselves,
while providing service to their customers/users.; this was a mis-statement. 
I missed the word private.  I meant [...] could not maintain private custom
patches which [...].

Anyone is welcome to maintain custom patches outside of the Exim source tree;
anyone is free to distribute binaries of Exim built using custom _public_
patches.  This is what Debian (and its derivatives) do, as one example.  Most,
but at any given time perhaps not all, of those patches might be from Exim as
the upstream, back-ported for security reasons, but a classic example of
out-of-tree patches would be when vendors (RedHat?) were maintaining the
dynamically-loaded lookup module support, to simplify binary dependencies for
package management purposes.

The issue is entirely around custom patches to Exim where the source code for
the patches is kept private, where the patches are _not_ solely in implementing
a function for the local_scan API, and where binaries including those changes
are run on systems not owned by (in a common-sense interpretation of the term
owned) the entity providing the binaries.


Running a service based on Exim is what every organisation installing Exim
does: they provide SMTP service connecting to/from the Internet.  They might be
an ISP or a University providing access to their customers/faculty/students,
and they are under no obligation to provide source for changes as long as the
binaries only run on their own servers.

The moment that a service is providing binaries for others to invoke and run as
a process on the systems belonging to those others, or engaging in obfuscation
schemes to try to avoid that onus, then the GPL impacted changes need to be
provided in source code form too.  As Exim is not LGPL but GPLv2 (with no
practical way to relicense), the GPL-impacted changes are any modification to
the source code not covered by an exemption.

There are exemptions for linking purposes, to ensure that Exim can be linked
with OpenSSL or any lookup type where the client library is not GPL.

There is an implicit exemption for local_scan purposes, which we may need to
make explicit.

No other exemptions come to mind.


-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

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

[exim-dev] [Bug 1536] GPL does not cover modifications that aren't distributed

[Phil Pennock]

--- You are receiving this mail because: ---
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1536

Phil Pennock p...@exim.org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |




--- Comment #5 from Phil Pennock p...@exim.org  2014-11-01 08:35:32 ---
To be compliant with the GPL, if the binaries are running on machines not owned
by the SaaS provider, then the source-code for those binaries needs to be made
available to those same customers, without restrictions other than the GPL. 
This does not mean that the changes need to be made directly available to
anyone else.

The most sensible way forward is probably to get the key moved out of the
source-tree into a file read from the filesystem and then contribute the
changes in a tracking issue in this bug-tracker.  There's no need for the Exim
Maintainers to merge the patch, as long as the running code is available. 
Embedding keys which must be secret into GPL code is highly unwise and leads to
scenarios where only lawyers win, especially since there's an ongoing
requirement to provide the source for the binaries which have already been made
available.

Generally speaking, nobody has a right to be able to debug arbitrary other
systems on the Internet and as long as a customer of the GPL'd product has a
way to debug and change the code, the obligations are met in my opinion.  It's
also perfectly reasonable for a support contract to be automatically terminated
should a customer do so.

Attempts to redefine the meaning of a legal term are another thing which only
leave lawyers richer.  As someone who is currently awaiting a personal bill
from a corporate law attorney, I have _no_ desire to get dragged into that if I
don't have to, especially for an open source project which doesn't make me
money to recoup those legal costs, so if I do find that I have to go that route
then I shall become rather grumpy.

So please lets get this resolved reasonably.  Mike H: your tone is not
reasonable and not conducive to getting this resolved smoothly.  Please don't
make demands in projects where you are not a copyright holder.  Thank you.


-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

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

[exim-dev] [Bug 1536] GPL does not cover modifications that aren't distributed

[Phil Pennock]

--- You are receiving this mail because: ---
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1536

Phil Pennock p...@exim.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Comment #1 from Phil Pennock p...@exim.org  2014-10-30 06:14:44 ---
A change to the Affero GPL would mean that an ISP or university could not
maintain custom patches which they support themselves, while providing service
to their customers/users.  Those patches tend to make their way back to us
eventually, but it would not be a good fit for our existing community.

Furthermore, this project does not use copyright assignment, so there is no
practical way to relicense.

It's unclear from this message exactly what is happening, but a quick glance
suggests that https://www.spamexperts.com/ is a SaaS provider and from you I
infer that they're using Exim.  This is little different from an ISP providing
a mail-service based around Exim, so I know that (if I have interpreted the
situation correctly, then) this use-case has been considered since the earliest
days of Exim and found acceptable.


-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

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

[exim-dev] [Bug 1535] Option for SSL/TLS Protocol configuration missing/required

[Phil Pennock]

--- You are receiving this mail because: ---
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1535




--- Comment #1 from Phil Pennock p...@exim.org  2014-10-16 00:44:00 ---
Which OS, with which TLS library?

With OpenSSL, you set:

openssl_options = +no_sslv2 +no_sslv3

With GnuTLS, I don't know off-hand what the option is.


-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

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

[exim-dev] [Bug 1535] Option for SSL/TLS Protocol configuration missing/required

[Phil Pennock]

--- You are receiving this mail because: ---
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1535




--- Comment #2 from Phil Pennock p...@exim.org  2014-10-16 00:49:32 ---
Looks like the GnuTLS Priority String to use is:

NORMAL:%LATEST_RECORD_VERSION:-VERS-SSL3.0

Set this as the value of `tls_require_ciphers`, both main section and on SMTP
transports.


-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

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

[exim-dev] [Bug 1526] Solaris 11: error compiling since exim 4.83 - Undefined symbol timegm first referenced in file tls.o

[Phil Pennock]

--- You are receiving this mail because: ---
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1526

Phil Pennock p...@exim.org changed:

   What|Removed |Added

 AssignedTo|p...@exim.org|jgh146...@wizmail.org




--- Comment #1 from Phil Pennock p...@exim.org  2014-09-09 00:16:57 ---
The file src/tlscert-openssl.c has this:

105 static uschar *
106 bio_string_time_to_int(BIO * bp, int len)
107 {
108 uschar * cp = US;
109 struct tm t;
110 len = len  0 ? (int) BIO_get_mem_data(bp, cp) : 0;
111 /*XXX %Z might be glibc-specific? */
112 (void) strptime(CS cp, %b%t%e%t%T%t%Y%t%Z, t);
113 BIO_free(bp);
114 /*XXX timegm might not be portable? */
115 return string_sprintf(%u, (unsigned) timegm(t));
116 }

Hey Jeremy: you're right, it's not.  :)


-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

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

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

[Phil Pennock]

--- You are receiving this mail because: ---
You are on the CC list for the bug.

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




--- Comment #2 from Phil Pennock p...@exim.org  2014-09-03 01:13:51 ---
The exbot42 build farm agent is using unbound as its local resolver.

Todd, shout if you want me to add a bunch more agents, as variant builds, or if
you just want ssh access to the build farm account on that machine.


-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

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

[exim-dev] DANE work

[Phil Pennock]

My jaw dropped when I returned to my list index view and saw just how
many patches came in from work this weekend by Todd and Jeremy to
implement DANE in Exim.

Seriously good work which makes me very happy and feeling that I owe
drinks to you both.  Thank you for picking up where I totally slacked
off and working on implementing this.  (Thank you for removing one of my
guilt layers of I need to find time to work on X too).

Happiness.  :)
-Phil

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

[exim-dev] [Bug 1518] router condition silently ignored if too many back braces

[Phil Pennock]

--- You are receiving this mail because: ---
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1518




--- Comment #8 from Phil Pennock p...@exim.org  2014-08-28 20:41:45 ---
For clarity: it's a mis-feature, and when PH wrote the ACL system, he used a
much more strict definition for condition rules in ACLs.

You can see the difference with the `bool` vs `bool_lax` expansion conditions;
`bool_lax` corresponds to Router condition syntax.

If we ever overhaul the syntax for a major version bump (with conversion tools)
we should revisit this.


-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

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