On Sun, Feb 05, 2023 at 10:51:04PM +0100, Ævar Arnfjörð Bjarmason wrote: > > 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. > 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. > 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
