bug#45711: 27.1; Ambiguous account match in .authinfo still used by smtpmail

bug#45711: 27.1; Ambiguous account match in .authinfo still used by smtpmail

[Duncan Bayne]

When I have an .authinfo file that contains multiple accounts for the
same host:

machine smtp.gmail.com login duncan@example.org password bazqux port 587
machine smtp.gmail.com login duncan@example.com password foobar port 587

... and have neglected to configure smptmail with the smtpmail-smtp-user
variable in either mu4e context, e.g.:

,(make-mu4e-context
  :name "example-com"
  :vars '((
           ;; Should contain, but doesn't ...
           ;; (smtpmail-smtp-user            . "duncan@example.com"

           (smtpmail-starttls-credentials . '(("smtp.gmail.com" 587 nil nil)))
           (smtpmail-default-smtp-server  . "smtp.gmail.com")
           (smtpmail-smtp-server          . "smtp.gmail.com")
           (smtpmail-smtp-service         . 587))))

... then smtpmail proceeds to authenticate with the *first* matching
account it finds.  So in this example, even if I'm using the
duncan@example.com context, it will log in as duncan@example.org.

(In practice this resulted in me sending email with the wrong From:
address, because Gmail unhelpfully and in violation of the relevant RFCs
re-writes the From: header to match the account to which you're logged
in, because STUFF YOU WE'RE GOOGLE.  Anyway.)

I think the correct behaviour here would be to have smtpmail to refuse
to send if there's an ambiguous account match in .authinfo.  I can't
off-hand think of a single case where I'd *want* it to just take the
first matching account where there are several possibilities.

Details from report-emacs-bug:

In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2020-11-03 built on duncan-w540
Repository revision: 7ff33faa62c0f3ca7b8dee9ec23671d650f827c5
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12009000
System Description: Ubuntu 20.10

Configured using:
 'configure --with-x=yes --with-x-toolkit=lucid
 --with-toolkit-scroll-bars --without-gconf --without-gsettings'

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GLIB NOTIFY INOTIFY ACL
LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS LIBSYSTEMD
PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: en_AU.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8

--
Duncan Bayne
+61 420 817 082 | https://duncan.bayne.id.au/

I usually check my mail every 24 - 48 hours.  If there's something
urgent going on, please send me an SMS or call me.

bug#45711: 27.1; Ambiguous account match in .authinfo still used by smtpmail

[Ted Zlatanov]

On Thu, 07 Jan 2021 23:12:09 +1100 Duncan Bayne <duncan@bayne.id.au> wrote: 

DB> I think the correct behaviour here would be to have smtpmail to refuse
DB> to send if there's an ambiguous account match in .authinfo.  I can't
DB> off-hand think of a single case where I'd *want* it to just take the
DB> first matching account where there are several possibilities.

I think it's common to have more specific matches on top, and less
specific matches down the list. That's why returning the first one makes
sense, and potentially there's always an ambiguous entry. It would break
such setups to do what you're suggesting.

Ted

bug#45711: 27.1; Ambiguous account match in .authinfo still used by smtpmail

[Duncan Bayne]

Ted Zlatanov writes:

> On Thu, 07 Jan 2021 23:12:09 +1100 Duncan Bayne <duncan@bayne.id.au> wrote:
>
> DB> I think the correct behaviour here would be to have smtpmail to refuse
> DB> to send if there's an ambiguous account match in .authinfo.  I can't
> DB> off-hand think of a single case where I'd *want* it to just take the
> DB> first matching account where there are several possibilities.
>
> I think it's common to have more specific matches on top, and less
> specific matches down the list. That's why returning the first one makes
> sense, and potentially there's always an ambiguous entry. It would break
> such setups to do what you're suggesting.

To be clear here I meant smtpmail as 'it'.

I think it's the right thing for auth-source-search to return a list of
matches, but I think it's a bug for smtpmail-try-auth-methods to just
quietly use the first match in that case.

The code in question is in smtpmail.el:510 ...

(defun smtpmail-try-auth-methods (process supported-extensions host port
                                  &optional ask-for-password)
         ;; snip
         (auth-info (car
                     (auth-source-search
                      :host host
                      :port port
                      :user smtpmail-smtp-user
                      :max 1
                      :require (and ask-for-password
                                    '(:user :secret))
                      :create ask-for-password)))

What it seems to be doing with (car (... :max 1) is to simply take the
first match and use that.

What I *think* it should do is either a) error out in the case of an
ambiguous match, or b) prompt the use to ask which of the various
matches it should use.

Meta: this is my first Emacs bug report, and I'm planning to write a
patch to address it.  Not sure whether the discussion of whether it's a
bug, and if so, what the appropriate fix is, belongs here or on the
emacs-devel list.  Happy to take the conversation there if that's
protocol.

--
Duncan Bayne
+61 420 817 082 | https://duncan.bayne.id.au/

I usually check my mail every 24 - 48 hours.  If there's something
urgent going on, please send me an SMS or call me.

bug#45711: 27.1; Ambiguous account match in .authinfo still used by smtpmail

[Lars Ingebrigtsen]

Duncan Bayne <duncan@bayne.id.au> writes:

> What it seems to be doing with (car (... :max 1) is to simply take the
> first match and use that.
>
> What I *think* it should do is either a) error out in the case of an
> ambiguous match, or b) prompt the use to ask which of the various
> matches it should use.

As Ted said, it's common to have specific passwords for some services,
and use a fallback for the rest.

machine foo port smtp password zot
machine foo port nntp password bar
machine foo password gazonk

Changing how this works would break people's setups, so we can't do
that.  But I see that this hasn't actually been documented anywhere?  So
I've now added that to the auth manual in Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45711: 27.1; Ambiguous account match in .authinfo still used by smtpmail

[Duncan Bayne]

Lars Ingebrigtsen writes:

> Duncan Bayne <duncan@bayne.id.au> writes:
>
>> What it seems to be doing with (car (... :max 1) is to simply take the
>> first match and use that.
>>
>> What I *think* it should do is either a) error out in the case of an
>> ambiguous match, or b) prompt the use to ask which of the various
>> matches it should use.
>
> As Ted said, it's common to have specific passwords for some services,
> and use a fallback for the rest.
>
> machine foo port smtp password zot
> machine foo port nntp password bar
> machine foo password gazonk
>
> Changing how this works would break people's setups, so we can't do
> that.

In the case you've cited above, there is no bug.  I wouldn't change that
behaviour at all.  There is only one SMTP account present.

But consider this hypothetical configuration (not so hypothetical,
because as I say, this recently happened to me):

machine foo port smtp login Alice@example.com password zot
machine foo port smtp login bob@example.com password bar

If smtpmail is configured not to specify smtpmail-smtp-user, *and* there
are multiple SMTP accounts in .authinfo, it'll just quietly use the
first account.

This behaviour I argue *is* a bug, because that is almost certainly the
wrong thing to do.

Perhaps to put it another way - can you imagine a case where it
*wouldn't* be a bug for smtpmail to behave in this way?  I honestly
can't.

> But I see that this hasn't actually been documented anywhere?  So
> I've now added that to the auth manual in Emacs 28.

Thank you :)  That would have been helpful at the time this was
initially confusing me, & will hopefully help others too.

--
Duncan Bayne
+61 420 817 082 | https://duncan.bayne.id.au/

I usually check my mail every 24 - 48 hours.  If there's something
urgent going on, please send me an SMS or call me.

bug#45711: 27.1; Ambiguous account match in .authinfo still used by smtpmail

[Lars Ingebrigtsen]

Duncan Bayne <duncan@bayne.id.au> writes:

> In the case you've cited above, there is no bug.  I wouldn't change that
> behaviour at all.  There is only one SMTP account present.

It's still ambiguous if you don't specify the port number in
`auth-source-search', but the rules are the same: The first matching
entry is used.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45711: 27.1; Ambiguous account match in .authinfo still used by smtpmail

[Ted Zlatanov]

On Sun, 10 Jan 2021 10:30:13 +1100 Duncan Bayne <duncan@bayne.id.au> wrote: 

DB> Ted Zlatanov writes:

DB> I think it's the right thing for auth-source-search to return a list of
DB> matches, but I think it's a bug for smtpmail-try-auth-methods to just
DB> quietly use the first match in that case.

OK.

...
DB> What it seems to be doing with (car (... :max 1) is to simply take the
DB> first match and use that.

DB> What I *think* it should do is either a) error out in the case of an
DB> ambiguous match, or b) prompt the use to ask which of the various
DB> matches it should use.

I see. Your approach makes sense, I agree, but it will be surprising to
people who intentionally have multiple matches. Maybe we need to search
with :max 2.

There, if the :max 2 search returns two equally specific entries, that's
probably an error, or at least a strong warning (sit-for 3 seconds or
something). But if the :max 2 search returns a less specific (more
general) entry in the second slot, then that's probably what the user
intended.

What do you think?

DB> Meta: this is my first Emacs bug report, and I'm planning to write a
DB> patch to address it.  Not sure whether the discussion of whether it's a
DB> bug, and if so, what the appropriate fix is, belongs here or on the
DB> emacs-devel list.  Happy to take the conversation there if that's
DB> protocol.

No, here is perfect. If you provide a patch I can apply it (unless it's
non-trivial, in which case you'll need to sign the contributor papers).

Ted