Mailing List Archive

https://bugs.exim.org/show_bug.cgi?id=3037

--- Comment #6 from Zakaria <hi@zakaria.website> ---
???? 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.

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.

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

--
## 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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

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@zakaria.website> ---
> ???? 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@aitchison.me.uk

--
## 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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 05/11/2023 18:35, Exim Bugzilla via Exim-dev wrote:
> not sure why when it
> reaches transport_write_block it fails and throws broken pipe

It gets a "broken pipe" error because when it tries to write
down the pipe to the filter, the filter has closed its end
of the pipe. Because the filter is written wrongly, in not actually using
the data from the pipe as its input - as I've been trying to tell
you, and you have been ignoring. It is totally irrelevant that it
sometimes works. There's an interlock, a contract, there so that it works
every time. Stop trying to ignore that, if you want it to work.
--
Cheers,
Jeremy


--
## 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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/