[exim-dev] [Bug 2735] New: Odd readsocket behavior with 4.94…

Top Page
Delete this message
Reply to this message
Author: admin
Date:  
To: exim-dev
New-Topics: [exim-dev] [Bug 2735] Odd readsocket behavior with 4.94.2
Subject: [exim-dev] [Bug 2735] New: Odd readsocket behavior with 4.94.2
https://bugs.exim.org/show_bug.cgi?id=2735

            Bug ID: 2735
           Summary: Odd readsocket behavior with 4.94.2
           Product: Exim
           Version: 4.94
          Hardware: x86
                OS: All
            Status: NEW
          Severity: bug
          Priority: medium
         Component: String expansion
          Assignee: unallocated@???
          Reporter: john@???
                CC: exim-dev@???


cPanel was caught off guard by the readsocket behavior changes #2630 introduced
to 4.94.2 for the opposite reason that bug raises...prior to 4.94.2 it was
always possible to have readsocket remove a trailing newline from simple
responses.

In 4.93, an empty {} EOL parameter removed newlines.

In 4.94, a newline {\n} EOL parameter removed newlines and an empty {} EOL
parameter retained them. (This obviously sounds backwards.)

In 4.94.2, newlines can't be removed by readsocket. They can only be changed to
a different character or left as-is. Null bytes or \N\N empty string as
replacements leave the newlines.

In our usage, the automatic removal of a trailing newline for simple yes/no
responses made it simple to feed the output into an ACL condition. After the
upgrade to 4.94.2, the trailing newlines made these conditions fail with a
truncated log message:

temporarily rejected RCPT <destination@address>: invalid "condition" value "yes

We worked around this change with ${sg{${readsocket...}}{\n}{}}}.

It would still be useful if there was some readsocket syntax available to mimic
the 4.93 {} behavior. It seems odd that even {\N\N} as the newline replacement
argument doesn't remove newlines.

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