#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

Reply via email to