Un bug amusant de l'outil GNU mailutils

Simulons un serveur SMTP : on lance netcat dans un terminal pour attendre une connexion sur le port TCP 25 :

# netcat -l -p 25 -v
listening on [any] 25 ...

Et dans un autre terminal on utilise mailutils send pour envoyer un mail à notre "serveur" :

$ mailutils send 127.0.0.1 mail.msg

Voici l'échange vu sur le premier terminal (la première ligne est affichée par netcat pour indiquer qu'un client vient de se connecter, les lignes précédées par * sont tapées dans le terminal et donc envoyées au client, les autres sont ce que nous recevons du client) :

   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: lulu@example.com
   To: jp@example.com
   Subject: yay!
   
   What's up doc?
   .
 * 250
   QUIT
 * 221

On répond un 250 ok à la requête EHLO, ce qui semble ne pas satisfaire le client, puisqu'il répète la requête. On choisit de persister avec la même réponse, et cela finit par fonctionner puisque la réponse est acceptée la quatrième fois, permettant à la suite de se dérouler normalement. Ceci est quand même très bizarre et, surtout, embêtant pour un TP où les étudiants doivent simuler avec netcat un serveur SMTP crédible pour mailutils send.

Pour essayer de comprendre ce qui se passe, nous allons utiliser la commande mailutils smtp, qui fournit un shell client smtp permettant de déclencher manuellement les différentes opérations. On l'utilise ici pour se connecter à notre "serveur smtp" afin d'examiner plus précisément les choses. Ci dessous le client est à gauche, le serveur à droite, les lignes précédées d'un * sont tapées le reste n'est qu'affiché. On voit que la réponse 250 smtp.example.com est bien traitée comme une erreur.

* $ mailutils smtp                    * $ netcat -l -v -p 2220
* smtp> connect 127.0.0.1 2222          Connection received ...
  220 smtp.example.com                * 220 smtp.example.com
* smtp> ehlo client.example.com         EHLO client.example.com
  Error: Invalid argument             * 250 smtp.example.com
  smtp> 

On imagine donc que c'est le cas aussi pour mailutils send, et qu'il décide de réessayer, mais on ne voit pas du tout pourquoi cette erreur, à la quatrième occurence, est finalement considérée comme non problématique…

Je vous préviens, le code source de mailutils est un peu touffu, respirons un grand coup et soyons attentif…

while (!done)
  {
    char *s, *line = input_line ();
    [...]  
    /* Remove leading and trailing whitespace from the line.
       Then, if there is anything left, add it to the history list
       and execute it. */
    s = mu_str_stripws (line);

    if (*s)
      {
        [...]
        status = execute_line (s);
        if (status != 0)
          mu_error ("Error: %s", mu_strerror (status));
      }
    free (line);
  }

static mu_smtp_t smtp;

typedef struct _mu_smtp *mu_smtp_t;

[...]

struct _mu_smtp
{
  int flags;
  [...]
  mu_list_t capa;
  [...]
  /* I/O buffers */
  char replcode[4];
  char *replptr;
  
  char *rdbuf;
  [...]
  mu_list_t mlrepl;
  [...]
};

typedef struct _mu_list *mu_list_t;

struct list_data
{
  void *item;
  struct list_data *next;
  struct list_data *prev;
};

struct _mu_list
{
  struct list_data head;
  [...]
};

 status = mu_smtp_create (&smtp);

 smtp = calloc (1, sizeof (*smtp));

static int
com_ehlo (int argc, char **argv)
{
  if (argc == 1)
    {
      if (mu_smtp_test_param (smtp, MU_SMTP_PARAM_DOMAIN))
        {
          mu_error (_("no domain set"));
          return 0;
        }
    }
  else
    mu_smtp_set_param (smtp, MU_SMTP_PARAM_DOMAIN, argv[1]);
  return com_capa (1, argv);
}

static int
com_capa (int argc, char **argv)
{
  mu_iterator_t iterator = NULL;
  int status = 0;

  [...]

      status = mu_smtp_capa_iterator (smtp, &iterator);

      if (status == 0)
        {
          [...]
          mu_iterator_destroy (&iterator);
        }
    }
  return status;
}

int
mu_smtp_capa_iterator (mu_smtp_t smtp, mu_iterator_t *itr)
{
  if (!smtp || !itr)
    return EINVAL;
  if (MU_SMTP_FISSET (smtp, _MU_SMTP_ERR))
    return MU_ERR_FAILURE;
  if (!smtp->capa)
    {
      int rc = mu_smtp_ehlo (smtp);
      if (rc)
        return rc;
    }
  if (!MU_SMTP_FISSET (smtp, _MU_SMTP_ESMTP))
    return MU_ERR_FAILURE;
  return mu_list_get_iterator (smtp->capa, itr);
}

int
mu_smtp_ehlo (mu_smtp_t smtp)
{
  int status;

  [...]
  
  status = mu_smtp_write (smtp, "EHLO %s\r\n",
                          smtp->param[MU_SMTP_PARAM_DOMAIN]);
  MU_SMTP_CHECK_ERROR (smtp, status);
  status = mu_smtp_response (smtp);
  MU_SMTP_CHECK_ERROR (smtp, status);
  if (smtp->replcode[0] == '2')
    {
      smtp->flags |= _MU_SMTP_ESMTP;
      smtp->capa = smtp->mlrepl;
      smtp->mlrepl = NULL;
      mu_list_set_comparator (smtp->capa, capa_comp);
    }
  else if (smtp->replcode[0] == '4')
    return MU_ERR_REPLY;
  else
    {
      status = mu_smtp_write (smtp, "HELO %s\r\n",
                              smtp->param[MU_SMTP_PARAM_DOMAIN]);
      MU_SMTP_CHECK_ERROR (smtp, status);
      status = mu_smtp_response (smtp);
      MU_SMTP_CHECK_ERROR (smtp, status);
      smtp->flags &= ~_MU_SMTP_ESMTP;
      if (smtp->replcode[0] != '2')
        return MU_ERR_REPLY;
    }
  if (smtp->state == MU_SMTP_EHLO)
    smtp->state = MU_SMTP_MAIL;
  return 0;

int
mu_smtp_response (mu_smtp_t smtp)
{
  int rc;
  size_t n;
  
  rc = mu_stream_getline (smtp->carrier, &smtp->rdbuf, &smtp->rdsize, &n);
  MU_SMTP_CHECK_ERROR (smtp, rc);
  if (n == 0)
    MU_SMTP_CHECK_ERROR (smtp, EIO);
  n = mu_rtrim_class (smtp->rdbuf, MU_CTYPE_ENDLN);
  if (n < 3 || !mu_isdigit (smtp->rdbuf[0]))
    {
      mu_diag_output (MU_DIAG_NOTICE,
                      "received invalid reply from SMTP server");
      MU_SMTP_CHECK_ERROR (smtp, MU_ERR_BADREPLY);
    }

  memcpy (smtp->replcode, smtp->rdbuf, 3);
  smtp->replcode[3] = 0;
  if (smtp->rdbuf[3] == '-')
    {
      smtp->flags |= _MU_SMTP_MLREPL;
      [...]

      rc = _mu_smtp_init_mlist (smtp);                           (ref:init)
      MU_SMTP_CHECK_ERROR (smtp, rc);
      do
        {
          char *p;

          rc = mu_stream_getline (smtp->carrier, &smtp->rdbuf, &smtp->rdsize,
                                  &n);
          MU_SMTP_CHECK_ERROR (smtp, rc);
          if (n == 0)
            MU_SMTP_CHECK_ERROR (smtp, EIO);
          n = mu_rtrim_class (smtp->rdbuf, MU_CTYPE_ENDLN);
          if (n < 3 || memcmp (smtp->rdbuf, smtp->replcode, 3))
            {
              mu_diag_output (MU_DIAG_NOTICE,
                              "received invalid reply from SMTP server");
              MU_SMTP_CHECK_ERROR (smtp, MU_ERR_BADREPLY);
            }
          p = strdup (smtp->rdbuf + 4);
          if (!p)
            MU_SMTP_CHECK_ERROR (smtp, ENOMEM);
          mu_list_append (smtp->mlrepl, p);                      (ref:append)
        }
      while (smtp->rdbuf[3] == '-');
    }

  else
    {
      smtp->flags &= ~_MU_SMTP_MLREPL;
      smtp->replptr = smtp->rdbuf + 4;
    }
  return 0;
}

Le problème est donc dans la fonction mu_smtp_response : si la réponse est multi-ligne, le contenu est placé sous forme d'une liste dans smtp->mlrepl, mais si ce n'est pas le cas, smtp->mlrepl reste indéterminé, alors qu'il devrait devenir la liste vide !

On peut corriger facilement ceci en plaçant l'initialisation à la liste vide avant le if pour qu'elle soit effectuée que la réponse soit multi-ligne ou pas :

   smtp->replcode[3] = 0;
 
   rc = _mu_smtp_init_mlist (smtp);     (====)
   MU_SMTP_CHECK_ERROR (smtp, rc);
 
   if (smtp->rdbuf[3] == '-')

Après ce déplacement de deux lignes et compilation, une réponse simple-ligne est acceptée pour le EHLO :

* $ mailutils smtp                    * $ netcat -l -v -p 2220
* smtp> connect 127.0.0.1 2222          Connection received ...
  220 smtp.example.com                * 220 smtp.example.com
* smtp> ehlo client.example.com         EHLO client.example.com
  smtp>                               * 250 smtp.example.com

Et l'envoi d'un message par mailutils send se fait donc maintenant sans EHLO répétés :

$ mailutils send 127.0.0.1 mail.msg    * # netcat -v -l -p 25
                                         listening on [any] 25 ...
                                         connect to [127.0.0.1] from localhost [127.0.0.1] 52090
                                       * 220 salut
                                         EHLO LC1758
                                       * 250 ok
                                         MAIL FROM:<jean.pierre@sender>
                                       * 250 ok
                                         RCPT TO:<lulu@receiver>
                                       * 250 ok
                                         DATA
                                       * 354 go
                                         From: jean.pierre@sender
                                         To: lulu@receiver
                                         Subject: that one

                                         yolo
                                         .
                                       * 250 ok                                         
                                         QUIT
                                       * 221 ok

On a corrigé le problème, mais tout n'est pas encore vraiment éclairci : dans le cas de mailutils send, pourquoi la requête EHLO est-elle répétée et la réponse acceptée la quatrième fois qu'elle est fournie !?

Cet outil n'utilise pas les fonctions com_ehlo etc, qui sont les commandes du shell smtp. Il est défini dans mu/libexec/send.c. Au cours de la conversation, le client a besoin de tester le support d'une extension par le serveur. Pour cela il peut consulter sa liste smtp->capa. Ceci est réalisé par la fonction mu_smtp_capa_test :

libproto/mailer/smtp_capa.c

int
mu_smtp_capa_test (mu_smtp_t smtp, const char *name, const char **pret)
{
  if (!smtp || !name)
    return EINVAL;
  if (MU_SMTP_FISSET (smtp, _MU_SMTP_ERR))
    return MU_ERR_FAILURE;
  if (!smtp->capa)
    {
      int rc = mu_smtp_ehlo (smtp);
      if (rc)
        return rc;
    }
  if (!MU_SMTP_FISSET (smtp, _MU_SMTP_ESMTP))
    return MU_ERR_FAILURE;
  return mu_list_locate (smtp->capa, (void*) name, (void**)pret);
}

Comme on le voit, si smtp->capa est nul, la fonction mu_smtp_ehlo est appelée pour l'initialiser. La fonction mu_list_locate teste si l'élément name est présent dans la liste smtp->capa, si c'est le cas elle retourne 0 et place un pointeur sur l'élément dans *pret.⁴ Mais on a vu qu'avec une réponse simple-ligne, smtp->capa n'était pas modifié, un argument nul sera passé à la fonction mu_list_locate qui retournera une valeur d'erreur (non nulle). Des appels répétés à mu_smtp_capa_test pour tester différentes extensions vont engendrer des appels répétés à mu_smtp_ehlo et donc l'envoi à chaque fois d'une requête EHLO.

Ci dessous la séquence des appels de fonctions au cours de l'exécution complète :

• main (mu/libexec/send.c)

  • mu_mailer_create_from_url

  • mu_mailer_open = libproto/mailer/smtp.c : smtp_open

    • mailer_smtp_init_late

    • mu_smtp_open (libproto/mailer/smtp_open.c)

      • check smtp->state == MU_SMTP_INIT
      • mu_smtp_response – check 2xx
      • smtp->state = MU_SMTP_EHLO
    • mu_smtp_ehlo # le premier EHLO

    • mu_smtp_capa_test STARTTLS

      • mu_smtp_ehlo # déclenché par le test sur STARTTLS

    • mu_smtp_capa_test AUTH

      • mu_smtp_ehlo # déclenché par le test sur AUTH

  • mu_mailer_send_message

    • smtp_send_message (libproto/mailer/smtp.c)

    • mu_smtp_capa_test SIZE

      • mu_smtp_ehlo # le test sur SIZE
  • mu_mailer_close
  • mu_mailer_destroy

Après l'ouverture de la session, le EHLO initial est envoyé. Le client souhaite utiliser l'extension STARTTLS⁵, il teste donc sa présence dans sa liste capa, ce qui déclenche un appel à mu_smtp_ehlo. Il teste ensuite l'extension AUTH pour l'authentification (rfc4954), et enfin l'extension SIZE permettant d'annoncer la taille d'un message avant son envoi (rfc1870). Évidemment aucune de ces extensions n'est utilisée.

Supposons maintenant que notre serveur est ancien et ne comprend pas les requêtes EHLO, il répondra donc par une erreur (par exemple 502 Command not implemented), et le client est censé retenter avec HELO (comme mentionné plus haut, code de mu_smtp_ehlo).

Voici ce qui se passe avec un serveur qui répond 502 à EHLO et 250 OK (simple ligne évidemment) à HELO :

root@LC1758:~# netcat -l -v -p 25
listening on [any] 25 ...
connect to [127.0.0.1] from localhost [127.0.0.1] 58162
220
EHLO LC1758
502
HELO LC1758
250
EHLO LC1758
502
HELO LC1758
250
EHLO LC1758
502
HELO LC1758
250
EHLO LC1758
502
HELO LC1758
250
MAIL FROM:<lulu@example.com>

Le problème est toujours le même. Après une réponse 5xx au EHLO le client essaie avec HELO mais smtp->capa reste égal à NULL ce qui entraîne une tentative de récupérer la liste des capabilities (et donc un appel à mu_smtp_ehlo pour chaque capa que le client aimerait bien utiliser, voir le code en #get-capa).

Puisque notre modification précédente met smtp->mlrepl à la liste vide dans tous les cas, on peut l'utiliser pour fixer la valeur de smtp->capa :

libproto/mailer/smtp_ehlo.c/mu_smtp_ehlo

      status = mu_smtp_write (smtp, "HELO %s\r\n",
                              smtp->param[MU_SMTP_PARAM_DOMAIN]);
      MU_SMTP_CHECK_ERROR (smtp, status);
      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 */ (ligne ajoutée) (====)
      if (smtp->replcode[0] != '2')
	return MU_ERR_REPLY;
    }

Et bien voilà, tout fonctionne maintenant normalement !

Note : le bug a depuis été corrigé, mais pas avec le patch montré ici, voir https://savannah.gnu.org/patch/?10439.