[exim-dev] [Bug 2994] New: dsearch subdir should only filter "." and ".."
https://bugs.exim.org/show_bug.cgi?id=2994 Bug ID: 2994 Summary: dsearch subdir should only filter "." and ".." Product: Exim Version: 4.97 Hardware: x86 OS: All Status: NEW Severity: security Priority: medium Component: Filters Assignee: unalloca...@exim.org Reporter: earl_c...@yahoo.com CC: exim-dev@exim.org Created attachment 1442 --> https://bugs.exim.org/attachment.cgi?id=1442=edit Constrain the ".." filter to exclude "..somefile" https://www.exim.org/exim-html-current/doc/html/spec_html/ch-file_and_database_lookups.html > The match value is one of "file", "dir" or "subdir" (the latter not matching > "." or ".."). A provisional patch is included in https://bugs.exim.org/show_bug.cgi?id=2916 where it is combined with other improvements. This bug report is constrained to reporting the issue that the code does not match the documentation, and proposing a fix. -- 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/ ##
[exim-dev] [Bug 2995] New: dsearch should only require search permission
https://bugs.exim.org/show_bug.cgi?id=2995 Bug ID: 2995 Summary: dsearch should only require search permission Product: Exim Version: 4.97 Hardware: x86 OS: All Status: NEW Severity: bug Priority: medium Component: Filters Assignee: unalloca...@exim.org Reporter: earl_c...@yahoo.com CC: exim-dev@exim.org Created attachment 1443 --> https://bugs.exim.org/attachment.cgi?id=1443=edit Use stat() rather than opendir() This issue was also reported in https://bugs.exim.org/show_bug.cgi?id=2916 and addressed along with other issues. The comment in the implementation states: > We open the directory to test whether it exists and whether it is searchable. Using opendir() only requires that the directory is readable, and does not verify that the directory is searchable. Since the function should at least check existence (as stated in the comment), this fix proposes to use stat() to: * Verify that the name refers to a directory, or a symlink that resolves to a directory * Verify that the directory is searchable by referring to the directory via its dot entry Note that this proposed patch does not address the problem that the name is removed, changed, or otherwise altered, after the check completes. -- 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/ ##
[exim-dev] [Bug 2980] exiqgrep -i broken
https://bugs.exim.org/show_bug.cgi?id=2980 Jeremy Harris changed: What|Removed |Added CC||exim...@mehtap.tv --- Comment #4 from Jeremy Harris --- *** Bug 2992 has been marked as a duplicate of this bug. *** -- 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/ ##
[exim-dev] [Bug 2993] wishlist for method to correctly create valid headers like SomeHeader:${format_header: .....}
https://bugs.exim.org/show_bug.cgi?id=2993 Jeremy Harris changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- 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/ ##
[exim-dev] [Bug 2912] cutthrough delivery gets canceled on unexpected (non 2xx) SMTP response
https://bugs.exim.org/show_bug.cgi?id=2912 Jeremy Harris changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Jeremy Harris --- Lacking further info, closing. -- 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/ ##
[exim-dev] [Bug 2992] -i broken exiqgrep
https://bugs.exim.org/show_bug.cgi?id=2992 Jeremy Harris changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jeremy Harris --- Exigrep is not designed for that purpose. *** This bug has been marked as a duplicate of bug 2980 *** -- 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/ ##
[exim-dev] [Bug 2992] New: -i broken exiqgrep
https://bugs.exim.org/show_bug.cgi?id=2992
Bug ID: 2992
Summary: -i broken exiqgrep
Product: Exim
Version: 4.95
Hardware: x86
OS: Windows
Status: NEW
Severity: bug
Priority: medium
Component: Exigrep
Assignee: unalloca...@exim.org
Reporter: exim...@mehtap.tv
CC: exim-dev@exim.org
Commit 42ed39da breaks exiqgrep -i by failing to check for the parameter and
exiting immediately when -i is provided as an option.
The following patch fixes the issue:
diff --git a/src/src/exiqgrep.src b/src/src/exiqgrep.src
index 0661c5792..3fa16a352 100644
--- a/src/src/exiqgrep.src
+++ b/src/src/exiqgrep.src
@@ -57,7 +57,7 @@ if ($ARGV[0] eq '--version') {
if (!getopts('hf:r:y:o:s:C:zxlibRcaG:E:',\%opt)) { exit; }
if ($opt{h}) { exit; }
-if ($ARGV[0] || !($opt{f} || $opt{r} || $opt{s} || $opt{y} || $opt{o} ||
$opt{z} || $opt{x} || $opt{c}))
+if ($ARGV[0] || !($opt{f} || $opt{r} || $opt{s} || $opt{y} || $opt{o} ||
$opt{z} || $opt{x} || $opt{c} || $opt{i}))
{ exit(1); }
if ($opt{a}) { $eargs = '-bp'; }
if ($opt{C} && -e $opt{C} && -f $opt{C} && -R $opt{C}) { $eargs .= ' -C
'.$opt{C}; }
--
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/ ##
[exim-dev] [Bug 2993] New: wishlist for method to correctly create valid headers like SomeHeader:${format_header: .....}
https://bugs.exim.org/show_bug.cgi?id=2993
Bug ID: 2993
Summary: wishlist for method to correctly create valid headers
like SomeHeader:${format_header: .}
Product: Exim
Version: 4.95
Hardware: All
OS: All
Status: NEW
Keywords: work:medium
Severity: wishlist
Priority: medium
Component: String expansion
Assignee: jgh146...@wizmail.org
Reporter: exim...@mehtap.tv
CC: exim-dev@exim.org
tHANKS iTS FIXED
--
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/ ##
[exim-dev] [Bug 2843] wishlist for method to correctly create valid headers like SomeHeader:${format_header: .....}
https://bugs.exim.org/show_bug.cgi?id=2843 exim 1st changed: What|Removed |Added CC||exim...@mehtap.tv --- Comment #5 from exim 1st --- tHANKS iTS FIXED -- 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/ ##
[exim-dev] [Bug 2987] $spam_score_int calculation for negative values is off-by-one
https://bugs.exim.org/show_bug.cgi?id=2987 exim 1st changed: What|Removed |Added CC||exim...@mehtap.tv --- Comment #2 from exim 1st --- Yes Its right -- 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/ ##
[exim-dev] [Bug 2843] wishlist for method to correctly create valid headers like SomeHeader:${format_header: .....}
https://bugs.exim.org/show_bug.cgi?id=2843 Jeremy Harris changed: What|Removed |Added Status|WAIT_FIX_CONFIRMATION |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jeremy Harris --- Lacking info, I'll assume fixed -- 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/ ##
[exim-dev] [Bug 2985] Better means for stripping bad Authentication-Results headers
https://bugs.exim.org/show_bug.cgi?id=2985 Jeremy Harris changed: What|Removed |Added Status|WAIT_FIX_CONFIRMATION |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jeremy Harris --- Nobody commented -- 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/ ##
[exim-dev] [Bug 2912] cutthrough delivery gets canceled on unexpected (non 2xx) SMTP response
https://bugs.exim.org/show_bug.cgi?id=2912 --- Comment #3 from Thomas Mechtersheimer --- (In reply to Jeremy Harris from comment #2) > Changing the message does not show up in the testsuite. > > I'm interested if you saw the meesage in "normal" output? Debug? > Or is this purely from code-inspection? This showed up in debug output as: cutthrough shutdown (target timeout on read) Unfortunately I didn't keep the full debug log files. I've patched my local copy to wrap the cancel_cutthrough_connection call in cutthrough_response with "if(errno != 0)" (without any negative side effects), so I cannot easily reproduce this situation... I'm trying to replace an old completely queue-less mail forwarding system with exim; so using cutthrough whenever possible would be my prime goal. -- 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/ ##
[exim-dev] [Bug 2912] cutthrough delivery gets canceled on unexpected (non 2xx) SMTP response
https://bugs.exim.org/show_bug.cgi?id=2912 --- Comment #4 from Jeremy Harris --- Possibly exim is not the right tool for you, if you want no store-and-forward. Something close to a pure proxy would be better, though I'm unclear how complex your routing needs are. Nor, indeed, why email can't be store-and-forward. -- 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/ ##
[exim-dev] [Bug 2989] No error provided after invalid characters in local-part of To: header
https://bugs.exim.org/show_bug.cgi?id=2989 --- Comment #2 from Matt --- The problem I had specifically was on a cPanel server, where Exim encountered the problem, didn't return an error to the SMTP client, and didn't send the message either. This resulted in the client thinking the message was sent successfully, although it wasn't. -- 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/ ##
[exim-dev] [Bug 2932] The preexpand option must be appended to run with ', ' but without a whitespace
https://bugs.exim.org/show_bug.cgi?id=2932 Jeremy Harris changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unalloca...@exim.org|jgh146...@wizmail.org Hardware|x86 |All Target Milestone|Exim 4.96 |Exim 4.97 -- 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/ ##
[exim-dev] [Bug 2912] cutthrough delivery gets canceled on unexpected (non 2xx) SMTP response
https://bugs.exim.org/show_bug.cgi?id=2912 --- Comment #2 from Jeremy Harris --- Changing the message does not show up in the testsuite. I'm interested if you saw the meesage in "normal" output? Debug? Or is this purely from code-inspection? -- 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/ ##
[exim-dev] [Bug 2702] XCLIENT ESMTP extension
https://bugs.exim.org/show_bug.cgi?id=2702 Jeremy Harris changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED -- 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/ ##
[exim-dev] [Bug 2989] No error provided after invalid characters in local-part of To: header
https://bugs.exim.org/show_bug.cgi?id=2989 Jeremy Harris changed: What|Removed |Added Summary|No error provided after |No error provided after |invalid characters in |invalid characters in |local-part |local-part of To: header -- 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/ ##
[exim-dev] [Bug 2912] cutthrough delivery gets canceled on unexpected (non 2xx) SMTP response
https://bugs.exim.org/show_bug.cgi?id=2912 Jeremy Harris changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unalloca...@exim.org|jgh146...@wizmail.org --- Comment #1 from Jeremy Harris --- It's reasonable to fix the message. I'm less happy about trying to continue using the onward conn after an unexpected response; always dropping back to the traditional store processing path keeps things simple. -- 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/ ##
[exim-dev] [Bug 2972] ACL check "!verify = reverse_host_lookup" gives error
https://bugs.exim.org/show_bug.cgi?id=2972 Jeremy Harris changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #6 from Jeremy Harris --- Lacking further information, closing. -- 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/ ##
[exim-dev] [Bug 2947] dkim=fail (signature did not verify) delivery to Microsoft Exchange
https://bugs.exim.org/show_bug.cgi?id=2947 Jeremy Harris changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from Jeremy Harris --- I'm assuming the Message-ID header thing was the problem; closing on that basis. -- 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/ ##
[exim-dev] [Bug 2989] No error provided after invalid characters in local-part
https://bugs.exim.org/show_bug.cgi?id=2989 Jeremy Harris changed: What|Removed |Added Target Milestone|Exim 4.96 |Exim 4.98+ Severity|bug |wishlist Version|4.96+ |4.95 Priority|medium |high --- Comment #1 from Jeremy Harris --- Exim mostly doesn't have a need to interpret mail addresses in headers (as opposed to the envelope), and will happily pass on such bad 822-level data. So this is a feature request. Reclassifying from Bug to Wishlist. -- 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/ ##
[exim-dev] [Bug 2989] New: No error provided after invalid characters in local-part
https://bugs.exim.org/show_bug.cgi?id=2989 Bug ID: 2989 Summary: No error provided after invalid characters in local-part Product: Exim Version: 4.96+ Hardware: x86 OS: Linux Status: NEW Severity: bug Priority: medium Component: Address Rewriting Assignee: unalloca...@exim.org Reporter: matthew.mcta...@vetta.nz CC: exim-dev@exim.org When Exim receives an email with DATA containing square brackets in the local-part of the "To" email address, without quotes. Exim correctly logs the error "rewrite: missing or malformed local part (expected word or "<")", however an error is not provided after DATA. Example from within DATA: ``` To: Example Company [Firstname] ``` -- 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/ ##
[exim-dev] [Bug 2987] $spam_score_int calculation for negative values is off-by-one
https://bugs.exim.org/show_bug.cgi?id=2987 Martin Kealey changed: What|Removed |Added CC||from-exim-bugzilla@kurahaup ||o.gen.nz --- Comment #1 from Martin Kealey --- Welcome to the (horrible, ugly) world of casting floating point values to ints, which causes "rounding towards zero". Instead, perform an actual floating rounding: EITHER for the intermediate value: #include j = (typeof(j)) floor(spamd_score*10+0.5); OR for the direct string result: string_format(spam_score_int_buffer, sizeof(spam_score_int_buffer), "%.0f", spamd_score*10); -- 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/ ##
[exim-dev] [Bug 2988] New: $domain usable in a non-multi-domain transport
https://bugs.exim.org/show_bug.cgi?id=2988 Bug ID: 2988 Summary: $domain usable in a non-multi-domain transport Product: Exim Version: 4.96 Hardware: All OS: All Status: NEW Severity: wishlist Priority: medium Component: String expansion Assignee: unalloca...@exim.org Reporter: jgh146...@wizmail.org CC: exim-dev@exim.org Doc for $domain says "in transport, only when a single address is being delivered" (paraphrased). In theory it could be used when only a single domain was used by a multi-address set of messages. -- 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/ ##
[exim-dev] [Bug 2987] $spam_score_int calculation for negative values is off-by-one
https://bugs.exim.org/show_bug.cgi?id=2987 Jeremy Harris changed: What|Removed |Added Priority|medium |low -- 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/ ##
[exim-dev] [Bug 2988] $domain usable in a non-multi-domain transport
https://bugs.exim.org/show_bug.cgi?id=2988 Jeremy Harris changed: What|Removed |Added Priority|medium |low -- 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/ ##
[exim-dev] [Bug 2702] XCLIENT ESMTP extension
https://bugs.exim.org/show_bug.cgi?id=2702 Jeremy Harris changed: What|Removed |Added Target Milestone|Exim 4.95 |Exim 4.97 Assignee|unalloca...@exim.org|jgh146...@wizmail.org OS|Linux |All Status|NEW |ASSIGNED Hardware|x86 |All -- 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/ ##
[exim-dev] [Bug 2987] New: $spam_score_int calculation for negative values is off-by-one
https://bugs.exim.org/show_bug.cgi?id=2987 Bug ID: 2987 Summary: $spam_score_int calculation for negative values is off-by-one Product: Exim Version: 4.97 Hardware: All OS: All Status: NEW Severity: bug Priority: medium Component: Content Scanning Assignee: t...@duncanthrax.net Reporter: bugzilla...@shadowweb.org CC: exim-dev@exim.org The internal calculation of spam_score_int in spam.c seems to be off-by-one if negative spamd_score values are encountered: /* create "int" spam score */ j = (int)((spamd_score + 0.001)*10); (void)string_format(spam_score_int_buffer, sizeof(spam_score_int_buffer), "%d", j); spam_score_int = spam_score_int_buffer; The above yields correct results for positive spam scores (0.1 => 1, 4.8 => 48), but will be off for negative values (-0.1 => 0, -4.8 => -47). I guess the correct way of fixing this would be to differentiate between positive and negative spamd_score values (adding 0.001 to positive and subtracting 0.001 from negative values before casting to int). -- 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/ ##
[exim-dev] [Bug 2986] src/configure.default did not know that port 465 is official.
https://bugs.exim.org/show_bug.cgi?id=2986 Andrew Aitchison changed: What|Removed |Added Resolution|--- |FIXED Status|WAIT_FIX_CONFIRMATION |RESOLVED -- 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/ ##
[exim-dev] [Bug 2986] src/configure.default did not know that port 465 is official.
https://bugs.exim.org/show_bug.cgi?id=2986 Jeremy Harris changed: What|Removed |Added Status|ASSIGNED|WAIT_FIX_CONFIRMATION --- Comment #1 from Jeremy Harris --- Committed as 3e6d406e8ae9. -- 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/ ##
[exim-dev] [Bug 2985] Better means for stripping bad Authentication-Results headers
https://bugs.exim.org/show_bug.cgi?id=2985 Jeremy Harris changed: What|Removed |Added Status|ASSIGNED|WAIT_FIX_CONFIRMATION --- Comment #1 from Jeremy Harris --- 1745d310db81 addreses -- 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/ ##
[exim-dev] [Bug 2984] uninitialized value in runtest
https://bugs.exim.org/show_bug.cgi?id=2984 Jeremy Harris changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Jeremy Harris --- da1702c0e2fd addresses. -- 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/ ##
[exim-dev] [Bug 2986] src/configure.default did not know that port 465 is official.
https://bugs.exim.org/show_bug.cgi?id=2986 Jeremy Harris changed: What|Removed |Added Assignee|unalloca...@exim.org|jgh146...@wizmail.org Target Milestone|Exim 4.96 |Exim 4.97 OS|Linux |All Status|NEW |ASSIGNED Hardware|x86 |All Priority|medium |low -- 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/ ##
[exim-dev] [Bug 2984] uninitialized value in runtest
https://bugs.exim.org/show_bug.cgi?id=2984 Jeremy Harris changed: What|Removed |Added Priority|medium |low Target Milestone|Exim 4.96 |Exim 4.97 OS|Linux |All Assignee|unalloca...@exim.org|jgh146...@wizmail.org Status|NEW |ASSIGNED Hardware|x86 |All -- 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/ ##
[exim-dev] [Bug 2985] Better means for stripping bad Authentication-Results headers
https://bugs.exim.org/show_bug.cgi?id=2985 Jeremy Harris changed: What|Removed |Added Status|NEW |ASSIGNED -- 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/ ##
[exim-dev] [Bug 2980] exiqgrep -i broken
https://bugs.exim.org/show_bug.cgi?id=2980 --- Comment #3 from Jeremy Harris --- 8ff2ba119ba6 introduces a cmdline option for exim to output only message-ids for the queue. -- 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/ ##
[exim-dev] [Bug 2979] Long SMTP response can result in deliverable bounce
https://bugs.exim.org/show_bug.cgi?id=2979 Jeremy Harris changed: What|Removed |Added Resolution|--- |FIXED Status|WAIT_FIX_CONFIRMATION |RESOLVED --- Comment #2 from Jeremy Harris --- Nobody commented -- 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/ ##
[exim-dev] [Bug 2827] bounce generated by exim gets too long lines breaching message_linelength_limit limit
https://bugs.exim.org/show_bug.cgi?id=2827 --- Comment #3 from Jeremy Harris --- Oddly, there's already a limit of 12 ref items in a generated References: - so the above example with 50-char items only make on order of 600. We should also impose a 998-char limit for them, but it's not obviously a fix for that case. Ah - you looked at the -D file, so it was the body not the headers, and bug 1760 should apply. -- 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/ ##
[exim-dev] [Bug 2827] bounce generated by exim gets too long lines breaching message_linelength_limit limit
https://bugs.exim.org/show_bug.cgi?id=2827 Jeremy Harris changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #4 from Jeremy Harris --- *** This bug has been marked as a duplicate of bug 1760 *** -- 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/ ##
[exim-dev] [Bug 2986] New: src/configure.default did not know that port 465 is official.
https://bugs.exim.org/show_bug.cgi?id=2986 Bug ID: 2986 Summary: src/configure.default did not know that port 465 is official. Product: Exim Version: N/A Hardware: x86 OS: Linux Status: NEW Severity: bug Priority: medium Component: Documentation Assignee: unalloca...@exim.org Reporter: e...@aitchison.me.uk CC: exim-dev@exim.org Created attachment 1441 --> https://bugs.exim.org/attachment.cgi?id=1441=edit Update src/configure.default - RFC 8314 makes port 465 official. Update src/configure.default - mention that RFC 8314 makes port 465 official. Patch attached. -- 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/ ##
[exim-dev] [Bug 1760] bounces may have overlong lines
https://bugs.exim.org/show_bug.cgi?id=1760 Jeremy Harris changed: What|Removed |Added CC||ar...@maven.pl --- Comment #4 from Jeremy Harris --- *** Bug 2827 has been marked as a duplicate of this bug. *** -- 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/ ##
[exim-dev] [Bug 2985] New: Better means for stripping bad Authentication-Results headers
https://bugs.exim.org/show_bug.cgi?id=2985
Bug ID: 2985
Summary: Better means for stripping bad Authentication-Results
headers
Product: Exim
Version: 4.95
Hardware: All
OS: All
Status: NEW
Severity: wishlist
Priority: medium
Component: ACLs
Assignee: jgh146...@wizmail.org
Reporter: jgh146...@wizmail.org
CC: exim-dev@exim.org
Having to remove and re-add A-R headers, using a ${filter {$lh_ {!match
is both awkward and disturbs original positioning.
Something that combs the existing headers would be good,
especially if it wasn't specialized to A-R headers.
Perhaps a selector option on the remove_header ACL modifier?
--
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/ ##
[exim-dev] [Bug 2982] Writing logs to standard output
https://bugs.exim.org/show_bug.cgi?id=2982 --- Comment #2 from ivanov17 --- Hello, Martin! Maybe I didn't explain well what's going on. I am running Exim in an OCI container. This assumes that only the Exim process will run in the container. Exim itself works well in a containerized environment. But there is a problem with logging. In containerized environments, logs are written to the container's standard output. Thus, they can be read and collected from outside the container. Exim doesn't allow logs to be sent to standard output. So I don't have the ability to read and collect container logs in the normal way. There is a workaround: we can create symlinks to /dev/stdout and /dev/stderr instead of log files when creating a container image for Exim. It works, but it's ugly. Or we can run multiple processes in the same container. This is possible, but requires process management via an entrypoint script. It is ugly and breaks security standards. Unfortunately, Exim cannot send log data to syslog daemon over tcp. If it were possible, I could use another container running the syslog daemon. It would be inconvenient, but better than running multiple processes in the same container. In summary, the problem with Exim logging in containerized environments can only be completely solved if Exim itself starts sending logs to standard output. -- 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/ ##
[exim-dev] [Bug 2982] Writing logs to standard output
https://bugs.exim.org/show_bug.cgi?id=2982
Martin Kealey changed:
What|Removed |Added
CC||from-exim-bugzilla@kurahaup
||o.gen.nz
--- Comment #1 from Martin Kealey ---
Exim can use syslog, and rsyslogd or syslogngd you can configure the daemons to
match based on the details of the sending process and/or the body of the
message, not just the labelled facility and severity.
Or link with this:
#include
#include
#include
#include
#include
void openlog(chat *ident, int option, int facility )
{}
void
syslog(int prio, char *msg, ...)
{
struct timespec t;
clock_gettime(CLOCK_REALTIME, );
struct tm T;
char tt[20];
strftime(tt, sizeof tt, "%F %T", gmtime_r(t.tv_sec, )),
printf("%s.%.4u [%u] ",
tt, t.tv_nsec/10,
getpid());
va_list v;
va_start(v,msg);
vprintf(m, v);
va_end(v);
}
void closesyslog()
{
fflush(stdout);
}
--
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/ ##
[exim-dev] [Bug 2982] Writing logs to standard output
https://bugs.exim.org/show_bug.cgi?id=2982 Jeremy Harris changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #4 from Jeremy Harris --- Exim writes several different classes of information to different files, when logging to files. Mixing them all to stdout would not make sense. -- 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/ ##
[exim-dev] [Bug 2843] wishlist for method to correctly create valid headers like SomeHeader:${format_header: .....}
https://bugs.exim.org/show_bug.cgi?id=2843 --- Comment #2 from Arkadiusz Miskiewicz --- Thanks, will test in next couple of weeks. Is that new functionality usable for fixing #2827 internally ? -- 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/ ##
[exim-dev] [Bug 2843] wishlist for method to correctly create valid headers like SomeHeader:${format_header: .....}
https://bugs.exim.org/show_bug.cgi?id=2843 --- Comment #3 from Jeremy Harris --- While it could be used, it'd be far from optimal (as Richard points out) -- 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/ ##
[exim-dev] [Bug 2984] New: uninitialized value in runtest
https://bugs.exim.org/show_bug.cgi?id=2984 Bug ID: 2984 Summary: uninitialized value in runtest Product: Exim Version: 4.96+ Hardware: x86 OS: Linux Status: NEW Severity: bug Priority: medium Component: Test harness Assignee: unalloca...@exim.org Reporter: e...@aitchison.me.uk CC: exim-dev@exim.org Created attachment 1439 --> https://bugs.exim.org/attachment.cgi?id=1439=edit Possible fix ./runtest 998 snip ... Will run 1 tests between 998 and 998 for flavour openssl_1_1_1 Use of uninitialized value $1 in concatenation (.) or string at ./runtest line 4075. Omitting tests in 0998-DSN-info (missing feature _HAVE_DSN_INFO) snip ... -- 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/ ##
[exim-dev] [Bug 2982] Writing logs to standard output
https://bugs.exim.org/show_bug.cgi?id=2982 --- Comment #3 from Martin Kealey --- "syslog over UDP is unreliable" is one of those things that while technically true, us rarely a real problem. Loss of UDP packets is caused by two factors: the underlying transport dropping oackets, and the receiver's packet queue (in the kernel) overrunning. Sending between containers within one host has 100% reliable transport - otherwise you have a kernel bug - and the only things that could stall syslogd enough to cause overruns would be IO bandwidth saturation and delayed process scheduling, both of which are manageable. The log messages are a tiny fraction of the size of the messages that are being transported, so in practice this risk is tolerable for many. If your use case cannot tolerate even a one-in-a-million loss of log messages, then you would want to use the syslog-to-stdout module that I posted before. -- 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/ ##
[exim-dev] [Bug 2843] wishlist for method to correctly create valid headers like SomeHeader:${format_header: .....}
https://bugs.exim.org/show_bug.cgi?id=2843 Jeremy Harris changed: What|Removed |Added Status|ASSIGNED|WAIT_FIX_CONFIRMATION --- Comment #1 from Jeremy Harris --- Addressed by a6d90e094d4e, ecc7ae95e36b. -- 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/ ##
[exim-dev] [Bug 2982] Writing logs to standard output
https://bugs.exim.org/show_bug.cgi?id=2982 --- Comment #5 from ivanov17 --- Hello, Jeremy! It just means that people will continue to create multilog for their Exim containers using tricks and bad practices because people want to read the logs. Common practice is to store logs from thousands of containers running on hundreds of hosts in one database and then filter the multilog with special tools. Of course, all these containers write very different classes of information. It probably doesn't make sense, right? -- 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/ ##
[exim-dev] [Bug 1687] Option to limit the length of a physical (header?) line
https://bugs.exim.org/show_bug.cgi?id=1687 Jeremy Harris changed: What|Removed |Added See Also||https://bugs.exim.org/show_ ||bug.cgi?id=2843 -- 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/ ##
[exim-dev] [Bug 2843] wishlist for method to correctly create valid headers like SomeHeader:${format_header: .....}
https://bugs.exim.org/show_bug.cgi?id=2843 Jeremy Harris changed: What|Removed |Added See Also||https://bugs.exim.org/show_ ||bug.cgi?id=1687 Status|NEW |ASSIGNED Assignee|unalloca...@exim.org|jgh146...@wizmail.org -- 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/ ##
[exim-dev] [Bug 2982] New: Writing logs to standard output
https://bugs.exim.org/show_bug.cgi?id=2982 Bug ID: 2982 Summary: Writing logs to standard output Product: Exim Version: 4.96 Hardware: x86 OS: Linux Status: NEW Severity: wishlist Priority: medium Component: Logging Assignee: unalloca...@exim.org Reporter: ivano...@riseup.net CC: exim-dev@exim.org Exim cannot write logs to standard output. This creates some problems when Exim is running as a container process. I can read container logs when I run the daemon with `-bdf` option, but this only works with pseudo-TTY allocated to the container. Unfortunately, I can't collect logs from such containers. I have searched the web for a solution, but everything that I found is ugly. First, I can create symlinks to /dev/stdout and /dev/stderr instead of log files. Another option is to run multiple processes in a container (xtail or a syslog daemon). That is a wrong way, but even if I do, I need to write simple process manager and in the case of the syslog daemon, I have to run it as root, because it has to create /dev/log socket. It would be great that Exim could write logs to standard output and we could use someting like log_file_path = stdout in the config to enable this. -- 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/ ##
[exim-dev] [Bug 2941] More convenient option behavior for containerized environments
https://bugs.exim.org/show_bug.cgi?id=2941 --- Comment #6 from ivanov17 --- Thank you, Jeremy and Heiko! I am sorry for my lack of attention, I really missed the statement that options that undergo string expansion before use are marked with †. Now I'm using a simply configuration where I override the compiled settings and default ports. I always have a stateless container that can run without additional configuration, but I can set all other options in an included file placed on a persistent volume. Also I can run Exim containers from non-priveleged user and they works fine. I can create an included configuration file from template using configuration management tools like Ansible, and have different configurations in different environments. Voila! $ cat /etc/exim/exim.conf # Override compiled settings exim_user = 101 exim_group = 101 spool_directory = /data log_file_path = /data/log/%slog : syslog # Listen on unprivileged ports daemon_smtp_ports = 2525 : 4465 tls_on_connect_ports = 4465 # Read configuration from a mounted volume .include_if_exists /data/exim.conf But there is a problem that I can't solve. Exim unable to write logs to standard output. I can read container logs when I run the daemon with `-bdf` option, but this only works with pseudo-TTY allocated to the container. Unfortunately, I unable to collection logs from such containers. I have searched the web for a solution, but everything that I found is ugly. First, I can create symlinks to /dev/stdout and /dev/stderr instead of log files. Another option is to run multiple processes in a container (xtail or a syslog daemon). That is a wrong way, but even if I do, I need to write simple process manager and in the case of the syslog daemon, I have to run it as root, because it has to create /dev/log file. So I think I should open a new issue for this. -- 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/ ##
[exim-dev] [Bug 2981] New: Chapter 32 - Retry configuration. Section - 10 Long-term failures.
https://bugs.exim.org/show_bug.cgi?id=2981 Bug ID: 2981 Summary: Chapter 32 - Retry configuration. Section - 10 Long-term failures. Product: Exim Version: N/A Hardware: x86 OS: All Status: NEW Severity: bug Priority: medium Component: Documentation Assignee: unalloca...@exim.org Reporter: li...@arneis-group.com CC: exim-dev@exim.org Sentence: Until the post-cutoff retry time for one of the IP addresses, as set by the retry_data_expire option, is reached, the failing email address is bounced immediately, without a delivery attempt taking place. Maybe the wrong - "as set by the retry_data_expire option" I think it could be - "as set by the arguments of last cutoff time" Thank you. -- 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/ ##
[exim-dev] [Bug 2890] autoreply driver: return_path option not working for that driver
https://bugs.exim.org/show_bug.cgi?id=2890 --- Comment #4 from Jeremy Harris --- It's still an automatic response. -- 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/ ##
[exim-dev] [Bug 2890] autoreply driver: return_path option not working for that driver
https://bugs.exim.org/show_bug.cgi?id=2890 --- Comment #5 from Arkadiusz Miskiewicz --- And standards do not prohibit that. -- 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/ ##
[exim-dev] [Bug 138] Use shared memory segment for queue list
https://bugs.exim.org/show_bug.cgi?id=138 --- Comment #8 from Jeremy Harris --- Fast queue ramp is now supported by default. -- You are receiving this mail because: You are the QA Contact for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] [Bug 2922] exim using random ipv6 for sending outbound mail
https://bugs.exim.org/show_bug.cgi?id=2922 Jeremy Harris changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Jeremy Harris --- Since it's working as designed, closing. -- 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/ ##
[exim-dev] [Bug 2890] autoreply driver: return_path option not working for that driver
https://bugs.exim.org/show_bug.cgi?id=2890 Jeremy Harris changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Jeremy Harris --- A local count would not be sufficient; a loop of more than one system is possible. Automated bounces should hae a null sender. The standard say so, for good reason. Closing as will-not-fix. -- 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/ ##
[exim-dev] [Bug 2980] exiqgrep -i broken
https://bugs.exim.org/show_bug.cgi?id=2980 --- Comment #1 from Jeremy Harris --- I'm not sure why you'd want to have no selector option as a usable function? Using "-i" in combination with a selector would not be affected by the proposed change. -- 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/ ##
[exim-dev] [Bug 2890] autoreply driver: return_path option not working for that driver
https://bugs.exim.org/show_bug.cgi?id=2890 --- Comment #3 from Arkadiusz Miskiewicz --- It's not a bounce but regular message, just autogenerated, using autoreply exim driver functionality. Standards AFAIK say nothing about sender for such message. So your claim seems wrong. And preventing loops is possible with hash added to the message or any other solution. Keep exim a swiss knife and don't impose artificial limits based on wrong assumptions. -- 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/ ##
[exim-dev] [Bug 452] Request variable(s) to show which item has matched in a list
https://bugs.exim.org/show_bug.cgi?id=452 Jeremy Harris changed: What|Removed |Added Assignee|unalloca...@exim.org|jgh146...@wizmail.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Jeremy Harris --- >From 4.95 :- $host_data, $local_part_data, $domain_data, $sender_data or $recipient_data are filled in. See docs Ch. 10 Sec. 5. -- You are receiving this mail because: You are the QA Contact for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] [Bug 2980] exiqgrep -i broken
https://bugs.exim.org/show_bug.cgi?id=2980 --- Comment #2 from Douglas Phillips --- -i by itself is useful in processing the output from another command which was piped in (for example exim -bp) or if one needed to purge the entire queue (e.g., if a PHP had been abused or there was a runaway process). -- 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/ ##
[exim-dev] [Bug 2980] New: exiqgrep -i broken
https://bugs.exim.org/show_bug.cgi?id=2980
Bug ID: 2980
Summary: exiqgrep -i broken
Product: Exim
Version: N/A
Hardware: All
OS: Linux
Status: NEW
Severity: bug
Priority: medium
Component: Exigrep
Assignee: unalloca...@exim.org
Reporter: d...@sbscomp.com
CC: exim-dev@exim.org
Commit 42ed39da breaks exiqgrep -i by failing to check for the parameter and
exiting immediately when -i is provided as an option.
The following patch fixes the issue:
diff --git a/src/src/exiqgrep.src b/src/src/exiqgrep.src
index 0661c5792..3fa16a352 100644
--- a/src/src/exiqgrep.src
+++ b/src/src/exiqgrep.src
@@ -57,7 +57,7 @@ if ($ARGV[0] eq '--version') {
if (!getopts('hf:r:y:o:s:C:zxlibRcaG:E:',\%opt)) { exit; }
if ($opt{h}) { exit; }
-if ($ARGV[0] || !($opt{f} || $opt{r} || $opt{s} || $opt{y} || $opt{o} ||
$opt{z} || $opt{x} || $opt{c}))
+if ($ARGV[0] || !($opt{f} || $opt{r} || $opt{s} || $opt{y} || $opt{o} ||
$opt{z} || $opt{x} || $opt{c} || $opt{i}))
{ exit(1); }
if ($opt{a}) { $eargs = '-bp'; }
if ($opt{C} && -e $opt{C} && -f $opt{C} && -R $opt{C}) { $eargs .= ' -C
'.$opt{C}; }
--
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/ ##
[exim-dev] [Bug 2979] Long SMTP response can result in deliverable bounce
https://bugs.exim.org/show_bug.cgi?id=2979 Jeremy Harris changed: What|Removed |Added Status|ASSIGNED|WAIT_FIX_CONFIRMATION --- Comment #1 from Jeremy Harris --- 7c60296900bd addresses as above. -- 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/ ##
[exim-dev] [Bug 2956] util to convert message id to human-readable time
https://bugs.exim.org/show_bug.cgi?id=2956 --- Comment #16 from Andrew Aitchison --- Created attachment 1438 --> https://bugs.exim.org/attachment.cgi?id=1438=edit Mention exim_msgdate in ChangeLog and NewStuff Mention exim_msgdate in ChangeLog and NewStuff -- 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/ ##
[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers
https://bugs.exim.org/show_bug.cgi?id=1684 --- Comment #18 from Jeremy Harris --- Tracking as bug 2979. -- 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/ ##
[exim-dev] [Bug 2979] Long SMTP response can result in deliverable bounce
https://bugs.exim.org/show_bug.cgi?id=2979 Jeremy Harris changed: What|Removed |Added See Also||https://bugs.exim.org/show_ ||bug.cgi?id=1684 -- 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/ ##
[exim-dev] [Bug 2979] New: Long SMTP response can result in deliverable bounce
https://bugs.exim.org/show_bug.cgi?id=2979 Bug ID: 2979 Summary: Long SMTP response can result in deliverable bounce Product: Exim Version: 4.95 Hardware: All OS: All Status: NEW Severity: bug Priority: medium Component: Delivery in general Assignee: unalloca...@exim.org Reporter: jgh146...@wizmail.org CC: exim-dev@exim.org Reported in 1684, but tracking here as a separate bug. A long SMTP error response, from end-of-data in the report, resulted in a bounce message that exceeded it's transport's limit on line length. Log sequence: 2023-02-16 10:36:25 1pSagd-006b9M-2u <= <> H=SENDER I=INTERFACE P=esmtp S=1747 for SRS_ENCODED_RECIPIENT 2023-02-16 10:42:05 1pSagd-006b9M-2u ** SRS_DECODED_RECIPIENT P=<> R=dnslookup T=remote_forwarded_smtp H=SENDER I=INTERFACE X=CERTIFICATE_INFO: SMTP error from remote mail server after pipelined end of data: 550-Rejected spam (score 5.7): Content analysis details:\n550-* -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at\n550-* https://www.dnswl.org/, no trust\n550-* [ANON_IP listed in list.dnswl.org]\n550-* 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%\n550-* [score: 0.5000]\n550-* 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily\n550-* valid\n550-* -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature\n550-* 0.5 MISSING_MID Missing Message-Id: header\n550-* 1.4 MISSING_DATE Missing Date: header\n550-* 3.0 MPI_OWN_HEADDOM_WO_DKIM mail with one of our domains in From\n550-* header but no DKIM signature found\n550\n550 * 05.7 Total Score DT=2s 2023-02-16 10:42:05 1pSagd-006b9M-2u Frozen (delivery error message) 2023-02-16 10:46:45 1pSagd-006b9M-2u removed by root 2023-02-16 10:46:45 1pSagd-006b9M-2u Completed 2023-02-16 10:42:05 1pSamD-006e0P-1E <= <> R=1pSagd-006b9M-2u U=Debian-exim P=local S=1533 for postmaster 2023-02-16 10:42:05 1pSamD-006e0P-1E ** POSTMASTER_ALIAS_ADDRESS P=<> R=local_user T=dovecot: message has lines too long for transport DT=0s 2023-02-16 10:42:05 1pSamD-006e0P-1E Frozen (delivery error message) 2023-02-16 10:47:02 1pSamD-006e0P-1E Message is frozen 2023-02-16 10:48:55 1pSamD-006e0P-1E removed by root 2023-02-16 10:48:55 1pSamD-006e0P-1E Completed >From examination of source so far, this only applies when compiled with EXPERIMENTAL_DSN_INFO defined. We don't have access to the specific transport for the bounce, in the code generating the bounce - routing it not having been done yet - so cannot know what limits it will apply. However, splitting a multiline response (this one was), which was munged for logging, seems obvious. We might also consider deliberate wrapping at word boundaries when exceeding an 80-char line. -- 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/ ##
[exim-dev] [Bug 2979] Long SMTP response can result in deliverable bounce
https://bugs.exim.org/show_bug.cgi?id=2979 Jeremy Harris changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unalloca...@exim.org|jgh146...@wizmail.org Target Milestone|Exim 4.96 |Exim 4.97 -- 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/ ##
[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers
https://bugs.exim.org/show_bug.cgi?id=1684 Jeremy Harris changed: What|Removed |Added See Also||https://bugs.exim.org/show_ ||bug.cgi?id=2979 -- 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/ ##
[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers
https://bugs.exim.org/show_bug.cgi?id=1684 --- Comment #17 from Patrick Cernko --- Sorry, I only checked the Changelogs and missed that there is a separate NewStuff file. The SMTP error was a reject after DATA due to spamassassin results. The error message included a longer report from spamassassin. In all my tries to reproduce this error later the message was wrapped by the complaining server and thus did not hit the line limit. I extracted (and anonymized) the relevant log lines from the incident: 2023-02-16 10:36:25 1pSagd-006b9M-2u <= <> H=SENDER I=INTERFACE P=esmtp S=1747 for SRS_ENCODED_RECIPIENT 2023-02-16 10:42:05 1pSagd-006b9M-2u ** SRS_DECODED_RECIPIENT P=<> R=dnslookup T=remote_forwarded_smtp H=SENDER I=INTERFACE X=CERTIFICATE_INFO: SMTP error from remote mail server after pipelined end of data: 550-Rejected spam (score 5.7): Content analysis details:\n550-* -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at\n550-* https://www.dnswl.org/, no trust\n550-* [ANON_IP listed in list.dnswl.org]\n550-* 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%\n550-* [score: 0.5000]\n550-* 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily\n550-* valid\n550-* -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature\n550-* 0.5 MISSING_MID Missing Message-Id: header\n550-* 1.4 MISSING_DATE Missing Date: header\n550-* 3.0 MPI_OWN_HEADDOM_WO_DKIM mail with one of our domains in From\n550-* header but no DKIM signature found\n550\n550 * 05.7 Total Score DT=2s 2023-02-16 10:42:05 1pSagd-006b9M-2u Frozen (delivery error message) 2023-02-16 10:46:45 1pSagd-006b9M-2u removed by root 2023-02-16 10:46:45 1pSagd-006b9M-2u Completed 2023-02-16 10:42:05 1pSamD-006e0P-1E <= <> R=1pSagd-006b9M-2u U=Debian-exim P=local S=1533 for postmaster 2023-02-16 10:42:05 1pSamD-006e0P-1E ** POSTMASTER_ALIAS_ADDRESS P=<> R=local_user T=dovecot: message has lines too long for transport DT=0s 2023-02-16 10:42:05 1pSamD-006e0P-1E Frozen (delivery error message) 2023-02-16 10:47:02 1pSamD-006e0P-1E Message is frozen 2023-02-16 10:48:55 1pSamD-006e0P-1E removed by root 2023-02-16 10:48:55 1pSamD-006e0P-1E Completed I have bounce_return_body enabled but I'm pretty sure, the body of the message did not contain any longer lines as it was a test mail generated by me directly via SMTP with telnet. -- 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/ ##
[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers
https://bugs.exim.org/show_bug.cgi?id=1684 --- Comment #16 from Jeremy Harris --- It would help a lot if you could say what sort of SMTP error message. The message_linelength_limit introduction was noted, with it's default value, in the NewStuff file file for 4.95 -- 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/ ##
[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers
https://bugs.exim.org/show_bug.cgi?id=1684 Patrick Cernko changed: What|Removed |Added CC||pcer...@mpi-klsb.mpg.de --- Comment #15 from Patrick Cernko --- I recently stumbled upon this change. I had a scenario, where my exim generated a bounce based on a very long SMTP error message and failed to deliver it via the local LMTP transport because the message *body* (generated by exim itself) contained a line longer than message_linelength_limit. The result was a frozen message. This caused a freeze_tell event but the resulting generated message also had the message_linelength_limit issue (AFAIK). So in the end I had two frozen messages in the queue but no message to postmaster about that. I only stumbled upon the frozen messages by accident. Unfortunately I removed the frozen message from the queue and was not able to reproduce the behavior later to provide more a more detailed description. I would like to request two things: 1. Please check all code sections generating (error) messages to not generate lines longer than message_linelength_limit. 2. I cannot find any documentation about the changed default for message_linelength_limit in the docs. Only thing I found was the documentation about the new option with a different default as before. The sections seems to be introduced in the 4.95 release but the release notes do not mention anything about the new setting. As the setting definitely changes the behavior of existing installations, it really should be worth mentioning. Besides my requests, I really appreciate that new feature! -- 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/ ##
[exim-dev] [Bug 2956] util to convert message id to human-readable time
https://bugs.exim.org/show_bug.cgi?id=2956 Jeremy Harris changed: What|Removed |Added Version|4.97|4.96 Target Milestone|Exim 4.96 |Exim 4.97 -- 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/ ##
[exim-dev] [Bug 2956] util to convert message id to human-readable time
https://bugs.exim.org/show_bug.cgi?id=2956 Jeremy Harris changed: What|Removed |Added Version|4.96+ |4.97 -- 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/ ##
[exim-dev] [Bug 2956] util to convert message id to human-readable time
https://bugs.exim.org/show_bug.cgi?id=2956 Jeremy Harris changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from Jeremy Harris --- Thanks. Committed as 7b5fe03f9c6c. -- 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/ ##
[exim-dev] [Bug 2956] util to convert message id to human-readable time
https://bugs.exim.org/show_bug.cgi?id=2956 --- Comment #14 from Andrew Aitchison --- > --- Comment #12 from Jeremy Harris --- > Looking good. One issue in timezone handling: > > $eximdir/exim_msgdate -C /data/jgh/git/exim/test/test-config > 1pEPHo-005xgk-2e > 2023-01-08 06:36:04.082000 GMT > $ TZ=PDT eximdir/exim_msgdate -C /data/jgh/git/exim/test/test-config > 1pEPHo-005xgk-2e > 2023-01-08 06:36:04.082000 PDT Do you have a PDT zoneinfo file ? I don't but do have PST8PDT, and $ TZ=PST8PDT ~eximtest/git/Exim/exim/src/build-Linux-x86_64/exim_msgdate 1pEPHo-005xgk-2e 2023-01-07 22:36:04.082000 PST This is going to bite other users, so I check that the environment variables in man tzset are sane. With patch 1437 (as well as 1436) I now get $ TZ=PDT ~eximtest/git/Exim/exim/src/build-Linux-x86_64/exim_msgdate 1pEPHo-005xgk-2e Cannot read timezone file /usr/share/zoneinfo/PDT (from TZDIR/TZ) 'man tzset' may help. 2023-01-08 06:36:04.082000 PDT -- 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/ ##
[exim-dev] [Bug 2956] util to convert message id to human-readable time
https://bugs.exim.org/show_bug.cgi?id=2956 --- Comment #13 from Andrew Aitchison --- Created attachment 1437 --> https://bugs.exim.org/attachment.cgi?id=1437=edit timezone.sanity.patch -- 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/ ##
[exim-dev] [Bug 2956] util to convert message id to human-readable time
https://bugs.exim.org/show_bug.cgi?id=2956 --- Comment #12 from Jeremy Harris --- Looking good. One issue in timezone handling: $eximdir/exim_msgdate -C /data/jgh/git/exim/test/test-config 1pEPHo-005xgk-2e 2023-01-08 06:36:04.082000 GMT $ TZ=PDT eximdir/exim_msgdate -C /data/jgh/git/exim/test/test-config 1pEPHo-005xgk-2e 2023-01-08 06:36:04.082000 PDT $ -- 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/ ##
[exim-dev] [Bug 2956] util to convert message id to human-readable time
https://bugs.exim.org/show_bug.cgi?id=2956 Andrew Aitchison changed: What|Removed |Added Attachment #1435|0 |1 is obsolete|| --- Comment #11 from Andrew Aitchison --- Created attachment 1436 --> https://bugs.exim.org/attachment.cgi?id=1436=edit Revised complete patch against current exim master I think this is complete now. -- 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/ ##
[exim-dev] [Bug 2956] util to convert message id to human-readable time
https://bugs.exim.org/show_bug.cgi?id=2956 John Jetmore changed: What|Removed |Added CC||j...@pobox.com --- Comment #9 from John Jetmore --- (In reply to Jeremy Harris from comment #8) > (In reply to Andrew Aitchison from comment #7) > > > Also, do we know the name of the exim executable at make time ? > > I think $(BIN_DIRECTORY) gives us the path, but Debian and Ubuntu change the > > name to exim4. > > Sigh, good point. Maybe yet another build-config item, to handle such > bloody-awkward distros (Exim version 3 was twenty years ago, dammit). > But given the below, moot. I perked up at this because I thought it was a perl question I could help with but I now realize it's not. Apologies if I am addressing a different issue than what is asked. I think what you are saying is "exim_msgdate needs to call exim, which it refers to as 'BIN_DIRECTORY/exim', with BIN_DIRECTORY getting replaced by the build process. Therefore how does the build process handle distros that use a different binary name than exim4" Assuming I read that right, the correct answer is it's not the exim distro's problem. There are already tools like this (see exiqgrep.src), and they are handled by the packager who chooses to change the binary name, as is proper (see https://sources.debian.org/src/exim4/4.96-13/src/exiqgrep.src/ which refers to BIN_DIRECTORY/exim4) -- 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/ ##
[exim-dev] [Bug 2956] util to convert message id to human-readable time
https://bugs.exim.org/show_bug.cgi?id=2956 Jasen Betts changed: What|Removed |Added CC||ja...@treshna.com --- Comment #10 from Jasen Betts --- Debian provides /usr/sbin/exim as a symlink to /usr/sbin/exim4. so you probably don't need to worry about exim4 because "exim" should work for most purposes. -- 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/ ##
[exim-dev] [Bug 2956] util to convert message id to human-readable time
https://bugs.exim.org/show_bug.cgi?id=2956 --- Comment #8 from Jeremy Harris --- (In reply to Andrew Aitchison from comment #7) > > It's using a hardwired config file path, at least in the testsuite. > > Noticing the -C the testharness gave it would be good; > > I've got that working, which confuses me. I had expected that to pass one of > the configs in test/confs/ It does; the one you supplied as confs/0700 - but the code picks up the -C option and ignores it. The hardcoded file is just after a commented-out "die". > > > but for production use - how about using `exim -bP localhost_number' > > as a default for no "-C foo" given? > > That makes some sense, but exim_msgtime has perl taint set, so I cannot > easily run a binary by name given as an argument. I was assuming exim in $PATH - but I don't know how perl taint restricts that. > Also, do we know the name of the exim executable at make time ? > I think $(BIN_DIRECTORY) gives us the path, but Debian and Ubuntu change the > name to exim4. Sigh, good point. Maybe yet another build-config item, to handle such bloody-awkward distros (Exim version 3 was twenty years ago, dammit). But given the below, moot. > It isn't working in attachment 1435 [details], but after a bug-fix, the > build now correctly writes the configfile list into the script and I can > search that for localhost_number. That'll be fine apart from the testsuite, which needs the -C value to take precedence. -- 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/ ##
[exim-dev] [Bug 2956] util to convert message id to human-readable time
https://bugs.exim.org/show_bug.cgi?id=2956 --- Comment #7 from Andrew Aitchison --- > It's using a hardwired config file path, at least in the testsuite. > Noticing the -C the testharness gave it would be good; I've got that working, which confuses me. I had expected that to pass one of the configs in test/confs/ > but for production use - how about using `exim -bP localhost_number' > as a default for no "-C foo" given? That makes some sense, but exim_msgtime has perl taint set, so I cannot easily run a binary by name given as an argument. Also, do we know the name of the exim executable at make time ? I think $(BIN_DIRECTORY) gives us the path, but Debian and Ubuntu change the name to exim4. It isn't working in attachment 1435, but after a bug-fix, the build now correctly writes the configfile list into the script and I can search that for localhost_number. -- 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/ ##
[exim-dev] [Bug 2956] util to convert message id to human-readable time
https://bugs.exim.org/show_bug.cgi?id=2956 --- Comment #5 from Andrew Aitchison --- Created attachment 1435 --> https://bugs.exim.org/attachment.cgi?id=1435=edit exim_msgdate utility Thought I might as well give you the patch. -- 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/ ##
[exim-dev] [Bug 2956] util to convert message id to human-readable time
https://bugs.exim.org/show_bug.cgi?id=2956 --- Comment #6 from Jeremy Harris --- - It's using a hardwired config file path, at least in the testsuite. Noticing the -C the testharness gave it would be good; but for production use - how about using `exim -bP localhost_number' as a default for no "-C foo" given? - I like single-char options where feasible, at least for common-use ones. Maybe "-z" as an alternate for --zulu, as sed bu exim_dumpdb? Also the help text should define the default. - On the name, I'm easy. exim_msgdate is as good as any. - Makefile/shell syntax - we'll run with that until we find a platform that can't handle it. - Are you OK with GPLv2-or-later? Needs an SPDX line. - Some verbiage in doc/doc-doc-book/spec.xfpt please. -- 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/ ##
[exim-dev] [Bug 2956] util to convert message id to human-readable time
https://bugs.exim.org/show_bug.cgi?id=2956
--- Comment #3 from Andrew Aitchison ---
I have a patch ready to submit, but I am not sure what to call the utility.
My working name is exim_msgdate but it should really have "msgid" in it.
eximmsgiddate has doubled letters in the wrong places.
Existing tools start with
exi_ (exim_checkaccess exim_dbmbuild exim_dumpdb exim_fixdb exim_lock
exim_msgdate eximstats exim_tidydb)
exi (exicyclog exigrep exinext exipick exiqgrep exiqsumm exiwhat)
or exim (eximstats)
so perhaps exi_msgid_date ?
I have had to use the new (to exim build) feature ${parameter:-word} in the
make shell script of src/OS/Makefile-Base.
What shells are used inside make on the various platforms ?
set BASE_62=36
echo BASE_62 | sed -e "s?BASE_62?${BASE_62:-62}?"
gives 36 on the shells I've tested (bash, dash = sh, ksh on Ubuntu 22:10 and
bash and sh on RedHat 6!) but these are modern, posix-type shells.
Can anyone test this on the other platforms on the build farm ?
Use
Or should I just submit the patch as it is ?
--
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/ ##
[exim-dev] [Bug 2956] util to convert message id to human-readable time
https://bugs.exim.org/show_bug.cgi?id=2956
--- Comment #4 from Andrew Aitchison ---
Oops. Accidentally submitted the previous comment prematurely.
Part 2 should have included the suggestion:
Use
echo BASE_62 | sed -e "s?BASE_62?$${BASE_62:-62}?"
with doubled $ if you test inside a Makefile.
Still interested in thoughts on the utilitiy's name.
--
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/ ##
[exim-dev] [Bug 2434] information about time from start of smtp connection exists only for some log messages
https://bugs.exim.org/show_bug.cgi?id=2434 Jeremy Harris changed: What|Removed |Added Resolution|--- |FIXED Status|WAIT_FIX_CONFIRMATION |RESOLVED --- Comment #5 from Jeremy Harris --- Nobody commented -- 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/ ##
[exim-dev] [Bug 2904] "bad memory reference" errors in paniclog
https://bugs.exim.org/show_bug.cgi?id=2904 Jasen Betts changed: What|Removed |Added CC||ja...@treshna.com --- Comment #5 from Jasen Betts --- I encountered a bug like this, it was caused by log lines of exactly the wrong length and was fixed by commit 1ed24e36e279c922d3366f6c3144570cc5f54d7a Which will be in the next point release "4.97" -- 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/ ##
[exim-dev] [Bug 2956] util to convert message id to human-readable time
https://bugs.exim.org/show_bug.cgi?id=2956 --- Comment #2 from Jeremy Harris --- Hmm, yes, that will indeed make the testsuite awkward. That's the right set of lines to be bypassing in runtest. Options are parsed around line 3060. Add a bit in README about the optinn you invent. -- 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/ ##
[exim-dev] [Bug 2872] Unable to select ONLY TLSv1.3 CHACHA20-POLY1305 cipher
https://bugs.exim.org/show_bug.cgi?id=2872 --- Comment #11 from help@novo.media --- There is a fundamental philosophical difference between my understanding and the developers, in that, Exim tries to be consistent/compatible over different libraries, TLS versions, connection directions and settings. An attempt I consider futile. Nonetheless, my proposals were always listened to with an open mind, exemplary professionalism and formidable endurance. For that, I kindly thank everyone participating. I now proceed with disabling all my TLS settings in each daemon/config and set the appropriate configurations globally within openssl.cnf. This solution is somewhat limiting in regards to outgoing connections, but it is also nice to have all TLS settings within one file! Thanks again. -- 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/ ##
[exim-dev] [Bug 2904] "bad memory reference" errors in paniclog
https://bugs.exim.org/show_bug.cgi?id=2904 --- Comment #6 from Chance Rollins --- That is encouraging to hear. Is there any estimated release timeline for 4.97? Thank you very much Jasen. -- 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/ ##
[exim-dev] [Bug 2904] "bad memory reference" errors in paniclog
https://bugs.exim.org/show_bug.cgi?id=2904 Jeremy Harris changed: What|Removed |Added Resolution|--- |ALREADY_FIXED Status|REOPENED|RESOLVED --- Comment #7 from Jeremy Harris --- No estimate, sorry. It all depends on the rate changes accumulate. We've only just gone over twenty ChangeLog entries for this cycle. Given your reported version number (4.96-5), I guess you're using a distro-built binary (not the same as the Exim project 4.96; but probably that with some particular patches). You could ask the distro maintainer to cherry-pick that 1ed24e36e fix. Or, if you're in a hurry, you could build from a git tree. Meantime, I'll close this bug as "already fixed". Thanks Jasen. -- 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/ ##
[exim-dev] [Bug 2904] "bad memory reference" errors in paniclog
https://bugs.exim.org/show_bug.cgi?id=2904 Jeremy Harris changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED croll...@sjrollins.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME |--- CC||croll...@sjrollins.com --- Comment #2 from Jeremy Harris --- Closing due to lack of futer occurrence. Please re-open if needed. --- Comment #3 from croll...@sjrollins.com --- I am currently on exim 4.96-5 and am experiencing this issue as well. We have been experiencing issues where messages being sent from an external system to this exim server error out at times for unknown reasons since August 2022 and we have now linked it back to this error message every time it happens. I have enabled +all logging and this is all that is provided. There are no messages between these two. Ultimately the client connection is dropped. 2023-01-23 13:17:28.955 [126517] SMTP connection from [xxx.xxx.xxx.xxx]:52521 I=[xxx.xxx.xxx.xxx]:25 (TCP/IP connection count = 1) 2023-01-23 13:17:32.776 [201051] 1pK1Ns-000qIl-2N bad memory reference; pool not found, at gstring_grow 1122 -- 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/ ##
