Confirmation email addresses may be over the 64-character limit suggested in RFC 2821

[raviprak]

Hi,

Thanks for the awesome software! I hope you folks keep up the great work!

I recently encountered this problem when I was trying to subscribe to a mailing list. I wasn't able to send the confirmation reply because Yahoo! Mail had strictly imposed the 64-character limit suggested in RFC 2821 (Bruce pointed this out).

4.5.3.1 Size limits and minimums

There are several objects that have required minimum/maximum sizes.
Every implementation MUST be able to receive objects of at least
these sizes. Objects larger than these sizes SHOULD be avoided when
possible. However, some Internet mail constructs such as encoded
X.400 addresses [16] 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 which impose no limits on the
length of these objects should be used.

local-part
The maximum total length of a user name or other local-part is 64
characters.

Although Yahoo! Mail will fix this issue, I wish ezmlm wouldn't have confirmation emails with the local part > 64-chars. Mail relays are allowed to legally drop such emails, and in that case, I would not be able to subscribe :(

[gurubert]

I have come across mail clients that plainly reject to reply to ezmlm confirmation messages because the local part is too long.

As this affects the very core of ezmlm can this ever be fixed?

[bruceg]

I'm not sure how I can guarantee an email address shorter than 64 characters, given that the prefix is under the control of the list creator. Consider if the list creator were to set up a crazy list with a 60 character "local" portion.

However, it is probably worth exploring reducing the confirmation email address suffix to just the cookie (instead of timestamp+cookie+address) and writing the rest of the details into a new confirm database, as is used for moderation and such.