[pfx] Re: cleanup(8): recipient_canonical can emit an over-long socketmap query with no operator guard; PERM then retried as 451
Dmytro Alieksieiev via Postfix-users <[email protected]> Thu, 16 Jul 2026 01:38:24 +0200
| Newsgroups | gmane.mail.postfix.user |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============6562628021785613244==
Content-Type: multipart/alternative;
boundary="------------7J2cTiOjZYJV9VjKFBTBTpVt"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------7J2cTiOjZYJV9VjKFBTBTpVt
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
P.S. it would be a nice addition if pcre: tables could opt into PCRE2's
UTF mode via a /u inline flag, the way native PCRE already spell it.
Today . and its quantifiers count bytes, with no way to switch to code
points, so any length- or content-rule over UTF-8 data can only reason
in bytes. For the length guard in this thread that's actually what I
want, so it's not a blocker — but for rules that genuinely need
character semantics it would help.
Worth noting the current handling makes u a natural letter to claim: an
unrecognized flag isn't rejected, it's skipped with a warning — so
/(.{300})/u today drops the whole rule (and, inside an if … ENDIF,
orphans the ENDIF) rather than erroring. That fail-open behavior is its
own small surprise, independent of the UTF question.
Regards,
Dmytro Alieksieiev
DevOps Engineer
On 16/07/2026 01:10, Dmytro Alieksieiev wrote:
> To quantify it, I placed a four-byte character (😅, F0 9F 98 85)
> across the 300-byte boundary at each alignment: three of the four
> offsets produce a query error, and only the alignment where the
> character ends exactly at byte 300 survives.
--------------7J2cTiOjZYJV9VjKFBTBTpVt
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>P.S. it would be a nice addition if pcre: tables could opt into
PCRE2's UTF mode via a /u inline flag, the way native PCRE already
spell it. Today . and its quantifiers count bytes, with no way to
switch to code points, so any length- or content-rule over UTF-8
data can only reason in bytes. For the length guard in this thread
that's actually what I want, so it's not a blocker — but for rules
that genuinely need character semantics it would help.<br>
<br>
Worth noting the current handling makes u a natural letter to
claim: an unrecognized flag isn't rejected, it's skipped with a
warning — so /(.{300})/u today drops the whole rule (and, inside
an if … ENDIF, orphans the ENDIF) rather than erroring. That
fail-open behavior is its own small surprise, independent of the
UTF question.<br>
<br>
</p>
<pre class="moz-signature" cols="72">Regards,
Dmytro Alieksieiev
DevOps Engineer</pre>
<div class="moz-cite-prefix">On 16/07/2026 01:10, Dmytro Alieksieiev
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:[email protected]">To
quantify it, I placed a four-byte character (😅, F0 9F 98 85)
across the 300-byte boundary at each alignment: three of the four
offsets produce a query error, and only the alignment where the
character ends exactly at byte 300 survives.</blockquote>
</body>
</html>
--------------7J2cTiOjZYJV9VjKFBTBTpVt--
--===============6562628021785613244==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--===============6562628021785613244==--