[Bug 1905962] [NEW] local-part of VERP sender may exceed 64 octet

Public bug reported: If the recipient mail address is too long, local part of VERP sender may exceed 64 octet, the maximum total length of local-part provided by RFC 5321. I think it should be checked in Mailman/Hander/SMTPDirect.py and fall back to original envsender. e.g. (not tested yet) --- Mailman/Handlers/SMTPDirect.py.org 2018-06-27 17:19:15.000000000 +0900 +++ Mailman/Handlers/SMTPDirect.py 2020-11-27 22:06:44.047857879 +0900 @@ -338,7 +338,14 @@ def verpdeliver(mlist, msg, msgdata, env 'mailbox': rmailbox, 'host' : DOT.join(rdomain), } - envsender = '%s@%s' % ((mm_cfg.VERP_FORMAT % d), DOT.join(bdomain)) + envlocal = (mm_cfg.VERP_FORMAT % d) + if len(envlocal) > 64: + syslog('smtp', + 'local part of VERP address exceeds 64 octet.' + 'fall back to original envsender: %s', + envlocal) + else: + envsender = '%s@%s' % (envlocal, DOT.join(bdomain)) if mlist.personalize == 2: # When fully personalizing, we want the To address to point to the # recipient, not to the mailing list ** Affects: mailman Importance: Undecided Status: New ** Branch linked: lp:mailman/2.1 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1905962 Title: local-part of VERP sender may exceed 64 octet To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1905962/+subscriptions

While it is true that https://www.rfc- editor.org/rfc/rfc5321.html#section-4.5.3.1.1 says: The maximum total length of a user name or other local-part is 64 octets. https://www.rfc-editor.org/rfc/rfc5321.html#section-4.5.3.1 says: However, some Internet mail constructs such as encoded X.400 addresses (RFC 2156 [35]) will often require larger objects. Clients MAY attempt to transmit these, but MUST be prepared for a server to reject them if they cannot be handled by it. To the maximum extent possible, implementation techniques that impose no limits on the length of these objects should be used. As I read this, It is OK for an envelope sender local part to be longer than 64 octets as long as we are prepared for a reject, and MTAs should if possible be implemented to accept these. Also, I tested with Postfix and there was no problem sending my test which had an envelope sender local part of 104 octets. Thus, I don't want to disable VERP arbitrarily just because the VERPed local part exceeds 64 octets. ** Changed in: mailman Importance: Undecided => Low ** Changed in: mailman Status: New => Won't Fix -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1905962 Title: local-part of VERP sender may exceed 64 octet To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1905962/+subscriptions

Thank you for the evaluation of this issue. I make sense. However, FYI, here is an example that mail gateway to use this limitation. (I've only heard, not tested by myself actually). https://kc.mcafee.com/corporate/index?page=content&id=KB89997&locale=en_US -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1905962 Title: local-part of VERP sender may exceed 64 octet To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1905962/+subscriptions

I've never seen a report of mail being rejected for this reason, and I don't want to break VERP for posters with long addresses based on a theoretical possibility. If and when I see reports of SMTP MAIL FROM: commands with long local parts being rejected, I may revisit this. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1905962 Title: local-part of VERP sender may exceed 64 octet To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1905962/+subscriptions
participants (2)
-
Mark Sapiro
-
Yasuhito FUTATSUKI at POEM