[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 14:28:23 +0200
| Newsgroups | gmane.mail.postfix.user |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============3432507008548719349==
Content-Type: multipart/alternative;
boundary="------------7m06O3Zulix0Ci0aqxyMBiK0"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------7m06O3Zulix0Ci0aqxyMBiK0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Wietse,
Btw I think there is an issue in how tok822 treats folding - if my tests are correct - Postfix do not follow RFC 5322 header folding, specifically: part which requires continuation lines to start with whitespace.
This what creates a significant difference between what Rspamd see and what Postfix see.
Can you please look into that?
Regards,
Dmytro Alieksieiev
DevOps Engineer
On 16/07/2026 13:49, Wietse Venema via Postfix-users wrote:
> Dmytro Alieksieiev:
>> The negative pattern
>> if !/(.{300})/
>> /(.+)/ $1
>> ENDIF
>>
>> never rewrites the key. It returns the whole, unmodified string when it
>> is under the limit, and no result for anything at or above 300 bytes, at
>> which point pipemap short-circuits and the socketmap is never queried.
>> Because the key is never truncated, there is no encoding hazard
>> regardless of where a multibyte character sits. Side note: I changed
>> (.*) to (.+) as empty string result is not allowed in maps.
> Good. It would make sense to implement a socketmap_max_query_size
> feature that forces a "not found" result for long queries. This can
> be a Postfix 3.12 feature.
>
> An over-long envelope address can already be blocked with a
> check_sender_access or check_recipient_access PCRE pattern:
>
> /.{300}/ REJECT address too long
>
> Adding support for signaling a new type of database lookup error
> remains future work.
>
> Wietse
> _______________________________________________
> Postfix-users mailing list [email protected]
> To unsubscribe send an email [email protected]
--------------7m06O3Zulix0Ci0aqxyMBiK0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<pre wrap="" class="moz-quote-pre">Wietse,
Btw I think there is an issue in how tok822 treats folding - if my tests are correct - Postfix do not follow RFC 5322 header folding, specifically: part which requires continuation lines to start with whitespace.
This what creates a significant difference between what Rspamd see and what Postfix see.</pre>
<p>Can you please look into that?</p>
<pre class="moz-signature" cols="72">Regards,
Dmytro Alieksieiev
DevOps Engineer</pre>
<div class="moz-cite-prefix">On 16/07/2026 13:49, Wietse Venema via
Postfix-users wrote:<br>
</div>
<blockquote type="cite"
cite="mid:[email protected]">
<pre wrap="" class="moz-quote-pre">Dmytro Alieksieiev:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">The negative pattern
if !/(.{300})/
/(.+)/ $1
ENDIF
never rewrites the key. It returns the whole, unmodified string when it
is under the limit, and no result for anything at or above 300 bytes, at
which point pipemap short-circuits and the socketmap is never queried.
Because the key is never truncated, there is no encoding hazard
regardless of where a multibyte character sits. Side note: I changed
(.*) to (.+) as empty string result is not allowed in maps.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
Good. It would make sense to implement a socketmap_max_query_size
feature that forces a "not found" result for long queries. This can
be a Postfix 3.12 feature.
An over-long envelope address can already be blocked with a
check_sender_access or check_recipient_access PCRE pattern:
/.{300}/ REJECT address too long
Adding support for signaling a new type of database lookup error
remains future work.
Wietse
_______________________________________________
Postfix-users mailing list -- <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
To unsubscribe send an email to <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
</pre>
</blockquote>
</body>
</html>
--------------7m06O3Zulix0Ci0aqxyMBiK0--
--===============3432507008548719349==
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]
--===============3432507008548719349==--