On 19/04/2025 13:09, Viktor Dukhovni via Postfix-users wrote:
On 19/04/2025 13:09, Viktor Dukhovni via Postfix-users wrote: To rewrite envelope recipients, use "virtual_aliases", not "recipient_canonical_maps".
Hi Viktor, sorry, but for me this not solution. The whole point of SRS is to utilize own domain in envelope as result - own SPF and be on track with bounces, if I would not need this - I would not use SRS.
Also discussion moved from "Localpart length validation" to SRS, but SRS itself or it's configuration was not my question in this thread - it works as intended. SRS just picked this input validation issue in Postfix up from the bottom for me, not more. ATM I don't see it in Postfix at this part of logic which can be abused in other places too, not just with SRS. First comes to mind is MemCache and key name limit of 250 bytes.
Limit of 250 bytes in pure ASCII is only 250 chars which less then email total limit by RFC. If we would take UTF8 here it would be in 4x less - just 50 chars potentially (1 UTF8 symbol can take from 1 to 4 bytes).
Postfix can now receive endlessly big RCTP which he will /always/ try to get from or put into MemCache, always will face timeout error and will never able to fit key into MemCache. It can be avoided by checking if key name is not greater 250 bytes, and throwing a warning without doing any request to memache, but it will not solve fact that logic for caching of such key will not work. This can be used to abuse systems with double-bounce on verify process for example, potentially exhausting not only edge Postfix system resources, but also system which sits behind it as well. Even if try apply strict limits from based on RFC - such abuse still can have place with UTF8 localparts, and SMTPUTF8 is Postfix defaults (which highly recommended to not be disabled based on my XP).
Key names hashing in MemCache table could solve this issue with accepting small risk of collisions, but unfortunately this is not supported in Postfix AFAIK.
There is no alternatives to MemCache for shared network caching except Redis which would remove such limits, but Redis table module of Postfix not part of most up-to-date OS repo's based on my observation, I assume it's abandoned and not getting updates, right?
P.s. client side sharding of MemCache which is a common thing for memcahce horizontal scaling also not supported by Postfix memcache module, usage of mcrouter is possible, but for most cases having client side sharding would just drop the need of mcrouter, which known to have memory leaks issues that will be never solved, as it not maintained anymore - which also brings up security risks unfortunately.
P.p.s. disabling SMTPUTF8 when Postfix used with PGSQL tables will lead to another issue - postfix allow Latin-1 in localpart of sender or rcpt and after getting such it using wrong encoding to query Postgres which lead to strong-long-term DoS, which not only fail one current connection - it hanging up DB queries for other connections inside this particular worker too.
Regards, Dmytro Alieksieiev DevOps Engineer
_______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
