Todd Lyons | 1 Aug 15:32 2014

Regression found in 4.83

We have discovered through bug reports that a change to the MIME
processing code in Exim 4.83 caused a regression: handling of quoted
parameter values is broken, affecting both the detection of MIME part
boundaries and the $mime_filename variable.  Details can be seen in
the bugzilla entry .

A fix has been devised by Jeremy Harris and tested by a longtime and
trusted Exim user Lena who verified it fixes the regression for her.
This change has already been committed to the Exim master development
branch.  This announcement is intended to address two things, a
short-term fix and a longer-term fix:

A) In the short term, if you locally build your own exim, you can
apply a patch from
the following blobdiff.  It is longer than the actual amount of code
change because a coding style adjustment was also committed prior. It
standardized indentation to be more aligned with the exim norm.  The
full diff against the 4.83 release is:

B) For the longer term, there have been very few changes since release
of 4.83 (documentation fixes and one compiler quietening), so we plan
on releasing a 4.84 version mainly to fix this regression, and include
all commits since 4.83.  I will be driving this release, and the
intended schedule I plan to adhere to:
1. Cut 4.84 RC1 sometime today (Friday Aug 1).
2. Any other regression or bug fixes can be submitted at this point.
3. I am away from a computer from Sunday-Tue (Aug 3-5).
4. If necessary (ie patches from #2 while I'm in #3), cut an RC2 next
week on Wed Aug 6 or Thu Aug 7.
(Continue reading)

Lena | 30 Jul 16:26 2014

Re: Behaviour change in 4.83?

Something even more strange in my testing (FreeBSD, Exim 4.83 from ports):

  warn logwrite = mime_content_type=$mime_content_type
       logwrite = mime_filename=$mime_filename
       decode = default
       logwrite = mime_decoded_filename=$mime_decoded_filename

Test message as received:

Message-ID: <20140730140329.GE786 <at> lena.kiev>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="/2994txjAzEdQwm5"
Content-Disposition: inline
User-Agent: Mutt/

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Content-Type: application/zip
Content-Disposition: attachment; filename=""
Content-Transfer-Encoding: base64


mainlog shows that acl_check_mime was called only once,
(Continue reading)

Stef Hoesli | 29 Jul 19:41 2014

From line in e-mails vs. vacation

Hi there,

I have a debian 7.6 server ( set up with myself as first user
with username "stef". (This reflects in the exim 4.80 configuration as:
errors_to = stef)

The issue I have is the following: I have an user set up called
webmaster-alt and a virtual domain on that server that excepts e-mails to
webmaster.alt <at> <VIRTUAL DOMAIN> that gets delivered to webmaster-alt.

For webmaster-alt I have a .forward file containing the following:

\webmaster-alt, "|/usr/bin/vacation webmaster-alt -r 0 -a webmaster.alt"

This doesn't work as expected, since all the e-mails in
/var/mail/webmaster-alt start with:

From stef <at>

Accordingly stef <at> get all the vacation auto-responses and not
the original sender.

Why does exim start every delivered e-mail with "From stef <at>"?


## List details at
## Exim details at
## Please use the Wiki with this list -
(Continue reading)

George | 29 Jul 17:09 2014

Behaviour change in 4.83?


I've noticed that my mime checking is not working as expected since I 
upgraded from 4.82.1 to 4.83 (on Arch Linux if that is significant).

Starting to try and work out why, I've logged $mime_filename for all 
attachments.  I see that it is now quoted but looking back through older 
logs, it wasn't before.

I can't see anything relevant in the changelog so I see 3 possibilities:

1. I'm being dense - this is always possible as I must admit to finding 
exim conditions hard to get my head round.  I don't think so as I've 
only had to touch simple config so far here.

2. It's an intentional change which I haven't found any documentation 
for, in which case I'll work on my config.

3. It's not supposed to happen, in which case I can either live with it 
(low email volumes make this plausible if not desirable) or I'll work on 
my config and then revert the changes when the behaviour changes back.

I can post the relevant log lines from my config but they are just a 
string including $mime_filename.

Hopefully someone with deep enough knowledge can help me out here.  TIA,


## List details at
(Continue reading)

Russell King | 27 Jul 17:02 2014

Weird retry behaviour

I know that 4.69 is an old version of exim, but... I'm seeing some
weird behaviour with it.

The machine in question acts as a backup machine for another computer.
It's setup such that each night, it powers itself on, transfers the
data, archives it, sends a mail and powers off.  Once a week, it
remains on for a 24 hour period.

The problem is this - exim behaves itself just fine when it can send
the message immediately.  If it can't (because of the DSL at the site
being down) then exim gives me a hard failure and bounces the message.

This goes totally against what is in the config file for the retry

*                      *           F,2h,15m; G,16h,1h,1.5; F,4d,6h

The config file is pretty much standard Fedora 14, but with these as
the routers (as is the above line being the F14 default):

  driver = smtp
  headers_rewrite = * <at> * hidden <at> fs
  return_path = hidden <at>

So it should take many days before bouncing.  However:

2014-07-26 07:01:42 1XAv38-0000iU-Ln <= backup <at> U=backup
P=local S=65027 id=20140726060142.GA2756 <at> shgc-backup
2014-07-26 07:01:48 1XAv38-0000iU-Ln => rmk <at> R=dnslookup T=remote_smtp
(Continue reading)

Markus Rebensburg | 25 Jul 14:42 2014

eximon shows errors after update from 4.82 to 4.83

Hi everyone,

after the update from exim 4.82 to exim 4.83 on SLES11 SP3 we
occasionally see errors like the following in the queue view of eximon:

    0m   560 1XAea3-00035H-P7 *** Format error in spool file: size =
    5272 ***

They vanishes after delivery of the message, so you have to refresh this
view often to see them. Exim himself does not complain about an error
and correctly delivers the message.

Maybe its a bug in eximon?

Best regards,
Attachment (rebensburg.vcf): text/x-vcard, 335 bytes
Attachment (smime.p7s): application/pkcs7-signature, 6995 bytes

## List details at
## Exim details at
## Please use the Wiki with this list -
Oliver Howe | 24 Jul 17:30 2014

matching non-english characters in system filter

Is it possible to match non-english characters in a system filter?
In particular I'm looking for some Russian characters in a Subject line.



## List details at
## Exim details at
## Please use the Wiki with this list -

Todd Lyons | 23 Jul 01:52 2014

Re: Decide what router to use according to the from field

Bringing this back on list.

On Tue, Jul 22, 2014 at 4:41 PM, rblue <rblue117 <at>> wrote:
> Hi,
> After a few tests, it looks like the variable isn't being used properly in
> the router because the data acl runs only after the router is decided - is
> that right? If so, is there any way to tell exim to choose the router only
> after the acl_smtp_data acl, which is where I can look up the $h_From
> variable?

I've been pushing you in the general direction.  Now I'm going to hold
your hand.

>> Now, having said that, *WHEN* is this being called?  Is this part of
>> the router process for delivery (i.e. at the end of the DATA phase)?
>> Or is the part of the router processing during address verification,
>> typically in the MAIL and RCPT acl's.  It appears to be during the

In a somewhat standard configuration, the routers are processed 3 times:
1) Once during the acl_smtp_mail when it's processing verify=sender.
It passes the MAIL FROM (envelope sender) address through the routers
attempting to verify if it's a valid sender.
2) Once during the acl_smtp_rcpt when it's processing
verify=recipient.  It passes *all* RCPT TO (envelope recipients)
addresses through the routers, attempting to verify if they are emails
it should be accepting (i.e. local domains, or from designated hosts
that you forward any received emails...if you are a smarthost).
3) After the email has been accepted (i.e. after the data phase), when
Exim is actually trying to deliver the message.
(Continue reading)

Todd Lyons | 22 Jul 17:24 2014

Exim Security Advisory CVE-2014-2972

The Exim developers want to inform you of a local vulnerability in Exim.
Exploitability requires the ability to provide unsanitised data to a
data source used by Exim for looking up a value, and the impact is the
ability to get a string expansion done as the Exim runtime user (so, run
commands, etc) because in a certain scenario, there's a
double-expansion, so it's equivalent to the result of the data being
"eval"d again. This bug was discovered by Patrick William of Rack911,
and reported to us by the Cpanel Security Team. Exploitation using this
method was discovered by penetration testing; it was not observed in the
wild. This security advisory has been assigned CVE-2014-2972.

We would like to publicly thank Rack911 and Cpanel for responsibly
notifying the Exim developers with a description of the problem
and coordinating their release of software fixes with ours. Appearing so
close to the end of the release cycle allowed us to handle the issue
with relative ease.

This is not a remote exploit. It requires a user account on a server
where Exim is configured to do lookups against files to which the user
has edit access. As such, this does not require a Security Release, so
we will proceed with the regular release cycle.

The root cause of this issue is the arguments to mathematical comparison
operations are expanded twice (<, <=, >, >=, =).  The intent of the
original code was the first expansion could (for example) lookup an item
from a file. The assumption was that entry would be some form of valid
integer so that value was then passed to the expand function again to do
a numeric conversion of values such as 19k or 45M to integers.  However,
if the content of the lookup is under direct user control, they could
(Continue reading)

Todd Lyons | 22 Jul 16:59 2014

Exim 4.83 Released

 have uploaded Exim 4.83 to:

This release of Exim includes one incompatible fix: the behavior of
expansion of arguments to math comparison functions (<, <=, =, =>, >)
was unexpected, expanding the values twice. This fix also addresses a
security advisory, CVE-2014-2972. This is not a remote exploit, but if
content that is searched by the above math comparison functions is under
the control of an attacker, specially crafted data can be inserted that
will cause the Exim mail server to perform various file-system functions
as the exim user.

This release contains the following enhancements and bugfixes:
+ PRDR was promoted from Experimental to mainline
+ OCSP Stapling was promoted from Experimental to mainline
+ new Experimental feature Proxy Protocol
+ new Experimental feature DSN (Delivery Status Notifications)
+ TLS session improvements
+ TLS SNI fixes
+ LDAP enhancements
+ DMARC fixes (previous CVE-2014-2957) and new $dmarc_domain_policy
+ several new operations (listextract, utf8clean, md5, sha1)
+ enforce header formatting with verify=header_names_ascii
+ new commandline option -oMm
+ new TLSA dns lookup
+ new malware "sock" type
+ cutthrough routing enhancements
+ logging enhancements
+ DNSSEC enhancements
(Continue reading)

Julian Bradfield | 17 Jul 15:19 2014


Is there a reason why the "errors-to" parameter to the "deliver"
filter command is restricted to the system filter, even for trusted

It would be useful to be able to use it in router-specific filters,
because some of my users want their mail delivered to gmail, and gmail
(a) honours SPF etc, (b) has sensitive spam triggers, so if I deliver
mail to gmail with the original sender address, it may well get
bounced. At present I have to have their personal procmails resend it,
but I'd much rather do everything in the router filter. (I have only
three users, and they don't want to touch our mail system:-)

I'm not sure what the security advantage is, as on most systems it's
trivial to manually reinject the mail with an arbitrary envelope

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


## List details at
## Exim details at
## Please use the Wiki with this list -