Re: [RFC] pop3: support `?limit=$NUM' parameter in mailbox name

[Eric Wong <e@80x24.org>]

Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> On Wed, Sep 13, 2023 at 06:20:40AM +0000, Eric Wong wrote:
> > Eric Wong <e@80x24.org> wrote:
> > > I'm not sure if `?' or `=' are allowed characters in POP3
> > > mailbox names.  In fact, I can't find any information on
> > > valid characters allowed in RFC 1081 nor RFC 1939.
> 
> It's a username, though, not mailbox name? There's no restriction on the
> characters or length of the username, though I'm guessing some UI clients may
> have their own limits regarding the length of the username field.

username == mailbox name as far as POP3 goes.

> > Of course, the parameters and all manner of special characters
> > can also be placed the password, so `anonymous?limit=1000'.
> > 
> > But somehow putting parameters in the "password" (even a
> > well-known and obvious one) feels wrong.
> 
> What if we move the uuid into the password field -- it seems it belongs there
> anyway, as it's tied to the user cookie.

I've thought about that, too; but it can get tricky since passwords
aren't visible in most UIs.  I've also seen some UIs (not POP3) which
forbid copy+paste in password fields.

Furthermore, if a user wants to migrate to a different POP3 client;
carrying their UUID with them is easier when it's readable in the
username.  (I'm assuming users won't be bothered backup their UUID
anywhere)

> username: newsgroup.name?params
> password: $(uuidgen)
> 
> So, in my example it becomes:
> 
> username: org.kernel.vger.git?limit=1000
> password: 288e5e35-1a35-46ef-b3d5-6d94c20aeab8
> 
> This could be backward-compatible with the current implementation -- if there
> is an @ in the username field, then the cookie is based on what's preceding
> it. If there's none, then we use the password field (unless it's "anonymous").
> 
> This way we're less likely to run into any problems with username length
> limitations set by MUAs.

Right, backwards compatibility isn't a problem either way.

I'm open to supporting both ways; but I'm also not inclined to
do so unless there's evidence of real-world POP3 clients being
unable to handle the user names.

Documenting both ways can be overwhelming to users.

Thanks.