Re: [exim] Help to logical OR two conditions

[Phil Pennock via Exim-users]

On 2020-10-01 at 13:24 +0700, Victor Sudakov via Exim-users wrote:
> Could you please help me unite the following two ACL expressions into one:
> 
> accept condition  = 
> ${lookup{$local_part@$domain}lsearch{/etc/dovecot/aliases}{yes}}
> accept condition  = 
> ${lookup{$local_part@$domain}lsearch{/etc/dovecot/users}{yes}}

Why?

It's _possible_ to combine conditions but too often it creates a bit of
a mess.

If you just leave it as two different accept verbs, then if the first
one doesn't pass, the second will be tested and ... you will have a
short-circuiting OR by using accept-then-accept.

For a Router, all condition rules must pass, so it becomes an AND.

> Should be fairly simple but...  I've tried variants of '${if or {...' by
> the manual but all I got were errors like 

The explanations here have been covered by others in the thread but I'm
combining it all into one, then comparing to the original.

So: a string needs to be made into a boolean status, because or/and take
booleans, not general strings.  "Expansion conditions".

 * bool{X} interprets X in the same way that ACL condition rules do
 * bool_lax{X} interprets X in the same way that Router conditions do

So these should be equivalent:

  accept condition = ${if or{\
   {bool{${lookup{$local_part@$domain}lsearch{/etc/dovecot/aliases}{yes\
   {bool{${lookup{$local_part@$domain}lsearch{/etc/dovecot/users}{yes\
   }}

  accept condition = 
${lookup{$local_part@$domain}lsearch{/etc/dovecot/aliases}{yes}}
  accept condition = 
${lookup{$local_part@$domain}lsearch{/etc/dovecot/users}{yes}}

I don't know about you, but I find the separate rules easier to read and
debug, with fewer braces to be matched and fewer bits of specialist lore
to be memorized.

Simplicity and lack of nesting wins out over fancy boolean conditions
constructed by a human instead of a machine.

(But I'm biased, I added the ability to have multiple condition rules to
a Router.)

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Moving a queue from server to server

[Phil Pennock via Exim-users]

On 2020-07-15 at 10:02 +0100, Jeremy Harris via Exim-users wrote:
> On 14/07/2020 18:57, Johnnie W Adams via Exim-users wrote:
> >  Now I'm replacing that box with a newer one and wondering how to move
> > the queue of frozen mail from the old machine to the new--or if I'm better
> > off just waiting till it all expires.
> 
> 
> As to how: just copy the files.  And delete the old ones.  Preferably
> having ensured the daemon on the old machine is not running.
> 
> I'm not answering the "whether to"; that's policy.

Be sure to transfer the -D files before the -H files; probably in order
"-D", "-J", "-H".

But otherwise, yes.

If you want to transfer them in one batch, then make sure the daemon on
the _receiving_ side is shut down first too.  Basically, Exim treats the
-H headers file as its control file.  If it's present, a queue-runner
will try to route/deliver etc and then get upset if -D is missing.  If
-D is present without -H then that's just new mail coming in and a
queue-runner will just skip to the next item.  Meanwhile -J are the
journals, if you've enabled that for your Exim.

So:
 1. shut down old Exim
 2. either shutdown new Exim temporarily and sync all files then start
new Exim back up, OR:
 3. Sync the -D files
 4. Sync the -J files if any
 5. Sync the -H files

-Phil, hoping I haven't gotten this all backwards, going just from
   memory.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] MTA-STS and Server Name Indication (SNI) on mail servers

[Phil Pennock via Exim-users]

On 2020-06-17 at 19:51 -0400, Felipe Gasper wrote:
> > On Jun 17, 2020, at 6:22 PM, Phil Pennock via Exim-users 
> >  wrote:
> > because TLS1.3 mandates SNI.
> 
> Phil, do you have a citation for this? I skimmed the RFC just now, and the 
> only mandatory details about SNI that I see are in the context of session 
> resumption.
> 
> If TLS 1.3 indeed mandates SNI, then that’s relevant in other conversations 
> I’m in and would love to be able to cite that.

My memory has faded.

In <https://bugs.exim.org/show_bug.cgi?id=2266> I wrote:
} With TLS 1.3 mandating SNI from clients unless an application profile
} prohibits that, we should be providing a default value of SNI.

My very vaguest of recollections is that client libraries are being
written around a model of the HTTPS application profile and other
profiles are second-class citizens and fighting a losing battle to work
without SNI.

So I probably miswrote: it's not "mandated by spec", it's, if I'm now
remembering correctly, "de facto mandated by all the usable profiles and
mandated by many libraries".

I don't remember the details or even the above with any degree of
confidence; it's been two years since I last even looked at this.
Sorry.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] MTA-STS and Server Name Indication (SNI) on mail servers

[Phil Pennock via Exim-users]

On 2020-06-17 at 15:34 -0400, John R. Levine via Exim-users wrote:
> For example, here's where you can find the MTA-STS for my iecc.com:
> 
>   https://mta-sts.iecc.com/.well-known/mta-sts.txt

My stance on MTA-STS is that it's reasonable to advertise to get the big
players talking to you, but it's a spiralling trap of trust-stores with
the same social failure mode which caused TLSA Usages 0 and 1 to be
rejected for use in SMTP (or really any federated service).  So I've
spoken out against implementing MTA-STS as a client, but at the same
time documented for folks how to implement it so that others (gorillas)
can use it.

Which is why:
  
works.  Originally purely so that mail from Gmail would be secured.
(Originally setup, perhaps for the JSON variant (I forget), in 2017)

I thought we at least had a wiki page on it.  We don't.  It's really
nothing specific to Exim though, since it's just static data publication
and entirely outside Exim's remit.

> Looking at the mail logs for my servers, it's pretty clear that Exim doesn't
> send SNI.

Exim sends SNI if it has a reasonable value to send.  In the absence of
DNSSEC, there's nothing reasonable to default to.  We have an old branch
(from 2018) where I made it default to the mail-domain if not otherwise
set, because TLS1.3 mandates SNI.  Looks like that was a "how about this
idea" proposal and we didn't go with it.

I keep mentally thinking that we're setting this automatically when DANE
is in play but it looks like we never got around to that.  Ah, I stopped
relying on fallible memory and filed a bug about it:
  
and we paused on "if we flat-out ignore the configured value for DANE,
we lose flexibility" ... but I suspect we should go ahead and flat-out
ignore it, as we do for several other TLS options once DANE is in play.

So at present, "reasonable value" still means statically configured.

> doesn't have any way to select a certificate using SNI. This is not hard to
> fix; I added SNI support to the mailfront SMTP daemon in a couple of hours.

Exim has supported using the inbound TLS SNI value in the expansion
controls for choosing keys and certs, etc, since I added support for
Exim 4.80 (change PP/17) in 2012.  With both OpenSSL and GnuTLS crypto
libraries.

The concept index at:
 

links to the various places in the documentation which describe our SNI
behavior.

Most pertinently:
 



-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Upcoming Glibc changes and DANE support in Exim, Postfix, and perhaps other MTAs

[Phil Pennock via Exim-users]

On 2020-04-16 at 16:00 -0400, Viktor Dukhovni via Exim-users wrote:
> On Thu, Apr 16, 2020 at 07:53:08PM +0100, Jeremy Harris via Exim-users wrote:
> > On 15/04/2020 18:46, Viktor Dukhovni via Exim-users wrote:
> > > I read this to mean that the new "trust-ad" option, if set, causes the
> > > Glibc stub resolver to set AD=1 in queries, but *otherwise*, causes it
> > > to strip the AD bit from replies.

Thanks for this notice, I picked it up from another mailing-list you
posted it to.

> FWIW, Wietse's fix for existing stable Postfix releases is to just set
> "RES_TRUSTAD" along with the previous "RES_USE_EDNS0" when the calling
> code is requesting RES_USE_DNSSEC.  This restores prior semantics.
> More fine-grained policy about when to set or not set RES_TRUSTAD will
> be in tested in the development snapshots over the next year and be
> part of 3.6 early in 2021.

Unfortunately we (I) named the relevant option `dns_dnssec_ok` to
closely match setting the DNSSEC OK (`DO`) bit, which was clear and
precise and ... means adding the option in Exim there will have a
side-effect of doing more than the administrator asked for.  It's 99%
likely to be the right thing to do, but I suspect we're going to need to
suck it up and change the option name and deprecate the current option.

(Otherwise I'd have already just coded up independently the exact same
 fix you have used for Postfix)

This also though means that _building_ an Exim binary has to be done on
the system with the newer glibc, because binaries can't be forward
compatible.  We need `RES_TRUSTAD` to be defined.

In the meantime, I've documented in dce58c04af that the problem exists
and pointed administrators at how to configure `resolv.conf`.
Unfortunately, the same OS family which needs this is the one which is
mostly likely to make `/etc/resolv.conf` be a symlink which gets stomped
upon with Yet Another Manager controlling the stomping every four or so
years.  So that's not the most postmaster-friendly of solutions.

https://git.exim.org/exim.git/commitdiff/dce58c04af4439fec7269f83886e22b503756a8f

This is going to be one of those days where I regret a career using some
of these computer thingies.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] DANE ERROR: TLSA LOOKUP DEFER

[Phil Pennock via Exim-users]

On 2020-03-25 at 13:10 -0400, Phil Pennock via Exim-users wrote:
> On 2020-03-23 at 20:54 +0800, daniel via Exim-users wrote:
> > We recently received many of our end users complains that they are having 
> > problem sending email to *.gov.hk with this exim error: 
> > DANE ERROR: TLSA LOOKUP DEFER
> 
> Their DNS is broken.

For clarity: I did not look at any DNS records before making that
statement, it was my short-form explanation of what the error message
means in practice.

95+% of the time, it means "they have DNS servers which don't reply when
asked for TLSA records".

To get more details out of Exim, run with `-d+transport+dns` to get
debugging, enabling additional debug content in the "transport" and
"dns" areas.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] DANE ERROR: TLSA LOOKUP DEFER

[Phil Pennock via Exim-users]

On 2020-03-23 at 20:54 +0800, daniel via Exim-users wrote:
> We recently received many of our end users complains that they are having 
> problem sending email to *.gov.hk with this exim error: 
> DANE ERROR: TLSA LOOKUP DEFER

Their DNS is broken.

> However we have contacted our government and their responds is:
> “Our DNSSEC setup is fine, and it is not nesserary to have DANE setup 
> together with DNSSEC , so it is the exim MTA problem. We have not actually 
> setup DANE “
> Now here comes the problem: how can we solve this problem passively? We have 
> many cPanel server with Exim.

You have one of these two options set on your SMTP Transport:

hosts_try_dane
hosts_require_dane

Each of those takes a host-list, so might currently look like:

hosts_try_dane = *

You can change that to look like:

hosts_try_dane = !*.gov.hk : *

If the host-list references external files, take a look at those.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Exim multi-server architecture with NAS

[Phil Pennock via Exim-users]

On 2020-03-10 at 17:11 -0400, Robert Blayzor via Exim-users wrote:
> Would this be a valid design and what are the caveats? What would a
> better design option be?

Caveat: the guarantee of SMTP is that you have responsibility once you
accept the message, so think carefully about the resiliency of the spool
directory for the servers in front of the NAS, and how you'd recover if
a machine or VM dies.

> One caveat I have run into is that we will have multiple NAS appliances
> holding mailboxes across multiple domains. This raises the issue of the
> Exim router looking at the mailbox user and knowing which NAS/LMTP
> server to deliver the mail to. This may be something as simple as
> putting a value along with the user in the database
> 
> Wondering what other may have done with similar deployments...

If you're avoiding a dependency on the NAS to avoid a single-point of
failure, think about the datastore for the lookups.  Resilient RDBMS is
one approach, but building a directory of CDB files and distributing
them might be another approach.  One thing I've done in the past is to
have a symlink for the current CDB dir pointing to the current
generation, then for updates copy the current generation, rsync the
updates, then once the rsync is done update the symlink atomically.

Figure out if the NASes should be able to forward to each other if
there's a move or somesuch.  But then be careful that a failure of one
server doesn't take them all down.

There are front-end application-layer proxies for IMAP/POP3 which let
you assemble a bunch of mailstores on separate servers into one unified
namespace, so that you can present `imap.example.org` for the entire
domain.  Or, you might just tell the customer which server is theirs,
but still think about keeping those names virtual, so that you can move
servers without needing customers/clients to all update.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] DKIM ed25519 signing issues

[Phil Pennock via Exim-users]

On 2020-03-05 at 09:02 +, Graham McAlister via Exim-users wrote:
> Suspect my distro build uses openssl instead of gnutls and my version
> of openssl is 1.1.0 but ed25519 support is in 1.1.1
> 
> So, either I build exim to use gnutls, or I upgrade openssl to 1.1.1
> 
> That's my plan, and will report back on results.

Note that the Exim source ships with a documentation file `openssl.txt`
to help with exactly this sort of situation: you need a different
OpenSSL than is shipped by the OS, you need to custom-build it for Exim,
you don't want to mess with any other installs or risk breaking anything
else.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] DKIM ed25519 signing issues

[Phil Pennock via Exim-users]

On 2020-03-04 at 09:06 +, Graham McAlister via Exim-users wrote:
> Has anyone successfully used Exim and DKIM with ed25519 keys? Any pointers?

Yes.  I dual-sign.  It's amusing to see all the status reports from
systems which don't implement Ed25519.  At least most of them now will
accept seeing the RSA signature and accept it as good enough, so ignore
the failure from the Ed25519 side.

I've attached `/etc/exim/dk/Makefile` from my own mailhub; there's other
process flow to get the secrets safely stashed away, etc.  A couple of
hard-coded paths you'll need to update: I doubt that
`OPENSSL:=/opt/openssl-1.1.1/bin/openssl` works for you.

Oh, it's a BSD Makefile.  I don't think GNU make likes the `.for`
syntax.  So unless you're on a BSD, this will at best provide you with a
crib source.

Running `make` will make the new RSA and Ed25519 keys for "this month".
I use dMM as the selector for RSA and dMMe2 as the selector for
Ed25519.

`make list-current` gets me the exact input I use for my DKIM selector
lookup input (it actually makes a CDB from this).

The actual key generation is done with:

( umask 027 && $(OPENSSL) genpkey -algorithm ed25519 > ${.TARGET} )

Git history of the secrets archive shows that I have been running with
this since making the d201804 keys.  It's been working fine in all that
time.

-Phil
.MAIN: all

# http://www.keylength.com/en/3/ -- ECRYPT II "smallest general purpose level"
# is 1248 bits symmetric
# Switching 2018-04-11 from 1248 to 2048, hope to switch to EC by end of 2020.
KEYSIZE_RSA=2048
ED25519:=true

# Path to an OpenSSL binary with support for Ed25519
.ifdef ED25519
OPENSSL:=/opt/openssl-1.1.1/bin/openssl
.else
OPENSSL:=openssl
.endif

DKIM_SIGN_DOMAINS_FILE:=/etc/mail/flat/dkim.selectors.hermes

DOMAINS!=sed -n 's/^\([^\#%][^:]*\):.*$$/\1/p' < $(DKIM_SIGN_DOMAINS_FILE)
DATE!=date +%Y%m

ALL_KEY_FILES:=
DNS_FRAGMENTS:=

.for domain in $(DOMAINS)
_DOMAIN= ${domain}

# Note:
# RFC 6376 paragraph 3.6.2.2:
# TXT RRs MUST be unique for a particular
#selector name; that is, if there are multiple records in an RRset,
#the results are undefined.
#
# Thus we use 'e2' as a suffix for ed25519 keys.
_KEYFILE_RSA= rsa.private.d$(DATE).$(_DOMAIN)
_KEYFILE_ED25519= ed25519.private.d$(DATE)e2.$(_DOMAIN)
_DNSFRAGMENT_RSA= _rsa.dns.d$(DATE).$(_DOMAIN)
_DNSFRAGMENT_ED25519= _ed25519.dns.d$(DATE)e2.$(_DOMAIN)
_DNS_COMBINED= dns.d$(DATE).$(_DOMAIN)

# Beware that modern OpenSSL does not honor umask and uses 0600 permissions as
# the base for -out, so we write to stdout and redirect instead.

$(_KEYFILE_RSA):
( umask 027 && $(OPENSSL) genrsa $(KEYSIZE_RSA) > ${.TARGET} )

$(_KEYFILE_ED25519):
( umask 027 && $(OPENSSL) genpkey -algorithm ed25519 > ${.TARGET} )

# These two yield identical outputs ... but I feel a little better about the 
first, not hard-coding
# the magic number of 13 (jumping first 12 of ASN.1)
#
# /opt/openssl-1.1.1/bin/openssl pkey -in ed25519.private.d201804.spodhuis.org 
-noout -text_pub | perl -ne 'next unless /^\s/; chomp; s/^\s+//; @a = 
split(/:/, $_); push @results, chr(hex($_)) foreach @a; END { print @results }' 
| openssl enc -a
# /opt/openssl-1.1.1/bin/openssl pkey -outform DER -pubout -in 
ed25519.private.d201804.spodhuis.org  | tail -c +13 | openssl enc -a

$(_DNSFRAGMENT_RSA): $(_KEYFILE_RSA)
$(OPENSSL) rsa -in ${.ALLSRC} -outform PEM -pubout 2>/dev/null | \
  perl -lne 'next unless /^-BEGIN/../-END/; next if /^-/; 
chomp; $$str.=$$_; \
  END {$$str = qq!"v=DKIM1; k=rsa; p=$$str"!; $$str =~ s/(.{250})/\1" 
"/; \
  print qq!d$(DATE)._domainkey IN TXT $$str!}' \
  > ${.TARGET}

$(_DNSFRAGMENT_ED25519): $(_KEYFILE_ED25519)
$(OPENSSL) pkey -in ${.ALLSRC} -noout -text_pub | \
  perl -MMIME::Base64 -lne \
'next unless /^\s/; chomp; s/^\s+//; @a = split(/:/, $$_); push 
@results, chr(hex($$_)) foreach @a; \
END { $$str = encode_base64(join("", @results), ""); \
  $$str = qq!"v=DKIM1; k=ed25519; p=$$str"!; \
  $$str =~ s/(.{250})/\1" "/; \
  print qq!d$(DATE)e2._domainkey IN TXT $$str! \
}' > ${.TARGET}

$(_DNS_COMBINED): $(_DNSFRAGMENT_RSA)
.ifdef ED25519
$(_DNS_COMBINED): $(_DNSFRAGMENT_ED25519)
.endif

$(_DNS_COMBINED):
cat ${.ALLSRC} > ${.TARGET}

DNS_FRAGMENTS:=$(DNS_FRAGMENTS) $(_DNS_COMBINED)
DNS_FRAGMENTS:=$(DNS_FRAGMENTS) $(_DNSFRAGMENT_RSA)
.ifdef ED25519
DNS_FRAGMENTS:=$(DNS_FRAGMENTS) $(_DNSFRAGMENT_ED25519)
.endif

ALL_KEY_FILES:=$(ALL_KEY_FILES) $(_KEYFILE_RSA)
.ifdef ED25519
ALL_KEY_FILES:=$(ALL_KEY_FILES) $(_KEYFILE_ED25519)
.endif

domain.${domain}: $(_DNS_COMBINED) $(_KEYFILE_RSA)
.ifdef ED25519
domain.${domain}: $(_DNSFRAGMENT_ED25519)
.endif

.endfor

all: $(ALL_KEY_FILES) $(DNS_FRAGMENTS)

# Easy enough to regenerate the DNS and we don't want it littering the dir
# We don't want to remove the keys.  Those are precious.
clean

Re: [exim] a tool to relay to Gmail using AUTH XOAUTH2

[Phil Pennock via Exim-users]

On 2019-09-18 at 23:05 +0200, Heiko Schlittermann via Exim-users wrote:
> Wouldn't it be better to integrate it into Exim itself?
> Can't we use the authenticators for this? Write a new
> driver, xoauth2, and use it in the transport section?

If recollection serves, XOAUTH2 can require prompting for reconfirmation
via opening a web-browser and after "whatever happens there" POSTing
back to a localhost listening port to provide the actual credential.

XOAUTH2 is really for desktop apps, like email clients talking to the
submission port, and not well suited to an MTA performing unattended
delivery.

So from Exim's side, this would be "Okay, what hooks can we provide for
'mostly unattended' delivery, grabbing a human for intervention when
needed".

So if this were to be in Exim, it would instead need to be something
like: "keep using this credential in this file, but when it fails,
execute this other command instead and pause usage of this authenticator
until the mod-time on the credential file changes" and an external tool
to manage the refresh.  And suggested monitoring integrations.

At which point, a local sidecar proxy for talking to Gmail where the
proxy manages all of that might actually be the better approach, thus
the OP's design.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] [oss-security] Sv: CVE-2019-15846: Exim - local or remote attacker can execute programs with root privileges

[Phil Pennock via Exim-users]

On 2019-09-07 at 08:23 +0200, Heiko Schlittermann wrote:
> Phil Pennock  (Sa 07 Sep 2019 02:52:56 CEST):
> > The connect ACL won't protect you against STARTTLS usage, which is far
> > more common for email than TLS-on-connect.
> >
> > I myself use the HELO ACL.
> 
> This doesn't seem to be sufficient, you can start "submitting" a message to
> a remote Exim with the following sequence

Yeah sorry folks, that was a little embarrassing: my setup, and various
common configurations (including apparently RedHat's) enforce
EHLO-after-STARTTLS.  But that's Exim configuration, not hard-enforced
in the code.

"Be lenient in what you accept" ... bah humbug.

Exim's default configuration has included this check, at RCPT time
(which still works for our purposes) since commit 731c6a9043 in 2016,
included in releases 4.87 onwards.

So I use the HELO ACL and it's safe in "many" configurations, but we
have to be more cautious in recommending mitigating workarounds.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] CVE-2019-15846: Exim - local or remote attacker can execute programs with root privileges

[Phil Pennock via Exim-users]

On 2019-09-06 at 22:04 +0200, Heiko Schlittermann via Exim-users wrote:
> The HELO ACL doesn't help either, as the first EHLO comes before
> STARTTLS, and the second EHLO doesn't have to come, the client may send

Oh pox.  My memory is going.  I hadn't realized that my protection
against this comes from long-standing local configuration, not Exim
defaulting to enforcing this:

acl_check_mail:
  denymessage   = 503 Bad sequence of commands - must send HELO/EHLO 
first
  condition = ${if !def:sender_helo_name}

If anyone wants to protect against stupidity: I've been using that guard
for "longer than the five years that the current mail-server is running"
and I'm not going diving through git history to find when it was
introduced to my older server.

To the best of my knowledge, that has never blocked legitimate mail.
Everyone does EHLO after STARTTLS.

Exim drops pre-TLS sender_helo_name after negotiating TLS.  This is
required by RFC 3207 (section 4.2) but not explicitly mentioned in the
Exim Spec, AFAICT.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] [oss-security] Sv: CVE-2019-15846: Exim - local or remote attacker can execute programs with root privileges

[Phil Pennock via Exim-users]

On 2019-09-06 at 20:50 +0200, Sebastian Nielsen wrote:
> Shouldn't this be in connect ACL?
> How would the deny in MAIL FROM prevent the exploit? What I have understand 
> is that there is exploit in the SNI of the TLS negotiation, thus the whole 
> connect attempt must be rejected right?

The connect ACL won't protect you against STARTTLS usage, which is far
more common for email than TLS-on-connect.

I myself use the HELO ACL.

Blocking in the MAIL ACL is safe.  The problem is not in the TLS SNI
itself.  The problem relates to safely storing the SNI in spool files
for messages and what happens when Exim reads those values back later.

Unless and until an email is spooled, there is no security hole.

Some time back, the TLS SNI would be written unescaped to the spool
files.  That meant that a newline in SNI would let attackers introduce
arbitrary metadata into the spool (which includes ACL variables,
commonly subject to expansion, so ${run ...} could be injected).  So I
fixed it, by escaping the SNI when writing it to the spool file and
unescaping when reading it back.

I remember sighing wistfully because I'm not fond of escaping/quoting
and much prefer using DJB netstrings, but didn't fancy rewriting all of
Exim's spool file handling, so just used the escape/unescape functions
we had.

I missed that the escape function didn't escape everything which the
unescape function would unescape, and that this provided a means to mess
up Exim's internal state.  Qualys were able to prove out that yes, this
is exploitable.

AFAIK that's the first remote execution exploitable security hole I've
ever introduced to a project.  :(

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Exim, Dovecot, mdir and hardlinks - a true story

[Phil Pennock via Exim-users]

On 2019-08-14 at 12:24 -0400, Phil Pennock via Exim-users wrote:
> On 2019-08-14 at 12:54 +0100, Jeremy Harris via Exim-users wrote:
> > Do we need a fast/poor quota method for cases where the size-file
> > cannot be used?
> 
> Just to raise the possibility to see if others can spot approaches which
> make this feasible rather than a giant can of worms: direct support for
> filesystem quotas in Exim, using soft limits set to match Dovecot's.

This was a stupid suggestion on my part.

In any sort of spool delivery system like this, one OS runtime user is
used and owns all the files.  OS quotas won't help at all.  This is
_why_ Exim supports other quota systems.

Sorry,
-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Exim, Dovecot, mdir and hardlinks - a true story

[Phil Pennock via Exim-users]

On 2019-08-14 at 12:54 +0100, Jeremy Harris via Exim-users wrote:
> Do we need a fast/poor quota method for cases where the size-file
> cannot be used?

Just to raise the possibility to see if others can spot approaches which
make this feasible rather than a giant can of worms: direct support for
filesystem quotas in Exim, using soft limits set to match Dovecot's.

Caveat in all of this: I've never played with quotas from the C APIs, so
don't know enough to speak authoritatively here; this is based on some
quick man-page and source checks, to write this email.

The portability and maintenance is going to be hell, unless I've missed
some standardization here (very possible).  The only approach likely to
reliably expose usage/limits to userland is the NFS RPC server approach,
which could probably be run even without NFS.  Otherwise, the issue is
that a lot of things assume that all enforcement is in the kernel and
userland only needs access to manipulate limits, not to query how close
a user is.

On FreeBSD there's quota_open/quota_read/quota_close, which are used by
repquota(8), but that's UFS only.  On FreeBSD, the cases to consider
would be NFS, ZFS, UFS.  Each different, AFAIK, with no standardized
access across them all.  However, the oldest API is quotactl(), which
was in 4.3BSD-Reno, so is widespread.  The manpage documents UFS-only.

Underneath, the UFS case uses quotactl(), which is also present on Linux
and appears to be used for other filesystem types on Linux too, albeit
perhaps requiring extra C header imports to work with those.

  rc = quotactl(path, Q_GETQUOTA, uid, &result);

Since quotactl() is on, at least, Linux and *BSD, and supports at least
some FS types, it might be worth seeing what sorts of OSes/FSes people
use for delivered email with Exim and design around using this general
API, initially supporting just quotactl() unless/until volunteers
contribute code for other APIs.

That should be a "proper" solution, which is lightweight in use, if
folks already have the FS quotas turned on.  Which my uninformed guess
is "yes, because that's the sanest way for Dovecot to implement quotas
with hard link support".

Exim's current approach has the benefit of working everywhere, on all
OSes which Exim supports.

I think that quotactl(), ZFS and NFS are _probably_ the only scenarios
we'd likely end up having code for.

People who actually work with quotas, please shoot holes in everything
I've just said.  :)

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Help with AUTH DDOS

[Phil Pennock via Exim-users]

On 2019-06-26 at 10:42 -, Jasen Betts via Exim-users wrote:
> alternatively in ACL_AUTH
>
>   drop
> set acl_c_auth_count = ${eval: $acl_c_auth_count + 1}
> condition = ${if >{1}{$acl_c_auth_count }}
> message = "go away"
>
> which will allow only one attempt at auth per connect.

Minor note:

-8< spec.txt >8-
11.7 Expansion conditions

 {}{}
>  greater

${if >{$message_size}{10M} ...

In all cases, a relative comparator OP is testing if  OP ; the above example is checking if $message_size is larger than 10M, not
if 10M is larger than $message_size.
-8< spec.txt >8-

So the condition as written is asking if 1 > the auth count, so will
never fail.

I'm using this:
  condition = ${if >{$acl_c_auth_count}{3}}
which will allow a fallback path but still block bulk auth attempts.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] exim-4.92: GSSAPI authenticator doesn't work

[Phil Pennock via Exim-users]

On 2019-06-20 at 14:26 +0200, Frank Richter via Exim-users wrote:
> after upgrading to exim-4.92 (EPEL exim-4.92-1.el6.x86_64) our gssapi
> authenticator doesn't work any more.

Debugging permissions and interactions and libraries automatically
dropping access for setuid programs was such a nightmare for me when
using cyrus_sasl for GSSAPI that several years ago I added the
`heimdal_gssapi` authenticator to Exim.



If you've got the Heimdal GSSAPI libraries, or an option to use
something which links against those (I'm not familiar with what the EPEL
builds enable, sorry) then this is the way to go.

Fewer moving parts intricately tied together leads to easier debugging,
and better debug logging inside Exim because Exim has more visibility
into what's going on.

I use GSSAPI for the mail-server for my personal domain so tend to
notice when it breaks.  Unfortunately, I didn't have spare time before
the 4.92 release, so didn't test in time to prevent a regression, but
the 6ee110613 commit in git unbreaks the compilation failure for this
authenticator.

My personal config then runs with:

auth_gssapi:
  driver   = heimdal_gssapi
  public_name  = GSSAPI
  server_hostname  = smtp.spodhuis.org
  server_keytab= /etc/kerberos/tabs/exim.keytab
  server_set_id= $auth1
  server_condition = ${if and{\
{or{\
{eqi{$auth1}{$auth2}}\
{eqi{${sg{$auth1}{@.*}{}}}{$auth2}}\
}}\
{eqi{${domain:$auth1}}{spodhuis.org}}\
}}
  server_advertise_condition = ${if and{{!def:authenticated_id}{or{\
{INBOUND_SUBMIT_CONDITION}\

{and{{def:tls_cipher}{!match_ip{$sender_host_address}{+relay_for_friends\
}}} {yes}{no}}

You'd probably want to simplify the server_advertise_condition (or
remove it) and adjust the spodhuis.org references in server_condition
and elsewhere.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Exim and file access right

[Phil Pennock via Exim-users]

On 2019-05-19 at 16:05 +0200, Arno Thuber via Exim-users wrote:
> From chapter 55 of the Exim documentation I see that Exim delivery drops
> rights which it has as a server but I don't fully understand it - or I
> don't understand Unix access rights. With user Debian-exim member of
> privkey_users why can't it read files with access rights for the group
> privkey_users?



  initgroupsUse: transports Type: boolean   Default: false

  If this option is true and the uid for the delivery process is
  provided by the transport, the initgroups() function is called when
  running the transport to ensure that any additional groups associated
  with the uid are set up.

Turn on that _Transport_ option for the transport which needs to read
the key file.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] SSL forcing

[Phil Pennock via Exim-users]

On 2019-05-19 at 19:17 +0100, Richard Jones via Exim-users wrote:
> # egrep -o 'X=TLS[^ ]+' /var/log/exim4/mainlog  | sort | uniq -c | sort -n | 
> tail

That will include all the outbound, and also all the spammers whom you
ended up rejecting (because yes spammers use TLS nowaways).

$ pcregrep -ho1 '<= .+\b(X=\S+)' mainlog* | sort | uniq -c | sort -nr

These are the ones which matter for inbound TLS.

For me, the only pre-1.2 senders over the past few days are
lists.gnu.org, an anti-spam mailing-list, and the IPv6-Ops mailing-list.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Sourcing Exim Filter from MySQL/MariaDB table?

[Phil Pennock via Exim-users]

On 2019-05-08 at 00:39 +0100, Mike Tubby via Exim-users wrote:
> Which suggests I need something like:
> 
> user_filter:
>     driver = forwardfile
>     data = ${lookup mysql{SELECT rule FROM users LEFT JOIN domains \
>         ON domains.id=users.domain_id LEFT JOIN filters \
>         ON users.id=filters.user_id WHERE
> domains.domain='${quote_mysql:$domain}' \
>         AND users.username='${quote_mysql:$local_part}' \
>         AND domains.active=1 \
>         AND users.active=1 \
>         AND filters.active=1}}
>     no_verify
>     no_expn
>     check_ancestor

This is a central mailhub where users no longer have accounts.  Please
read the Exim Spec security section on "Running Local Commands":

  
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-security_considerations.html#SECTsecconslocalcmds

You're going to need to add a bunch of forbid_* options to that Router,
and keep an eye on release notes when upgrading, to watch for shiny new
forbid_* options.

See:

  
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_redirect_router.html#SECID130

for the list of options, search for "forbid_" (and "allow_").

> Am I going to need to arrange for the database result set to start with '#
> Exim Filter' each time or is their a boolean to force this?

If it worked before, it'll work now; if I were choosing, I would leave
it to the users to choose an Exim filter, a Sieve filter, or just a
simple forward rule.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Strange log message: no IP address found for host bazar2, conectiva.com.br

[Phil Pennock via Exim-users]

On 2019-03-31 at 19:12 +0100, Mike Tubby via Exim-users wrote:
>     no IP address found for host bazar2.conectiva.com.br

Some Googling suggests that this host used to run a Mailman instance
popular for hosting some Brazilian mailing-lists.

Seems like the sort of thing which might end up special-cased in a
domainlist somewhere, for whitelisting or special retry handling.

So if you have a DB/CDB file somewhere, or RDBMS, or special logic in
the exim configure file, this sort of hostname might be laying around as
cruft.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Server offering *all* certificates

[Phil Pennock via Exim-users]

On 2019-03-29 at 13:44 +, Richard Jones via Exim-users wrote:
> I was hoping to be able to validate them, yes. It just seems overkill to
> also offer every root CA installed.
> 
> If it's a choice of one cert or all, then clearly this isn't the end of
> the world, and thanks!

This is a crypto library issue.

With OpenSSL, as Jeremy hints at: the behaviour depends entirely upon
whether you provide the library with "a file containing all valid certs"
or "a directory within which we can look for files matching a hash of
the certs".

If you give OpenSSL a file, then it advertises them all to the client.
If you give OpenSSL a directory (processed with c_rehash or equivalent)
then it advertises none to the client, but can verify them all.

I forget what GnuTLS does and frankly have had too good of a Friday
evening to go documentation spelunking to look it up now.  :)

In both cases, the behaviour is outside of the direct control of Exim
(AFAIK) and we just expose ways of working with the libraries in their
"normal" ways.  Because we're masochists like that ^W^W^W^W thought that
would be a good idea.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] MTA-STS support?

[Phil Pennock via Exim-users]

On 2019-01-31 at 10:10 +, Jeremy Harris via Exim-users wrote:
> On 31/01/2019 09:47, sqit via Exim-users wrote:
> > Forgive me if there has already been a thread on this but I didn't see one. 
> > Is MTA-STS policy validation being considered for the Exim development 
> > roadmap?
> 
> Not by me.  The requirement to involve an http server puts me off.
> 
> I can't speak for other Exim devs, and contributions are generally
> welcome - if they come with testsuite coverage and preferably some
> indication of actual use in-the-wild.

I am opposed to MTA-STS as it embodies the security and failures of TLSA
usages 0 and 1 (PKIX-TA(0) and PKIX-EE(1)) which are in RFC 7672 section
3.1.3 described as SHOULD NOT for use with SMTP.

If entity A publishes policy in DNS for domains {a0, a1, a2, .. aN} then
that policy should not have any impact upon the security of connecting
to servers for domains {b0, .. bN} run by entity B.  Yet the PKIX-TA/EE
usages provide just that: DANE-TA says that in addition to meeting the
trust anchor requirements for this connection, the client software must
also fully trust this certificate authority for all TLS connections not
otherwise constrained by DANE.  That's not their business and not their
authority.

Once you have that, in an environment where postmasters get harassed to
just make the mail flow, you have a race-to-the-bottom spiral of ever
more unreliable CAs having to be trusted, in order to reach some
organizations.  Instead of the PKIX being "only those you trust" it
becomes "you have to trust every disreputable org on the planet".  In a
federated system of servers, with no end-user to click OK and affect
_only their connection_, being able to force third party trust is
reprehensible.

And yet MTA-STS embodies just this mode, with certain CAs becoming "too
big to fail" and whatever the large operators trust being forced on
everyone.  This is not appropriate for an independent and freely
operating Internet of equals.  It is overreach.

Stick to DANE with TLSA usages DANE-TA/DANE-EE, either of which is
suitable for federated trust between servers.  If not DANE for whatever
reason (some FUD about DNSSEC usually) then if trying to design a
replacement then *please* try to understand _why_ the DANE-implementing
MTA developer community rejected PKIX-TA/PKIX-EE before going ahead and
making their moral equivalent be your sole mode of operation.

For exim.org, we _publish_ an MTA-STS policy.  Anything which gets
stupid senders to latch onto better security is something to be
considered.  I almost rejected it outright on moral principle, but
decided to try it out.  It was a close call.  If you want certain large
senders to reach you and use verified TLS to do so, you can consider
publishing such policies.  It may result in a small group of senders and
their CA policies which constrain your choices, and you should figure
out ahead of time when you want to cut and run, if another big sender
suddenly says that your chosen CA is not good enough for them.

I do not want to see Exim implement client support for MTA-STS as I
believe that we would be performing a profound disservice for our users
by doing so.

What I say is not what goes for Exim, other developers may disagree with
my stance.  But I will object strongly to attempts to introduce MTA-STS
client support.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] NFSv4: failed to set ownership on spool file

[Phil Pennock via Exim-users]

On 2019-01-29 at 10:30 +0100, Heiko Schlittermann via Exim-users wrote:
> - The tcpdump show a V4 SETATTR, but only for the owner (I'd have
>   expected the group too), AND the owner is numerical, not user@domain,
>   as I would have expected. The pcap file is attached.

It's showing a GETATTR, not a SETATTR, according to my tcpdump.  I just
installed:
  tcpdump version 4.9.2
  libpcap version 1.9.0-PRE-GIT
and that's unchanged.

  NFS request xid 281459612 216 getattr fh 0,0/22
  NFS reply xid 281459612 reply ok 64 getattr ERROR: Permission denied
  (connection close)

As to what to expect: there's what the protocol allows, and there's what
the OS supports.  I'm not an NFSv4 expert, the last time I used NFS
professionally with email it was v3, but even there we had READDIR vs
READDIRPLUS and _how_ does the OS decide what to do?

In this case, GETATTR with major/minor devices of 0 and file descriptor
22 is issued, then you get permission denied on just the getattr, so the
OS isn't getting as far as failing at the chown (or this happened
after the chown?  Incomplete trace, can't tell.)

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Expiriences with TLS 1.3

[Phil Pennock via Exim-users]

On 2019-01-28 at 15:09 +, Andrew C Aitchison via Exim-users wrote:
> I see many header lines like:
> 
> Received: from smtp.spodhuis.org ([2a02:898:31:0:48:4558:736d:7470]:34422
>  helo=mx.spodhuis.org)
>  by hummus.csx.cam.ac.uk with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256)
>  (Exim 4.91) (envelope-from ) id 1f8ZjZ-0007nY-8Q
>  for exim-...@exim.org; Wed, 18 Apr 2018 00:09:57 +0100

FWIW, I use a Transport override so that mail going to the Hummus
machine connects to port 26 instead of port 25.  Port 26 is where we
install things like RCs or run tests before rolling changes out to port
25.  Anyone who wants can make a similar change, I don't anticipate us
ending the use of port 26 for "next-exim".  Just beware that things
might break so if you get mail queuing up, be prepared to switch back
(and provide logs pointing to what we've/I've messed up).

I do need to get around to installing the latest RC.  Sorry Heiko.

next-exim is currently:
Library version: OpenSSL: Compile: OpenSSL 1.1.1-pre5 (beta) 17 Apr 2018
  Runtime: OpenSSL 1.1.1-pre8 (beta) 20 Jun 2018
and I should fix that too.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Exim 4.92-RC1

[Phil Pennock via Exim-users]

On 2018-12-14 at 17:22 +, Jeremy Harris via Exim-users wrote:
> Possibly the main-config option openssl_options?
> 
> The docs list possibilities including
>   no_tlsv1
>   no_tlsv1_1
> 
> so I'd be tempted to try those without the "no_".

Alas, no.  You'd want `-no_tlsv1` but I doubt that works here: OpenSSL
is using an orthogonal set of tuning options.

The problem is that the system is using the new OpenSSL configuration
system which is not supported by LibreSSL, so until now we've avoided
it.

This config file is much simpler to support than "moving the TLS
configuration inside the Exim config file".  Pretty much we'd want to
use the `SSL_CTX_config()` library call inside Exim's
`tls-openssl.c:tls_init()`, guarded by some macro to protect against
LibreSSL/BoringSSL/whatever.

if (!SSL_CTX_config(ctx, "exim")) {
  handle_failure_accordingly();
}

Bonus points for copying the `tcp_wrappers_daemon_name` pattern and
making `"exim"` the default which can be overridden by an administrator.

(I'm not volunteering to do this, I'm busy)

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] [m...@openssl.org: Re: [openssl-users] openssl 1.0.2 and TLS 1.3]

[Phil Pennock via Exim-users]

On 2018-09-11 at 11:05 -0400, Viktor Dukhovni via Exim-users wrote:
> On Tue, Sep 11, 2018 at 03:37:12PM +0100, Jeremy Harris via Exim-users wrote:
> > They may well find that applications just refuse to change.
> 
> Debian Stretch ships with 1.1.0, applications are moving along.

My proposal to change the OpenSSL API we use ran into the need to
basically recreate the framework, because of LibreSSL declining to
implement that new API.

It will be interesting to watch to see what LibreSSL does about TLS 1.3
and that is likely to influence the course of action for Exim.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

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

[Phil Pennock via Exim-users]

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-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[exim] Administrivia: Direct requests for help

[Phil Pennock via Exim-users]

Folks,

Everyone here provides help on the mailing-lists on a volunteer basis.
That's part of how open source projects work.  If you get value from the
code and give help back in return, everyone benefits.  If the developers
give help here, that's nice of them; any developer who thinks the
documentation is could have helped better will often improve the
documentation as well as helping.  It's all important, not just the code
and those who write patches.

Please do not send direct requests for help to developers unless you
have some other arrangement with them, or are willing to enter into a
business relationship to pay for support.  If you need more help than
the community provides, then paid support is the way to go.  Various
companies are quite successful at doing this for open source software
(Red Hat comes to mind) and there are usually some companies listed in
the Exim wiki as providing commercial support for Exim.

For anyone reaching out to me for direct 1:1 support, please be advised
of the following: I live in the USA, and while my hourly rates would not
make an American lawyer blush, they would sit up in respect at the rates
being commensurate with their own.  I'm happy to bill, but do strongly
encourage folks to find other solutions first.

-Phil


signature.asc
Description: Digital signature
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[exim] exim mail outage

[Phil Pennock via Exim-users]

Folks,

I seriously messed up and didn't test enough scenarios when making a
change to Exim configs for exim.org on Tuesday.  I then spent yesterday
heads-down on work and didn't see Jeremy's report to me.

I broke things such that sender verification failed for almost
everybody.

Sorry.

I've rolled back the configuration changes to restore working mail.

(I should have known that the paucity of spam in the mailman moderation
 queues was too good to be true and not me just happening to look too
 soon after someone else had cleared the gunk).

-Phil


signature.asc
Description: Digital signature
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] detecting DMARC-protected domain

[Phil Pennock via Exim-users]

On 2018-07-07 at 18:56 +0100, Julian Bradfield via Exim-users wrote:
> Is there a way to detect, in the Exim configuration file, whether a
> sender domain has a DMARC record?

Use a `dnsdb` lookup, look for the DMARC DNS record.  The rest of your
mail leads me to suggest a better approach, but to first answer the
question as asked:

${lookup dnsdb{txt=_dmarc.$sender_address_domain}{yes}{no}}

> I suppose I should explain the reason, in case there's a better way:
> one of my users forwards her email to gmail (which I do via formail in
> her .procmailrc). Unfortunately, she gets mail from domains with a
> DMARC reject policy - so when I'm forwarding a DKIM-signed message, I
> munge it to come from us (using the percent hack, for old times' sake
> - yes, the acceptance of incoming percent-hacked addresses for relaying is
> tightly tied down:), and strip the signature.
> 
> Unfortunately again, one of the domains sometimes sends unsigned
> messsages. When they go directly to people, the From: address will
> authenticate against SPF, so will still pass; but since they're not
> signed, I don't detect and munge them, and of course they don't pass
> when relayed from me. I would prefer to avoid munging *all* her
> relayed mail, but could cope with munging all mail relayed from a
> DMARC protected domain.

Build Exim from source, either from git on the exim-4_91+fixes branch or
apply the patches from that branch to 4.91 (beware the extra src/ in the
hierarchy for the git repo as compared to release tarballs).

Jeremy would probably appreciate more testing and feedback.  :)

It's slightly intricate to configure and probably worth putting inside
".ifdef _HAVE_ARC" guards inside your Exim configuration file, so that
if you have to build without it you still have a mostly-working config.
It will require you to be doing both SPF and DMARC validation already.
But ARC is the way that you can try to chain forward in delivery to
folks like Gmail, saying "I received it from these folks and this is the
result of the validations _I_ did, please accept this as a good-faith
forwarding without penalizing other mail" and if you send enough mail,
Gmail might score your system to have a reputation such that it believes
your claims, and so if it sees that SPF passed for _you_ then it will
accept that.

There's a fair chunk more to ARC.  It's all about chains of headers,
redoing the Received: header system with a parallel set of
cryptographically signed headers which integrate more detailed
provenance claims.  If you're forwarding email to systems outside your
own administrative control, then ARC needs to be on your radar, if not
deployed already.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Rspamd-Proxy error with exim

[Phil Pennock via Exim-users]

On 2018-06-15 at 17:26 -0400, Phil Pennock via Exim-users wrote:
> On 2018-06-15 at 11:51 +, Emanuel Gonzalez via Exim-users wrote:
> > "In fact, it is Exim who SHOULD drop fucking legacy protocol support.
> > But I cannot convince its developers to do that. I have fixed this
> > issue at some point in the past but I have no Exim to test that."
> 
> For the record: this is the first I've ever heard of such an issue.
> 
> I've just checked <https://bugs.exim.org/> and there's no sign of a
> tracking issue.

I've found one mail pair on exim-dev, where I asked what was wanted and
some stuff was described in a follow-up.  That's it.

There's been no refusal, that I know of, to implement changes.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Rspamd-Proxy error with exim

[Phil Pennock via Exim-users]

On 2018-06-15 at 11:51 +, Emanuel Gonzalez via Exim-users wrote:
> "In fact, it is Exim who SHOULD drop fucking legacy protocol support.
> But I cannot convince its developers to do that. I have fixed this
> issue at some point in the past but I have no Exim to test that."

For the record: this is the first I've ever heard of such an issue.

I've just checked  and there's no sign of a
tracking issue.

We're open to patches to change protocols, that's how this code was
contributed in the first place.  We support open source and closed
source products both.  We've no objection to changing protocols here.

I do object to finding out that there's an issue by a developer of
another project bad-mouthing us and I object to spending my time
cleaning up the mess.  I've little to no incentive to go out of my way
to chase this down any further.

In the meantime, it looks like Exim just doesn't support rspam-proxy
if it's truly just ignoring configuration to speak their own protocol.

I've filed a feature request tracking issue:

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

I'm going to step away now because this entire situation is leaving a
bad taste in my mouth and making me grumpy.  "Feature request filing
against a project by bad-mouthing the developers and shaming them into
development" is not a model I wish to support or encourage for open
source development.  This is not why I give up my own time to work on
software such as Exim.  This is bullshit.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] unable to get local issuer certificate cert

[Phil Pennock via Exim-users]

On 2018-06-15 at 03:56 +0200, krz...@gmail.com via Exim-users wrote:
>  SSL verify error: depth=1 error=unable to get local issuer
> certificate cert=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert
> SHA2 High Assurance Server CA
> 
> Its the same error for every receiver and I belive error is about my
> certificate not remote one.

You're missing a system certificate trust store, so Exim can't verify
certs.  See the documentation for the "tls_verify_certificates" option.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Rspamd-Proxy error with exim

[Phil Pennock via Exim-users]

On 2018-06-14 at 18:31 +, Emanuel Gonzalez via Exim-users wrote:
> Here the log:
> 
> https://github.com/vstakhov/rspamd/files/2102038/rspamdserver.log

The rspamd proxy is replying with an HTTP response, not an RSPAM
protocol response.

Since I saw logic in the proxy source-code to handle this and perform
legacy conversions, my best guess is that some older release of rspamd
was missing that conversion logic and you need to upgrade rspamd.  My
second-best guess is that you didn't restart rspamd-proxy after setting
the option to enable the legacy format, or are editing the wrong config
file, or some other glitch like that.

Exim speaks the rspamc output format when told variant=rspamd and the
spamc output format by default.  rspamd seems to class these both as
"legacy" now.  The proxy in your examples is not speaking that when
talking back to Exim.

Where the rspamd-proxy is responding "HTTP/1.1 200 OK" to Exim, it
_should_ be responding something like "RSPAMD/1.3 0 EX_OK" instead.
Once you get it responding like that, everything should work.

Regards,
-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Rspamd-Proxy error with exim

[Phil Pennock via Exim-users]

On 2018-06-13 at 18:44 +, Emanuel Gonzalez via Exim-users wrote:
> rspamd-proxy doesn't work with Exim v4.87. Connection works etc but exim 
> can't parse the response.

Interesting.  From the rspamd log attached to your ticket against rspamd
it looks as though rspamd thinks things succeeded?

Since you have the service listening on a TCP port, could you provide a
tcpdump of the response, so we can see what text you're getting in
reply, please?

This means seeing the _actual_ reply, not just that there was a reply.

> 2018-06-13 13:45:23 1fT8te-0004kn-Pw spam acl condition: cannot parse spamd 
> [1.2.3.4]:11332, output: 0

Our code seems to match what I can figure out from the rspamd codebase,
but I've never looked at rspamd's code before so am unfamiliar with it.

The core parsing is unchanged from the logic which rspamd supplied to
us, I believe.

> More information see this report 
> https://github.com/vstakhov/rspamd/issues/2289

You include a tcpdump there showing that packets were exchanged, and
their sizes, but nothing about the content of the packets.

You'll want to tell tcpdump:  -Xs0

The "-s 0" says "read the entire packet, not just the start" and the
"-X" says to print a dump in hex and ASCII.

We only want the actual text from the reply, we don't need all the stuff
sending the mail across.  The reply probably includes the text:

   RSPAMD/1.3 0 EX_OK

That packet, to the end of the connection, is the bit we need, to
compare what the server sent with what Exim expected.

Regards,
-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] exim4 Versions above about 4.80 Don't Talk to my ISP's smarthost.

[Phil Pennock via Exim-users]

On 2018-05-31 at 21:41 -0500, Martin McCormick via Exim-users wrote:
>   The last part of this long message is the log of the
> delivery attempt.  As you see, I do now log in to the smarthost
> and the only reason for the failure is that the sender name gets
> changed.
> 
>   The ISP knows me as martin.m which is why the process
> still falls short.  End of message except for the long log.

I'm going to just discuss the Exim side of things, terminology and such,
to hopefully provide enough context and terminology for you; I can't
really help with the Debian config building.

There are two different identifiers:

 1. Which address is the sender of the email
 2. What is the authentication account for SMTP AUTH

The log-file you show has the authentication account (2) as martin.m
which all works fine.

If you generate mail with a particular sender (1), then that's what Exim
normally sends.  You can use "rewrites" to change that.

I suspect that in your upgrade you lost a rewrite configuration item.

Does this provide enough terminology to let you fix it?

Exim's use of Rewrites is not the same as Sendmail's.  Sendmail uses
rewrites for deciding how to send a message, and they're a core part of
routing.  Exim does not, the recipient and sender addresses should not
be changed to make routing decisions, that's why we have Routers.  But
if you do explicitly want to mutate an email address, you do still need
rewrites.



I simplified a little above, (1) should be (1a) and (1b), where there's:

 1a. The SMTP Envelope Sender
 1b. Some "Internet Message Format" header ("From:", "Sender:", ...)

I suspect that you want the SMTP Transport used for the smarthost
connection to do two things:

  i) set the `return_path` option to the same identifier used for
 authentication; this handles (1a)
  ii) use `headers_rewrite` to rewrite the From: header in the same way,
  to handle (1b)

If you want these to apply to all messages processed, not just those
sent to that smarthost, then this can be done a little more simply in
the rewrites section of the config file.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[exim] DANE example (Re: Exim & DANE .. status ?)

[Phil Pennock via Exim-users]

On 2018-05-22 at 18:09 +0200, Cyborg via Exim-users wrote:
> the german office of security ( BSI ) has given out a policy, that
> secure emailserver should have implemented DANE.
> 
> So, whats the status of DANE for Exim?
> 
> Any usefull selfexplaning examples at hand ? :)

Outbound or inbound?  Inbound, once you have TLS configured there's
nothing to do in Exim, it's all in how you configure DNS.  Viktor
provided a link to the docs:

  
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html#SECDANE

For outbound delivery:

Make sure that you have a validating DNS resolver.  I use Unbound.

Search for both "dnssec" and "dane" in:

  https://git.exim.org/exim.git/blob/HEAD:/src/src/configure.default

That's the current default Exim configuration in Git, updated since the
last release.  Future releases will have the default configuration file
enable DANE as long as Exim was compiled with support.

Relevant parts (line-numbers per "current HEAD" and might change):

   228  # The setting below causes Exim to try to initialize the system resolver
   229  # library with DNSSEC support.  It has no effect if your library lacks
   230  # DNSSEC support.
   231
   232  dns_dnssec_ok = 1

   596  dnslookup:
 #...
   603dnssec_request_domains = *

   733  remote_smtp:
 #...
   736  .ifdef _HAVE_DANE
   737dnssec_request_domains = *
   738hosts_try_dane = *
   739  .endif

That's it.  You tell Exim to try to enable DNSSEC in DNS queries, when
Routing you tell Exim to ask for DNSSEC for all domains, when delivering
you tell Exim to enable DNSSEC for all domains and to try to enable DANE
verification for all outbound connections.

If you want to enable filtered lists of hosts/domains, to work around
known brokenness, then change the `= *` to hostlist patterns in the
usual Exim way, so you can reference files etc.  If you want to enable
such workarounds, then try: .  They link to their
GitHub repository, with current lists.  You'll need to automate the
updates of that.

Myself, I don't currently run commercial mail-services, so I just don't
bother exempting anyone.  If someone breaks DANE, they lose inbound mail
until they fix it, and it's almost never been an issue.  I think I once
saw issues in the queues of exim.org for some domain and I reached out
to them separately and it got fixed.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] MySQL Connection errors – SSL?

[Phil Pennock via Exim-users]

On 2018-05-14 at 14:12 +0200, Kai Bojens via Exim-users wrote:
> 1. Does Exim close the MySQL connection properly? One explanation I
> found suggested that this could pose a problem.

It should be closing it.  There might be a leak, that is something we'd
probably fix given sufficient information.

Invoke exim with -d+lookup to get debugging information for lookups,
including MySQL.  When Exim closes a MySQL connection it will debug-log:

close MYSQL connection: 

When opening a connection it will debug-log:

MYSQL new connection: host=%s port=%d socket=%s database=%s user=%s

> 2. Is there any other possivle explanation for this behaviour?

Having written wire-protocol handling for MySQL I have many odious
thoughts on the topic, but most are not constructive.

Has Exim been recompiled with client libraries for the newer MySQL?
Exim with debugging enabled will report library versions, including at
compile-time and run-time, which may hint at issues here. MySQL's wire
protocol is ...  not sufficiently well structured that I'd be confident
in the handling across major versions here.

> 3. Are there any SSL related configuration options? My new server has
> ssl configured but the Exim documentation shows no options for this.

In the my.cnf file, whatever MySQL-specific options you want can be
given, in an "[exim]" section (by default).

Exim uses the MySQL client libraries, and calls roughly:

mysql_options(handle, MYSQL_READ_DEFAULT_GROUP, "exim")

so whatever client initialization is done based on that, should happen
automatically.  Note that the mysql_servers option can override that
value, in square brackets before the DB name.  So you could have
different groups for different purposes.

So you configure MySQL stuff in general with the "[client]" section in
my.cnf (wherever that is on your system), and then override the
all-clients defaults with an "[exim]" section.  More details at:

https://dev.mysql.com/doc/refman/8.0/en/option-files.html

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] setting up purchased SSL certificates on existing system

[Phil Pennock via Exim-users]

On 2018-04-30 at 14:58 +0100, Gary Stainburn via Exim-users wrote:
> I have now purchased (through 123-reg) a SSL certificate and I am trying to 
> install it on the server.

Which method did you use to buy the cert, and are you a "shared hosting
package" customer?

> My problem is that from my SSL certificate purchase I have an "Intermediate 
> Certificate" and a 'SSL Certificate'. The second of which is apparently 
> formatted for web software including Apache. I did not receive any key files.

Did you start from

?

Did you generate a CSR?  From a key?

If you have a key, which _you_ made, then you're good.  If you did not
make the key, but relied upon them to make one, then .. you'll need to
figure out where they put it.

If you used the `-des3` option, then the private key is encrypted.
You'll need to remove that encryption for Exim.  You can look at the
keyfile, it will be in PEM format (I hope!) and so start with
"-BEGIN yada yada" and around about there, it should tell you if
it's encrypted.  If it is, then to decrypt, assuming "roughly normal"
setup:

  (umask 077; openssl rsa -in encrypted.key -out unprotected.key; )

That will prompt for the passphrase, then write the key out unprotected
by encryption.  See below in my reply to Viktor for notes on correct
permissions.

Various other people have given good feedback on how to combine the
certificate with the bundle (append the bundle to the certificate) to
make a complete certificate chain for use.

Once you have those, the process should be roughly the same for both
Exim and Dovecot, just pointing config options at the key/cert.


On 2018-04-30 at 11:13 -0400, Viktor Dukhovni via Exim-users wrote:
> Don't forget a prior "umask 077" to make sure that the key file is NOT
> world-readable.

Be careful.  Exim opens the files as the Exim run-time user, *NOT* as
root!  The tls_* options can depend upon TLS SNI from the client, so are
capable of arbitrary string expansion.  The actual path isn't known
until that point.  Exim will have dropped privileges from root to the
run-time user long before this point.

So while the certificate can be permission 0644 just fine, the _key_
should probably be permission 0640 owner root, group Exim runtime user's
primary group.  Eg, `root:exim`.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Fw: paniclog after upgrade from 4.90_1 to 4.91

[Phil Pennock via Exim-users]

On 2018-04-23 at 21:20 +0200, Sławomir Dworaczek via Exim-users wrote:
>> Afertupgrade from exim version 4.90_1 to 4.91 messages not sending to 
>> external host
>> Panic log : Delivery status for user@external_domain.com got 0 of 7 bytes 
>> (pipeheader) from transport process 13323 for transport smtp
>
> i killed all exim process, The error is still there, no mail goes outside 
> domains

What is the output of:

  exim -d-all+acl --version

If you use `exim -bpru` to pick a message-id to try to deliver, what do
you see around the time of the failure in output of:

  exim -d+exec+transport+tls+auth -M $that_message_id

What's the output of:

  ldd -a -v $(which exim)

?

Is there anything in dmesg about a delivery attempt failing?

The above error seems to be saying that the delivery process died
without reporting back status.  So I tentatively suspect a crash either
in whatever (if any) authentication you perform against the remote
system, or TLS setup.  Thus I suspect something like "built with OpenSSL
headers for one version of OpenSSL but using a different version at
runtime".

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Next Exim: TLS: changed smarthost example config

[Phil Pennock via Exim-users]

On 2018-04-20 at 22:38 -0400, Viktor Dukhovni via Exim-users wrote:
> I'd make that:
> 
>   HIGH:!aNULL:!aDSS:!kECDHr:!kECDHe:!kDHr:!kDHd
> 
> Because, the ciphers are already sensibly ordered as of OpenSSL 1.0.0.

No matter what we tell people and how much we push towards 1.0.2 as a
minimum, I am confident that as long as someone can cobble together a
way to keep running with OpenSSL 0.9.8 then _someone_ will do so.

Thus @STRENGTH stays.  I believe that !aNULL is covered by requiring
verification, but sure good to disable here.  The others: it's more
complex knowledge of what should be put where end administrators touch
things than I'm entirely comfortable with.

So your string is "better" but I don't want to be putting that level of
intimidating TLS configuration into our starting configuration file.

Thus "HIGH:!aNULL:@STRENGTH" and _if_ I find time to work on the
suggested OpenSSL integration revamp, then something which disables
older versions of TLS, as for GnuTLS.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Next Exim: TLS: changed smarthost example config

[Phil Pennock via Exim-users]

On 2018-04-21 at 11:23 +0200, Andreas Metzler via Exim-users wrote:
> Personally I am not convinced that this is the right way for trying to
> enforce stronger encryption standards on mail providers.

It's not about that.  It's about providing people relying upon defaults
with worthwhile security, so that when their system goes to send email,
it's not trivially susceptible to MitM attack.

Along the way, I'm saying roughly "if these things don't work, then it's
breakage on the mail provider's side, here's my wet-finger-in-air
assessment of what these types of breakage mean as to whether or not you
should be using that mail-provider."

> is going to be any effect, people won't change their email address
> because the hosting smarthost does not provide TLS1.2 (due to SPF et

I didn't actually provide a wet-finger-in-air assessment of this point.
I covered "no TLS", "unverifiable certificate" and "ciphersuite
problems".

I mapped "no TLS" to "change mail provider" and I'm pretty serious
there: having to send email without any kind of link security at all
should be unacceptable.

I mapped "unverifiable certificate" to "seriously consider" changing
mail provider; after the past six years, since Heartbleed, enough
attention has been paid to TLS security that anyone providing a
commercial service to others should be able to manage a verifiable
certificate.  Let's Encrypt is two years old and now common enough to be
a baseline minimum.  If folks aren't offering a verifiable certificate
to their userbase, then now is the time to fix that.

This can be something from an internal certificate authority for an
organization which has such a thing and only lets internal systems send
email, or can be a free certificate if the more general public needs to
be able to send email.  The verifiable identity should be "whatever you
tell end users is the real name of the server".  None of this applies to
MX delivery.

I mapped "ciphersuite problems" to something which folks should expect
their mail provider to be able to fix quickly.  If there are issues and
they can't be fixed quickly, then why trust that the provider can do
much of anything to provide TLS service?

I did not map "no TLS1.2 support" but would tend to treat it much like
ciphersuite problems.

> cu Andreas

Thanks for the GnuTLS fixes, I'll apply those.  I did consider TLS 1.3
but there's enough uncertainty there that it seemed reasonable to wait,
rather than debug what protocol strings may or may not exist and be
parsed for SSLv3 etc etc.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[exim] Next Exim: TLS: changed smarthost example config

[Phil Pennock via Exim-users]

Folks,

I've committed and pushed a change to the default Exim configuration
file for the next Exim release.  This change has the example SMTP
Transport used for _smarthosts_, such as talking to an ISP, using TLS by
default, with _strong_ TLS enabled, and certificate verification, and
sending SNI.

The commented-out "smarthost" Router now uses a Transport named
"smarthost_smtp" instead of "remote_smtp".  The new smarthost_smtp
currently looks like the text below, which is subject to change before
the next release.

NOTE: every single bit of this configuration should work with the
current release of Exim, and the past several releases in fact.  So you
can try this out now to see if it works or not, if your current
configuration isn't this demanding.  *DO* watch your queues after doing
so.

Because many mail-clients are configured to talk directly to ISP
smarthosts and mail-clients usually enable TLS with decent verification
(or at least, the ones I use do), there _shouldn't_ be any issues.
But if there are, then they're likely to be:

1. Mail-provider does not provide STARTTLS on their smarthost.  In 2018.
   Seriously?  Find a new mail-provider.

2. Certificate does not verify.  File a Support request with the
   mail-provider to get it fixed.
   In 2018?  Seriously consider a new mail-provider.

3. You have to comment out the tls_require_ciphers because the
   mail-provider is running with really poor TLS support.
   File a Support request.  If they don't fix this quickly, then
   consider a new mail-provider.


The example configuration, all of which can be simplified by removing
the .ifdef branches which don't apply to you:

--8< smarthost_smtp >8--
smarthost_smtp:
  driver = smtp
  message_size_limit = ${if > {$max_received_linelength}{998} {1}{0}}
  multi_domain
  #
.ifdef _HAVE_TLS
  # Comment out any of these which you have to, then file a Support
  # request with your smarthost provider to get things fixed:
  hosts_require_tls = *
  tls_sni = $host
  tls_verify_hosts = *
  # As long as tls_verify_hosts is enabled, this won't matter, but if you
  # have to comment it out then this will at least log whether you succeed
  # or not:
  tls_try_verify_hosts = *
  #
.ifdef _HAVE_OPENSSL
  tls_require_ciphers = HIGH:@STRENGTH
.endif
.ifdef _HAVE_GNUTLS
  tls_require_ciphers = NONE:+VERS-TLS1.2:SECURE192
.endif
.endif
--8< smarthost_smtp >8--



signature.asc
Description: Digital signature
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Assistance requested with $if foray{...

[Phil Pennock via Exim-users]

On 2018-04-18 at 11:42 +, Robert Bannocks via Exim-users wrote:
> I want to search a file for decreasingly specific forms of an address
> that come from a given host and do some specialist routing thereafter.
> To this end I have constructed the following confition:

Can you change the stored format at all?  So that you have *@example.org
stored instead of just example.org ?  How important is the domainless
matching, and it being used in the same Router, instead of two different
Routers, given that usually mail addresses are per-domain?

https://www.exim.org/exim-html-current/doc/html/spec_html/ch-file_and_database_lookups.html#SECTdefaultvaluelookups

See how you'd use >> dbm*@ << instead of >> dbm << for matching; and see
subsequent sections of the documentation for other things which can be
done.

Consider also use of multiple Routers all using the same Transport.

Consider if you might be better served for at least one of those using
the local_parts precondition option with a query-style lookup, instead
of a condition option with a single-key lookup.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] compiling 4.91 under FreeBSD

[Phil Pennock via Exim-users]

On 2018-04-16 at 12:14 -0500, Larry Rosenman via Exim-users wrote:
> http://home.lerctr.org:/data/live-host-ports/2018-04-16_11h54m01s/logs/errors/exim-4.91.log

Enable OCSP support.  It's on by default in Exim and our test suite
isn't good at ensuring we still compile when various things are
disabled.  Instead, we rely upon people testing Release Candidates.

Jeremy has fixed this for the next release, but 4.91 hard-requires
either OCSP or a patch.

(Patches to update the test-suite to handle this cleanly would be
 gratefully received, and considered.)

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] compiling 4.91 under FreeBSD

[Phil Pennock via Exim-users]

On 2018-04-16 at 20:21 +0200, Max Kostikov via Exim-users wrote:
> I had this
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227560

The experimental DMARC support hard-requires SPF support.

NewStuff:

 4. SPF support is promoted from Experimental to mainline status.  The template
src/EDITME makefile does not enable its inclusion.

In Local/Makefile, replace EXPERIMENTAL_SPF=yes with SUPPORT_SPF=yes

Looks like the FreeBSD Ports tree has now adapted:

  
https://github.com/freebsd/freebsd-ports/commit/5c374cf90a31c879d053db12db0c08d830c8f31f

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Exim 4.91: option "hosts_try_dane" unknown

[Phil Pennock via Exim-users]

On 2018-04-16 at 20:47 +0200, Max Kostikov via Exim-users wrote:
> Is this option deprecated now?
> Found nothing about this in ChangeLog and NewStuff.
> (system is FreeBSD 11.1-RELEASE-p9)

With the benefit of 20/20 hindsight, there's a couple of things which
could have gone into README.UPDATING.  (Arguable, since the whole point
of something being "experimental" is that there are no guarantees about
it and we want feedback before making anything about it supported).

JH/20 DANE support moved from Experimental to mainline.  The Makefile control
  for the build is renamed.

So: in Local/Makefile replace EXPERIMENTAL_DANE with SUPPORT_DANE.

Roughly speaking, you always want to start with a current src/EDITME, or
at least diff the previous src/EDITME against the current one if you
want to stick with a file which is much reduced.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[exim] DKIM dual-signing RSA+Ed25519 working

[Phil Pennock via Exim-users]

Just so folks see it can be done: dual-DKIM signing, and verification,
with Exim.  Jeremy did all the Exim code to manage this, I'm acting
purely as a sysadmin in deploying this.

Exim 4.91, using OpenSSL 1.1.1-pre4, is the MTA for spodhuis.org;
and is the next-exim for exim.org, so is the version listening on port
26; @spodhuis.org is sending mail to @exim.org on port 26.  exim.org's
normal port-25 Exim is also 4.91, but is using OpenSSL 1.1.0h.

Note that RFC 6376 § 3.6.2.2 is very explicit that there can be only one
key for a given selector, so you MUST use multiple selectors when
signing, rather than two different algorithms under the same selector.

My Exim configuration is rather grotesque and could do with a spring
cleaning, but here's the relevant part of the SMTP Transport:

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

The $acl_m_dkim_sender_address boils down to $sender_address overridden
by ${reduce{${addresses:$h_from:}}{}{$item}} if From: exists, in both
the ACL connected to acl_smtp_data and the one connected to
acl_not_smtp.

With 4.91, when dkim_selector is a list, we expand dkim_private_key
repeatedly, with $dkim_selector set to each element in turn of that
list.  (Commit 9e70917d0aa).

At the current time, I'm sticking to RSA for ARC and haven't even looked
at the options there.

This mess is probably about at the point where I should be moving from
CDB to SQL with materialized views expanding the canonical form out to
easy forms to reason about from Exim's side.

The attached message is from one of my email addresses to my exim.org
address, where you can see Exim then verifying the signatures, before
sending it back to me.

Note that Ed25519 is "not something to rush to production", given that
important parts of the specification have not yet been nailed down.
With OpenSSL, it also requires a beta release, although things are a
little more stable over in GnuTLS land.

Note also that Gmail constructs an ARC-Authentication-Results: header
with two dkim entries too, but the second is "neutral", not "pass".  An
example header of a message sent to Gmail:

ARC-Authentication-Results: i=1; mx.google.com;
   dkim=pass header.i=@spodhuis.org header.s=d201804 header.b=XvwARr12;
   dkim=neutral (no key) header.i=@spodhuis.org header.s=d201804e2 
header.b=1q0qppzF;
   spf=pass (google.com: domain of 
prvs=064468e5c1=phil.penn...@spodhuis.org designates 94.142.241.89 as permitted 
sender) smtp.mailfrom=prvs=064468e5c1=phil.penn...@spodhuis.org;
   dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=spodhuis.org

The "no key" is bogus and should be "unsupported key".

Regards,
-Phil
--- Begin Message ---
wibble
--- End Message ---


signature.asc
Description: Digital signature
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Future OpenSSL configuration: sketch 1

[Phil Pennock via Exim-users]

On 2018-04-09 at 08:14 +0200, Kirill Miazine via Exim-users wrote:
> Hi, Phil
> * Phil Pennock via Exim-users [2018-04-08 17:24]:
> [...]
> > We've said "we only support versions of OpenSSL supported by the
> > upstream project", so now it's time to take advantage of that.
> 
> So LibreSSL is not supported officially, is it? If it breaks, it breaks,
> and Exim should be built with OpenSSL?

Exim is a volunteer project, we live on patches.  Our history is full of
features and support provided by drive-by patches, which were massaged
to be somewhat maintainable.  Jeremy, Todd and Heiko have done a lot of
work rounding out our test suite to remediate some of the negative
consequences of that.

When working across multiple choices of provider for a given interface,
the usual approach is a bridge pattern, where we stick to one simpler
subset of functionality and plugging in other providers can satisfy that
bridge.

If LibreSSL is going to continue to diverge, and if anyone cares enough
to provide patches, then we could easily have a `tls-libressl.c` file
which _implements_ the `SSL_CONF_cmd()` API, dispatching relevant
text-based calls to the correct feature-specific SSL_CTX manipulating
functions.

As someone maintaining an application built on SSL libraries, and
needing to provide tuning to multiple end-sites, while doing too much
already in terms of propagating SSL options and such like, I think that
the SSL_CONF_cmd() API is a great idea.  That it would let us change our
configuration to be more extensible, more flexible, easier to maintain
and generally more _useful_, for _less_ ongoing maintenance, is A Good
Thing.  I encourage folks to look carefully at what I proposed and how
easy it is to implement with this API and consider if their library
should support it too.

At present, we "support" GnuTLS and OpenSSL.  If anything else happens
to work, that's great for you.  If it break, you can either keep the
pieces or provide patches to make it work again, in a way which is
maintainable going forward.

We've been saying, including on the -announce list, for the past few
_years_ that we'll only support versions of OpenSSL which are supported
upstream and that "some release Real Soon Now" would break compatibility
with older versions.

-Phil


signature.asc
Description: Digital signature
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[exim] Future OpenSSL configuration: sketch 1

[Phil Pennock via Exim-users]

Folks,

The way we configure OpenSSL and the amount of special stuff we have to
do is a bit of a mess.  GnuTLS is a bit better, because you can put TLS
protocol versions into the Priority String, but with OpenSSL, we're
stuck trying to support every last thing and caught when some folks
stuck supporting bad clients hold us back from letting everyone else
move forward.

Several years ago, I added the openssl_options config knob to Exim,
which at least made things a bit better, but we're creaking now.

This is a rough proposal, with not a single line of code written to
support it, but I'm looking for considered informed feedback as to
whether it makes sense to postmasters out there.

We've said "we only support versions of OpenSSL supported by the
upstream project", so now it's time to take advantage of that.  I'm
proposing a new configuration section, when built against OpenSSL, which
uses an API introduced with OpenSSL 1.0.2, the minimum version still
supported upstream.  We would use SSL_CONF_cmd(3) and pass settings
through from Exim's configure file, straight to OpenSSL.

How it would look:

8< hooking: variant 1 >8
# Variant 1: main section config, handled like tls_require_ciphers now:

openssl = ${if eq{$received_port}{25}{server_mx}{server_submission}}
8< hooking: variant 1 >8

8< hooking: variant 2 >8
# main section:
acl_smtp_connect = acl_connect

begin acl

acl_connect:
  warn   condition = ${if eq{$received_port}{25}}
 control   = openssl/server_mx
  warn   condition = ${if !eq{$received_port}{25}}
 control   = openssl/server_submission
8< hooking: variant 2 >8

~8< hooking: smtp transport >8~~
begin transports:

remote_smtp:
  driver  = smtp
  openssl = ${if dane{client_dane}{client_insecure}}
~8< hooking: smtp transport >8~~

8< new config section >8
# This section is ignored if built against GnuTLS
#
# Warning: no string expansion is performed here (but may be in future).
# Macros are allowed.

begin openssl

server_mx:
  CipherString   DEFAULT:!SSLv2:!LOW:aNULL:!eNULL
  MinProtocolTLSv1# requires OpenSSL 1.1.0.
  Certificate/etc/exim/tls/mx.crt
  PrivateKey /etc/exim/tlx/mx.key

server_submission:
  Ciphersuites   TLS13-CHACHA20-POLY1305-SHA256:...   # used for TLS1.3
  CipherString   
ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:HIGH:!MD5:!RC4:!aNULL:!ADH:!DES:!EXP:!NULL
  MinProtocolTLSv1.2
  Groups X25519
  Options-SessionTicket
  Certificate/etc/exim/tls/submission.crt   # private CA, perhaps
  PrivateKey /etc/exim/tls/submission.key

client_dane:
  MinProtocolTLSv1.2
  CipherString   something modern-ish here
  # VerifyCAPath irrelevant here, DANE only supports usages 2/3 which
  # ignores this ... although if the remote server doesn't send a full
  # chain and uses fingerprint-based pinning, this might unbreak things
  # enough?

client_insecure:
  MinProtocolTLSv1
  VerifyCAPath   /etc/ssl/certs # Exim's require/try options still affect 
this
  CipherString   something broad here

# This isn't referenced above, but fancier config options could make it
# required for domains in a whitelist, eg to say "use better security
# for gmail.com":
client_secure:
  MinProtocolTLSv1.2
  CipherString   something modern-ish here
  VerifyCAPath   /etc/ssl/certs
8< new config section >8

Some settings come in with newer versions of OpenSSL.  We wouldn't have
to do anything special to support them, that's _why_ we'd just pass
things through.  If someone shouts and wants MinProtocol with older
OpenSSL, we'd shrug and say "upgrade OpenSSL, we use what they export
and are not getting sucked into replicating their work."

We simply split on whitespace to a "key" and a "value", where the value
can have internal whitespace we don't touch, but we strip off leading
and trailing whitespace.  Then we pass each key/value down.

The openssl main setting, or ACL control, and openssl SMTP transport
would all only be valid when built with OpenSSL and be parse errors with
GnuTLS.  The "begin openssl" could be allowed and ignored with GnuTLS.

At daemon startup, before backgrounding, where we do validation right
now, we'd go through every defined config block in the openssl section,
and for each one we're create an OpenSSL context, call SSL_CONF_cmd() to
set each line, and make sure there's no error.  If there's an error,
that's a fatal configuration error and is passed back.  These contexts
are all discarded.  This would then automatically be visible as an error
when running "exim -bV"/"exim --version".

Then at runtime, these values are just passed in when configuring the
context.

Fo

[exim] DANE / TLS ciphersuite improvements

[Phil Pennock via Exim-users]

On 2018-03-28 at 21:29 -0400, Phil Pennock via Exim-users wrote:
> On 2018-03-28 at 21:11 -0400, Phil Pennock via Exim-users wrote:
> > $smtp_found_dane or something?  Note that DANE support is Experimental
> > and feedback and requests are a good thing (patches even better!).
> 
> Uh ... DANE graduated from Experimental, I forgot.  Sorry.
> 
> Am tentatively thinking that since so many other TLS-related Transport
> options are ignored under DANE, and we don't require complicated
> expansion rules, the cleanest and easiest would be to have a new option,
> `dane_require_tls_ciphers`; if unset, `tls_require_ciphers` would be
> used as the default, but if set and _IF_ DANE is in play, then this
> cipherlist would be used instead.
> 
> I'll code up a strawman for consideration.

This has been merged.  I wrote the feature, Jeremy wrote the tests, the
buildfarm was happy, I've merged it to master.

This should be part of the imminent feature-freeze RC and thus part of
Exim 4.91 -- probably the last thing to squeak in, but it fits as part
of Jeremy's work maturing DANE: 4.91 will be the first release where
DANE is "normal" not "experimental", with support both via OpenSSL and
GnuTLS.

SMTP Transport option dane_require_tls_ciphers -- exactly the same as
tls_require_ciphers and falls back to tls_require_ciphers appropriately.
Use it to specify a different cipher list for when DANE is in play.

This makes it easier to be much stricter for hosts which appear to be
doing security right, and where there is no plaintext fallback.

With GnuTLS, where the string is interpreted as a "priority string", you
can also turn on and off TLS/SSL protocol versions as part of the
option.  With OpenSSL, it's just ciphersuites.

Have fun!
-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Exclude TLS_RSA_WITH_SEED_CBC_SHA from cipher list

[Phil Pennock via Exim-users]

On 2018-03-28 at 21:11 -0400, Phil Pennock via Exim-users wrote:
> $smtp_found_dane or something?  Note that DANE support is Experimental
> and feedback and requests are a good thing (patches even better!).

Uh ... DANE graduated from Experimental, I forgot.  Sorry.

Am tentatively thinking that since so many other TLS-related Transport
options are ignored under DANE, and we don't require complicated
expansion rules, the cleanest and easiest would be to have a new option,
`dane_require_tls_ciphers`; if unset, `tls_require_ciphers` would be
used as the default, but if set and _IF_ DANE is in play, then this
cipherlist would be used instead.

I'll code up a strawman for consideration.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Exclude TLS_RSA_WITH_SEED_CBC_SHA from cipher list

[Phil Pennock via Exim-users]

On 2018-03-28 at 11:43 +0200, Mark Elkins via Exim-users wrote:
> Begs the question, do DANE enabled machine therefore perhaps require a
> stronger encryption - as their owners should know what they are doing?
> 
> I've no idea if its possible to allow weaker encryption for
> opportunistic connections
> but enforce stronger encryption types on DANE compliant connections?

At present, it would require a bit of fiddling and logs-processing.

We have `$tls_out_dane` but the value is determined far too late to be
usable for setting `tls_require_ciphers` on the Transport.

We'd probably want some other variable, set as soon as we have DNS
signalling that DANE should be used, which can be referenced.
$smtp_found_dane or something?  Note that DANE support is Experimental
and feedback and requests are a good thing (patches even better!).

If not willing to edit Exim's source, then at present I'd just make sure
that `log_selector` includes `+tls_certificate_verified` and look for
`CV=dane` in the logs.  A logs processor could identify all domains
where that's seen, and things verified, and then update a DB of "domains
we should use better crypto for".  It's hacky, but then it would be the
beginning of a lightweight reputation tracking system for outbound
connections.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Question TLS

[Phil Pennock via Exim-users]

On 2018-02-22 at 17:34 +, Luciano InfoCultura via Exim-users wrote:
> How do I make connections initiated on ports 25 or 587 in plain text only 
> allow the sending of messages after using STARTTLS.
> my brief configuration:The message exchange is between servers and do not use 
> authentication.
> ..MAIN_TLS_ENABLE = truedaemon_smtp_ports = 25: 465: 587tls_on_connect_ports 
> = 465..

The MAIN_TLS_ENABLE setting is a sign of the Debianized configuration.

All of the Exim settings you have listed above are for how Exim listens,
not how it sends; sending is controlled via the SMTP "Transport" linked
to whichever "Router" accepted the message/recipient and chose remote
delivery via SMTP for it.

Ports 465 and 587 are for initial Submission by clients and not for
server-to-server traffic (except in special hacky situations such as
having your mail-server pretend to be a client, of Gmail/whatever).
Unless you've got a special arrangement in place, you're sending on port
25 and using STARTTLS to upgrade the connection.

I don't see a Debian control knob for this.  From Exim's side, you want
the SMTP Transport to include:

  hosts_require_tls = *

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Get the value of an external script in a condition

[Phil Pennock via Exim-users]

On 2018-02-20 at 13:54 +, Andrew C Aitchison via Exim-users wrote:
> Interesting idea to use the whois database to detect spammers.
> Since whois data has expiry info and doesn't change every day,
> I wonder how easy it would be to cache the results.

The jwhois client does this; it's a GNU project and I haven't looked at
it in ... 10+ years, but I used to use it a fair bit.  No idea what
they've done to adapt to the gTLD explosion.

Honestly, any wrapper script for use by an MTA should be caching
results.  And probably be a bit better about quoting, although at least
$sender_address_domain should be proof against those attacks.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] send mail based on origin domain

[Phil Pennock via Exim-users]

On 2018-02-16 at 12:21 -0300, Nicolas Leonel via Exim-users wrote:
> I apologizes but my exim knowledge is extremely limited, can you share an
> example on how to setup two different users with that example.

I did.  In the linked message:

> >   https://lists.exim.org/lurker/message/20171015.030553.5600347d.en.html

If you read that, you have a worked example of the various stanzas for
parts of Exim configuration.

If you need more than that, then I'm not the person to help you.  Paid
professional support from someone might help.

Regards,
-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] TLS BEAST attack on exim

[Phil Pennock via Exim-users]

On 2018-02-16 at 10:27 +0100, Cyborg via Exim-users wrote:
> has anyone ever heared, that Beast worked against TLSv1 on mailservers ?

I wrote a post to exim-announce at the time, analysing the situation.

A Google search for (exim beast) turned this up as the first result:

https://lists.exim.org/lurker/message/20110924.025611.322d31d8.en.html

Regards,
-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Exim-users Digest, Vol 165, Issue 9 [verification failed - body hash mismatch]

[Phil Pennock via Exim-users]

On 2018-02-12 at 18:53 -0500, Phil Pennock via Exim-users wrote:
> > On 12/02/18 12:12, Martin Nicholas via Exim-users wrote:
> > > I notice this from "Exim-users Digest, Vol 165, Issue 9":

> I've subscribed another address to the mailing-list, in digest mode, to
> see what happens next time.

Issues 11 and 12 of volume 165 reached me just fine.  I've checked the
mail-server logs and issue 10 didn't try to go to me, so I must have
subscribed after that one was sent.

Martin, do you see DKIM verification failures for exim-users digest
issues 11 or 12 on your side?

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] [META/OT] DKIM sender rewriting [Was: TLS error in incoming emails from *.outlook.com]

[Phil Pennock via Exim-users]

On 2018-02-12 at 19:45 -0800, Ian Zimmerman via Exim-users wrote:
> I note with horror that now I am also a 'via Exim-users' despite
> intentionally NOT using DKIM for list messages, including this one.
> Why?  Is the rewriting now done regardless?

Yes.  I don't know who/why.

from_is_list has been set to 1 (Mailman, General options)

Before, we just had set the DMARC-specific options (Mailman, Privacy
options, Sender filters).

I _suspect_ that it was a mistake when someone was hunting for options
to fix an apparent missing filter.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Exim-users Digest, Vol 165, Issue 9 [verification failed - body hash mismatch]

[Phil Pennock via Exim-users]

On 2018-02-12 at 14:04 +, Jeremy Harris via Exim-users wrote:
> On 12/02/18 12:12, Martin Nicholas via Exim-users wrote:
> > I notice this from "Exim-users Digest, Vol 165, Issue 9":
> > 
> > DKIM: d=exim.org s=d201802 c=relaxed/relaxed a=rsa-sha256 b=1248
> > [verification failed - body hash mismatch (body probably modified in
> > transit)]
> 
> What date was that?

Today.

So Exim 4.90.1 as sender.
Nothing hinky in the exim.org hub's Exim logs; message id
1elCmD-0003Wp-1g was queued by ACL (because it's from Mailman); 3mins12s
later a connection was made the Martin's MX host.  We log a certificate
verification failure because it's a self-signed cert and no DANE, but
continue on (as per normal for opportunistic TLS on SMTP/MX).  10
seconds later, we log successful delivery.  (There are some SMTP banner
delays from the remote server, I think).

QT=3m22s DT=25s  -- that's a little painful.
exigrep -I 'Exim-users Digest, Vol 165, Issue 10' /var/log/exim/main.log | 
pcregrep -o 'DT=\K\d+' | sort | uniq -c | sort -n

Result: (of 201 digest recipients total) 79 messages spent less than 1
second on the queue, 8 recipients took longer to deliver than 25seconds.
I'm assuming if it's not a slow network connection then it's heavy
processing before the message is accepted.

There's nothing else in the Exim mainlog; the sizes of each digest
message sent differ, which I expect for stuff with the recipient in the
body.

Hrm, the `b=` field is a little long for logging, with RSA keys, but
perhaps the `bh=` value could be included in the outbound logging?  In
theory that would at least let us look at a received mail and detect
tampering after the message left our system; but really, if a broken
corporate mail-filtering device tampered with the body, it almost
certainly has not adjusted the claimed DKIM-Signature: header too, so it
should be possible to take the digest and reconstruct.

Part of the qualification for a new Exim install on the Exim mail-hub
involves sending a short mail through to Gmail and looking at the
headers to confirm that an independent implementation is verifying
messages fine.  Won't help if it's a bug tickled by some large messages.

I've subscribed another address to the mailing-list, in digest mode, to
see what happens next time.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] send mail based on origin domain

[Phil Pennock]

On 2018-02-01 at 13:32 -0300, Nicolas Leonel via Exim-users wrote:
> Im using Sendgrid to send out email through my exim server, it uses a
> remote SMTP host, port, username and password for sending email. The
> problem is that now I would like to segment my delivery through multiple
> SMTP users, aka SendGrid Sub-users.
> 
> It appears I can do this by either using their API or through the MTA which
> I believe would be easier to implement, my question is does anyone know how
> to specify a certain SMTP user and password depending on the domain used to
> send the email from?

Yes.  This post might help:

  https://lists.exim.org/lurker/message/20171015.030553.5600347d.en.html

The two censored-for-web email addresses in the sample config extract
were `x...@gmail.com` and `z...@example.org`.

In essence: in the Router, use a lookup of `$sender_address` in some
data-source to get space-separated key=value pairs and stash that with
the `address_data` option, then refer to `$address_data` in the
Transport via `${extract{keyname}{$address_data}{true-val}{false-val}}`
to get the values of various options.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[exim] RFC8314: enable TLS-on-connect for clients to reach you

[Phil Pennock]

Postmasters might be interested in the newly issued RFC:

  https://www.rfc-editor.org/rfc/rfc8314.txt

In this, Standards Track recommendations are made concerning TLS between
an MUA (mail client) and the SMTP Submission Server (and IMAP/POP3
services).  This does _not_ affect server->server communications ("MX
Delivery").

Note that port 465 is now "blessed" as "submissions", for clients to use
for submitting messages, it's _preferred_ and mail server operators
should offer both this and 587 service.

If you've hit political resistance to deploying 465 mail service, this
should be the document to use to justify to others doing the sane thing
for mail clients.

The IANA registry has been updated and now dual-assigns port 465.
(Actually, triple-assigns).

There are also recommendations concerning TLS versions; note that Exim
when using OpenSSL has to use `openssl_options` to control these and
there's no way to use something different for incoming/outgoing from one
Exim config, let alone vary based on port.  When using GnuTLS, the Exim
`tls_require_ciphers` option is interpreted as a GnuTLS Priority String,
and so you can control the allowed versions of SSL/TLS from within that
string.

Something like this might work for you (depends upon version of GnuTLS):

  # macros section
  CIPHERS_IN_MX=NORMAL
  CIPHERS_IN_SUBMIT=NORMAL:-VERS-SSL3.0:-VERS-TLS1.0:-VERS-TLS1.1

  # main section
  tls_require_ciphers = ${if forany{465:587}{=={$received_port}{$item}} 
{CIPHERS_IN_SUBMIT} {CIPHERS_IN_MX}}:!aNULL:!eNULL

  # nb: outbound TLS controlled via tls_require_ciphers on
  # `smtp`-driver Transport used

There's also stuff around SHOULD for using DNS SRV records for service
discovery by clients, etc.  Basically updating the IETF standards to
current best practices.  There's new Received: header fields to record
the TLS cipher and group, and the ciphersuite text format is _not_ the
format which Exim currently uses!  We'll have to consider that
carefully.

-Phil


signature.asc
Description: Digital signature
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Can't register in bugs.exim.org

[Phil Pennock]

On 2018-01-06 at 19:50 -0500, Phil Pennock wrote:
> On 2018-01-05 at 15:09 +0200, Max Kostikov via Exim-users wrote:
> > Tried few times but received nothing in email.
> 
> This is a bug in Exim, exposed on our side.  Sorry.

Bug worked around, mail should be flowing, bug 2220 filed.

Max: I've manually deleted the row from the buganizer "tokens" table for
your email address, so you should not get any complaints about trying
again "too soon".  If you start afresh now, then you should be able to
create an account.

Thanks for the report!

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Can't register in bugs.exim.org

[Phil Pennock]

On 2018-01-05 at 15:09 +0200, Max Kostikov via Exim-users wrote:
> Tried few times but received nothing in email.

This is a bug in Exim, exposed on our side.  Sorry.

Logs show "DKIM: message could not be signed, and dkim_strict is set."

I'll include diagnostics here as "of interest to others in reporting
bugs".

Exim is 4.90

DKIM configuration on remote_smtp is:

  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

bugs.exim.org does not have an entry in the domains-mapping, so is not
signed.

Running >> exim -d+all -t -f ad...@bugs.exim.org << and entering an
email manually, to send to me, I see:

8< exim debug output >8-
00:36:25.069  5832 dkim signing direct-mode
00:36:25.069  5832  ┌considering: ${domain:$sender_address}
00:36:25.069  5832   ┌considering: $sender_address}
00:36:25.069  5832   ├──expanding: $sender_address
00:36:25.069  5832   └─result: ad...@bugs.exim.org
00:36:25.069  5832  ├──expanding: ${domain:$sender_address}
00:36:25.069  5832  └─result: bugs.exim.org
00:36:25.069  5832  ┌considering: ${lookup 
{$dkim_domain}lsearch{/etc/exim/dkim/domains-mapping} {$value}{SKIP}}
00:36:25.069  5832   ┌considering: 
$dkim_domain}lsearch{/etc/exim/dkim/domains-mapping} {$value}{SKIP}}
00:36:25.069  5832   ├──expanding: $dkim_domain
00:36:25.069  5832   └─result: bugs.exim.org
00:36:25.069  5832   ┌considering: /etc/exim/dkim/domains-mapping} 
{$value}{SKIP}}
00:36:25.069  5832   ├──expanding: /etc/exim/dkim/domains-mapping
00:36:25.069  5832   └─result: /etc/exim/dkim/domains-mapping
00:36:25.069  5832 search_open: lsearch "/etc/exim/dkim/domains-mapping"
00:36:25.069  5832   cached open
00:36:25.069  5832 search_find: file="/etc/exim/dkim/domains-mapping"
00:36:25.069  5832   key="bugs.exim.org" partial=-1 affix=NULL starflags=0
00:36:25.069  5832 LRU list:
00:36:25.069  5832   6/etc/exim/dkim/domains-mapping
00:36:25.069  5832   End
00:36:25.069  5832 internal_search_find: file="/etc/exim/dkim/domains-mapping"
00:36:25.069  5832   type=lsearch key="bugs.exim.org"
00:36:25.069  5832 cached data used for lookup of bugs.exim.org
00:36:25.069  5832   in /etc/exim/dkim/domains-mapping
00:36:25.069  5832 lookup failed
00:36:25.069  5832   ┌───scanning: $value}{SKIP}}
00:36:25.069  5832   ├──expanding: $value
00:36:25.070  5832   ├─result:
00:36:25.070  5832   └───skipping: result is not used
00:36:25.070  5832   ┌considering: SKIP}}
00:36:25.070  5832   ├──expanding: SKIP
00:36:25.070  5832   └─result: SKIP
00:36:25.070  5832  ├──expanding: ${lookup 
{$dkim_domain}lsearch{/etc/exim/dkim/domains-mapping} {$value}{SKIP}}
00:36:25.070  5832  └─result: SKIP
00:36:25.070  5832  ┌considering: ${if 
eq{$dkim_selector}{SKIP}{false}{/etc/exim/dkim/rsa.private.$dkim_selector.$dkim_domain}}
00:36:25.070  5832   ┌considering: 
$dkim_selector}{SKIP}{false}{/etc/exim/dkim/rsa.private.$dkim_selector.$dkim_domain}}
00:36:25.070  5832   ├──expanding: $dkim_selector
00:36:25.070  5832   └─result: SKIP
00:36:25.070  5832   ┌considering: 
SKIP}{false}{/etc/exim/dkim/rsa.private.$dkim_selector.$dkim_domain}}
00:36:25.070  5832   ├──expanding: SKIP
00:36:25.070  5832   └─result: SKIP
00:36:25.070  5832  ├──condition: eq{$dkim_selector}{SKIP}
00:36:25.070  5832  ├─result: true
00:36:25.070  5832   ┌considering: 
false}{/etc/exim/dkim/rsa.private.$dkim_selector.$dkim_domain}}
00:36:25.070  5832   ├──expanding: false
00:36:25.070  5832   └─result: false
00:36:25.070  5832   ┌───scanning: 
/etc/exim/dkim/rsa.private.$dkim_selector.$dkim_domain}}
00:36:25.070  5832   ├──expanding: 
/etc/exim/dkim/rsa.private.$dkim_selector.$dkim_domain
00:36:25.070  5832   ├─result: /etc/exim/dkim/rsa.private..
00:36:25.070  5832   └───skipping: result is not used
00:36:25.070  5832  ├──expanding: ${if 
eq{$dkim_selector}{SKIP}{false}{/etc/exim/dkim/rsa.private.$dkim_selector.$dkim_domain}}
00:36:25.070  5832  └─result: false
00:36:25.070  5832 PDKIM >> Body data for hash, canonicalized 

00:36:25.070  5832 PDKIM 

00:36:25.070  5832 LOG: MAIN
00:36:25.070  5832   DKIM: message could not be signed, and dkim_strict is set. 
Deferring message delivery.
8< exim debug output >8-

Per 
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-support_for_dkim_domainkeys_identified_mail.html#SECDKIMSIGN
we see this (here from spec.txt because formatted for mail):

-8< dkim_private_key >8-
+---+
|dkim_private_key|Use: smtp|Type: string*|Default: unset|
+-

Re: [exim] Some mails are queued, other are sent immediately

[Phil Pennock]

On 2017-12-18 at 15:02 +0100, Yvan Masson wrote:
> Anyway, during tests I noticed that some emails are sent immediately
> (what I prefer), while other are queued (introducing useless delay):
> - Why this difference ?
> - What could I do to avoid the queue ?

By default, Exim will tell you why, with a log-line, when it doesn't
deliver immediately.  This appears to have been turned off in your
installation -- I don't know if that's Debian or site-local.

This is the "delay_delivery" log selector field.  See:
  
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-log_files.html#SECTlogselector

If you run:

  exim -bP log_selector

then you'll see the actual configured value.

Get the default logging of "why we're not delivering immediately" turned
back on, and you should be in a stronger position.

If it is turned on, then ... look for signs of a crashing Exim process
(eg, complaints in dmesg).

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Exim 4.90 RC3 uploaded

[Phil Pennock]

On 2017-11-30 at 08:35 +0100, Frank Elsner wrote:
> On Wed, 29 Nov 2017 20:21:47 + Jeremy Harris wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > I have built, signed and uploaded RC3 of Exim 4.90 to the ftp site:
> 
> Hi,
> 
> I've still problems to compile on an actual Fedora 26 system:

Which version of OpenSSL is this?

Try:
  yum -y install --allowerasing compat-openssl10-devel
to replace openssl-devel (OpenSSL 1.1.x) with OpenSSL 1.0 stuff.

We still haven't actually moved to a newer OpenSSL API, although we keep
threatening to, so we probably still build with upstream-unsupported
releases of OpenSSL.  But part of the reason for moving to "only support
the versions which upstream supports" is that it will let us switch APIs
(at some point) to use stuff which works with OpenSSL 1.1 too.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Verifying local addresses for inbound emails when using Dovecot/pipe transport

[Phil Pennock]

On 2017-11-29 at 22:18 +, Sebastian Arcus via Exim-users wrote:
> Is there a way to build a router only for verification of local addresses
> for inbound messages? As far as I can tell, verify = recipient doesn't work
> when Exim delivers to Dovecot through dovecot-lda - as this always verifies
> the recipient (as long as the domain is in +local_domains) no matter what
> the local part is. I guess the only way is to construct an extra router,
> which does verification separately, maybe against a separate list of local
> addresses in a file?

Yes.  Put "verify_only" on that Router, and "no_verify" on the delivery
Router, and have them adjacent in the configuration.

This is also a useful split if you have to send mail off to a smarthost
but are online and can do DNS lookups; eg "remote_dns_verify:" Router
with "same_domain_copy_routing" and "verify_only" immediately before
your "smarthost:" Router.

I'm surprised that dovecot-lda isn't verifying the recipient.  You're
using it in LMTP mode right, so that Exim can talk to it?  And if it's
an SMTP/LMTP Driver then you probably need to explicitly do
verify=recipient/callout in the ACL.

For myself, I deliver most mail to Cyrus and I cheat and use knowledge
of the backing filesystem layer, breaking the black box open, so I just
use one Router for delivery and verification, but it has:

  require_files = 
IMAP_MAIL_BASE/${length_1::$local_part}/user/${tr{$local_part}{.}{^}}

for the user-address router, and a shared-folder router has:

  require_files = 
IMAP_MAIL_BASE/${length_1::$local_part}/${lookup{$domain}cdb{CDBMAILTABLES/imap_shared_name.cdb}}/${tr{$local_part}{.}{^}}

This is indubitably "wrong and evil" from the Cyrus perspective, but
it's simple and clean and right from my postmaster perspective.

This should be doable for Dovecot too; or use Dovecot's user database in
a lookup:   condition = ${lookup pgsql{SELECT whatever}{yes}{no}}
instead.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] exim and clamav deny malware

[Phil Pennock]

On 2017-11-18 at 10:57 +, Jeremy Harris wrote:
> On 18/11/17 04:52, Phil Pennock wrote:
> > Or try:
> > 
> >   malware = */defer_ok
> 
> Nope; this case sisdn't get as far as the call out to clamav.  It failed
> trying to write the file for clamav to work on.

malware.c:
 448 /* Ensure the eml mbox file is spooled up */
 449
 450 if (!(mbox_file = spool_mbox(&mbox_size, scan_filename, &eml_filename)))
 451   return malware_errlog_defer(US"error while creating mbox spool file");

 121 static inline int
 122 malware_errlog_defer(const uschar * str)
 123 {
 124 log_write(0, LOG_MAIN|LOG_PANIC, "malware acl condition: %s", str);
 125 return DEFER;
 126 }

It _should_ be handled by /defer_ok and if not, then we have a bug to be
investigated.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] exim and clamav deny malware

[Phil Pennock]

On 2017-11-17 at 16:18 +, Jeremy Harris wrote:
> On 16/11/17 16:41, Emanuel wrote:
> > Is it possible to add an exception, in case the analysis fails mail is
> > sent anyway?
> 
> Currently no; it's a fatal error.  Even if you did go on it'd probably
> fail for the same reason later in processing, so I don't think it's
> worth trying to be more clever.

Or try:

  malware = */defer_ok

That _should_ mean that problems with the virus scanner don't block the
message.  It's been a long time since I looked at the logic involved and
I wouldn't swear that all scanners are great at distinguishing framework
problems from message malware.  But ClamAV support is likely to be
solid.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Exim and MySQL with UTF-8 encoding

[Phil Pennock]

On 2017-11-08 at 22:15 +0100, Yves Goergen wrote:
> How can I tell Exim to talk to the MySQL server with UTF-8 encoding?

If "[exim]" is not already in my.cnf then perhaps:

  # printf '[exim]\ncharacter_set_client=utf8\n' >> /etc/my.cnf

Exim specifies an option group to the MySQL client library.  The default
value given is "exim", so in `/etc/my.cnf` you can have a section
starting `[exim]` and put whatever options you want in there.

(MySQL searches a range of places, my last blog-post where I touched
this, I noted that Ubuntu required /etc/mysql/my.cnf so ... figure out
which ones actually work on your distribution; I'm going to write
/etc/my.cnf here)

If that's not specific enough and you want other clients, then the Exim
configuration option `mysql_servers` or the server-spec at the start of
the query has an expanded syntax, as described in "Special MySQL
features" in The Exim Specification:

  host:port(socket)[group]

The `[group]` part there is the name of the group parsed from
`/etc/my.cnf`.  So `mysql_servers = maildb.example.com[exim-utf8]`
should work just fine.

My MySQL is incredibly rusty, but I think something like:

/etc/my.cnf :

  [exim]
  host=maildb.example.com
  ssl
  ssl-capath=/etc/ssl/certs/
  character_set_client=utf8

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Exim 4.90 RC1 uploaded

[Phil Pennock]

On 2017-10-28 at 15:58 +0200, Heiko Schlittermann via Exim-users wrote:
> So, what's the owner of the binary? And - does your OS provide some
> means to disallow set-uid binaries from setting the (e)uid (Linux has,
> but has your *BSD?)

Yes.  FreeBSD supports nosuid mounts.  With ZFS, it's even an
inheritable property on the dataset.  In either case, just running
`mount` and looking for the mount-point where the binary lives should
reveal it.

Eg:

  # mount | grep music
  cast/media/music on /mnt/cast/media/music (zfs, local, noatime, noexec, 
nosuid, nfsv4acls)
  # zfs get setuid cast/media/music
  NAME  PROPERTY  VALUE   SOURCE
  cast/media/music  setuidoff inherited from cast/media

Hope this helps with debugging,
-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] sender-address and gmail

[Phil Pennock]

On 2017-10-23 at 17:46 +0200, Heiko Schlittermann via Exim-users wrote:
> Angelo Chen via Exim-users  (Mo 23 Okt 2017 10:25:33 
> CEST):
> > > client_send = : $sender-address : aPassword
> > >
> > > this failed, looks like $sender-address is expanded into user1@localhost,
> > > any idea how to make this work? THanks,
> 
> Your 
> 
> echo … | mail … -r …
> 
> is called by a non-privileged user "user1", isn't it?
> Exim overrides the envelope sender with the ID it believes to be correct
> and trusted. In your case it is the "user1".

Thus `qualify_domain` as a main configuration option.

Change `qualify_domain` to not be `localhost`, but the desired local
domain.  Then no trust configuration should be needed.  However, that
does require that all local usernames be valid login names, which seems
undesirable to me.  But hey, that's what was asked.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Spambox cfg for remote delivery?

[Phil Pennock]

On 2017-10-18 at 08:36 +, Jaap Winius wrote:
> Some time ago I devised a spambox configuration for Exim so that messages
> that are flagged by only one or two types of filters will end up in a user's
> spambox. The transport looks like this:
> 
> spambox:
[...]

Last time I ran ISP mail-systems (now over a decade ago), I built the
mail-platform to have front-end MX servers ("incoming-N") and store
boxes ("store-N"), with the incoming boxes running spam and virus
filters, etc.  That way, if there were a remote exploit against the
virus scanner (likely, as there's a large attack surface) then for the
duration of the attack, the attacker could get to "mail passing through
incoming", not to "all the mail which the user has stored".

I then had the store boxes run two instances of Exim, on different
ports.  Port 25 was regular, and I think it was port 26 for Spam.  I no
longer remember for sure, but I suspect that port 26 was the same config
file and Exim invoked with "-DFOO=bar" to enable spam-mode, with a
different path to the storage area for all the spam (and different
log-files, etc).

That way, the front-end box can decide to classify the message as spam
and send it on with an intact envelope to the spam storers.  Basic Exim
logs processing for the two instances then gets you spam-vs-nonspam
stats.  And any tools which examine spam, eg to learn from it, can look
at the original recipient address and not learn "oh, all spam is sent to
addresses with +spam in them".  Preserving the envelope seemed
worthwhile to me.

In your case, you'd then keep the Routers the same, but have spambox be
redefined to be an "smtp" transport instead of "appendfile" and just
override "port = 26" in the definition:

  spambox:
debug_print = "T: spambox for $local_part@$domain"
driver = smtp
port = 26

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] how to get the email address of the sender?

[Phil Pennock]

On 2017-10-14 at 22:34 +0800, Angelo Chen via Exim-users wrote:
> I'm trying to set up a gmail relay:

This is modified from my setup, with the bit which relays mail from
exim.org out through the exim.org server; so this isn't 100% known to
work, I might have made typos.

The file /etc/exim/auth/outbound-passwords would need to exist, have
appropriate permissions, and look something like:

8< outbound-passwords >8
x...@gmail.com: user=x...@gmail.com password=12345678 
clienttoken=my-short-persistent-id
z...@example.org:   user=dhr.zyx   password=geheim  port=29  tls=yes
8< outbound-passwords >8

The default cipherspec looks awful to people who don't understand SMTP
security and cargo-cult everything, but it's better than falling back to
plaintext and is reliant upon TLS correctly picking a good ciphersuite.
If the attribute 'tlshigh' is set then its value is used as a spec, or
if it's set to just 'yes' then the other macro is used.

Note that you should get an "App Specific Password" from Google
 and use that for the mail
configs, instead of hard-coding in your regular password.  This will
also let you enable 2FA but still use SMTP mail.

-8< cut here >8-
# macros section
RUNAUTHDIR=/etc/exim/auth
TLS_CLIENT_DEFAULT_CIPHERSPEC=DEFAULT:!SSLv2:!LOW:aNULL:!eNULL
TLS_CLIENT_HIGHSEC_CIPHERSPEC=ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:HIGH:!MD5:!RC4:!aNULL:!ADH:!DES:!EXP:!NULL
SSL_CERTS_DIR=/etc/ssl/certs


# routers
# nb: on main routers, avoid "same_domain_copy_routing" because it will
# interfere with sender-based routing
via_gmail:
  driver= manualroute
  senders   = *@gmail.com
  domains   = ! +local_domains
  route_data= smtp.gmail.com
  transport = secure_smtp
  address_data  = ${lookup 
{$sender_address}lsearch{RUNAUTHDIR/outbound-passwords}} authreq=yes tls=yes 
tlshigh=yes port=587

# transports
secure_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}}}{}}
  tls_sni = ${extract{tlssni}{$address_data}{$value}{}}
  tls_require_ciphers = ${extract{tlshigh}{$address_data}{${if 
eq{$value}{yes}{TLS_CLIENT_HIGHSEC_CIPHERSPEC}{$value}}}{TLS_CLIENT_DEFAULT_CIPHERSPEC}}
  tls_verify_certificates = 
${extract{tlsverify}{$address_data}{SSL_CERTS_DIR}fail}
  dnssec_request_domains  = *
  hosts_try_dane  = *
  no_multi_domain
  no_delay_after_cutoff

# authenticators
auth_plain:
  driver= plaintext
  public_name   = PLAIN
  client_condition  = ${if def:tls_out_cipher}
  client_send   = 
^${extract{user}{$address_data}{$value}fail}^${extract{password}{$address_data}{$value}fail}

auth_plain_clienttoken:
  driver= plaintext
  public_name   = PLAIN-CLIENTTOKEN
  client_condition  = ${if def:tls_out_cipher}
  client_send   = 
^${extract{user}{$address_data}{$value}fail}^${extract{password}{$address_data}{$value}fail}^${extract{clienttoken}{$address_data}{$value}fail}

-8< cut here >8-

This adds support for using PLAIN-CLIENTTOKEN for Gmail instead of
PLAIN; I've added it here based on a description posted by one of
Google's postmasters to another mailing-list recently.  Untested by me,
but it should work.  If not, just remove that authenticator.  The id
should be something short and stable you pick but keep private, changing
it on each machine which uses this, to let Google's security systems
track moving devices and protest if the same token is being used on two
different continents at the same time, etc.

-Phil


signature.asc
Description: Digital signature
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] 4 issues to fix

[Phil Pennock]

On 2017-10-06 at 17:50 -0600, The Doctor wrote:
> On Fri, Oct 06, 2017 at 05:28:43PM -0600, The Doctor wrote:
> > Current version of the FreeBSD 11 port 
> > 
> > /usr/local/sbin/exim -bd -q1m -C /usr/local/etc/exim/configure.out

Is the Exim binary setuid?
Is the filesystem mounted nosuid?
  Eg, if zfs:   zfs get setuid /usr/local/sbin

If a program is crashing on a signal on FreeBSD then by default there
will be a message written to dmesg.  If you run dmesg, do you see
reports of Exim dying?

> > > Because the delivery process is dying.
> >
> > How is that?

Are you trolling?  Seriously?  Point 1, the delivery process is dying.

> > Will read
> > 
> > Basically we just do not need the Originating as, just that it is 
> > authenticated
> > and off it going without being rewirttern.

This is not the first time we've been through this dance.

At some point, you need to put in the effort to learn for yourself, or
pay someone to do it, instead of relying upon volunteers on the Internet
to do your work for you when you can't be bothered to do the basic
research.

If you reply and your next reply doesn't indicate that you're willing to
do even basic work for yourself, then I won't bother replying again.

At some point, continuing to ask for help from a volunteer community
without putting in work for yourself crosses the line into being toxic
behavior and will result in your being kicked from the mailing-list.
Please consider yourself on notice for abuse.

> > > My first suspicion is that DNS is configured to point the domain at your
> > > servers but you haven't configured it as a local-domain or
> > > relay-for-domain in either of the relevant domainlists.
> > 
> > New 'operational values'?
> 
> Are 
> 
> Uname
> 
> and 
> 
> the revelant configuration files 
> 
> needed?

No, what's needed is for you to look at your configuration, read the
comments, and think about the advice offered so far.

If your configuration is anything like the default supplied with Exim,
then in the main configuration section will be "domainlist
local_domains" and "domainlist relay_to_domains".

Think about the domain in question, think about what _should_ happen
with it, read the configuration, understand where you're configuring the
domains, and add the domain to the right place.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] 4 issues to fix

[Phil Pennock]

On 2017-10-06 at 13:32 -0600, The Doctor wrote:
> 1)
> 2017-10-06 12:55:36 1e0XmX-Ww-I2 failed to read delivery status for 
> ***@doctor.nl2k.ab.ca from delivery subprocess

The child process has terminated without writing status back to the
parent.  It has probably crashed.  Is dmesg reporting crashed Exim
processes?

Which version of Exim?  Any patches?  How configured?

> 2)
> I have to push e-mail through every 3 to 5 minutes using a cron job.
> 
> Why is the e-mail simply not flowing?

Because the delivery process is dying.

> 3)
> I do not wish to see sendmail from account@realdomain ;  it should be 
> at account@custoemrdomain .  How do I rewrite?

This is a large topic.  How about you tell us where you got in

  
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-address_rewriting.html

and what parts are causing you problems, so that we can help you and fix
the documentation to better help others in future?

> 4)
> 
> Outlook.com is getting a relay not permitted notice on the outgoing exim 
> server.
> 
> What gives?

To be clear: a server under your control is returning "relay not
permitted" to Outlook, for a domain which it should be accepting?

My first suspicion is that DNS is configured to point the domain at your
servers but you haven't configured it as a local-domain or
relay-for-domain in either of the relevant domainlists.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Problem with exim

[Phil Pennock]

On 2017-10-05 at 11:06 +0200, Daniel Heß wrote:
> i have the problem on my exim-server ( 4.82 ) that mails to remote_smtp
> servers only work by the second connect. On the first connect i recive a Bad
> file descriptor.

A bug fixed in 4.83, released in 2014.  We're now on 4.89.

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

See change TF/01 under 4.83.

Regards,
-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] set return_path in config gives error

[Phil Pennock]

On 2017-10-04 at 22:58 +0200, Andy Smith via Exim-users wrote:
> In case its of interest to anyone this was for request tracker which
> usually sets the return_path to the email of the Apache OS user by
> default (at least in my config), it now sets it to the reply-to address
> specified in RT which is what I wanted, 

It's likely that this is just the default configuration not letting
normal users set whatever return-path they want.

Either `untrusted_set_sender` or `trusted_users` might help with
reducing the configuration complexity a little.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Stalled in the queue

[Phil Pennock]

On 2017-09-26 at 08:45 -0600, The Doctor wrote:
> Question what cause mail to stall in a queue?

Depends entirely.  What does stalled mean?  Is the message frozen?

Every message has an Exim message-id, shown in the output from
`exim -bp`.  (I normally use `exim -bpru` to list the queue, to only
seem remaining recipients and to not sort the output, just see
everything fast).

As long as you haven't chosen to disable the `message_logs` option, then
`exim -Mvl the-message-id` will show you the logs for that message.  You
can see every action Exim has taken, including failed deliveries, etc.

If you have disabled the per-message logs, then as a fallback you can
use `exigrep` as a tool to search the logs for that message-id.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Error: maximum allowed line length is 998 octets, got 76

[Phil Pennock]

On 2017-09-13 at 11:44 +0200, Quaquaraquà via Exim-users wrote:
> and the error became:
> 
> 2017-09-13 11:34:07 1ds43b-0004yq-UV <= xx...@gmx.com H=mout.gmx.net
> [212.227.15.18] P=esmtps X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no
> S=2150 id=3f5a9488-75fd-5d1e-8ac4-004e7564f...@gmx.com

This is Exim receiving the message.

> 2017-09-13 11:34:08 1ds43b-0004yq-UV == x...@whatsthecraic.net R=local_users
> T=dovecot_lmtp defer (-1): LMTP connection closed after initial connection

This is Exim reporting that it tried to hand the message off to Dovecot,
using the `dovecot_lmtp` transport, but that the connection got closed
on Exim.

So Dovecot is failing and Exim is just the messenger in the middle.

I highly doubt that _all_ your messages had lines great than 998
characters, those are rare; I think that LMTP handoff problem is likely
to be a/the real problem here, the other message was just noticeable
because Exim was able to report more clearly what has happening in that
scenario.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Code contribution process

[Phil Pennock]

On 2017-08-26 at 10:19 -0700, Ian Zimmerman wrote:
> What is the way to contribute code patches to exim?  I see some pull
> requests on github but they haven't been acted on for a while.  I
> haven't checked git.exim.org but I assume it is read only :)

Mail to exim-...@exim.org or use https://bugs.exim.org/

If you were to read the readme visible when you go to
 you'd see this and a few other notes of
interest.  :)

Pragmatically, some people will just not read and will submit PRs on
GitHub no matter what we say.  We can (and have) disabled Issues, but
GitHub doesn't let us disable PRs there (although we could reject them
all via a reject-everything CI hook I guess).  So every now and again,
someone might happen to look through the GitHub PRs and try to clean
them out.  Very much ad-hoc.

Personally (not committing anyone else to this) I go on the theory that
it's better to take the contributions where they happen and work around
the issues that creates than to demand contributors jump through hoops
to do things _only_ the way we want, but still reward those who do use
the proper tools by dealing with those first, always.

But I do rather little Exim work these days.  So my opinion should be
taken with a heavier discount.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Cipher suites identifier

[Phil Pennock]

On 2017-08-01 at 19:10 +0200, Luciano Rinetti wrote:
> #exim -bV
[...]
> GnuTLS compile-time version: 2.8.6
> GnuTLS runtime version: 2.8.6

On 2017-08-05 at 11:09 +0200, Luciano Rinetti wrote:
> #exim -bV
> Exim version 4.74 #1 built 24-May-2011 20:35:05
[...]
> GnuTLS compile-time version: 2.8.6
> GnuTLS runtime version: 2.8.6

Since you've reposted the exact same information four days later, I'm
confused.  The request for information was:

} What it means ? Are GNUTLS encrypted sessions or OpenSSL encrypted
} sessions ?

I think that your reposting means that you didn't notice these lines in
the output?  So: they're GnuTLS connections.

Exim supports _either_ OpenSSL _or_ GnuTLS.  If you see one in the
version output, then that is the TLS library provider in use.

That's an old version of Exim, which pre-dates a bug-fix where for
GnuTLS support we were reporting the size in bytes, not bits.  So the
":32" at the end of "X=TLS1.0:RSA_AES_256_CBC_SHA1:32" is 32 8-bit
bytes, or ":256" if expressed in bits.

Exim's GnuTLS support was overhauled in 4.80 and has been improved
since; the code in 4.74 only supports some old ciphersuites which will
be increasingly limiting on today's Internet.  I would not recommend
those suites today.

(History: when GnuTLS support was added to Exim, GnuTLS was missing some
API features which would let it handle a lot of the feature tuning, so
the Exim glue code did a lot of low-level tinkering itself.  Over time,
GnuTLS became more full-featured and so several years back we rewrote
Exim's bindings to use the GnuTLS features.  With newer Exim, you get
TLS1.2 support and much more modern ciphers.)

Be very _very_ careful with online documentation around TLS for such an
old version of Exim.  Make sure that you're looking at the documentation
for _that_ version, not the current documentation.

With newer Exim, run >> exim -d-all+dns -bV << to see the library
versions of everything (the TLS library stuff is no longer shown by
default).

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Retiring old build targets

[Phil Pennock]

On 2017-07-27 at 15:04 +0100, Jeremy Harris wrote:
> I don't think that would be good, as it maintains the illusion
> that those builds are actually tested - which, lacking buildfarm
> or other participation, I have no confidence in.

The "or other participation" is the clincher here.  In the past, we've
said that if someone tests a Release Candidate on a given platform then
we support the platform but if nobody tests an RC then we don't:

  
https://github.com/Exim/exim/wiki/EximReleasePolicy#release-candidates--buggy-releases

That's not a binding document and "how we've done things" is not "how we
must do things".  Very much not.

The test suite requires pretty much root access by the Exim code on the
entire system with broad sudo.  That requires a dedicated OS instance in
most sane environments.  For closed-source platforms, that requires
paying money for licenses, etc, and is harder to justify.

So I will typically test that the Darwin stuff "works for me" because I
use a macOS laptop but I don't usually invoke the full test suite there.
I don't have spare equipment to provide a dedicated build-farm animal
for this OS.

Given the security-critical boundary nature of Exim, the goal of "should
have full test suite passes" is a good one.  So the switch to "should be
in the buildfarm" is hard to argue against.  It's probably the right
move for Exim.  The people doing the work, which is mostly not me,
should be the ones making this call, so I shrug and accept it.

But a little more clarity around "buildfarm" vs "someone tests RCs"
would be good, to know whether I need to check files out of git history
to do a laptop build in future.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] EBL: blacklist for email addresses in Reply-To and message bodies

[Phil Pennock]

On 2017-06-29 at 11:00 +0200, Jan Ingvoldstad via Exim-users wrote:
> There are DNS lookups for the sender and recipient domains, and in the
> case of spam filtering, there are often additional DNS lookups in
> DNSBLs for URIs found in the message content.

URIs, is a fair point, but privacy-focused services don't do those
lookups anyway.

If Gmail's outbound hosts connect to your server, you do a lookup based
on IP, or upon "gmail.com", and you reveal nothing more than was
observable already: Gmail connected to you.  For a very few
organizations which host mail for many domains, you _might_ additionally
leak which domain was talked to, but since those will often be local
they can be queried on local network, or for a client's domain, it might
just be leaked anyway, but with a high probability of being cached.

Doing predictable lookups based upon the full email address, not just
the domain, is drastically different from a privacy perspective.  This
is the sort of thing which is sensitive metadata with reasonable privacy
expectations.  Folks who go around sending cleartext queries to sites
across the open Internet which are long-term 1:1 tied to email addresses
are hindering their legal defense against future wiretap orders.

I *STRONGLY* encourage any postmaster considering deploying this
technology to talk to their organization's legal counsel before doing
so, to be sure that the implications are understood and to protect you
from personal liability.

-Phil


signature.asc
Description: Digital signature
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] EBL: blacklist for email addresses in Reply-To and message bodies

[Phil Pennock]

On 2017-06-29 at 10:20 +0200, Jan Ingvoldstad via Exim-users wrote:
> On Wed, Jun 28, 2017 at 9:27 PM, Phil Pennock  wrote:
> > There could stand to be some privacy implications discussion too --
> > you're sending out, over the wire in unencrypted DNS packets, a
> > predictable derivation of the Reply-To: header received for every email
> > from a given domain.  Using a cryptographic checksum protects against
> > casual snoopers knowing, but does not protect against those with a
> > dictionary of email addresses generating a reverse map and using that
> > for lookups, so undermines a chunk of the TLS-by-default work going on
> > by leaking metadata.  Usual RBLs only leak that there was communication
> > from an IP, which a network traffic sniffer could see anyway.
> 
> Although SHA-1 is known to be weak, it's still a bit of work to brute
> force it for a busy mailserver, but for a server that only sees
> occasional traffic, there is legitimate concern.

That's not how a reverse map dictionary works.

Instead, you take the email addresses you care about, hash them, and
just match those values.  The reverse map gives you back the email
address you care about, so you know who was talking.

Your favorite acronym agency builds a list of observed hashes, and any
time they get a new email address they care about, they can not only
add it to automated matching, they can go back and look at all past
recorded hashes, to see when email was sent out, to which domains.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] EBL: blacklist for email addresses in Reply-To and message bodies

[Phil Pennock]

On 2017-06-28 at 18:19 +0300, Lena--- via Exim-users wrote:
> How to use EBL in Exim config (requires Exim version 4.87 or higher):
> https://github.com/Exim/exim/wiki/EBL

Looks potentially useful.

The Reply-To: header takes an address-list and is interpreted as such,
and IIRC used in that way by some mail-clients when subscribed to
mailing-lists but wanting personal copies of replies too.  So the `rt:`
ACL is going to calculate something which will emit bogus queries to an
external service.

There could stand to be some privacy implications discussion too --
you're sending out, over the wire in unencrypted DNS packets, a
predictable derivation of the Reply-To: header received for every email
from a given domain.  Using a cryptographic checksum protects against
casual snoopers knowing, but does not protect against those with a
dictionary of email addresses generating a reverse map and using that
for lookups, so undermines a chunk of the TLS-by-default work going on
by leaking metadata.  Usual RBLs only leak that there was communication
from an IP, which a network traffic sniffer could see anyway.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Alias file is appearing in mainlog

[Phil Pennock]

On 2017-06-26 at 15:52 +, Dippery, Kyle wrote:
> Last week I switched from a slightly-out-of-date-but-working
> compiled-from-source exim 4.85 to a FreeBSD port exim 4.89.  I've
> updated my configuration to stop changing the exim user and group from
> what got compiled in, and updated permissions on log and database
> files so things are getting delivered.

Are you happy dropping extra patches into the Port files/ directory and
so forth?

> Now I see, though, that pieces of my /etc/aliases file are being
> written to my mainlog file.  All the ones I see seem to be in DKIM log
> messages:

> I'm pretty sure this isn't supposed to be happening.  It wasn't before
> I installed the port last week.  It seems to have stopped when I
> disabled DKIM verification this morning.  Is this likely to be a
> misconfiguration on my part, or a bug that I should report?

Neither: a bug which has already been fixed, I think.  Can you grab
commit 31323b304 and build with that, to see if it fixes the issues,
please?

https://git.exim.org/exim.git/commitdiff/31323b30449a59713ed7a99f86e356cb1b9d0fb7

If so, great!  If not, we need to know so that we can continue to chase
this down.

Either way, could you let us know?

Thanks,
-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Exim with virtual domains and Sieve

[Phil Pennock]

On 2017-06-11 at 12:35 +0200, Yves Goergen wrote:
> I cannot find pysieved on the internet. Does it still exist? There are a few
> traces, some only contain broken links. Nothing looks authoritative.
> 
> Adding that "# Sieve filter" with an SQL query is easy enough. Letting users
> edit their script is more interesting. I have a web-based management UI that
> users could use for that. Since I have no experience with Sieve at all
> myself, I don't know what tools exist for that and whether they're any good.

Can't help with "any good", but for "what exists", there's stuff broken
down by category at:

  http://sieve.info/

Re pysieved: looks like the FreeBSD Port has switched to a copy of a
tarball hosted by the port maintainer, for version 1.0, while Ubuntu
references a 1.2: 
http://archive.ubuntu.com/ubuntu/pool/universe/p/pysieved/pysieved_1.2-1.dsc

I'd probably start with this third-party preservation:

  https://github.com/miracle2k/pysieved

or look for another implementation.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] help creating a rule for virtual accounts

[Phil Pennock]

On 2017-05-30 at 18:55 -0500, Dan Liles via Exim-users wrote:
> Yes it's a file separated by : just like the other ones.

So  ?

${lookup {$local_part@$domain}lsearch{/etc/dovecot/passwd} {yes}{no}}

https://www.exim.org/exim-html-current/doc/html/spec_html/ch-file_and_database_lookups.html

See also ${extract{}{}{}{}{}}
to get fields from the results, once you've confirmed the key is either
present or not.  Lookup results are cached so doing the same search
repeatedly is usually light-weight.

So this might be the password crypt field:
  ${extract{2}{:}{${lookup {$local_part@$domain}lsearch{/etc/dovecot/passwd
which might be usable as the second parameter to the
crypteq{Supplied}{Needed} expansion condition for use in an SMTP
Authenticator.

For stuff like wildcard entries of auxiliary data to be a default for
anyone in the domain, look at "lsearch*@" instead of "lsearch" and
"partial2-lsearch*@" etc.  See the docs for more details.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Exim with virtual domains and Sieve

[Phil Pennock]

On 2017-05-27 at 15:03 +0200, Yves Goergen wrote:
> Another question is how the managesieve service can be integrated in this.
> Exim wants to read the sieve script from somewhere (might be a local file or
> a database query), and managesieve, which is required by several client-side
> plugins, wants to store the scripts somewhere, too. I have no idea whether
> it's even possible to glue all these pieces together.

pysieved is the service usually (AFAIK) used with Exim for providing
ManageSieve service.  It has a mode to automatically insert the "# Sieve
filter" line which Exim requires as a transparent step, an
implementation detail of the store, not exposed to the clients.

It already has support for MySQL for various things, so if the actual
script storage can't be in MySQL at present, you could add it easily
enough, as long as you can write Python.

I'm the author of sieve-connect, the ManageSieve client which is
packaged by a few OSes; it's known to work with Cyrus IMAP's timsieved
and with pysieved.  When testing by hand with Exim, pysieved is what
I've used.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Symlinks in cert / keyfile

[Phil Pennock]

On 2017-05-26 at 23:53 +0200, basti wrote:
> as I can see Exim won't use certificates when the path is a link.

Yes it will.  I use symlinks.  That's not what's happening here.

> /etc/letsencrypt/live/mail.example.com# ls -la
> insgesamt 12
> drwxr-xr-x 2 root root 4096 Mai 26 17:24 .
> drwx-- 4 root root 4096 Mai 26 17:17 ..
> lrwxrwxrwx 1 root root   42 Mai 26 17:24 cert.pem ->
> ../../archive/mail.example.com/cert2.pem

Exim is not running as root when the connection is received.  It's
running as the Exim Runtime User, which might be `exim`, `exim4`,
`_exim`, `mailnull` or something else, depending upon your system.

Because the values of the paths are subject to string expansion, they
can't be pre-loaded while root.  The key and cert need to be readable by
the Exim runtime user, using the path as given.

So you have `/etc/letsencrypt/live` permission 0700 (according to the
`..` line above) and a cert in
`/etc/letsencrypt/archive/mail.example.com/cert2.pem` which is readable
to the runtime user, but the runtime user can't figure out where
`../../` is because the OS, when given that path, is returning errors.

Run:

  chmod 0711 /etc/letsencrypt/live

That will give "lookup" permission on the directory, to resolve a fixed
name, without needing to be able to enumerate the directory contents, to
every user.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] string expansion

[Phil Pennock]

On 2017-05-26 at 16:27 -0400, Phil Pennock wrote:
> On 2017-05-26 at 13:13 +0200, Uwe Rothmeier wrote:
> > condition = ${if 
> > or{{match_address{$local_part@$domain}{lsearch;CONFDIR/ldapdir}} \
> > 
> > {match_local_part{$local_part}{lsearch;/etc/exim4/aliases/$domain}}}{1}{0}}
> > 
> > Works with Exim 4.72
> > 
> > 
> > With Exim 4.89 $domain ist not expanded:
> > failed to open /etc/exim4/aliases/$domain for linear search: No such file 
> > or directory
> 
> To use the config unmodified, rebuild Exim with EXPAND_LISTMATCH_RHS
> defined.  This was a change in Exim 4.77 for security, because many
> people had security vulnerabilities in their configurations.
> 
> This is called out in "README.UPDATING", which should be read before
> updating.  Exim 4.77 was released in October 2011.

The condition:

  match_local_part{$local_part}{lsearch;/etc/exim4/aliases/$domain}

is probably a close match to:

  bool{${lookup{$local_part}lsearch{/etc/exim4/aliases/$domain}{yes}{no}}}

This has the advantage of _only_ looking at $domain as something for
constructing a path component, so as long as it comes after something
which validates that $domain is "real" (and not something like
"../../../etc/passwd"), you're safe.  Your particular use, based upon
$domain, was pretty safe before too.

Unfortunately, people used stuff like $h_from: as a key, which suddenly
means that you get SQL injection attacks.  We played whack-a-mole with
explaining that people had insecure configurations and mostly got
ignored.  So we made a security-motivated compatibility-breaking change
so that the default was harder to make insecure.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] string expansion

[Phil Pennock]

On 2017-05-26 at 13:13 +0200, Uwe Rothmeier wrote:
> condition = ${if 
> or{{match_address{$local_part@$domain}{lsearch;CONFDIR/ldapdir}} \
> 
> {match_local_part{$local_part}{lsearch;/etc/exim4/aliases/$domain}}}{1}{0}}
> 
> Works with Exim 4.72
> 
> 
> With Exim 4.89 $domain ist not expanded:
> failed to open /etc/exim4/aliases/$domain for linear search: No such file or 
> directory

To use the config unmodified, rebuild Exim with EXPAND_LISTMATCH_RHS
defined.  This was a change in Exim 4.77 for security, because many
people had security vulnerabilities in their configurations.

This is called out in "README.UPDATING", which should be read before
updating.  Exim 4.77 was released in October 2011.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] SSL3_GET_CLIENT_HELLO No shared cipher - when SSLv3 disabled?

[Phil Pennock]

On 2017-03-30 at 17:11 -0400, Viktor Dukhovni wrote:
> > On Mar 30, 2017, at 4:40 PM, Heiko Schlittermann wrote:
> > You're right, Exim picks up the cert/keys per connection, as the
> > relevant options are expandable at runtime. (But, as far as I know,
> > currently not based on the key that is requested (so we do not support
> > multiple key setups for the same CN, as far as I know. But I may be
> > wrong, as always.)

Key appears to be expanded; this is `tls_expand_session_files()` in
tls-openssl.c and tls-gnu.c and re-expands the key for each.

Introduced with commit 7be682ca5 and I thought you were right that
historically we didn't re-expand the key, but apparently I did have it
expand the key from the beginning.  GnuTLS support was a few commits
later when I rewrote the GnuTLS support.

> What this means is that session resumption can't possibly work in
> Exim (which is OK, Exim is not obligated to optimize the handshake
> overhead of high-volume TLS traffic).  Consequently, it would be
> best if Exim did not generate SSL session ids or vend TLS session
> tickets.

Sounds right; we should consider adding this to the default value of
openssl_options, which theoretically exposes _every_ `SSL_OP_` to
administrator control.

As to the ECC/RSA support: I've looked at the code required and it's all
requiring newer OpenSSL, so I punted until after we dropped support for
older OpenSSL.  4.89 is out, after the "official" drop but with old
OpenSSL still working and is probably the last release to support those
old OpenSSL builds.

IIRC, the other thing which was blocked waiting was switching to using
some DSA loading routines for DH parameters, to be able to load q values
too, for dodging small subgroup attacks as a pre-requisite before Exim
can ever consider reusing an SSL configuration.

Filed: https://bugs.exim.org/show_bug.cgi?id=2092
  Subject: Should support dual-key configuration with lists of keys/certs

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Turning off no_enforce_sync conditionally in acl_smtp_helo

[Phil Pennock]

On 2016-05-04 at 14:52 -0500, Jason L Tibbitts III wrote:
> One possibility is to just use:
> 
> acl_check_helo:
>   accept hosts = :
>   accept control = no_enforce_sync
> 
> which appears to work.  But can I turn it off just for Thunderbird's
> probes?  I tried the following, but it doesn't appear to work:
> 
> acl_check_helo:
>   accept hosts = :
>   accept condition = ${if eq{$sender_helo_name}{we-guess.mozilla.org} {true}}
>  control = no_enforce_sync
>  logwrite = Turning off sync enforcement for Thunderbird.
>   accept

Sync enforcement is done as part of figuring out what the incoming SMTP
verb is, long before ACLs are applied.  The ACL for a given command can
not affect whether or not sync enforcement applies to _that_ command.

I suggest using a _connect_ time ACL to set `control = no_enforce_sync`
and then use the _HELO_ time ACL to re-apply `control = enforce_sync`
if _not_ Thunderbird.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Using multiple SMTP AUTH drivers

[Phil Pennock]

On 2017-03-17 at 13:31 +1000, Adam Nielsen wrote:
> Is this correct or am I missing something?

It's correct, I was not on top form.  Most auth stuff which speaks
plaintext can be done with a plaintext driver and using expansions, but
dovecot can't and I missed that.  Sorry for wasting your time.

At present, the best I can think of for moving forward is to run a
different Exim config on another port and point the service-only stuff
to that port instead.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Using multiple SMTP AUTH drivers

[Phil Pennock]

On 2017-03-16 at 17:13 +1000, Adam Nielsen wrote:
> [...] , so I'd like to set up a separate
> set of credentials just for SMTP from these devices.
> 
> Unfortunately if I add a new auth section to the Exim config with
> driver=plaintext, I get an error:
> 
>   two server authenticators (dovecot_login and file_login) have the same
>   public name (LOGIN)
> 
> Is there some way to configure multiple authentication drivers with
> Exim, such that they are tried in order until one is found that
> succeeds?

No, but the condition used for approval can use `or`.

It's `or{{cond1}{cond2}...{condN}}`

server_condition = ${if or{\
  {${lookup WHATEVER1}}\
  {${lookup WHATEVER2}}\
  }}

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] Exim 4.89 compile warning on Ubuntu 14.04

[Phil Pennock]

On 2017-03-08 at 09:05 +, Michael J. Tubby B.Sc. MIET wrote:
> exim.c: In function ‘usr1_handler’:
> exim.c:235:1: warning: ignoring return value of ‘write’, declared
> with attribute warn_unused_result [-Wunused-result]
>  (void)write(fd, process_info, process_info_len);
>  ^

> and believing that cleanliness is next to godliness have fixed the
> warning by removing the (void) cast over the write function and
> assigning the return value to variable 'sz'.

No, I object to this change.

Assigning to a variable which is then unused is wrong, and a sign of a
bug.  Decent languages treat this as a compile error (Golang).  Return
values should either be handled _properly_ or honestly and openly
discarded.  In that handler, the decision was made to discard.

The return value is being explicitly discarded via explicit `(void)`
cast of the result.  This is as explicit as it gets that we are
knowingly and deliberately not heeding the result.

The compiler treating this as a warning is a compiler bug.  I got the
same warning on an Ubuntu box.  I ignore it.  `-Wunused-result` should
be skipping complaining about explicit void casts.  Making the code
deceptive by assigning to a variable is the wrong thing to do here.

-Phil


signature.asc
Description: Digital signature
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/