Funny thing - as I come to memcache in scope of email length validation
I decided to check how its working too, and on practice it's also
results in endless errors and 4xx failures when doing verify or any
other operation. On verify it's critical as I was right that it creates
double-bounces to check availability, trying to save record to memcache
and fails and this will go endlessly. In most optimistic case using
memcache on verify requires limiting global length of rcpt to 248
characters if we speak about ASCII and if verify cache key using 1 char
as a prefix f.e. (v:user+tag@domain). smtpd_recipient_restrictions
should contain check_recipient_access
regexp:/etc/postfix/recipient_checks which placed before
reject_unverified_recipient to avoid such cases.
But for a proper solution I still think that memcache table module must
verify that key name not exceed 250 bytes and if it is - throw perm
error without doing any actually queries to memcache instead of looping
in tempfail loop.
About my first issue with localpart length after checking logs for a
long period of time I see that there could be valid cases when localpart
is longer then in RFC and contain up to 120-130 chars, I end I decided
that limit localpart with regex up to 200 chars is big enough to not any
user complains and at same time not face any issues with SRS or whatever.
Regards,
Dmytro Alieksieiev
DevOps Engineer
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
