[exim-dev] [Bug 1684] Malformed headers which exceed length …

Página Inicial
Delete this message
Reply to this message
Autor: admin
Data:  
Para: exim-dev
Assunto: [exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers
https://bugs.exim.org/show_bug.cgi?id=1684

Patrick Cernko <pcernko@???> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pcernko@???


--- Comment #15 from Patrick Cernko <pcernko@???> ---
I recently stumbled upon this change. I had a scenario, where my exim generated
a bounce based on a very long SMTP error message and failed to deliver it via
the local LMTP transport because the message *body* (generated by exim itself)
contained a line longer than message_linelength_limit. The result was a frozen
message. This caused a freeze_tell event but the resulting generated message
also had the message_linelength_limit issue (AFAIK). So in the end I had two
frozen messages in the queue but no message to postmaster about that. I only
stumbled upon the frozen messages by accident.
Unfortunately I removed the frozen message from the queue and was not able to
reproduce the behavior later to provide more a more detailed description.

I would like to request two things:
1. Please check all code sections generating (error) messages to not generate
lines longer than message_linelength_limit.
2. I cannot find any documentation about the changed default for
message_linelength_limit in the docs. Only thing I found was the documentation
about the new option with a different default as before. The sections seems to
be introduced in the 4.95 release but the release notes do not mention anything
about the new setting. As the setting definitely changes the behavior of
existing installations, it really should be worth mentioning.

Besides my requests, I really appreciate that new feature!

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