On Sun, 5 Nov 2023, Exim Bugzilla via Exim-dev wrote:
> https://bugs.exim.org/show_bug.cgi?id=3037
>
> --- Comment #6 from Zakaria <hi@???> ---
> ???? 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
andrew@???
--
## subscription configuration (requires account):
##
https://lists.exim.org/mailman3/postorius/lists/exim-dev.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-dev-unsubscribe@???
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://wiki.exim.org/
