Re: [PATCH v2 6/6] imap-send: correctly report "host" when using "tunnel"

From: Jeff King <peff@peff.net>
Date: Feb 7, 2023, 18:30 UTC
Message-ID: <Y+KYwsBjty0aaLes@coredump.intra.peff.net>
In-Reply-To: <230205.86ilgf7osb.gmgdl@evledraar.gmail.com>

On Sun, Feb 05, 2023 at 10:51:04PM +0100, Ævar Arnfjörð Bjarmason wrote:

Show 8 quoted lines

> > Not if they did:
> >
> >   [imap]
> >   host = example.com
> >   tunnel = some-command
> 
> Yes, but how would they have ended up doing that? By discarding the
> documentation and throwing things at the wall & hoping they'd stick?

That's what I would have tried without reading the documentation at all, based on using other programs that tunnel imap. I'm just one data point, of course.

Show 6 quoted lines

> I just don't get how anyone could have come to rely on this so that we'd
> care about supporting it.
> 
> Because mutt has a feature that looks similar, users might have
> configured git-imap-send thinking it might do the same thing, and gotten
> lucky?

It's less "mutt happens to do it this way" and more "associating a host is strictly more useful, because it lets you interact with all the other host-like features". It's only imap-send's funky config scheme that makes it easy to mis-configure.

Show 5 quoted lines

> I guess in principle that could be true, but I think it's more likely
> that nobody's ever had reason to use it that way. I.e. if you use the
> "tunnel" the way the docs suggest you won't hit the credential helper,
> as you're authenticating with "ssh", and using "imapd" to directly
> operate on a Maildir path.

As I said, my main use of tunneling is to trigger the imap server's preauth mode. But there are other reasons one might want to do so, like piercing a firewall. E.g.:

  [imap]
  host = internal.example.com
  tunnel = "ssh bastion-server nc internal.example.com 143"

-Peff