Pourquoi sendmail ajoute-t-il un return de chariot supplémentaire dans les en-têtes?

J'ai reçu SendMail 8.14.4 sur un server CentOS 5.

Un user au Japon envoie un message et lorsqu'il est traité par le server, SendMail ajoute un return de voiture supplémentaire pour une raison quelconque.

Le courrier électronique contient un en-tête X avec des valeurs qui (vraisemblablement) contiennent des caractères internationaux. Je dis "vraisemblablement" parce que lorsque j'examine la source MIME avec le bloc-notes ++, je vois des bizarreries comme STX et CAN .

J'ai pu réduire la scope des tests à ce sujet:

entrez la description de l'image ici

Si je l'envois par Sendmail, il en résulte que SendMail en fin de count:

entrez la description de l'image ici (ips, Q-ID et nom d'hôte ont changé pour protéger l'innocent)

Maintenant, évidemment, un drapeau rouge potentiel ici: la valeur d'en-tête commence par un devis mais n'a pas de fermeture. Est-ce que cela exige des normes RFC? Ou cette partie est-elle un hareng rouge?

Le résultat final est que les valeurs d'en-tête fuient dans le corps du message:

entrez la description de l'image ici

Des idées sur pourquoi sendmail ajoute le return de chariot supplémentaire?

C'est assez simple en fait: RFC 2822 section 2.2.3 permet des en-têtes longs, où un en-tête est un nom de champ suivi d'un : plier et continuer sur la ligne suivante, tant que (simplifié) que la ligne suivante commence par un espace .

La règle générale est que partout où cette norme permet de plier l'espace blanc (pas simplement les caractères WSP), un CRLF peut être inséré avant tout WSP. Par exemple, le champ d'en-tête:
Subject: This is a test
peut être représenté comme suit:

 Subject: This is a test 

La ligne 3 de l'input d'origine ne commence pas avec un espace, mais avec le caractère c et ne contient pas deux points : ce qui ne constitue pas la continuation de l'en-tête précédent ni le champ d'en-tête suivant (§2.2).

Cela marque la fin des en-têtes …

Et le début du corps.

Sendmail "corrige" ce message mal formé et ajoute la ligne vide requirejse entre ce qu'il perçoit comme fin des en-têtes et le début du corps.

Une simple session de mess telnet peut reproduire ce comportement:

 [user@example ~]$ telnet localhost 25 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. <<< 220 example.com ESMTP Sendmail 8.14.4/8.14.4; Fri, 17 Jul 2015 20:29:26 +0200 helo localhost <<< 250 example.com Hello localhost [127.0.0.1], pleased to meet you mail from:me@localhost <<< 250 2.1.0 me@localhost... Sender ok RCPT TO:user@example.com <<< 250 2.1.5 user@example.com... Recipient ok data <<< 354 Enter mail, end with "." on a line by itself Subject: test X-header: do not try this at home start the body . <<< 250 2.0.0 t6HITQXA020072 Message accepted for delivery quit 

Ce qui donne lieu à un message similaire à celui de votre exemple:

 [user@example ~/Maildir/new]$ cat 1437157845.20091_2.example.com Return-Path: <me@example.com> X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on example.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, MISSING_HEADERS autolearn=no version=3.3.1 Received: from localhost (localhost [127.0.0.1]) by example.com (8.14.4/8.14.4) with SMTP id t6HITQXA020072 for herman@example.com; Fri, 17 Jul 2015 20:30:06 +0200 Date: Fri, 17 Jul 2015 20:29:26 +0200 From: me@example.com Message-Id: <201507171830.t6HITQXA020072@example.com> Subject: test X-header: do not try this at home start the body 

Avec une nouvelle ligne supplémentaire entre la continuité d'en-tête d'origine et le «nouveau» démarrage du corps.