patchGNU Mailutils - Patches: patch #10439, smtp capa list uninitialized when...


You are not allowed to post comments on this tracker with your current authentication level.

patch #10439: smtp capa list uninitialized when a single line answer is received for EHLO request

Submitter:  Christophe Deleuze <deleuzec>
Submitted:  Fri 15 Mar 2024 10:16:40 PM UTC
Category:  None Priority:  5 - Normal
Status:  Done Privacy:  Public
Assigned to:  gray Open/Closed:  Open

Fri 29 Mar 2024 01:47:47 PM UTC, comment #2: 

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.

Christophe Deleuze <deleuzec>
Fri 22 Mar 2024 12:36:52 PM UTC, comment #1: 

Hi Christophe,

Thanks a lot for your patch! I believe that attempting to issue EHLO command
in the wrong state is the main reason for this behavior. Therefore I have pushed
the following patch:

Sergey Poznyakoff <gray>
Group administrator
Fri 15 Mar 2024 10:16:40 PM UTC, original submission:  

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!)

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 [] from localhost [] 56584
  |  * 220 hello
  |    EHLO LC1758
  |  * 250 ok
  |    EHLO LC1758
  |  * 250 ?
  |    EHLO LC1758
  |  * 250 excellence ?
  |    EHLO LC1758
  |  * 250 innovation !
  |    MAIL FROM:<>
  |  * 250 ok
  |    RCPT TO:<>
  |  * 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!

Christophe Deleuze <deleuzec>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #55842:  smtp-capa.patch added by deleuzec (1KiB - text/x-patch)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by gray (Posted a comment)
  • -email is unavailable- added by deleuzec (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.


    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-03-22 gray StatusNone Done
        Assigned toNone gray
    2024-03-15 deleuzec Attached File- Added smtp-capa.patch, #55842

    Back to the top

    Powered by Savane 3.13-b921.
    Corresponding source code