Jeremy Harris | 1 Apr 2012 01:02

[Bug 1232] New: The default makefile is unhelpful for IPv6

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

http://bugs.exim.org/show_bug.cgi?id=1232
           Summary: The default makefile is unhelpful for IPv6
           Product: Exim
           Version: 4.77
          Platform: x86-64
        OS/Version: Linux
            Status: NEW
          Severity: wishlist
          Priority: medium
         Component: Networking
        AssignedTo: nigel <at> exim.org
        ReportedBy: jgh146exb <at> wizmail.org
                CC: exim-dev <at> exim.org

There are no comments about IPv6 in src/EDITME.  Unless one reads the docs to
find "Setting HAVE_IPV6=YES in Local/Makefile" in chapter 4 an IPv4-only exim
will probably result.

--

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

Phil Pennock | 1 Apr 2012 02:21
Favicon
Gravatar

[Bug 1229] authenticator tests failing

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

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

Phil Pennock <pdp <at> exim.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pdp <at> exim.org

--- Comment #2 from Phil Pennock <pdp <at> exim.org>  2012-04-01 01:21:06 ---
This was me in commit 44bbabb5 as I redid some of the checking to better report
where problems were coming from.

Changes are expected, test output should be updated.

--

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

Phil Pennock | 1 Apr 2012 02:22
Favicon
Gravatar

[Bug 1230] Reject lines with Auth info fail testsuite

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

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

Phil Pennock <pdp <at> exim.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pdp <at> exim.org

--- Comment #3 from Phil Pennock <pdp <at> exim.org>  2012-04-01 01:22:10 ---
Concur as to source of diff and that the new output should be accepted as
correct.

--

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

Jeremy Harris | 2 Apr 2012 21:06

[Bug 1234] New: testsuite IPv6 tests u/s

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

http://bugs.exim.org/show_bug.cgi?id=1234
           Summary: testsuite IPv6 tests u/s
           Product: Exim
           Version: 4.77
          Platform: x86-64
        OS/Version: Linux
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Networking
        AssignedTo: nigel <at> exim.org
        ReportedBy: jgh146exb <at> wizmail.org
                CC: exim-dev <at> exim.org

The double-colon rule for IPv6 addresses invalidated some REs
used for testing (a trailing colon, being a non-word char,
didn't result in a word-boundary).

Affects at least case 1001; possibly 1003 1006 1007 1009 too.

Suggested patch:

diff --git a/test/runtest b/test/runtest
index 2a8dd16..e71ee9f 100755
--- a/test/runtest
+++ b/test/runtest
 <at>  <at>  -560,9 +560,9  <at>  <at>  RESET_AFTER_EXTRA_LINE_READ:
(Continue reading)

Jeremy Harris | 2 Apr 2012 22:54

[Bug 1184] code refactoring in acl.c

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

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

Jeremy Harris <jgh146exb <at> wizmail.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #522 is|0                           |1
           obsolete|                            |

--- Comment #2 from Jeremy Harris <jgh146exb <at> wizmail.org>  2012-04-02 21:54:46 ---
Created an attachment (id=554)
 --> (http://bugs.exim.org/attachment.cgi?id=554)
Code refactoring for verify= parse in acl (updated)

Let's hear it for test suites.  I'd broken the verify=
sender=altperson <at> altdomain parsing, which was spotted by case 0029 - and also
the case-independent parsing of verify= WHATEVER.   New patch attached; it
still requires the acceptance of new output for case 0027 - there's a slight
loss in debug information output.

--

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

Kris Oye | 2 Apr 2012 21:50
Picon

[Bug 1031] Implement database logging of completed remote delivery

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

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

Kris Oye <kristianoye <at> gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kristianoye <at> gmail.com

--- Comment #10 from Kris Oye <kristianoye <at> gmail.com>  2012-04-02 20:50:56 ---
(In reply to comment #9)
> Created an attachment (id=521)
 --> (http://bugs.exim.org/attachment.cgi?id=521) [details]
> Patch updated for 4.77 release
> 
> This patch combines the contributed code from Gedalya and myself and is
> unchanged from the previous version with one typo corrected.
> The patch applies cleanly to 4.77 and runs here on 4 production servers for one
> week now.
> This is the 6th exim release where I merged this patch myself and at least 2
> users depend on it.
> If there are any objectives against merging this experimental feature into
> HEAD, let me know.
> 

I would really like to see this patch included in HEAD.  I need the ability to
report delivery times and elapsed time and this is so much better than combing
logs for a successful remote transport!
(Continue reading)

Jeremy Harris | 4 Apr 2012 02:28

[Bug 1184] code refactoring in acl.c

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

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

Jeremy Harris <jgh146exb <at> wizmail.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #554 is|0                           |1
           obsolete|                            |

--- Comment #3 from Jeremy Harris <jgh146exb <at> wizmail.org>  2012-04-04 01:28:10 ---
Created an attachment (id=555)
 --> (http://bugs.exim.org/attachment.cgi?id=555)
Code refactoring for verify= parse in acl (updated x2)

Essentially the same coding error in another place, affecting the callout=
parsing.  Plus a really stupid thinko.

Fixing those tidies up most of the testsuite cases.  Of particular interest in
the outstanding ones, though, is:

Basic/0376 callout verification (with caching)
===============f test-stdout-munged with stdout/0376 failed
Line 370 of "test-stdout-munged" does not match line 370 of "stdout/0376".
----------
MAIL FROM:<pmsend <at> a.domain>
----------
MAIL FROM:<>
(Continue reading)

Yuri Arabadji | 8 Apr 2012 12:36
Favicon
Gravatar

[Bug 1178] queue runner is using huge amounts of memory

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

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

Yuri Arabadji <admins <at> fused.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|4.69                        |4.77

--- Comment #13 from Yuri Arabadji <admins <at> fused.net>  2012-04-08 11:36:47 ---
Still happening with 4.77

17736 root      28  12 2510m 2.4g 1604 R 30.2 12.0 653:08.63 exim               
 8946 root      28  12 2397m 2.3g 1600 S 32.5 11.4 612:29.30 exim               
21797 root      28  12 2240m 2.1g 1600 R 37.8 10.7 543:39.58 exim               
16813 root      28  12 2179m 2.1g 1600 R 36.8 10.4 513:01.35 exim               
21019 root      28  12 1746m 1.7g 1264 R 34.1  8.3 692:35.32 exim  

Exim version 4.77 #2 built 03-Nov-2011 00:54:43
Copyright (c) University of Cambridge, 1995 - 2007
Berkeley DB: Sleepycat Software: Berkeley DB 4.3.29: (July 12, 2010)
Support for: crypteq iconv() IPv6 PAM Perl OpenSSL Content_Scanning DKIM
Old_Demime Experimental_SPF Experimental_SRS
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch dbm dbmnz passwd
Authenticators: cram_md5 dovecot plaintext spa
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir autoreply pipe smtp
Size of off_t: 8
(Continue reading)

Nigel Metheringham | 12 Apr 2012 11:00
Picon
Gravatar

Documentation: marking of expansion options in documentation

Theres been a couple of cases recently where people have been caught out
by whether a configuration option uses expanded string value or the
literal string.

Currently we mark whether or not an option expands its value by adding a
dagger symbol to the type - see the first couple of entries at

http://www.exim.org/exim-html-current/doc/html/spec_html/ch14.html#SECTalomo

Would it be sensible to see about changing that dagger to something else
- say the string " (expanded)" in a smaller font, to make things rather
more obvious to those glancing at the docs.

[I'm also wondering about the idea of trying to grab a complete option
list from the source code and comparing it to that in the documentation,
but thats another ramble]

	Nigel.

--

-- 
[ Nigel Metheringham ------------------------------ nigel <at> dotdot.it ]
[                 Ellipsis Intangible Technologies                  ]

Phil Pennock | 12 Apr 2012 11:19
Favicon
Gravatar

Re: Documentation: marking of expansion options in documentation

On 2012-04-12 at 10:00 +0100, Nigel Metheringham wrote:
> Theres been a couple of cases recently where people have been caught out
> by whether a configuration option uses expanded string value or the
> literal string.
> 
> Currently we mark whether or not an option expands its value by adding a
> dagger symbol to the type - see the first couple of entries at
> 
> http://www.exim.org/exim-html-current/doc/html/spec_html/ch14.html#SECTalomo
> 
> Would it be sensible to see about changing that dagger to something else
> - say the string " (expanded)" in a smaller font, to make things rather
> more obvious to those glancing at the docs.

As long as it's output format-specific, I'm okay with that.  It just
won't fit in the plain text output.

Of course, at this point it might be worth instead explicitly marking
those options which are *not* expanded.

> [I'm also wondering about the idea of trying to grab a complete option
> list from the source code and comparing it to that in the documentation,
> but thats another ramble]

I did a sweep a couple of releases ago, to make sure OptionLists.txt was
up-to-date; I don't recall if I cross-referenced the main docs

Expanded-or-not requires more investigation for every option.  :/

-Phil
(Continue reading)


Gmane