#3394: smtp authentication: AUTH command is not sent to server when needed
----------------------+-----------------------------------------------------
Reporter: grobian | Owner: mutt-dev
Type: defect | Status: closed
Priority: major | Milestone: 1.6
Component: mutt | Version: 1.5.20
Resolution: invalid | Keywords:
----------------------+-----------------------------------------------------
Changes (by me):
* status: new => closed
* resolution: => invalid
Old description:
> forwarded from http://bugs.gentoo.org/show_bug.cgi?id=309715
>
> When connecting to the ESMTP server mutt does not send proper AUTH
> command.
> This results in the following server response (taken from ~/.muttdebug0):
> 6< 530 5.7.0 No AUTH command has been given.
>
> Mutt itself prints the following in the status line:
> SMTP session failed: 530 5.7.0 No AUTH command has been given.
>
> Moreover, if mutt is compiled with gnutls use-flag enabled, an attempt to
> send
> the email leads to hang up, so only `killall -9 mutt` helps.
> If gnutls is disabled, mutt doesn't hang up but gives the error mentioned
> below.
>
> mutt-1.5.20.-r13 shows the same behavior.
>
>
> Reproducible: Always
>
> Steps to Reproduce:
> 1. Get an account on ESMTP server (in particular, if possible, Sun Java
> System
> Messaging Server 7u2-7.02)
> 2. Try to send an email via this server using mutt.
>
>
> Actual Results:
> Email is not sent.
> mutt hangs up in case of gnutls enabled.
>
> Expected Results:
> Message is sent.
> mutt does not hang up.
>
> It seems like this 'Sun Java System Messaging Server' asks for additional
> authentication after starttls have been executed. And mutt does not
> provide
> this additional authentication.
>
> ...
> 6> STARTTLS^M
> 6< 220 2.5.0 Go ahead with TLS negotiation.
> ...
> 6< 250-AUTH PLAIN LOGIN
> 6< 250-AUTH=LOGIN PLAIN
> ... now server wants an AUTH command (if my guess is right), but mutt
> sends:
> 6> MAIL FROM:<[email protected]>^M
> ... which results in:
> 6< 530 5.7.0 No AUTH command has been given.
>
> Please find the additional debug logs as attachments on the Gentoo bug.
>
> Note that mutt-1.5.20-r13 includes a (very) large amount of patches
> grabbed from hg, mainly selected on being a regression or bugfix. The
> applied patches are basically from
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/mail-client/mutt/files/
> mutt-1.5.20-*.
New description:
forwarded from http://bugs.gentoo.org/show_bug.cgi?id=309715
When connecting to the ESMTP server mutt does not send proper AUTH
command.
This results in the following server response (taken from ~/.muttdebug0):
6< 530 5.7.0 No AUTH command has been given.
Mutt itself prints the following in the status line:
SMTP session failed: 530 5.7.0 No AUTH command has been given.
Moreover, if mutt is compiled with gnutls use-flag enabled, an attempt to
send
the email leads to hang up, so only `killall -9 mutt` helps.
If gnutls is disabled, mutt doesn't hang up but gives the error mentioned
below.
mutt-1.5.20.-r13 shows the same behavior.
Reproducible: Always
Steps to Reproduce:
1. Get an account on ESMTP server (in particular, if possible, Sun Java
System
Messaging Server 7u2-7.02)
2. Try to send an email via this server using mutt.
Actual Results:
Email is not sent.
mutt hangs up in case of gnutls enabled.
Expected Results:
Message is sent.
mutt does not hang up.
It seems like this 'Sun Java System Messaging Server' asks for additional
authentication after starttls have been executed. And mutt does not
provide
this additional authentication.
...
6> STARTTLS^M
6< 220 2.5.0 Go ahead with TLS negotiation.
...
6< 250-AUTH PLAIN LOGIN
6< 250-AUTH=LOGIN PLAIN
... now server wants an AUTH command (if my guess is right), but mutt
sends:
6> MAIL FROM:<[email protected]>^M
... which results in:
6< 530 5.7.0 No AUTH command has been given.
Please find the additional debug logs as attachments on the Gentoo bug.
Note that mutt-1.5.20-r13 includes a (very) large amount of patches
grabbed from hg, mainly selected on being a regression or bugfix. The
applied patches are basically from
http://sources.gentoo.org/viewcvs.py/gentoo-x86/mail-client/mutt/files/
mutt-1.5.20-*.
--
Comment:
as noted by https://bugs.gentoo.org/show_bug.cgi?id=309715#c7 the auth
problem is due to the lack of a specified username.
The SMTP protocol doesn't allow for a client to know a priori whether
server policy requires authentication for some action. The AUTH keyword
merely specifies which mechanisms the server supports.
The issue with hanging under GNUTLS is a separate issue and another bug
should be filed if that is still the case.
--
Ticket URL: <http://dev.mutt.org/trac/ticket/3394#comment:1>
Mutt <http://www.mutt.org/>
The Mutt mail user agent