On Sun, 5 Nov 2023, Exim Bugzilla via Exim-dev wrote:
https://bugs.exim.org/show_bug.cgi?id=3037
--- Comment #6 from Zakaria <[email protected]> ---
???? this comment came to me as a surprise just now. I was trying to get
transport filter working, since I opened this ticket but so far to no avail I
found way.
I'm just going to input my findings in case you want to consider it might be a
bug actually regardless to one aspect in my usage to the transport filter and
save me couple of more nightmares before I might give up ????.
I used log_write and debugged the lines of transport.c to this bit where as
soon as it reaches EXIM throws broken pipe. It seems the problem happens in
write_chunk after writing headers and starting with body.
if (!write_chunk(tctx, deliver_in_buffer, len)){
log_write(0, LOG_MAIN, "size %d", size);
return FALSE;
}
I printed the content of the chunk in write_chunk and I noticed it contains the
body and the attachment base64 and it looks fine and not sure why when it
reaches transport_write_block it fails and throws broken pipe, I wonder if
there is anything I can do in transport_write_block_fd?
BOOL
write_chunk(transport_ctx * tctx, uschar *chunk, int len)
{
uschar *start = chunk;
uschar *end = chunk + len;
int mlen = DELIVER_OUT_BUFFER_SIZE - nl_escape_length - 2;
........
if (!transport_write_block(tctx, deliver_out_buffer, len, FALSE)){
log_write(0, LOG_MAIN, "ahoj %.*s %d", 3, chunk, sizeof(chunk));
return FALSE;
}
chunk_ptr = deliver_out_buffer;
Also, I noticed the DELIVER_OUT_BUFFER_SIZE and DELIVER_IN_BUFFER_SIZE limits
8190 and increased and didn't make difference and I noticed broken pipe happens
when size var in internal_transport_write_message reaches -65537 which is kind
of recalls to me linux -65535 common limits value. I have increased all the
ulimits variables in service and sysctl and it didn't make difference.
Hmm. -65537 is 0xFFFEFFFF - all bits but one set.
Looking at internal_transport_write_message am a little concerned at
nested variables called "size" declared as int at line 930
and unsigned long at line 1138.
The inner block is controlled by
if (!(tctx->options & topt_no_body))
*If* this block is active, I am also concerned about the read which
is passed and returns "len" which is an int, but read takes and returns a
ssize_t which is likely bigger than an int.
Last but not least point, I sent messages that's going through transport
filter, literally without and with modifying it, if the message has attachment
over 45kb, totalling above 67KB, it throws broken pipe, otherwise it passes.
This proves to me there is a bug regardless to the usage of transport filter
whether appropriate or inappropriate.
I hope to have any helpful feedback which guides me.
Anyways, thanks for your all efforts.
--
Andrew C. Aitchison Kendal, UK
[email protected]
--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-dev.lists.exim.org/
## unsubscribe (doesn't require an account):
## [email protected]
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
