workflows.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* lore+lei: part 2, now with IMAP
@ 2021-11-12 19:13 Konstantin Ryabitsev
  2021-11-15 18:34 ` Gmail (was: Re: lore+lei: part 2, now with IMAP) Geert Uytterhoeven
  2021-11-22 14:37 ` lore+lei: part 2, now with IMAP Jani Nikula
  0 siblings, 2 replies; 14+ messages in thread
From: Konstantin Ryabitsev @ 2021-11-12 19:13 UTC (permalink / raw)
  To: workflows

Hello:

Continuing on my previous email about setting up lei with lore.kernel.org,
here's the next installment. As with the previous part, this will be posted on
people.kernel.org as well as here.

# lore+lei: part 2, now with IMAP

This is the second installment in the series where we're looking at using the
public-inbox `lei` tool for interacting with remote mailing list archives such
as lore.kernel.org. In the previous article we looked at delivering your
search results locally, and today let's look at doing the same, but with
remote IMAP folders.

For our example query today, we'll do some stargazing. The following will show
us all mail sent by Linus Torvalds:

    f:torvalds AND rt:1.month.ago..

I'm mostly using it because it's short, but you may want to use something
similar if you have co-maintainer duties and want to automatically receive a
copy of all mail sent by your fellow subsystem maintainers.

## Note on saving credentials

When accessing IMAP folders, `lei` will require a username and password.
Unless you really like typing them in manually every time you run `lei up`,
you will probably want to have them cached on your local system. `Lei` will
defer to `git-credential-helper` for this purpose, so if you haven't already
set this up, you will want to do that now.

The two commonly used credential storage backends on Linux are "libsecret" and
"store":

- *libsecret* is the preferred mechanism, as it will work with your Desktop
  Environment's keyring manager to store the credentials in a relatively safe
  fashion (encrypted at rest).

- *store* should only be used if you don't have any other option, as it will
  record the credentials without any kind of encryption in the
  `~/.git-credentials` file. However, if nothing else is working for you and
  you are fairly confident in the security of your system, it's something you
  can use.

Simply run the following command to configure the credential helper globally
for your environment:

    git config --global credential.helper libsecret

For more in-depth information about this topic, see `man git-credential`.

## Getting your IMAP server ready

Before you start, you should get some information about your IMAP server, such
as your login information. For my examples, I'm going to use Gmail, Migadu,
and a generic Dovecot IMAP server installation, which should hopefully cover
enough ground to be useful for the vast majority of cases.

What you will need beforehand:

- the IMAP server hostname (and port, if it's not 993)
- the IMAP username
- the IMAP password

It will also help to know the folder hierarchy. Some IMAP servers create all
subfolders below INBOX, while others don't really care.

### Generic Dovecot

We happen to be running Dovecot on mail.codeaurora.org, so I'm going to use it
as my "generic Dovecot" system and run the following command:

    lei q -I https://lore.kernel.org/all/ -d mid \
      -o imaps://mail.codeaurora.org/INBOX/torvalds \
      <<< 'f:torvalds AND rt:1.month.ago..'

The `<<<` bit above is a Bash-ism, so if you're using a different shell, you
can use the POSIX-compliant heredoc format instead:

    lei q -I https://lore.kernel.org/all/ -d mid \
      -o imaps://mail.codeaurora.org/INBOX/torvalds <<EOF
    f:torvalds AND rt:1.month.ago..
    EOF

The first time you run it, you should get a `username:` and `password:`
prompt, but after that the credentials should be cached and no longer required
on each repeated access to the same imaps server.

NOTE: some IMAP servers use the dot `.` instead of the slash `/` for
indicating folder hierarchy, so if `INBOX/torvalds` is not working for you,
try `INBOX.torvalds` instead.

### Refreshing and subscribing to IMAP folders

If the above command succeeded, then you should be able to view the IMAP
folder in your mail client. If you cannot see `torvalds` in your list of
available folders, then you may need to refresh and/or subscribe to the newly
created folder. The process will be different for every mail client, but it
shouldn't be too hard to find.

### The same with Migadu

If you have a linux.dev account (see https://korg.docs.kernel.org/linuxdev.html),
then you probably already know that we ask you not to use your account for
subscribing to busy mailing lists. This is due to Migadu imposing soft limits
on how much incoming email is allowed for each hosted domain -- so using `lei`
+ IMAP is an excellent alternative.

To set this up with your linux.dev account (or any other account hosted on
Migadu), use the following command:

    lei q -I https://lore.kernel.org/all/ -d mid \
      -o imaps://imap.migadu.com/lei/torvalds \
      <<< 'f:torvalds AND rt:1.month.ago..'

Again, you will need to subscribe to the new `lei/torvalds` folder to see it
in your mail client.

### The same with Gmail

If you are a Gmail user and aren't already using IMAP, then you will need to
jump through a few additional hoops before you are able to get going. Google
is attempting to enhance the security of your account by restricting how much
can be done with just your Google username and password, so services like IMAP
are not available without setting up a special "app password" that can only be
used for mail access.

Enabling app passwords requires that you first enable 2-factor authentication,
and then generate a random app password to use with IMAP. Please follow the
process described in the following Google document:
https://support.google.com/mail/answer/185833

Once you have the app password for use with IMAP, you can use `lei` and imaps
just like with any other IMAP server:

    lei q -I https://lore.kernel.org/all/ -d mid \
      -o imaps://imap.gmail.com/lei/torvalds \
      <<< 'f:torvalds AND rt:1.month.ago..'

It requires a browser page reload for the folder to show up in your Gmail web
UI.

## Automating lei up runs

If you're setting up IMAP access, then you probably want IMAP updates to
happen behind the scenes without your direct involvement. All you need to do
is periodically run `lei up --all` (plus `-q` if you don't want non-critical
output).

If you're just getting started, then you can set up a simple `screen` session
with a `watch` command at a 10-minute interval, like so:

    watch -n 600 lei up --all

You can then detach from the screen terminal and let that command continue
behind the scenes. The main problem with this approach is that it won't
survive a system reboot, so if everything is working well and you want to make
the command a bit more permanent, you can set up a systemd user timer.

Here's the service file to put in `~/.config/systemd/user/lei-up-all.service`:

    [Unit]
    Description=lei up --all service
    ConditionPathExists=%h/.local/share/lei

    [Service]
    Type=oneshot
    ExecStart=/usr/bin/lei up --all -q

    [Install]
    WantedBy=mail.target

And the timer file to put in `~/.config/systemd/user/lei-up-all.timer`:

    [Unit]
    Description=lei up --all timer
    ConditionPathExists=%h/.local/share/lei

    [Timer]
    OnUnitInactiveSec=10m

    [Install]
    WantedBy=default.target

Enable the timer:

    systemctl --user enable --now lei-up-all.timer

You can use `journalctl -xn` to view the latest journal messages and make sure
that the timer is running well.

CAUTION: user timers only run when the user is logged in. This is not actually
that bad, as your keyring is not going to be unlocked unless you are logged
into the desktop session. If you want to run `lei up` as a background process
on some server, you should set up a system-level timer and use a different
git-credential mechanism (e.g. `store`) -- and you probably shouldn't do this
on a shared system where you have to worry about your account credentials
being stolen.

## Coming up next

In the next installment we'll look at some other part of lei and
public-inbox... I haven't yet decided which. :)

Best regards,
-K

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Gmail (was: Re: lore+lei: part 2, now with IMAP)
  2021-11-12 19:13 lore+lei: part 2, now with IMAP Konstantin Ryabitsev
@ 2021-11-15 18:34 ` Geert Uytterhoeven
  2021-11-15 21:46   ` Konstantin Ryabitsev
  2021-11-22 14:37 ` lore+lei: part 2, now with IMAP Jani Nikula
  1 sibling, 1 reply; 14+ messages in thread
From: Geert Uytterhoeven @ 2021-11-15 18:34 UTC (permalink / raw)
  To: Konstantin Ryabitsev; +Cc: workflows

Hi Konstantin,

On Fri, Nov 12, 2021 at 8:13 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> Continuing on my previous email about setting up lei with lore.kernel.org,
> here's the next installment. As with the previous part, this will be posted on
> people.kernel.org as well as here.
>
> # lore+lei: part 2, now with IMAP

> ### The same with Gmail
>
> If you are a Gmail user and aren't already using IMAP, then you will need to
> jump through a few additional hoops before you are able to get going. Google
> is attempting to enhance the security of your account by restricting how much
> can be done with just your Google username and password, so services like IMAP
> are not available without setting up a special "app password" that can only be
> used for mail access.
>
> Enabling app passwords requires that you first enable 2-factor authentication,
> and then generate a random app password to use with IMAP. Please follow the
> process described in the following Google document:
> https://support.google.com/mail/answer/185833

On a related subject, I am using Gmail for email (e.g. patch review),
but not for actual patch submission (git send-email through my ISP's
SMTP server). I do have app passwords set up for git send-email on
my laptop (if I ever need to send patches while on the road, barely
used so far) and for backing up email using getmail.

Recently I received an email from Google that my account may be "at
greater risk of targeted attack", and that they recommend enrolling
into Google's strongest account security offering, the Advanced
Protection Program.  Apparently this makes use of a hardware token,
the Titan Security Key.  I have no idea what kind of criteria are
used to reach out to people (might be people involved with important
FLOSS projects, who knows? ;-), but the other family members haven't
received this.

Perhaps other people are in the same boat?
Do you have any advice here? Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Gmail (was: Re: lore+lei: part 2, now with IMAP)
  2021-11-15 18:34 ` Gmail (was: Re: lore+lei: part 2, now with IMAP) Geert Uytterhoeven
@ 2021-11-15 21:46   ` Konstantin Ryabitsev
  2021-11-16  8:01     ` Geert Uytterhoeven
  2021-11-16 12:18     ` Han-Wen Nienhuys
  0 siblings, 2 replies; 14+ messages in thread
From: Konstantin Ryabitsev @ 2021-11-15 21:46 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: workflows

On Mon, Nov 15, 2021 at 07:34:00PM +0100, Geert Uytterhoeven wrote:
> On a related subject, I am using Gmail for email (e.g. patch review),
> but not for actual patch submission (git send-email through my ISP's
> SMTP server). I do have app passwords set up for git send-email on
> my laptop (if I ever need to send patches while on the road, barely
> used so far) and for backing up email using getmail.
> 
> Recently I received an email from Google that my account may be "at
> greater risk of targeted attack", and that they recommend enrolling
> into Google's strongest account security offering, the Advanced
> Protection Program.  Apparently this makes use of a hardware token,
> the Titan Security Key. 

Well, I'm sure they wouldn't mind if you paid them money for a "Titan Security
key", but it's really just a rebranded Chinese-made U2F token and, as such,
not any different from any other U2F security key. You can get one from
Nitrokey (nitrokey.com) or SoloKeys (solokeys.com). I *do* recommend using a
hardware token for your Google account, seeing as it's increasingly tied to so
much of our online identity.

> I have no idea what kind of criteria are
> used to reach out to people (might be people involved with important
> FLOSS projects, who knows? ;-), but the other family members haven't
> received this.

It's anyone's guess, but it's probably based on analyzing various account
dumps a-la haveibeenpwned.com or Mozilla's Firefox Monitor. It doesn't
necessarily mean that you have anything in particular to worry about.

Best regards,
-K

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Gmail (was: Re: lore+lei: part 2, now with IMAP)
  2021-11-15 21:46   ` Konstantin Ryabitsev
@ 2021-11-16  8:01     ` Geert Uytterhoeven
  2021-11-16  8:04       ` Drew DeVault
  2021-11-16 13:35       ` Konstantin Ryabitsev
  2021-11-16 12:18     ` Han-Wen Nienhuys
  1 sibling, 2 replies; 14+ messages in thread
From: Geert Uytterhoeven @ 2021-11-16  8:01 UTC (permalink / raw)
  To: Konstantin Ryabitsev; +Cc: workflows

Hi Konstantin,

On Mon, Nov 15, 2021 at 10:46 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> On Mon, Nov 15, 2021 at 07:34:00PM +0100, Geert Uytterhoeven wrote:
> > On a related subject, I am using Gmail for email (e.g. patch review),
> > but not for actual patch submission (git send-email through my ISP's
> > SMTP server). I do have app passwords set up for git send-email on
> > my laptop (if I ever need to send patches while on the road, barely
> > used so far) and for backing up email using getmail.
> >
> > Recently I received an email from Google that my account may be "at
> > greater risk of targeted attack", and that they recommend enrolling
> > into Google's strongest account security offering, the Advanced
> > Protection Program.  Apparently this makes use of a hardware token,
> > the Titan Security Key.
>
> Well, I'm sure they wouldn't mind if you paid them money for a "Titan Security
> key", but it's really just a rebranded Chinese-made U2F token and, as such,
> not any different from any other U2F security key. You can get one from
> Nitrokey (nitrokey.com) or SoloKeys (solokeys.com). I *do* recommend using a
> hardware token for your Google account, seeing as it's increasingly tied to so
> much of our online identity.

Thanks for the explanation.
Given it uses U2F, that means I cannot use the Nitrokey Start for that?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Gmail (was: Re: lore+lei: part 2, now with IMAP)
  2021-11-16  8:01     ` Geert Uytterhoeven
@ 2021-11-16  8:04       ` Drew DeVault
  2021-11-16  8:26         ` Geert Uytterhoeven
  2021-11-16 13:35       ` Konstantin Ryabitsev
  1 sibling, 1 reply; 14+ messages in thread
From: Drew DeVault @ 2021-11-16  8:04 UTC (permalink / raw)
  To: Geert Uytterhoeven, Konstantin Ryabitsev; +Cc: workflows

Apologies for being That Guy, but: but have you considered simply
leaving gmail?

I recommend Migadu: https://www.migadu.com

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Gmail (was: Re: lore+lei: part 2, now with IMAP)
  2021-11-16  8:04       ` Drew DeVault
@ 2021-11-16  8:26         ` Geert Uytterhoeven
  2021-11-16  8:29           ` Drew DeVault
  0 siblings, 1 reply; 14+ messages in thread
From: Geert Uytterhoeven @ 2021-11-16  8:26 UTC (permalink / raw)
  To: Drew DeVault; +Cc: Konstantin Ryabitsev, workflows

Hi Drew,

On Tue, Nov 16, 2021 at 9:04 AM Drew DeVault <sir@cmpwn.com> wrote:
> Apologies for being That Guy, but: but have you considered simply
> leaving gmail?

Thanks for your suggestion ;-)

> I recommend Migadu: https://www.migadu.com

Which is subject to the traffic limitations as mentioned by Konstantin?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Gmail (was: Re: lore+lei: part 2, now with IMAP)
  2021-11-16  8:26         ` Geert Uytterhoeven
@ 2021-11-16  8:29           ` Drew DeVault
  2021-11-16 13:49             ` Konstantin Ryabitsev
  0 siblings, 1 reply; 14+ messages in thread
From: Drew DeVault @ 2021-11-16  8:29 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: Konstantin Ryabitsev, workflows

On Tue Nov 16, 2021 at 9:26 AM CET, Geert Uytterhoeven wrote:
> > I recommend Migadu: https://www.migadu.com
>
> Which is subject to the traffic limitations as mentioned by Konstantin?

I might have missed Konstantin's message, but yes, Migadu has traffic
limits. I use the standard plan, which supports 500 outgoing and 3000
incoming emails per day. This might not be enough for you, though, and
the "maxi" plan is pretty pricey.

https://www.migadu.com/pricing/

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Gmail (was: Re: lore+lei: part 2, now with IMAP)
  2021-11-15 21:46   ` Konstantin Ryabitsev
  2021-11-16  8:01     ` Geert Uytterhoeven
@ 2021-11-16 12:18     ` Han-Wen Nienhuys
  1 sibling, 0 replies; 14+ messages in thread
From: Han-Wen Nienhuys @ 2021-11-16 12:18 UTC (permalink / raw)
  To: Konstantin Ryabitsev; +Cc: Geert Uytterhoeven, workflows

On Mon, Nov 15, 2021 at 11:59 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> On Mon, Nov 15, 2021 at 07:34:00PM +0100, Geert Uytterhoeven wrote:
> > On a related subject, I am using Gmail for email (e.g. patch review),
> > but not for actual patch submission (git send-email through my ISP's
> > SMTP server). I do have app passwords set up for git send-email on
> > my laptop (if I ever need to send patches while on the road, barely
> > used so far) and for backing up email using getmail.
> >
> > Recently I received an email from Google that my account may be "at
> > greater risk of targeted attack", and that they recommend enrolling
> > into Google's strongest account security offering, the Advanced
> > Protection Program.  Apparently this makes use of a hardware token,
> > the Titan Security Key.
>
> Well, I'm sure they wouldn't mind if you paid them money for a "Titan Security
> key", but it's really just a rebranded Chinese-made U2F token and, as such,
> not any different from any other U2F security key. You can get one from

Most electronics are made in China, but the Titan is set apart because
it was designed by Google, and was certified for FIPS 140-2,

https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp3361.pdf

If assurances about secure hardware implementations aren't important
to you, you can use any U2F device. If you have USB ports to spare, I
can recommend the Yubikey Nano, which you can just leave in a USB port
permanently. I also have a HyperFIDO Titanium Pro (from HyperSECU) on
my keychain which is very sturdy.

-- 
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
--
Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Gmail (was: Re: lore+lei: part 2, now with IMAP)
  2021-11-16  8:01     ` Geert Uytterhoeven
  2021-11-16  8:04       ` Drew DeVault
@ 2021-11-16 13:35       ` Konstantin Ryabitsev
  1 sibling, 0 replies; 14+ messages in thread
From: Konstantin Ryabitsev @ 2021-11-16 13:35 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: workflows

On Tue, Nov 16, 2021 at 09:01:35AM +0100, Geert Uytterhoeven wrote:
> > Well, I'm sure they wouldn't mind if you paid them money for a "Titan Security
> > key", but it's really just a rebranded Chinese-made U2F token and, as such,
> > not any different from any other U2F security key. You can get one from
> > Nitrokey (nitrokey.com) or SoloKeys (solokeys.com). I *do* recommend using a
> > hardware token for your Google account, seeing as it's increasingly tied to so
> > much of our online identity.
> 
> Thanks for the explanation.
> Given it uses U2F, that means I cannot use the Nitrokey Start for that?

No, the Start doesn't support u2f. Their Nitrokey 3 should support all
operation modes that kernel devs would want (PGP, Fido2), but they have been
hit by the same chips shortage as everyone else, so the launch has been
delayed multiple times. I should get mine soon, hopefully, so I'll be able to
review it.

If you just want a U2F token for your Google account, then you can get any
common Fido2 device, including the Titan key. If you only use it for Google
and a handful of other sites supporting u2f, then you only need it extremely
occasionally and it can just hang on your keychain and look pretty the rest of
the time.

-K

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Gmail (was: Re: lore+lei: part 2, now with IMAP)
  2021-11-16  8:29           ` Drew DeVault
@ 2021-11-16 13:49             ` Konstantin Ryabitsev
  2021-11-16 13:51               ` Drew DeVault
  0 siblings, 1 reply; 14+ messages in thread
From: Konstantin Ryabitsev @ 2021-11-16 13:49 UTC (permalink / raw)
  To: Drew DeVault; +Cc: Geert Uytterhoeven, workflows

On Tue, Nov 16, 2021 at 09:29:03AM +0100, Drew DeVault wrote:
> > > I recommend Migadu: https://www.migadu.com
> >
> > Which is subject to the traffic limitations as mentioned by Konstantin?
> 
> I might have missed Konstantin's message, but yes, Migadu has traffic
> limits. I use the standard plan, which supports 500 outgoing and 3000
> incoming emails per day. This might not be enough for you, though, and
> the "maxi" plan is pretty pricey.
> 
> https://www.migadu.com/pricing/

We do have the maxi plan for linux.dev, and we *have* hit limits. The Migadu
folks have been extremely accommodating for us, so it's not been a huge deal
thus far, but I'm not sure if the relaxed restrictions they've put in place
are just for the linux.dev domain or now apply globally. For example, sending
large patch series (20+) used to trip up Migadu's outgoing rate limit for too
much mail sent at once. We've not hit that error for a while, so I assume
they've relaxed that restriction either just for linux.dev, or perhaps
globally.

It's important to keep in mind that the overall outgoing/incoming limits are
per account, not per mailbox. Not a huge deal for personal use, but quickly
adds up for setups like we have, which is why we ask folks not to subscribe to
busy lists (see #4 in the list of our requirements here:
https://www.kernel.org/doc/projects/korg/linuxdev.html#rules-and-restrictions)

Overall, Migadu is a good recommendation for individual developer accounts,
but may be too restricting for maintainers that do end up sending huge
amounts of mail. Gmail or Fastmail could be better options for those folks.

-K

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Gmail (was: Re: lore+lei: part 2, now with IMAP)
  2021-11-16 13:49             ` Konstantin Ryabitsev
@ 2021-11-16 13:51               ` Drew DeVault
  2021-11-16 14:04                 ` Konstantin Ryabitsev
  0 siblings, 1 reply; 14+ messages in thread
From: Drew DeVault @ 2021-11-16 13:51 UTC (permalink / raw)
  To: Konstantin Ryabitsev; +Cc: Geert Uytterhoeven, workflows

On Tue Nov 16, 2021 at 2:49 PM CET, Konstantin Ryabitsev wrote:
> We do have the maxi plan for linux.dev, and we *have* hit limits. The
> Migadu folks have been extremely accommodating for us, so it's not
> been a huge deal thus far, but I'm not sure if the relaxed
> restrictions they've put in place are just for the linux.dev domain or
> now apply globally. For example, sending large patch series (20+) used
> to trip up Migadu's outgoing rate limit for too much mail sent at
> once. We've not hit that error for a while, so I assume they've
> relaxed that restriction either just for linux.dev, or perhaps
> globally.
>
> It's important to keep in mind that the overall outgoing/incoming
> limits are per account, not per mailbox. Not a huge deal for personal
> use, but quickly adds up for setups like we have, which is why we ask
> folks not to subscribe to busy lists (see #4 in the list of our
> requirements here:
> https://www.kernel.org/doc/projects/korg/linuxdev.html#rules-and-restrictions)
>
> Overall, Migadu is a good recommendation for individual developer
> accounts, but may be too restricting for maintainers that do end up
> sending huge amounts of mail. Gmail or Fastmail could be better
> options for those folks.

I'm surprised to learn that linux.dev is using Migadu rather than its
own infrastructure. I would only recommend it for personal use.

I will say that I have also occasionally hit Migadu's limits, but they
have been accomodating in loosening them for legitimate use when asked.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Gmail (was: Re: lore+lei: part 2, now with IMAP)
  2021-11-16 13:51               ` Drew DeVault
@ 2021-11-16 14:04                 ` Konstantin Ryabitsev
  0 siblings, 0 replies; 14+ messages in thread
From: Konstantin Ryabitsev @ 2021-11-16 14:04 UTC (permalink / raw)
  To: Drew DeVault; +Cc: Geert Uytterhoeven, workflows

On Tue, Nov 16, 2021 at 02:51:59PM +0100, Drew DeVault wrote:
> > Overall, Migadu is a good recommendation for individual developer
> > accounts, but may be too restricting for maintainers that do end up
> > sending huge amounts of mail. Gmail or Fastmail could be better
> > options for those folks.
> 
> I'm surprised to learn that linux.dev is using Migadu rather than its
> own infrastructure. I would only recommend it for personal use.

1. We couldn't easily gauge how many people would be interested in the
   service, so the goal was to avoid setting up infrastructure if only a small
   subset of users would be interested in using it. And that's largely proven
   correct, as only about 20 people requested accounts on linux.dev, and only
   about 5-7 people use them regularly to send and receive mail.
2. Dealing with spammers is a huge effort sink, so if someone already has a
   good setup for recognizing and catching spammers, then we might as well
   delegate this to them.
3. Migadu offers open-source project discounts, so it's actually dramatically
   cheaper for us to use them than to run our own infra in terms of admin
   time. :)

> I will say that I have also occasionally hit Migadu's limits, but they
> have been accomodating in loosening them for legitimate use when asked.

Yes, I have no complaints about Migadu. They are great and I heartily
recommend it to others.

-K

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: lore+lei: part 2, now with IMAP
  2021-11-12 19:13 lore+lei: part 2, now with IMAP Konstantin Ryabitsev
  2021-11-15 18:34 ` Gmail (was: Re: lore+lei: part 2, now with IMAP) Geert Uytterhoeven
@ 2021-11-22 14:37 ` Jani Nikula
  2021-11-22 15:07   ` Konstantin Ryabitsev
  1 sibling, 1 reply; 14+ messages in thread
From: Jani Nikula @ 2021-11-22 14:37 UTC (permalink / raw)
  To: Konstantin Ryabitsev, workflows

On Fri, 12 Nov 2021, Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> For our example query today, we'll do some stargazing. The following will show
> us all mail sent by Linus Torvalds:
>
>     f:torvalds AND rt:1.month.ago..

IMHO you're making the prefixes too short at the cost of not being clear
or easy to remember for the casual user. f? rt?

For example, the same query using Notmuch (which also uses Xapian as the
backend) would be:

	from:torvalds AND date:1month..

I'm not convinced the brevity is all good here, YMMV.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: lore+lei: part 2, now with IMAP
  2021-11-22 14:37 ` lore+lei: part 2, now with IMAP Jani Nikula
@ 2021-11-22 15:07   ` Konstantin Ryabitsev
  0 siblings, 0 replies; 14+ messages in thread
From: Konstantin Ryabitsev @ 2021-11-22 15:07 UTC (permalink / raw)
  To: Jani Nikula; +Cc: workflows

On Mon, 22 Nov 2021 at 09:37, Jani Nikula <jani.nikula@intel.com> wrote:
>
> On Fri, 12 Nov 2021, Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> > For our example query today, we'll do some stargazing. The following will show
> > us all mail sent by Linus Torvalds:
> >
> >     f:torvalds AND rt:1.month.ago..
>
> IMHO you're making the prefixes too short at the cost of not being clear
> or easy to remember for the casual user. f? rt?
>
> For example, the same query using Notmuch (which also uses Xapian as the
> backend) would be:
>
>         from:torvalds AND date:1month..
>
> I'm not convinced the brevity is all good here, YMMV.

Pretty sure public-inbox just uses mairix-style queries here, so it's
really an "vi vs. emacs" kind of discussion.
http://manpages.ubuntu.com/manpages/bionic/man1/mairix.1.html

-K

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2021-11-22 15:07 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-12 19:13 lore+lei: part 2, now with IMAP Konstantin Ryabitsev
2021-11-15 18:34 ` Gmail (was: Re: lore+lei: part 2, now with IMAP) Geert Uytterhoeven
2021-11-15 21:46   ` Konstantin Ryabitsev
2021-11-16  8:01     ` Geert Uytterhoeven
2021-11-16  8:04       ` Drew DeVault
2021-11-16  8:26         ` Geert Uytterhoeven
2021-11-16  8:29           ` Drew DeVault
2021-11-16 13:49             ` Konstantin Ryabitsev
2021-11-16 13:51               ` Drew DeVault
2021-11-16 14:04                 ` Konstantin Ryabitsev
2021-11-16 13:35       ` Konstantin Ryabitsev
2021-11-16 12:18     ` Han-Wen Nienhuys
2021-11-22 14:37 ` lore+lei: part 2, now with IMAP Jani Nikula
2021-11-22 15:07   ` Konstantin Ryabitsev

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).