Hi Sergey,

Thanks for your quick handling of this.  I'm not really surprised your
patch is different since I looked for the most direct/local fix, without
much insight about the whole program logic.

In mailutils send, when the EHLO request gets a single-line 250 answer,
smtp->capa isn't changed and it thus keeps its NULL value, i.e. an
uninitialized list.  I believe it should be set to the empty list, as
the single-line 250 answer should be interpreted as providing an empty
list of capabilities (honestly, this is not clearly stated in the RFCs,
but it seems to me to be the most reasonable thing to do).

This also happens when the EHLO is refused by a 502 (or alike) answer:
the client (rightfully) tries a HELO instead, but smtp->capa keeps in
NULL value.  The attached patch is a proposal to solve these two (tiny!)
problems.


Some details

  In the current code, in function mu_smtp_response, smtp->mlrepl is
  initialized to the empty list (by the _mu_smtp_init_mlist(smtp)) only
  in the case of a multi-line answer, but its value is copied to
  smtp->capa in all cases. The patch below moves the initialization out
  of the if testing for a multi-line answer.  The result is that
  smtp->capa is then set to the actual list of capabilities received
  (multi-line answer) or to an empty list (single-line answer).

  ,----
  | diff --git a/libproto/mailer/smtp_io.c b/libproto/mailer/smtp_io.c
  | index 72c9740b4..c1fed2cf4 100644
  | --- a/libproto/mailer/smtp_io.c
  | +++ b/libproto/mailer/smtp_io.c
  | @@ -77,6 +77,10 @@ mu_smtp_response (mu_smtp_t smtp)
  |      }
  |    memcpy (smtp->replcode, smtp->rdbuf, 3);
  |    smtp->replcode[3] = 0;
  | +
  | +  rc = _mu_smtp_init_mlist (smtp);
  | +  MU_SMTP_CHECK_ERROR (smtp, rc);
  | +
  |    if (smtp->rdbuf[3] == '-')
  |      {
  |        smtp->flags |= _MU_SMTP_MLREPL;
  | @@ -93,8 +97,6 @@ mu_smtp_response (mu_smtp_t smtp)
  |        smtp->flbuf[n - 1] = 0;
  |        smtp->replptr = smtp->flbuf;
  | 
  | -      rc = _mu_smtp_init_mlist (smtp);
  | -      MU_SMTP_CHECK_ERROR (smtp, rc);
  |        do
  |  {
  |            char *p;
  `----

  The current behavior leads to something very suprising when such a
  single-line 250 answer is given to the EHLO request: the EHLO is sent
  three more times, and then the communication makes normal progress.
  This is caused by the code successively testing for the STARTTLS,
  AUTH, and SIZE capabilities.  Since smtp->capa wasn't initialized,
  each call to mu_smtp_capa_test triggers mu_smtp_ehlo in an attempt to
  initialize the capabilities list.

  Here's a transcript of a communication between mailutils send and such
  an "SMTP server" replying to EHLO with a single-line 250 answer
  (actually just me typing SMTP answers in a netcat):

  ,----
  |    connect to [127.0.0.1] from localhost [127.0.0.1] 56584
  |  * 220 hello
  |    EHLO LC1758
  |  * 250 ok
  |    EHLO LC1758
  |  * 250 ?
  |    EHLO LC1758
  |  * 250 excellence ?
  |    EHLO LC1758
  |  * 250 innovation !
  |    MAIL FROM:<lulu@example.com>
  |  * 250 ok
  |    RCPT TO:<jp@example.com>
  |  * 250 ok
  |    DATA
  |  * 354 vas y toto
  |    From: -email is unavailable-
  |    To: -email is unavailable-
  |    Subject: yay!
  |   
  |    What's up doc?
  |    .
  |  * 250
  |    QUIT
  |  * 221
  `----

  As for the HELO case, the proposed modification is simply:

  ,----
  | diff --git a/libproto/mailer/smtp_ehlo.c b/libproto/mailer/smtp_ehlo.c
  | index 5cc249fa9..cd828e031 100644
  | --- a/libproto/mailer/smtp_ehlo.c
  | +++ b/libproto/mailer/smtp_ehlo.c
  | @@ -122,6 +122,7 @@ mu_smtp_ehlo (mu_smtp_t smtp)
  |        status = mu_smtp_response (smtp);
  |        MU_SMTP_CHECK_ERROR (smtp, status);
  |        smtp->flags &= ~_MU_SMTP_ESMTP;
  | +      smtp->capa = smtp->mlrepl;  /* this must be the empty list */
  |        if (smtp->replcode[0] != '2')
  |  return MU_ERR_REPLY;
  |      }
  `----

  Now, this does not sound like a serious issue at all, since I doubt
  that SMTP servers that provide a single line answer to a EHLO request,
  or don't understant EHLO do still exist.  For the record I discovered
  this during networking labs where I ask students to use netcat to
  simulate SMTP servers against mailutils send based scripts.  I was
  puzzled by this bizarre behavior and wanted to understand what was
  going on...

  Hey, it was fun tracking this down!

  Any comment welcome!