https://bugs.exim.org/show_bug.cgi?id=2622
Bug ID: 2622
Summary: bounce_return_linesize_limit not honoured for headers
Product: Exim
Version: N/A
Hardware: x86
OS: Windows
Status: NEW
Severity: bug
Priority: medium
Component: Delivery in general
Assignee: unallocated@exim.org
Reporter: david-exim-bugs@infotrek.co.uk
CC: exim-dev@exim.org
Hi,
bounce_return_linesize_limit does not appear to be honoured for headers, only
the body.
In our case this means that with a remote_smtp transport like the following (as
used in e.g. Debian):
remote_smtp:
driver = smtp
message_size_limit = ${if > {$max_received_linelength}{998} {1}{0}}
If a message is received with a header line longer than 998 characters, the
following log message is written:
** xx@xx.com F=<> R=dnslookup T=remote_smtp: message is too big (transport
limit = 1)
and a bounce message is generated. However the headers are copied directly to
the bounce message, including the line that was too long, meaning the bounce
also cannot be delivered and gets frozen.
Bounce settings are all at defaults:
# exim -bP | grep bounce
bounce_message_file =
bounce_message_text =
bounce_return_body
bounce_return_linesize_limit = 998
bounce_return_message
bounce_return_size_limit = 100K
bounce_sender_authentication =
ignore_bounce_errors_after = 2d
I think in my case I am going to have to remove the transport limit as there is
nothing we can do about Outlook generating 1021-octet long References header
lines, but I thought I would report the bug as it seems odd that someone has
considered this RFC limit and created the bounce_return_linesize_limit option
to prevent invalid bounces being generated, but then didn't apply it to the
headers, so an invalid bounce can still happen.
It looks like this may need to be fixed in both moan.c and deliver.c, I'm not
familiar with the code but it looks like in my case the text/rfc822-headers
MIME part is being created by deliver.c.
(I would suggest that if such an invalid header is found, only the affected
header line is truncated in the bounce - not the entire header set removed,
which would make troubleshooting harder).
Regards,
David
--
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/ ##
Bug ID: 2622
Summary: bounce_return_linesize_limit not honoured for headers
Product: Exim
Version: N/A
Hardware: x86
OS: Windows
Status: NEW
Severity: bug
Priority: medium
Component: Delivery in general
Assignee: unallocated@exim.org
Reporter: david-exim-bugs@infotrek.co.uk
CC: exim-dev@exim.org
Hi,
bounce_return_linesize_limit does not appear to be honoured for headers, only
the body.
In our case this means that with a remote_smtp transport like the following (as
used in e.g. Debian):
remote_smtp:
driver = smtp
message_size_limit = ${if > {$max_received_linelength}{998} {1}{0}}
If a message is received with a header line longer than 998 characters, the
following log message is written:
** xx@xx.com F=<> R=dnslookup T=remote_smtp: message is too big (transport
limit = 1)
and a bounce message is generated. However the headers are copied directly to
the bounce message, including the line that was too long, meaning the bounce
also cannot be delivered and gets frozen.
Bounce settings are all at defaults:
# exim -bP | grep bounce
bounce_message_file =
bounce_message_text =
bounce_return_body
bounce_return_linesize_limit = 998
bounce_return_message
bounce_return_size_limit = 100K
bounce_sender_authentication =
ignore_bounce_errors_after = 2d
I think in my case I am going to have to remove the transport limit as there is
nothing we can do about Outlook generating 1021-octet long References header
lines, but I thought I would report the bug as it seems odd that someone has
considered this RFC limit and created the bounce_return_linesize_limit option
to prevent invalid bounces being generated, but then didn't apply it to the
headers, so an invalid bounce can still happen.
It looks like this may need to be fixed in both moan.c and deliver.c, I'm not
familiar with the code but it looks like in my case the text/rfc822-headers
MIME part is being created by deliver.c.
(I would suggest that if such an invalid header is found, only the affected
header line is truncated in the bounce - not the entire header set removed,
which would make troubleshooting harder).
Regards,
David
--
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/ ##