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_HI, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 0BBE01F560 for ; Tue, 19 Sep 2023 21:28:21 +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=Cc73qpGj; dkim-atps=neutral Received: by mail-qt1-x831.google.com with SMTP id d75a77b69052e-4142ca41b89so40597781cf.0 for ; Tue, 19 Sep 2023 14:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=google; t=1695158899; x=1695763699; 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=3hOx4s5mtgyNRMRQ378/39BDWnvJMTv85h+6C6M0LdI=; b=Cc73qpGjTfwdVBd7MZkHj6K6x2el8XSKvLvGvIkgUvFa9+V55qbMZOQA9K57EcQomk RHow+vI3EKmp3DZKV57JbygJ/8vXy4W3D/BQbEpiXOrbBIbhcURtNBb1miB4Na58BgO/ GP246iXBal+KaCLwz7W8UQDawOpFDhGKM4JMA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695158899; x=1695763699; 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=3hOx4s5mtgyNRMRQ378/39BDWnvJMTv85h+6C6M0LdI=; b=HeR6FTtPMByFxQBMUA2JymzmfBFZ9tet66+59rNjOzaP9L9L0EayxL4eJXkF3haKUx tBWSuYIz1xgV0NmmtWLDmR+OWVvu6Y3EZrhJsGfa1DWczuIiYxSJ/U8a4ffn83TpeEQ/ pOBoz0L0kpR43k0dAjnl/WVdEl4IlcqQ5yV/maKCcCP4bBbK3/TU6hdC8k7Cq7f7cZ4C ygYhKGLNzkmRGM407Mz/DavrBTM70eqoxAd2LMoEM1jFdpjZb5oQqPnAHu7YF+nryTto 2Z/d7RxnQZtlNnLBChFqSPPzjCHiB/t5Xm+zd3iZHDyKXffwWMAD2AmsdTmXP1hQIuD3 dQEg== X-Gm-Message-State: AOJu0YyGERIqmqyu38vX8N+q1oRv+fFBLjgpngbDnqE/bB/Az6eBEerp ukPBY442ZuCUZeoA6QZdE28jeVy+SJiN8s2pUck= X-Google-Smtp-Source: AGHT+IHBwcjWvz10GeYEAdtzjK8FV7xSK620RYL51fgqGh5WQbLz5BKzDH7WUmBsCKXZuM81iVY1lQ== X-Received: by 2002:ac8:7f10:0:b0:413:5f84:4244 with SMTP id f16-20020ac87f10000000b004135f844244mr817987qtk.57.1695158898741; Tue, 19 Sep 2023 14:28:18 -0700 (PDT) Received: from meerkat.local ([209.226.106.110]) by smtp.gmail.com with ESMTPSA id f13-20020ac8134d000000b00410ac0068d0sm4027432qtj.91.2023.09.19.14.28.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Sep 2023 14:28:18 -0700 (PDT) Date: Tue, 19 Sep 2023 17:28:09 -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: <20230919-buggy-unsent-411b34@meerkat> References: <20230912-impart-swinger-4c2434@meerkat> <20230912224034.M689061@dcvr> <20230913-tarot-monogamy-2f614c@meerkat> <20230914003828.M101484@dcvr> <20230915-reputable-maverick-13736d@meerkat> <20230915204110.M732304@dcvr> <20230918-barrel-unhearing-b63869@meerkat> <20230918211422.M309741@dcvr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20230918211422.M309741@dcvr> List-Id: On Mon, Sep 18, 2023 at 09:14:22PM +0000, Eric Wong wrote: > > Oh, I did notice what is probably unintentional behaviour -- passing > > ?limit=XXX affects all mailbox access, not just the initial retrieval. > > > > E.g. if I configured pop3 with ?limit=128, then leave for the weekend and > > return on Monday, I will only be able to retrieve 128 new messages, regardless > > of how many arrived over the weekend. > > > > I'm not sure if this is what was intended -- I think it makes more sense to > > have ?limit=XXX only affect the initial retrieval. In all other cases, when a > > tracking uuid cookie is present, it should return all messages regardless of > > ?limit=. > > > > Does that make sense? > > I think there should be an initial_limit parameter in addition to the > current limit. initial_limit would be more suited for cronjobs and > such running on 24/7 systems. The regular limit would be better > for systems with intermittent access and could go weeks w/o being > online (including situations where somebody restored a system from > a months/years-old backup). I'm game with that. Maybe even shorten that to l= and il=? I'm still worried about the field size limit a bit. > Not feeling well, will try to work on it once (or if) I feel better. Please take care! -K