Konstantin Ryabitsev <konstan...@linuxfoundation.org> wrote: > On Thu, Sep 02, 2021 at 09:58:50PM +0000, Eric Wong wrote: > > # the destination, could be Maildir > > MFOLDER=imaps://u...@example.com/INBOX.landlock > > > > # initial search: > > lei q -o $MFOLDER -t -I https://lore.kernel.org/all/ --stdin <<EOF > > If I had a local mirror with extindex and I wanted to do the same thing, would > I just modify the -I flag to point at the extindex location?
Yes. For local stuff that's permanently mounted, I tend to do "lei add-external $PATHNAME" so it's included by default. > One of the > options I want to investigate is making IMAP/POP3 accessible individual > mailboxes fed by lei, such that a new subsystem maintainer could have a > ready-made mailbox available to them without needing to subscribe/unsubscribe > to a bunch of mailing lists. (This would be different from read-only imap > mailboxes offered by public-inbox-imapd, since we'll be tracking individual > message state. The POP3 bit would allow them to plug it into something like > Gmail which allows sucking down remote POPs.) I think using the "-o v2:..." option for now would be the way to go for making a v2 inbox available via -imapd (and it'll get JMAP/POP3 support in the future). We don't have POP3 support in client nor server form, yet. Not sure how account/state management would work, nor how to prioritize it vs JMAP support. I'm thinking POP3 takes priority since there's more clients for it... Existing POP3 servers would work, too; since lei can output to Maildir/mbox* which can work with them. On a side note, I'm not aware of IMAP sync tools accounting for read-only IMAP servers well, since they attempt bidirectional sync. "lei import" seems alright in that regard, treating IMAP the same way it will (eventually) treat POP3. -- unsubscribe: one-click, see List-Unsubscribe header archive: https://public-inbox.org/meta/
