admin | 8 Feb 12:55 2016

[Bug 1790] New: Need testcases for SRS

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

            Bug ID: 1790
           Summary: Need testcases for SRS
           Product: Exim
           Version: 4.86
          Hardware: All
                OS: All
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Test harness
          Assignee: nigel <at> exim.org
          Reporter: jgh146exb <at> wizmail.org
                CC: exim-dev <at> exim.org

Lack of regression detection

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

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##
admin | 8 Feb 12:53 2016

[Bug 1789] New: Need testcases for SPF

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

            Bug ID: 1789
           Summary: Need testcases for SPF
           Product: Exim
           Version: 4.86
          Hardware: All
                OS: All
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Test harness
          Assignee: nigel <at> exim.org
          Reporter: jgh146exb <at> wizmail.org
                CC: exim-dev <at> exim.org

Lack of regression detection

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

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##
admin | 7 Feb 00:31 2016

[Bug 1788] New: Deliveries to one ISP sometimes fail silently after T=remote_smtp defer on first delivery attempt

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

            Bug ID: 1788
           Summary: Deliveries to one ISP sometimes fail silently after
                    T=remote_smtp defer on first delivery attempt
           Product: Exim
           Version: 4.84
          Hardware: x86-64
                OS: Linux
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Delivery in general
          Assignee: nigel <at> exim.org
          Reporter: exim <at> presland.net
                CC: exim-dev <at> exim.org

I've been running exim mailservers on Debian for years.  Having upgraded the
server to Debian Jessie in December 2015, we've noticed some emails going
missing.  We're running the "4.84-8+deb8u2" of the exim4-daemon-heavy package.
Doing an "exim4 --version" reports:
Exim version 4.84 #2 built 15-Dec-2015 04:15:40
Copyright (c) University of Cambridge, 1995 - 2014
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2014
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS
move_frozen_messages Content_Scanning DKIM Old_Demime PRDR OCSP
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz
dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa
(Continue reading)

admin | 4 Feb 18:44 2016

[Bug 1787] New: Instant Retry Timeout when graylisted

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

            Bug ID: 1787
           Summary: Instant Retry Timeout when graylisted
           Product: Exim
           Version: 4.86
          Hardware: x86
                OS: Linux
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Delivery in general
          Assignee: nigel <at> exim.org
          Reporter: marc <at> perkel.com
                CC: exim-dev <at> exim.org

This is getting really annoying and I can't explain it.

Retry setting is:

* * F,6d,30m

I deleted everything in /var/spool/exim in an attempt to make it forget
everything it retried. Restarted the server.

Sent an email and instantly get rejected:

The following address(es) failed:

  dang <at> ****
(Continue reading)

admin | 30 Jan 14:01 2016

[Bug 1784] New: exim fails to write PID file when alternative ports are specified

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

            Bug ID: 1784
           Summary: exim fails to write PID file when alternative ports
                    are specified
           Product: Exim
           Version: 4.80
          Hardware: x86-64
                OS: Linux
            Status: NEW
          Severity: bug
          Priority: medium
         Component: General execution
          Assignee: nigel <at> exim.org
          Reporter: developerchris <at> rebel.com.au
                CC: exim-dev <at> exim.org

When exim is configured to use ports from the command line a pid file is not
written

When this happens the stop start script fails to stop exim and the new process
fails to bind to the port and therefore exits after multiple retries

The problem occurs if you add the following to /etc/default/exim4 in debian

# options for daemon listening on port 25
SMTPLISTENEROPTIONS='-oX 25:587:465' 

in debian this generates a command line similar to this
/usr/sbin/exim4 -bd -q30m -oX 25:587:465
(Continue reading)

Heiko Schlittermann | 25 Jan 23:25 2016
Picon

New Commit for exim-4_86+fixes

Hello Maintainers, Developers and Users,

I've pushed a new commit to the 4.86+fixes branch. 

    commit 8d58e3501ce731c5d6d5efc9e76058832d4bc941
    Author: Jeremy Harris <jgh146exb <at> wizmail.org>
    Date:   Thu Jan 21 15:37:08 2016 +0000

    Cutthrough: Fix bug with dot-only line

    (cherry picked from commit 1bc460a64a0de0766d21f4f8660c6597bc410cbc)

From the ChangLog

    JH/38 Fix cutthrough bug with body lines having a single dot. The dot was
      incorrectly not doubled on cutthrough transmission, hence seen as a
      body-termination at the receiving system - resulting in truncated mails.
      Commonly the sender saw a TCP-level error, and retransmitted the nessage
      via the normal store-and-forward channel. This could result in duplicates
      received - but deduplicating mailstores were liable to retain only the
      initial truncated version.

You're free to pick this patch (or the complete exim-4_86+fixes branch)
from git://exim.org/exim.git or the usual places.

    git clone --branch exim-4_86+fixes git://exim.org/exim.git

or if you've already a cloned repo:

    git fetch origin exim-4_86+fixes
(Continue reading)

admin | 25 Jan 19:13 2016

[Bug 1782] New: retry time not reached for any host after a long failure period - but failure is instant

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

            Bug ID: 1782
           Summary: retry time not reached for any host after a long
                    failure period - but failure is instant
           Product: Exim
           Version: 4.86
          Hardware: x86
                OS: Linux
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Queues
          Assignee: nigel <at> exim.org
          Reporter: marc <at> perkel.com
                CC: exim-dev <at> exim.org

I'm seeing rejections like this:

retry time not reached for any host after a long failure period

But the message occurs instantly - not after a long period of failure.

Details:

The recipient server is actually down and has been down for some time. But a
new message comes in and it is immediately rejected. 

However ....

(Continue reading)

admin | 21 Jan 23:00 2016

[Bug 1781] New: DKIM: signing failed (RC -101) with certain private keys (base64 data ending in =)

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

            Bug ID: 1781
           Summary: DKIM: signing failed (RC -101) with certain private
                    keys (base64 data ending in =)
           Product: Exim
           Version: 4.86+ HEAD
          Hardware: x86-64
                OS: OpenBSD
            Status: NEW
          Severity: bug
          Priority: medium
         Component: DKIM
          Assignee: tom <at> duncanthrax.net
          Reporter: km <at> krot.org
                CC: exim-dev <at> exim.org

After putting RC3 in production yesterday, I noticed following in the panic
log:

2016-01-19 09:52:20 1aLS1T-0001rn-8S DKIM: signing failed (RC -101)
2016-01-19 19:37:59 1aLbAA-0003vd-Ol DKIM: signing failed (RC -101)
2016-01-19 20:16:15 1aLblG-0000Na-2I DKIM: signing failed (RC -101)
2016-01-21 17:59:45 1aMIaG-0001WD-E9 DKIM: signing failed (RC -101)
2016-01-21 21:04:24 1aMLSx-00071m-P8 DKIM: signing failed (RC -101)
2016-01-21 21:05:35 1aMLTh-0006yA-4x DKIM: signing failed (RC -101)
2016-01-21 21:07:36 1aMLVi-0003U2-0s DKIM: signing failed (RC -101)

This error doesn't happen on 4.86.

(Continue reading)

Heiko Schlittermann | 19 Jan 14:16 2016
Picon

Cutthrough routing: data loss on client side error

Hello,

we've some finding about cutthrough routing…
It seems we loose parts of the messages.

Our setup:

  { internet } --> host HH --> cutthrough --> host MX
  exim 4.86_8-c4dcf90 (4.86+fixes) on HH

Sometimes the delivery size on host HH from the log
is *bigger* then the delivery size on host MX. Customers
reported cut attachments.

msg-id ----------------------------------------+ size HH + size MX
... <at> eu-west-1.amazonses.com                      69739     9088
... <at> captrain.de                                 889136    15803
... <at> www.travelbeyond.de                          28680     3648
... <at> webprd-m107.mail.aol.com                     44967     9360
... <at> SBS2011.zeller-france.local                 918753   903892
... <at> amsona-coaching.de                          283006     2392
... <at> Paraguay.intranet.bonapartehotel.it          58941     5933
... <at> cmail20.com                                  98329     4446
... <at> amsona-coaching.de                          283694     2408
... <at> hajmxmdb03.msrf.insite                      281470     3474
... <at> news.lidl.de                                142437     6759
... <at> VI1PR02MB1392.eurprd02.prod.outlook.com       4499     4277

It seems(!) that there is some correlation to SSL problems of:

(Continue reading)

Jeremy Harris | 18 Jan 19:00 2016

Exim 4.87 RC3 uploaded


The ftp site:

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

now has RC3 of Exim 4.87 available.  Built and
signed by myself.

Changes of interest since RC2:
DKIM: fix quoted-printable decode
Malware: Fix potential spin-on-read-error with kavdaemon
dnslists: permit use with explicit key(s) in nonsmtp ACLs.  Bug 1748
Pretty print for -bP config
Consolidate base64 encode/decode routines
New expansion operator base64d, and base64 as synonym for str2b64.  Bug 1746
Support certificates in base64 expansion operator.  Bug 1762
DKIM: use TLS library where possible in preference to embedded PolarSSL copy
add requirement on good HELO in the example configuration
OpenSSL: Default the SINGLE_DH_USE option flag set
Expansions: fix memory-usage bug in ${run }.  Bug 1778
Permit an ACL to override the default 252 VRFY response.  Bug 1769
Restrict line lengths in bounces.  Bug 1760

No feature-introductions will be accepted in the mainline code branch
between now and 4.87 final release.  Bug fixes are still welcome.

Please report issues here in the exim-dev or
exim-users mailinglist, or by raising bugs
on http://bugs.exim/org

(Continue reading)

Graeme Fowler | 18 Jan 18:32 2016
Picon
Gravatar

LDAP multiline attribute oddity

Hi folks

My "not being a programmer" problem has reared its head again, and I need some help debugging a (possibly
esoteric) problem in 4.86 onwards (I haven't checked before that).

Long and short of it (code in lookups/ldap.c):

At work (courtesy of some sterling work by Mike Cardwell some time ago), we have a method of looking up the MS
Exchange blocked/safe senders via LDAP and comparing sender addresses against them - this can avoid us
backscattering by moving the rejection "up the stack" to our border MX farm.

However, someone has recently raised a case with us that email sent by a sender which has been added to their
blocked senders list is still being delivered. Here's where the problem lies - this user has hundreds of
addresses in their blocked (and safe) senders list, which in turn is exposed as a multi-line (note NOT
multi-value, nor multi-instance) attribute by the LDAP query. Mine, however, is very short and returns a
single line attribute.

In my case, Exim looks it up and all is well. This is the expected behaviour.

In the multiline case, we get an empty result despite being able to see the data on the wire/in strace. This,
self-evidently, is not what I expect to happen!

Using ltrace, the issue appears to be with the call to ldap_get_values, which I suspect is not being handed
the full response (or is being handed a response with newlines in and doesn't like that) and subsequently
returns a value of 0.

In both cases the call flow is:

ldap_search
ldap_result
(Continue reading)


Gmane