https://bugs.exim.org/show_bug.cgi?id=1661
--- Comment #6 from Jasen Betts ---
> Did any of your other event handlers create (by using for the first time) any
> new acl variables? This might be a source of corruption in the variables
> data structure.
It turns out that I did have a "set acl_m_x
https://bugs.exim.org/show_bug.cgi?id=1661
Jeremy Harris changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|ni...@exim.org
https://bugs.exim.org/show_bug.cgi?id=1623
Jeremy Harris changed:
What|Removed |Added
Target Milestone|Exim 4.87+ |Exim 4.87
Version|4.85+ HEAD
https://bugs.exim.org/show_bug.cgi?id=1647
Jeremy Harris changed:
What|Removed |Added
Version|4.85+ HEAD |4.85
Status|ASSIGNED
https://bugs.exim.org/show_bug.cgi?id=1659
Jeremy Harris changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://bugs.exim.org/show_bug.cgi?id=1661
Jeremy Harris changed:
What|Removed |Added
Target Milestone|Exim 4.87+ |Exim 4.87
--- Comment #8 from Jeremy Harris ---
https://bugs.exim.org/show_bug.cgi?id=1661
--- Comment #9 from jasen Betts ---
I was expecting you to close this one as "won't fix"
I'm setting the variable in a msg:delivery event ACL and then trying to read it
in the msg:completed event. if that's not going to work I'll find a way to push
the
https://bugs.exim.org/show_bug.cgi?id=1661
--- Comment #10 from Jeremy Harris ---
It's not going to work because it won't be visible.
But it shouldn't crash, and that needs fixing.
--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.e
https://bugs.exim.org/show_bug.cgi?id=1664
Jeremy Harris changed:
What|Removed |Added
Assignee|p...@exim.org|jgh146...@wizmail.org
--
You are receiving thi
https://bugs.exim.org/show_bug.cgi?id=1664
Bug ID: 1664
Summary: OSCP stapling with GnuTLS results in dropped
connections
Product: Exim
Version: 4.86
Hardware: x86
OS: Linux
Status: NEW
https://bugs.exim.org/show_bug.cgi?id=1664
Jeremy Harris changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #1 from Jeremy Harris ---
https://bugs.exim.org/show_bug.cgi?id=1664
--- Comment #2 from Jeremy Harris ---
Repeatable with GnuTLS 3.3.16 (Debian Stretch).
--
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 h
https://bugs.exim.org/show_bug.cgi?id=1664
--- Comment #3 from Jeremy Harris ---
Further: reproducible using the "client-ssl" utility from Exim's
testsuite, against the current Exim HEAD, but not when using
the "client-gnutls" utility. The former is built with OpenSSL,
the latter with GnuTLS 3.3.
https://bugs.exim.org/show_bug.cgi?id=1664
--- Comment #4 from Jeremy Harris ---
Untested as yet, but a commit addressing this has been made in the GnuTLS code
(https://gitlab.com/gnutls/gnutls.git 1965e2c2f724 +branches). Unsafe versions
are 3.4.3 & 3.3.16 . It seems best to disable Exim's use
https://bugs.exim.org/show_bug.cgi?id=1664
--- Comment #5 from Jeremy Harris ---
GnuTLS versions from 3.2 and earlier branches should also be regarded as buggy.
--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/list
https://bugs.exim.org/show_bug.cgi?id=1664
Git Commit changed:
What|Removed |Added
CC||g...@exim.org
--- Comment #6 from Git Commit ---
G
https://bugs.exim.org/show_bug.cgi?id=1664
--- Comment #7 from Git Commit ---
Git commit:
http://git.exim.org/exim.git/commitdiff/9196d5bf543d75a81ae0825a352920d27241c325
commit 9196d5bf543d75a81ae0825a352920d27241c325
Author: Jeremy Harris
AuthorDate: Sun Aug 2 13:53:15 2015 +0100
Commit:
https://bugs.exim.org/show_bug.cgi?id=1664
--- Comment #8 from Git Commit ---
Git commit:
http://git.exim.org/exim.git/commitdiff/82d14d6a7ecbaf515d7feb30c351c92a4b429f43
commit 82d14d6a7ecbaf515d7feb30c351c92a4b429f43
Author: Jeremy Harris
AuthorDate: Sun Aug 2 14:33:56 2015 +0100
Commit:
https://bugs.exim.org/show_bug.cgi?id=1664
--- Comment #9 from Jeremy Harris ---
Debian Sid as of today has 3.3.16-2 for the major architectures (not all)
which has the fix pulled in. It works for the "swaks" test.
Not certain yet if the client side of the problem was also fixed; keeping the
bu
https://bugs.exim.org/show_bug.cgi?id=1666
Bug ID: 1666
Summary: exim should log unexpanded queries
Product: Exim
Version: 4.86
Hardware: x86
OS: Linux
Status: NEW
Severity: bug
Priority: medium
https://bugs.exim.org/show_bug.cgi?id=1666
Graeme Fowler changed:
What|Removed |Added
CC||gra...@graemef.net
--- Comment #1 from Graeme Fo
https://bugs.exim.org/show_bug.cgi?id=1282
--- Comment #4 from Don Craig ---
A couple of additional things to note:
1) as of 4.86 JH/07 changed the default rfc1413 settings to disable calls.
2) The infamous GHOST vulnerability documented by Qualys in January 2015
relied on buffer overflow prob
https://bugs.exim.org/show_bug.cgi?id=1666
Graeme Fowler changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|ni...@exim.org
https://bugs.exim.org/show_bug.cgi?id=1666
Jeremy Harris changed:
What|Removed |Added
CC||jgh146...@wizmail.org
--- Comment #2 from Jeremy
might that not give us more problems when
trying to isolate problems? I'd argue here that in the majority of cases the
admin who looks at the logs in which this information is placed is also the
admin of the server, so can trap/catch/log credentials in a rather large number
of ways additional to h
https://bugs.exim.org/show_bug.cgi?id=1664
Jeremy Harris changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://bugs.exim.org/show_bug.cgi?id=1668
Bug ID: 1668
Summary: RFE: sasl_user_exists condition
Product: Exim
Version: 4.85+ HEAD
Hardware: All
OS: All
Status: NEW
Severity: wishlist
Priority: m
https://bugs.exim.org/show_bug.cgi?id=1668
Jeremy Harris changed:
What|Removed |Added
CC||jgh146...@wizmail.org
--- Comment #1 from Jeremy
https://bugs.exim.org/show_bug.cgi?id=1664
--- Comment #11 from Jeremy Harris ---
GnuTLS library fix versions: 3.4.4 and 3.3.17
--
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 ht
https://bugs.exim.org/show_bug.cgi?id=1424
Lucian Atody changed:
What|Removed |Added
CC||luc...@spamexperts.com
--- Comment #4 from Lucian
https://bugs.exim.org/show_bug.cgi?id=1671
Bug ID: 1671
Summary: segfault after delivery
Product: Exim
Version: 4.86
Hardware: x86
OS: Linux
Status: NEW
Severity: bug
Priority: medium
Co
https://bugs.exim.org/show_bug.cgi?id=1671
Wolfgang Breyha changed:
What|Removed |Added
CC||wbre...@gmx.net
--- Comment #1 from Wolfgang B
https://bugs.exim.org/show_bug.cgi?id=1671
--- Comment #2 from Wolfgang Breyha ---
I was able to produce coredumps with full debug info... I did that by adding
iptables DROP for well known MX hosts of my own domains and queuing some mails
caused by the timeouts.
I had 3 emails for 2 domains in t
https://bugs.exim.org/show_bug.cgi?id=1671
Phil Pennock changed:
What|Removed |Added
CC||p...@exim.org
--- Comment #3 from Phil Pennock -
https://bugs.exim.org/show_bug.cgi?id=1671
--- Comment #4 from Phil Pennock ---
Added Julian to CC list for this bug; Julian, any thoughts?
--
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
d
https://bugs.exim.org/show_bug.cgi?id=264
Jeremy Harris changed:
What|Removed |Added
CC||jgh146...@wizmail.org
--- Comment #2 from Jeremy
https://bugs.exim.org/show_bug.cgi?id=1671
--- Comment #5 from Wolfgang Breyha ---
Created attachment 828
--> https://bugs.exim.org/attachment.cgi?id=828&action=edit
fix SIGSEGV for split_directory
I think, I found *one* reason first of all it only happens if
split_spool_directory = true
https://bugs.exim.org/show_bug.cgi?id=1671
Heiko Schlittermann changed:
What|Removed |Added
CC||h...@schlittermann.de
--- Comment #6 from
https://bugs.exim.org/show_bug.cgi?id=1671
--- Comment #7 from Wolfgang Breyha ---
Created attachment 830
--> https://bugs.exim.org/attachment.cgi?id=830&action=edit
check deliver_get_sender_address() return value
safeguard for missing spoolfile and deliver_get_sender_address() returning
NULL.
https://bugs.exim.org/show_bug.cgi?id=1671
--- Comment #8 from Wolfgang Breyha ---
(In reply to Phil Pennock from comment #3)
> But that doesn't explain why the backtrace shows `tblock=0x0` here, because
> it should have done the same on lines 1278/1279 as it does on 1282 and it
> should have cra
https://bugs.exim.org/show_bug.cgi?id=1671
--- Comment #9 from Wolfgang Breyha ---
interesting:
frame 2:
(gdb) print tblock
$6 = (struct transport_instance *) 0x0
but
(gdb) print ob
$7 = (smtp_transport_options_block *) 0x999f478
and
smtp_transport_options_block * ob =
(smtp_transport_options
https://bugs.exim.org/show_bug.cgi?id=1671
Heiko Schlittermann changed:
What|Removed |Added
Assignee|ni...@exim.org |h...@schlittermann.de
Status|N
https://bugs.exim.org/show_bug.cgi?id=1671
--- Comment #11 from Wolfgang Breyha ---
your patch does not restore sender_address in case
deliver_get_sender_address(()
fails.
--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/
https://bugs.exim.org/show_bug.cgi?id=1671
--- Comment #12 from Heiko Schlittermann ---
(In reply to Wolfgang Breyha from comment #11)
> your patch does not restore sender_address in case
> deliver_get_sender_address(()
> fails.
Thx.
Forgotten.
And I'm not sure about the store_free(), if really
https://bugs.exim.org/show_bug.cgi?id=1671
Heiko Schlittermann changed:
What|Removed |Added
Attachment #831 is|0 |1
obsolete|
https://bugs.exim.org/show_bug.cgi?id=1671
Git Commit changed:
What|Removed |Added
CC||g...@exim.org
--- Comment #14 from Git Commit ---
https://bugs.exim.org/show_bug.cgi?id=264
Jeremy Harris changed:
What|Removed |Added
Status|NEW |ASSIGNED
Target Milestone|Exim 4.77
https://bugs.exim.org/show_bug.cgi?id=264
Git Commit changed:
What|Removed |Added
CC||g...@exim.org
--- Comment #3 from Git Commit ---
Gi
https://bugs.exim.org/show_bug.cgi?id=1677
Bug ID: 1677
Summary: transports should check setup parameters when
continuing.
Product: Exim
Version: N/A
Hardware: All
OS: All
Status: NEW
S
https://bugs.exim.org/show_bug.cgi?id=1678
Bug ID: 1678
Summary: retry rules are confused by different static interface
settings.
Product: Exim
Version: N/A
Hardware: x86
OS: Linux
Status: NEW
https://bugs.exim.org/show_bug.cgi?id=1677
Jeremy Harris changed:
What|Removed |Added
CC||jgh146...@wizmail.org
--- Comment #1 from Jeremy
https://bugs.exim.org/show_bug.cgi?id=728
Andreas Pflug changed:
What|Removed |Added
Resolution|WORKSFORME |---
Target Milestone|Exim 4.77
https://bugs.exim.org/show_bug.cgi?id=728
--- Comment #4 from Jeremy Harris ---
Could you check whether it appears to be the queue-runner process, as in the
original report?
--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org
https://bugs.exim.org/show_bug.cgi?id=728
--- Comment #5 from Andreas Pflug ---
AFAIR at the time I noticed the deleted file, it was owned by the single
running exim process /usr/sbin/exim4 -bd -q30m, i.e. the SMTP listener, not a
queue runner.
I'll be observing the issue the next days for more
https://bugs.exim.org/show_bug.cgi?id=728
--- Comment #6 from Jeremy Harris ---
There's a comment at the top of the main daemon loop saying that the log
is only written to for exceptional conditions, and always closed immediately.
OTOH, the per-connection handling optionally does log a connection
https://bugs.exim.org/show_bug.cgi?id=1677
jasen Betts changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://bugs.exim.org/show_bug.cgi?id=1141
jasen Betts changed:
What|Removed |Added
CC||eximbugzi...@revmaps.no-ip.
|
https://bugs.exim.org/show_bug.cgi?id=728
--- Comment #7 from Andreas Pflug ---
Ok, just checked and exim keeps mainlog open. I'll continue observing how long
this will last, and if it will keep another mainlog open when it's renamed to
mainlog.1 and deleted. I can't see why it arises now, wasn't
https://bugs.exim.org/show_bug.cgi?id=728
--- Comment #8 from Jeremy Harris ---
Hypothesis: logwrites are being done infrequently by this process, only for
exceptional conditions (as you don't log new connections), one such does not
close the log after, and this is only detected on the next logwr
https://bugs.exim.org/show_bug.cgi?id=728
--- Comment #9 from Andreas Pflug ---
The last logfile that's still open is quite small (500k; I rotated manually to
observe it), so I had a look at it for irregularities.
The only rare event I found is
Connection from [nn.nn.nn.nn] refused: too many
https://bugs.exim.org/show_bug.cgi?id=728
Heiko Schlittermann changed:
What|Removed |Added
CC||h...@schlittermann.de
--- Comment #10 from
https://bugs.exim.org/show_bug.cgi?id=728
--- Comment #11 from Jeremy Harris ---
Yup, that would do it. The obvious fix is a log_close_all() call at the
tail of handle_smtp_call() in the error-handling block.
--
You are receiving this mail because:
You are on the CC list for the bug.
--
## Li
https://bugs.exim.org/show_bug.cgi?id=728
Jeremy Harris changed:
What|Removed |Added
OS|Linux |All
Assignee|ni...@exim.org
https://bugs.exim.org/show_bug.cgi?id=728
--- Comment #13 from Andreas Pflug ---
How about solution #4
- close all logfiles when a name change is detected and a new logfile has to be
opened?
I don't quite see the reasoning why an old logfile should stay open when it has
been detected as obsolet
https://bugs.exim.org/show_bug.cgi?id=728
--- Comment #14 from Jeremy Harris ---
We already do that. In your case it was not being detected, as the detection
is done on the next attempt to use it and you didn't yet make such an attempt.
--
You are receiving this mail because:
You are on the CC
https://bugs.exim.org/show_bug.cgi?id=728
--- Comment #15 from Andreas Pflug ---
Hm, there's only the main process holding that file open, which is handling
>10k Mails per day, logging every one of them...
OTOH, I usually do NOT see open mainlogs, so the standard logfile procedure
seems to clos
https://bugs.exim.org/show_bug.cgi?id=728
Git Commit changed:
What|Removed |Added
CC||g...@exim.org
--- Comment #16 from Git Commit ---
G
https://bugs.exim.org/show_bug.cgi?id=728
--- Comment #17 from Jeremy Harris ---
Most of your logging of these 10k connections is being done by sub-processes;
those processes are not long-lasting and do not hold the mainlog open once they
die.
--
You are receiving this mail because:
You are on
https://bugs.exim.org/show_bug.cgi?id=728
--- Comment #18 from Heiko Schlittermann ---
(In reply to Andreas Pflug from comment #13)
> How about solution #4
> - close all logfiles when a name change is detected and a new logfile has to
> be opened?
>
> I don't quite see the reasoning why an old
https://bugs.exim.org/show_bug.cgi?id=728
--- Comment #19 from Heiko Schlittermann ---
(In reply to Andreas Pflug from comment #15)
> Hm, there's only the main process holding that file open, which is handling
> >10k Mails per day, logging every one of them...
>
> OTOH, I usually do NOT see ope
https://bugs.exim.org/show_bug.cgi?id=1671
--- Comment #15 from Git Commit ---
Git commit:
http://git.exim.org/exim.git/commitdiff/f1b81d811582d37370363ba0a7ea3bc2422a5e66
commit f1b81d811582d37370363ba0a7ea3bc2422a5e66
Author: Heiko Schlittermann (HS12-RIPE)
AuthorDate: Tue Aug 25 13:37:47
https://bugs.exim.org/show_bug.cgi?id=1684
Bug ID: 1684
Summary: Malformed headers which exceed length spec willingly
passed to remote servers
Product: Exim
Version: 4.80
Hardware: x86
OS: Linux
https://bugs.exim.org/show_bug.cgi?id=1684
Rubin changed:
What|Removed |Added
CC||ru...@afternet.org
--- Comment #1 from Rubin ---
Exampl
https://bugs.exim.org/show_bug.cgi?id=1684
--- Comment #2 from Heiko Schlittermann ---
Exim should not accept messages with such oversized lines. This can be
accomplished by an ACL entry in the DATA ACL.
Once the message is accepted, Exim should do it's best to transmit it.
I'm not sure if refo
https://bugs.exim.org/show_bug.cgi?id=1684
Heiko Schlittermann changed:
What|Removed |Added
Assignee|ni...@exim.org |h...@schlittermann.de
CC|
https://bugs.exim.org/show_bug.cgi?id=1684
--- Comment #3 from Rubin ---
Note that adding:
header_line_maxsize = 998
to the main config section, will stop exim from accepting messages that cause
this.
I propose the default value of that variable should be changed to that.
--
You are receivi
https://bugs.exim.org/show_bug.cgi?id=1684
--- Comment #4 from Heiko Schlittermann ---
According to the spec, header_line_maxsize imposes a limit on the total length
of all joined lines of a specific header - so it's limit on the logical line
length.
And I'm sure you'll find legitimate logical h
https://bugs.exim.org/show_bug.cgi?id=1685
Bug ID: 1685
Summary: interface_strict
Product: Exim
Version: N/A
Hardware: All
OS: All
Status: NEW
Severity: wishlist
Priority: medium
Compone
https://bugs.exim.org/show_bug.cgi?id=1685
Alexander Maassen changed:
What|Removed |Added
Keywords||work:medium
--
You are receiving this mail
https://bugs.exim.org/show_bug.cgi?id=1685
Phil Pennock changed:
What|Removed |Added
CC||p...@exim.org
--- Comment #1 from Phil Pennock -
https://bugs.exim.org/show_bug.cgi?id=1686
Bug ID: 1686
Summary: DSNs should give the sending IP used
Product: Exim
Version: 4.86
Hardware: All
OS: All
Status: NEW
Severity: wishlist
Priority: me
https://bugs.exim.org/show_bug.cgi?id=1686
jasen Betts changed:
What|Removed |Added
CC||eximbugzi...@revmaps.no-ip.
|
https://bugs.exim.org/show_bug.cgi?id=1686
--- Comment #2 from Jeremy Harris ---
Timestamps, yeah... until the remote mail admin fails to actually give you one
to compare with.
--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https
https://bugs.exim.org/show_bug.cgi?id=1686
--- Comment #3 from jasen Betts ---
All well formed "Received:" headers have timestamps.
those should be present in the DSN. The DSN itself will have a date header too.
you can add other arbitrary headers before delivering the email, and in most
cases
https://bugs.exim.org/show_bug.cgi?id=1686
--- Comment #4 from Jeremy Harris ---
It's attempting to help the cases I see where some remote user or mail admin
does not send me the entire DSN.
It adds further information to the body of a fail DSN in the hope that some of
the information wil
https://bugs.exim.org/show_bug.cgi?id=1687
Bug ID: 1687
Summary: Option to limit the length of a physical (header?)
line
Product: Exim
Version: 4.85+ HEAD
Hardware: All
OS: All
Status: NEW
https://bugs.exim.org/show_bug.cgi?id=1687
Heiko Schlittermann changed:
What|Removed |Added
Assignee|ni...@exim.org |h...@schlittermann.de
--
You are receivin
https://bugs.exim.org/show_bug.cgi?id=1687
--- Comment #1 from Heiko Schlittermann ---
To reject messages with overlong physical header lines some data ACL condition
could help:
MAX_PHYSICAL_HEADER_LENGTH = \
${reduce\
{<\n${map{<\n$message_headers_raw}{${strlen:$item}}}
https://bugs.exim.org/show_bug.cgi?id=425
Jeremy Harris changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|REMIND
https://bugs.exim.org/show_bug.cgi?id=425
--- Comment #6 from Marc Perkel ---
Thank you for coming up with a solution.
--
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.
https://bugs.exim.org/show_bug.cgi?id=425
Git Commit changed:
What|Removed |Added
CC||g...@exim.org
--- Comment #7 from Git Commit ---
Gi
https://bugs.exim.org/show_bug.cgi?id=1688
Bug ID: 1688
Summary: overlength error message in expand.c
Product: Exim
Version: 4.84
Hardware: x86
OS: Linux
Status: NEW
Severity: bug
Priority: mediu
https://bugs.exim.org/show_bug.cgi?id=1684
Rubin changed:
What|Removed |Added
See Also||https://bugs.exim.org/show_
|
https://bugs.exim.org/show_bug.cgi?id=1687
Rubin changed:
What|Removed |Added
See Also||https://bugs.exim.org/show_
|
https://bugs.exim.org/show_bug.cgi?id=1686
Git Commit changed:
What|Removed |Added
CC||g...@exim.org
--- Comment #5 from Git Commit ---
G
https://bugs.exim.org/show_bug.cgi?id=1630
Jeremy Harris changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://bugs.exim.org/show_bug.cgi?id=728
Jeremy Harris changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://bugs.exim.org/show_bug.cgi?id=1661
Jeremy Harris changed:
What|Removed |Added
Resolution|--- |REMIND
Status|ASSIGNED
https://bugs.exim.org/show_bug.cgi?id=423
--- Comment #6 from Jeremy Harris ---
Does $acl_verify_message suffice here?
--
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.
https://bugs.exim.org/show_bug.cgi?id=264
Jeremy Harris changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
201 - 300 of 5355 matches
Mail list logo
