Confirmation message response problem

[Melissa]

Originally Posted by Erica C.

So should I just manually add the address again?

Yep, that's fine. Just keep your documentation showing that they intended to subscribe.

Originally Posted by Erica C.

And suggest that the subscriber complain to Yahoo?

Yes, please. They will likely have more clout with Yahoo as a user.

[Erica C.]

I've saved the documentation. Maybe I should create a Yahoo problems folder to go next to the AOL problems folder? (sigh)

I did suggest she contact Yahoo.

Thanks for your help.

Erica

[Bob]

Hi again Erica and other interested readers

We received an inquiry about this same problem from another site owner last night. In the course of reply to that ticket it struck me, again, how odd it as that the AT&T (Powered by Yahoo) email portal did not experience this issue while the main Yahoo email portal did...

I did some googling and found some related complaints for Yahoo's email portal where users were unable to reply to messages received where the Reply-To address had somewhat similar form as the ezmlm-idx structured reply email addresses.

In my searching I found one mention of changing the "View" you use in Yahoo's email portal seemed to help in these cases...

So off to my Yahoo email portal I went

Sure enough, when my Yahoo email portal was set to "Page by Page (Classic)" view I received an Invalid Email error when trying to reply to a ezmlm-idx confirmation message.

However when I changed the View to "In scrolling List (Show preview)" I was able to reply to the confirmation email and I received confirmation that the reply was received by the list.

So if you receive a complaint from a visitor they were unable to confirm a subscription to your mailing list and they use Yahoo you can suggest changing their view in their Yahoo email portal.
http://help.yahoo.com/l/us/yahoo/mai...ttings-33.html

Of course it is inexcusable for a Giant such as Yahoo to allow such a bug to exist for at least 2 months, most likely much longer... But unfortunately it doesn't surprise me... Maybe they were not aware? right...

-Bob

[raviprak]

Hi folks,

Terribly sorry about this problem. I'm a Yahoo! and although I am not in the team managing Y! Mail, I've filed a bug with the team which is. They are an awesome team, and hopefully this problem will be resolved soon!

Sorry about this again!

[raviprak]

Turns out the email address should be invalid after all. The RFC states that the local-part of the email address should have at most 64 characters and the one ezmlm sent out had more than that. I'm trying to file a bug with ezmlm now but their bug-tracking site is 404

Anyway, the awesome Y! mail team I was telling you about has already patched this. And it should reach our customers very soon! Within 2 weeks!

[Bruce]

Originally Posted by raviprak

Turns out the email address should be invalid after all. The RFC states that the local-part of the email address should have at most 64 characters and the one ezmlm sent out had more than that.

The RFC you appear to be referencing is for SMTP (RFC 2821), while the problem presented itself only with the webmail system. I have not heard of the Yahoo SMTP servers themselves presenting any problems with these addresses.

Further, the text of the RFC is a little less strict and never explicitly says such addresses are invalid:

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.

In shorter language, you may send longer addresses, but should not, because some servers may (legally) reject them. Everything shorter must be accepted. On the other hand, server developers should avoid such limits wherever possible.

I'm trying to file a bug with ezmlm now but their bug-tracking site is 404

Yes, that is a rather frustrating problem that happened earlier this year. The registration for ezmlm.org, the main ezmlm site, expired. I am the current maintainer, and have contacts with the domain's technical contact, but neither of us owned the domain. When it expired, we were eventually able to make contact with the domain owner (who long since moved on to other enterprises), but didn't manage to get the domain ownership issues dealt with before somebody else snapped up the domain.

[Bruce]

Originally Posted by raviprak

I'm trying to file a bug with ezmlm now but their bug-tracking site is 404

Since the web site is down, I would suggest sending a suggestion to the ezmlm mailing list at ezmlm@lists.untroubled.org

[raviprak]

Hi Bruce!

Thanks a lot for your reply! I contacted the ezmlm mailing list and Lars Kruse replied very promptly. He's fixed the broken link. I'm not sure if it was you and Bruce is just another name But thanks a ton!

For now Yahoo! Mail will allow sending the emails, and we plan to pop up a message saying a relay may (legally) drop the message, so its delivery might not be guaranteed.

Keep up the good work with ezmlm Thanks for the great software

[raviprak]

Hi Bruce,

I read through Lars's mail more carefully It is probably your github https://github.com/bruceg/ezmlm-idx that can solve this. Although Yahoo! Mail will soon allow these emails with addresses longer than 64 characters to be sent, I wish ezmlm would not have confirmation emails longer than that.

I love ezmlm. Its super-simple and very fast and does what it needs to do very well. Do you think we could have it not send out confirmation email addresses which might be dropped via any of the relays?

[Bruce]

Originally Posted by raviprak

I contacted the ezmlm mailing list and Lars Kruse replied very promptly.

That's curious. I'm subscribed to both ezmlm mailing lists that I am aware of (I just confirmed both), and saw nothing on either.

He's fixed the broken link.

Since I did not see the discussion, which site are you referring to?

I'm not sure if it was you and Bruce is just another name

No, Lars and I are definitely two different people.

Although Yahoo! Mail will soon allow these emails with addresses longer than 64 characters to be sent

To be clear, and probably to repeat myself, Yahoo's SMTP servers already allow these emails to be received, and clients not using the Yahoo! Mail webmail system have been able to subscribe

I wish ezmlm would not have confirmation emails longer than that.

It's not exactly as simple as just turning on a switch that makes the addresses shorter. As it stands now, the subscribe process is purely stateless. That is, all that the mailing list needs to authenticate the subscription confirmation is contained in that address. Nothing is stored on the server. In order to shorten the confirmation address in any way, some state would need to be saved for each subscription request. This is a significant architectural change to the whole process.

There's an additional gotcha, albeit a minor one. Since the prefix (aka list name) is not under ezmlm's control, adding the "-sc.TOKEN" suffix as an abbreviated confirmation code may still push the local portion longer than 64 characters. Now, I grant you that few people are going to name their mailing lists averylonglistnamethatshouldbehungout...wn@example.com but it is still impossible to guarantee that ezmlm will never extend the local portion past 64 characters.