From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-3.6 required=3.0 tests=AWL,BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 3C5CF1F55F for ; Wed, 13 Sep 2023 15:33:42 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=google header.b=BQvCui5a; dkim-atps=neutral Received: by mail-qk1-x731.google.com with SMTP id af79cd13be357-7708bfce474so414985785a.3 for ; Wed, 13 Sep 2023 08:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=google; t=1694619221; x=1695224021; darn=public-inbox.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=LcGrFBSCVyAPMJNivuAHTFUvKtozhRmPAmLXl3rALaY=; b=BQvCui5alfH+wPfs8rsti/9Gwveg2nbwxMIKx3+OnBYqF3Gt6aKLAGZ5LxmJP5K2lU a9cMlcbmN5YEEEZVc6l0kTMfdTYEHpTuH9X+/2bRMOFESQLqibyZSG1Y1J8CKJ+j/oeu iF7+6ZBEFftPNa/rHaa0Vai86p+953RQlcUvg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694619221; x=1695224021; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=LcGrFBSCVyAPMJNivuAHTFUvKtozhRmPAmLXl3rALaY=; b=cSXs8iNd8OJND8RwrODbMZiog8gy+O8T3pdHmc8xp40Naxwo4SttpRNVKOZaeoDlnJ 2kJFP+dW3bi6t1Zg3UJXSfvBKxml2l29JHgaFCa808E1zFcjPOA4i/vwTXqy44oTNLxv kGTRW3XUBBfI8sPwvJnZxcBOoD2aRN3A0yVKjEpd6BJPdMdsWctw/qZt+8P1CHlVHhA3 2aLJ3e1044FNWzkAu034kxZGSh0PylZ6TRC/oR6ufnlrwWHFazp6ByU5PJNBnHBcgWeC QwHzxfgWmdV71eU/TxlawtchAJqylnYSq+mo2dokXnejtJyHXPG9i+7EzislFLTBMKGL yIfA== X-Gm-Message-State: AOJu0YyvJ1tbdvcWOB0SWHdIspPcIKbxHkrgldWfYxkRmb+U3n/3PX0c FjZwFUwsqabMxzen8ciCD7kcREn1JJBbMe6WRvs= X-Google-Smtp-Source: AGHT+IGZX38R9d2Et5bb+F8GemvtIQCUCzVLXuoGPs47elzEyGHMoaJNtTDoTqN+DrSGvDrUIQmSBg== X-Received: by 2002:a05:620a:bc9:b0:771:31c:adcb with SMTP id s9-20020a05620a0bc900b00771031cadcbmr3010361qki.7.1694619220965; Wed, 13 Sep 2023 08:33:40 -0700 (PDT) Received: from meerkat.local ([209.226.106.110]) by smtp.gmail.com with ESMTPSA id a13-20020a05620a02ed00b0076cda7eab11sm372944qko.133.2023.09.13.08.33.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Sep 2023 08:33:40 -0700 (PDT) Date: Wed, 13 Sep 2023 11:33:31 -0400 From: Konstantin Ryabitsev To: Eric Wong Cc: meta@public-inbox.org Subject: Re: [RFC] pop3: support `?limit=$NUM' parameter in mailbox name Message-ID: <20230913-sizzling-uncoated-629002@meerkat> References: <20230912-impart-swinger-4c2434@meerkat> <20230912224034.M689061@dcvr> <20230913062040.M617670@dcvr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20230913062040.M617670@dcvr> List-Id: On Wed, Sep 13, 2023 at 06:20:40AM +0000, Eric Wong wrote: > Eric Wong 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. > 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. 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. -K