* bug#26307: 25.1; smtpmail hard-coded auth mechanism order does not allow coping with misbehaving servers
@ 2017-03-30 6:54 Marco Maggi
2017-03-31 22:59 ` Glenn Morris
0 siblings, 1 reply; 4+ messages in thread
From: Marco Maggi @ 2017-03-30 6:54 UTC (permalink / raw)
To: 26307
In GNU Emacs 25.1.1 (x86_64-slackware-linux-gnu, GTK+ Version 2.24.30)
the library "smtpmail.el" contains the hard-coded list of authentication
mechanisms to try in sequence:
(defconst smtpmail-auth-supported '(cram-md5 plain login)
"List of supported SMTP AUTH mechanisms.
The list is in preference order.")
it would be useful to have a public API mechanism to change such order
in case the server misbehaves when using the cram-m5 method.
I am customer of a mail service using a server that advertises to
support the cram-md5, plain and login methods but then when trying
cram-md5 the authentication fails; the login method succeeds.
Just changing the above code to:
(defconst smtpmail-auth-supported '(login cram-md5 plain)
and recompiling fixes my problems.
It is hard to contact the service administrators and having them fix
the problem, so a workaround is useful.
TIA
--
Marco Maggi
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#26307: 25.1; smtpmail hard-coded auth mechanism order does not allow coping with misbehaving servers
2017-03-30 6:54 bug#26307: 25.1; smtpmail hard-coded auth mechanism order does not allow coping with misbehaving servers Marco Maggi
@ 2017-03-31 22:59 ` Glenn Morris
2017-04-01 11:12 ` Marco Maggi
0 siblings, 1 reply; 4+ messages in thread
From: Glenn Morris @ 2017-03-31 22:59 UTC (permalink / raw)
To: marco.maggi-ipsu; +Cc: 26307
Marco Maggi wrote:
> (defconst smtpmail-auth-supported '(cram-md5 plain login)
> "List of supported SMTP AUTH mechanisms.
> The list is in preference order.")
>
> it would be useful to have a public API mechanism to change such order
> in case the server misbehaves when using the cram-m5 method.
>
> I am customer of a mail service using a server that advertises to
> support the cram-md5, plain and login methods but then when trying
> cram-md5 the authentication fails; the login method succeeds.
>
> Just changing the above code to:
>
> (defconst smtpmail-auth-supported '(login cram-md5 plain)
>
> and recompiling fixes my problems.
Intead of recompiling, you can add to your .emacs:
(with-eval-after-load 'smtpmail
(setq smtpmail-auth-supported '(login cram-md5 plain)))
Perhaps no Emacs change is needed then?
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#26307: 25.1; smtpmail hard-coded auth mechanism order does not allow coping with misbehaving servers
2017-03-31 22:59 ` Glenn Morris
@ 2017-04-01 11:12 ` Marco Maggi
2017-04-02 15:35 ` Glenn Morris
0 siblings, 1 reply; 4+ messages in thread
From: Marco Maggi @ 2017-04-01 11:12 UTC (permalink / raw)
To: Glenn Morris; +Cc: 26307
Glenn Morris wrote:
> Marco Maggi wrote:
>> (defconst smtpmail-auth-supported '(cram-md5 plain login)
>> "List of supported SMTP AUTH mechanisms.
>> The list is in preference order.")
>> it would be useful to have a public API mechanism to change such order
>> in case the server misbehaves when using the cram-m5 method.
> Intead of recompiling, you can add to your .emacs:
> (with-eval-after-load 'smtpmail
> (setq smtpmail-auth-supported '(login cram-md5 plain)))
> Perhaps no Emacs change is needed then?
But the symbol is defined as a constant, so it would be bad style? It
is also undocumented. Ideally one should be able to select such
configuration on a per-server basis.
--
Marco Maggi
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#26307: 25.1; smtpmail hard-coded auth mechanism order does not allow coping with misbehaving servers
2017-04-01 11:12 ` Marco Maggi
@ 2017-04-02 15:35 ` Glenn Morris
0 siblings, 0 replies; 4+ messages in thread
From: Glenn Morris @ 2017-04-02 15:35 UTC (permalink / raw)
To: Marco Maggi; +Cc: 26307
Marco Maggi wrote:
>> (with-eval-after-load 'smtpmail
>> (setq smtpmail-auth-supported '(login cram-md5 plain)))
>
>> Perhaps no Emacs change is needed then?
>
> But the symbol is defined as a constant, so it would be bad style? It
> is also undocumented. Ideally one should be able to select such
> configuration on a per-server basis.
It's (presumably) a constant because in normal operation there's no need
to change it, but if you have a special need to change it, it's easy to
do so.
Personally I don't see a need to add complexity to Emacs to cater to
misconfigured servers.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-04-02 15:35 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-03-30 6:54 bug#26307: 25.1; smtpmail hard-coded auth mechanism order does not allow coping with misbehaving servers Marco Maggi
2017-03-31 22:59 ` Glenn Morris
2017-04-01 11:12 ` Marco Maggi
2017-04-02 15:35 ` Glenn Morris
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.