From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <e@80x24.org>
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN:  
X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,
	T_SCC_BODY_TEXT_LINE shortcircuit=no autolearn=ham autolearn_force=no
	version=3.4.2
Received: from localhost (dcvr.yhbt.net [127.0.0.1])
	by dcvr.yhbt.net (Postfix) with ESMTP id EF3FC1F4D7;
	Fri, 27 May 2022 10:53:02 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=80x24.org;
	s=selector1; t=1653648783;
	bh=fn7Z56jYd7IZ9Rkab7PREESET7HEvVNZEaJ3O/tIPjo=;
	h=Date:From:To:Subject:From;
	b=roSHqGoSn4R6Nadzx26NKKbrqg3MOVdKAN4z70JN+R0u5vGYRJFukJPy66jDYC7HX
	 VAGL0X0VlZWk+uiIPNTOcTnuP+W8OcaZzNlnFDMWSNuNqKPRgo5kqlQDsYMkxrUpCY
	 ikdgHBgeY9kkJFN6OiNZdABqUPnrUp3DnzJ0nazs=
Date: Fri, 27 May 2022 10:53:02 +0000
From: Eric Wong <e@80x24.org>
To: meta@public-inbox.org
Subject: APOP-only POP3 clients?
Message-ID: <20220527105302.M842323@dcvr>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
List-Id: <meta.public-inbox.org>

cf. https://tools.ietf.org/html/rfc1939

Well, POP3 clients being webmail services which import from
POP3, mainly...  Just wondering, are there POP3 clients which do
NOT support USER/PASS and enforce the use of APOP for
authentication?

Background:  POP3 is one mailbox per-user, so we'll rely on
the username being $NEWSGROUP.$SLICE (same idea as IMAP, to
limit mailboxes to 50k to avoid problems).

POP3 clients can be distinguished by PASS (password cookie), to
keep track of per-client message deletions.  The output of
`uuidgen` or `dbus-uuidgen` is a sufficiently-unique cookie for
distinguishing clients from each other.

Initially, that would be:

	username: $NEWSGROUP.$SLICE
	password: $UUID

for POP3 USER/PASS support.

However, supporting APOP that way would inflict a usability
problem for all users since the password is sent as a digest and
the actual password is never sent unencrypted.  Our POP3 server
would have no clue how to match a digest to a password since
many clients will be sharing the username.

So far, the solution I come up with is to require another UUID
to be part of the username, too:

	username: $UUID_1@$NEWSGROUP.$SLICE
	password: $UUID_2

Which may be an extremely long username...  Now I'm thinking
it's safe for UUID_1 and UUID_2 to be the same, to save storage
space on the server and to save users from dealing with
excessively long, compression-unfriendly field entries. So,
this:
	username: $UUID@$NEWSGROUP.$SLICE
	password: $UUID