Outlook.com / Hotmail : erreur 5.6.11 « Bare Line Feeds » (CRLF) — diagnostic et correctifs

Des e‑mails envoyés depuis Outlook.com/Hotmail vers un domaine précis reviennent en erreur 5.6.11 (« bare line feeds »). Voici comment comprendre le problème, le diagnostiquer rapidement et appliquer des correctifs durables côté expéditeur et côté serveur.

Sommaire

Vue d’ensemble du problème

Envoi depuis Outlook.com (web) ou Hotmail vers un domaine destinataire précis.
Le serveur du destinataire renvoie un NDR 5.6.11 signalant la présence de bare line feeds (LF non précédé d’un CR) dans le message.
Contexte : Microsoft a récemment renforcé la conformité RFC, ce qui met en évidence les messages mal formés. Si le serveur distant est strict et ne tolère pas ces caractères, il rejette l’e‑mail.

Explication technique : qu’est‑ce qu’un « bare line feed » ?

En SMTP et selon les RFC (notamment RFC 5322/RFC 5321), toute fin de ligne doit être encodée avec la séquence CRLF (Carriage Return + Line Feed), soit \r\n. Un bare line feed correspond à un LF (\n) non immédiatement précédé d’un CR (\r). La présence d’un simple \n dans les en‑têtes ou le corps du message viole la norme et peut entraîner un rejet.

Origines fréquentes des bare LFs :

Source possible	Exemple
Copié‑collé depuis un éditeur qui force `\n` (éditeurs Unix, Notepad++ mal paramétré)	Signatures, blocs de code, extraits HTML collés
Génération de courrier par un script ou un add‑in	Macros VBA, automatisations PowerShell, scripts Python/PHP/Node
Application courriel non à jour	Anciens clients IMAP/SMTP, plug‑ins tiers obsolètes

Symptômes et messages d’erreur observés

Retour immédiat d’un NDR avec 5.6.11, souvent accompagné d’un texte du type : « Message content rejected (bare line feed) », « Invalid end‑of‑line », « Body type not supported ».
L’incident se produit uniquement vers un ou quelques domaines précis ; les autres destinataires reçoivent le message normalement.
Le problème peut disparaître si l’e‑mail est renvoyé en « texte brut » sans signature ni pièce jointe.

Pourquoi cela arrive‑t‑il maintenant ?

Plusieurs opérateurs, dont Microsoft, ont durci l’application des RFC. Depuis 2023, les messages qui contiennent des anomalies de formatage (comme un simple \n en fin de ligne) sont davantage détectés et rejetés, soit par l’émetteur, soit par le récepteur. Cette rigueur vise à réduire les vecteurs d’abus (injections d’en‑têtes, contournement de filtres, ambiguïtés d’analyse MIME) et à assurer une interopérabilité propre entre MTAs.

Diagnostic pas à pas

1) Confirmer le périmètre

Tester un envoi vers plusieurs domaines (professionnel, personnel, autre fournisseur). Si l’échec ne concerne qu’un domaine précis, la chaîne de réception de ce domaine est co‑responsable (trop stricte ou non normalisante).
Tester depuis un autre client : nouveau Outlook, Outlook pour Windows/macOS/iOS/Android, Thunderbird, Apple Mail. Si l’un d’eux passe, l’origine est probablement le générateur de message initial (éditeur dans le navigateur, signature, add‑in, etc.).

2) Simplifier le message

Envoyer un message texte brut sans signature ni images ni pièces jointes.
Si le message passe, réintroduire progressivement les éléments (signature, images, copier‑coller, liens) pour isoler le déclencheur.

3) Inspecter un EML

Exportez le message en .eml et ouvrez‑le dans un éditeur hexadécimal ou un éditeur qui affiche les fins de ligne. Recherchez des séquences 0A non précédées de 0D ; dans un flux conforme, chaque fin de ligne est 0D 0A.

# Exemple de commande (Linux/macOS) pour visualiser les octets
xxd -g 1 -l 512 message.eml | sed -n '1,40p'
# Vous devriez voir 0d 0a pour toute fin de ligne. Un 0a isolé est suspect.

4) Reproduire via SMTP interactif

En environnement de test, établir une session SMTP vers un serveur de lab et injecter délibérément un bare LF pour valider la détection.

# (Exemple) Ouverture d'une session de test
telnet smtp.exemple.lan 25
EHLO test.local
MAIL FROM:<expediteur@exemple.lan>
RCPT TO:<dest@exemple.lan>
DATA
Subject: Test LF
From: Expéditeur <expediteur@exemple.lan>

Ligne correcte
Ligne incorrecte
.
QUIT

Le serveur conforme doit soit normaliser avant la remise, soit rejeter avec un message explicite.

5) Examiner la chaîne de transit

Déterminez s’il existe des passerelles (antivirus, DLP, réécriture de liens, disclaimers) qui pourraient altérer les fins de ligne ou réencoder des parties MIME.
Vérifiez que les composants intermédiaires (reverse proxy SMTP, filtrage SaaS, appliances) préservent les CRLF et n’appliquent pas de transformations « Unix‑style ».

Solutions et bonnes pratiques (résumé)

Action	Détails
Contrôler le client d’envoi	Vérifier que l’éditeur/le plug‑in insère `\r\n`. Tester un autre navigateur ou l’application Outlook pour Windows/macOS/iOS/Android.
Envoyer depuis un autre programme	Un essai avec le nouveau Outlook ou un client conforme (Thunderbird, Apple Mail) confirme l’origine côté générateur de message.
Nettoyer le contenu avant envoi	Coller le texte dans un éditeur qui convertit les fins de ligne (Bloc‑notes Windows, Word en mode texte) puis renvoyer.
Scripts et automatisation	Ajouter explicitement `\r\n` dans tout appel SMTP (`"\r\n".join(lines)` en Python, `vbCrLf` en VBA).
Impliquer l’administrateur du domaine destinataire	Le serveur cible peut être configuré pour normaliser les LFs ou mettre à jour son MTA afin de respecter les exigences modernes.
Solution provisoire	Tant que le serveur de réception n’est pas corrigé, utiliser une autre adresse (Gmail, domaine secondaire) pour joindre ces correspondants.

Exemples de correction côté scripts et automatisations

Python (smtplib/email)

Forcer le CRLF lors de la construction du message :

from email.message import EmailMessage
from email import policy
import smtplib

def to_crlf(s: str) -> str:
# Normalise toutes les variantes vers CRLF
return s.replace('\r\n', '\n').replace('\r', '\n').replace('\n', '\r\n')

msg = EmailMessage()
msg['Subject'] = 'Test CRLF'
msg['From'] = '[expediteur@example.com](mailto:expediteur@example.com)'
msg['To'] = '[dest@example.net](mailto:dest@example.net)'
body = "Ligne 1\nLigne 2\nLigne 3"     # Entrées diverses possibles
msg.set_content(to_crlf(body))

with smtplib.SMTP('smtp.example.com', 587) as s:
s.starttls()
s.login('user','pass')
# Utilise la policy SMTP pour des fins de ligne conformes
s.sendmail(msg['From'], [msg['To']], msg.as_string(policy=policy.SMTP))

PowerShell (.NET SmtpClient)

$nl   = "`r`n"
$lines = @("Ligne 1","Ligne 2","Ligne 3")
$body = [string]::Join($nl, $lines)

$msg = New-Object System.Net.Mail.MailMessage
$msg.From = "[expediteur@example.com](mailto:expediteur@example.com)"
$msg.To.Add("[dest@example.net](mailto:dest@example.net)")
$msg.Subject = "Test CRLF"
$msg.Body = $body
$msg.IsBodyHtml = $false

$cli = New-Object System.Net.Mail.SmtpClient("smtp.example.com",587)
$cli.EnableSsl = $true
$cli.Credentials = New-Object System.Net.NetworkCredential("user","pass")
$cli.Send($msg) </code></pre>

<h3>VBA (Outlook/Office)</h3>
<pre><code>Sub SendCrLfMail()
  Dim o As Outlook.MailItem
  Set o = Application.CreateItem(olMailItem)
  o.To = "dest@example.net"
  o.Subject = "Test CRLF"
  o.Body = "Ligne 1" &amp; vbCrLf &amp; "Ligne 2" &amp; vbCrLf &amp; "Ligne 3"
  o.Send
End Sub
</code></pre>

<h3>Node.js (Nodemailer)</h3>
<pre><code>const nodemailer = require('nodemailer');

(async () => {
const transporter = nodemailer.createTransport({
host: 'smtp.example.com',
port: 587,
secure: false
}, {
// Force CRLF
newline: 'windows'
});

await transporter.sendMail({
from: '[expediteur@example.com](mailto:expediteur@example.com)',
to: '[dest@example.net](mailto:dest@example.net)',
subject: 'Test CRLF',
text: 'Ligne 1\r\nLigne 2\r\nLigne 3'
});
})(); </code></pre>

<h3>PHP (en‑têtes et corps)</h3>
<pre><code>&lt;?php
$to = "dest@example.net";
$subject = "Test CRLF";
$headers = "From: expediteur@example.com\r\n" .
           "MIME-Version: 1.0\r\n" .
           "Content-Type: text/plain; charset=UTF-8\r\n";
$body = "Ligne 1\r\nLigne 2\r\nLigne 3\r\n";
mail($to, $subject, $body, $headers);
?&gt;
</code></pre>

<h2>Actions côté administrateur du domaine destinataire</h2>
<p>Lorsque le flux entrant est particulièrement strict, vous pouvez :</p>
<ul>
  <li><strong>Mettre à jour</strong> le MTA et les filtres intermédiaires afin qu’ils gèrent correctement les flux modernes et n’introduisent pas de conversions de fins de ligne indésirables.</li>
  <li><strong>Vérifier les appliances</strong> (DLP, antivirus, réécriture d’URL, disclaimers) : certaines réécritures peuvent <em>réencoder</em> le corps et produire des <code>\n</code> isolés.</li>
  <li>En dernier recours, <strong>normaliser</strong> les fins de ligne dans un pré‑filtre/Content‑Filter dédié (milter, proxy SMTP) qui re‑sérialise le message en <code>CRLF</code> avant la remise interne. Cette option doit rester exceptionnelle et contrôlée.</li>
  <li><strong>Rendre les rejets explicites</strong> : un code 5.6.11 clair, avec mention « bare line feed », facilite la remédiation côté expéditeur.</li>
</ul>

<h2>Outils de contrôle et scripts de validation</h2>
<table>
  <thead>
    <tr>
      <th>Objectif</th>
      <th>Commande / Pseudo‑code</th>
      <th>Attendu</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Repérer un <code>\n</code> non précédé de <code>\r</code> dans un EML</td>
      <td><pre><code>grep -nP "[^\r]\n" message.eml</code></pre></td>
      <td>Retourne les lignes suspectes</td>
    </tr>
    <tr>
      <td>Assainir un corps avant envoi (shell)</td>
      <td><pre><code>perl -pe 's/\r\n?/\n/g; s/\n/\r\n/g' &lt; in.txt &gt; out_crlf.txt</code></pre></td>
      <td>Convertit toutes les fins de ligne en CRLF</td>
    </tr>
    <tr>
      <td>Vérifier les octets autour des fins de ligne</td>
      <td><pre><code>xxd -g 1 -c 32 message.eml | less</code></pre></td>
      <td>Visualisation 0d 0a vs 0a isolé</td>
    </tr>
  </tbody>
</table>

<h2>Cas fréquents et pièges</h2>
<ul>
  <li><strong>Signatures riches</strong> : les éditeurs WYSIWYG intégrés aux navigateurs peuvent insérer des retours « Unix‑style » dans des blocs collés depuis d’autres outils.</li>
  <li><strong>Génération multipart/mixed</strong> : une frontière MIME (boundary) mal sérialisée provoque des erreurs 5.6.x lorsqu’une partie est terminée par <code>\n</code> seul.</li>
  <li><strong>Disclaimers automatiques</strong> : l’ajout d’un bloc HTML par un proxy peut convertir le flux en <code>\n</code> si la bibliothèque sous‑jacente n’impose pas <code>CRLF</code>.</li>
  <li><strong>Scripts hybrides</strong> : concaténer des morceaux provenant de sources hétérogènes (fichiers Windows + buffers Unix) sans normalisation préalable est une cause classique.</li>
</ul>

<h2>Procédure de mitigation « express » en entreprise</h2>
<ol>
  <li>Basculer temporairement l’émetteur impacté sur un <strong>client conforme</strong> (Outlook pour Windows/macOS) et en <strong>texte brut</strong>.</li>
  <li>Désactiver provisoirement la <strong>signature</strong> et tout add‑in d’édition.</li>
  <li>Mettre en place un <strong>content‑filter d’assainissement</strong> (file d’attente dédiée) pour les domaines sensibles, le temps de corriger la source.</li>
  <li>Informer le destinataire et <strong>ouvrir un ticket</strong> auprès de son administrateur avec l’<strong>EML fautif</strong> et le <strong>NDR</strong>.</li>
</ol>

<h2>Informations complémentaires utiles</h2>
<ul>
  <li><strong>Sécurité accrue</strong> : Microsoft applique les recommandations du <em>RFC 5321 4.1.1.4</em> depuis 2023, d’où la multiplication récente de ce type de rejets.</li>
  <li><strong>Test rapide</strong> : envoyer un message <em>pur texte</em> sans signature ni pièce jointe ; si le rejet disparaît, le problème se situe dans les blocs formatés ajoutés.</li>
  <li><strong>Suivi long terme</strong> : vérifier régulièrement les journaux NDR ; une hausse d’erreurs 5.6.x indique d’autres non‑conformités possibles (encodage MIME, caractères interdits, etc.).</li>
</ul>

<h2>FAQ</h2>
<p><strong>Q : Pourquoi seulement avec Outlook.com (web) ?</strong><br>
R : Parce que l’éditeur dans le navigateur et certains contenus collés (signature riche, code) peuvent introduire des fins de ligne inconsistantes. Le même compte, utilisé via Outlook pour Windows/macOS, sérialise généralement correctement en <code>CRLF</code>.</p>

<p><strong>Q : Les pièces jointes sont‑elles concernées ?</strong><br>
R : Le problème vise surtout les <strong>délimiteurs MIME</strong> et les <strong>en‑têtes/corps</strong>. Une pièce jointe binaire correctement encodée (Base64) ne pose pas problème si les <em>boundaries</em> et les en‑têtes autour respectent <code>CRLF</code>.</p>

<p><strong>Q : L’activation de SMTPUTF8 change‑t‑elle quelque chose ?</strong><br>
R : Non. SMTPUTF8 concerne l’encodage des caractères dans les adresses et les en‑têtes, pas la <strong>séquence de fin de ligne</strong> qui demeure <code>CRLF</code>.</p>

<p><strong>Q : Puis‑je « réparer » côté réception en silence ?</strong><br>
R : C’est possible via un content‑filter qui re‑sérialise, mais cela doit être <strong>encadré</strong>. Corriger côté expéditeur reste préférable pour éviter des surprises ailleurs (archivage, signatures numériques, S/MIME).</p>

<h2>Modèle d’e‑mail de test conforme vs non conforme</h2>
<table>
  <thead>
    <tr>
      <th>Conforme (CRLF)</th>
      <th>Non conforme (LF seul)</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>
        <pre><code>Subject: Test conforme\r\n
From: A &lt;a@example.com&gt;\r\n
To: B &lt;b@example.net&gt;\r\n
MIME-Version: 1.0\r\n
Content-Type: text/plain; charset=UTF-8\r\n
\r\n
Ligne 1\r\n
Ligne 2\r\n
</code></pre>
      </td>
      <td>
        <pre><code>Subject: Test non conforme\n
From: A &lt;a@example.com&gt;\n
To: B &lt;b@example.net&gt;\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
\n
Ligne 1\n
Ligne 2\n

  </td>
</tr>

Checklist de résolution

Étape	Action	Résultat attendu
1	Tester en « texte brut » sans signature	Si OK, contenu enrichi incriminé
2	Essayer un autre client (Outlook desktop / mobile)	Si OK, éditeur web ou add‑in incriminé
3	Analyser un EML à la recherche de `\n` isolés	Identifier l’emplacement exact du défaut
4	Normaliser les fins de ligne dans le script/outil	Plus de bare LFs en sortie
5	Vérifier les passerelles/filtres intermédiaires	Absence de conversions indésirables
6	Échanger avec l’admin du domaine cible	Alignement sur un comportement interopérable

Bonnes pratiques durables

Dans les pipelines d’automatisation, convertir les fins de ligne juste avant l’envoi vers CRLF (fonction utilitaire centralisée).
Configurer les éditeurs (IDE, Notepad++, VS Code) sur le profil CRLF pour les fichiers/rendus destinés aux e‑mails.
Éviter d’assembler des fragments de texte provenant de sources hétérogènes sans normalisation (copier‑coller mixte Windows/Unix).
Surveiller régulièrement les NDR 5.6.x dans les rapports afin de détecter précocement d’autres non‑conformités (MIME, encodages, caractères de contrôle).

Résumé exécutif

L’erreur 5.6.11 liée aux bare line feeds survient lorsqu’un message ne respecte pas la séquence CRLF exigée par les RFC. Elle se manifeste souvent lors d’envois depuis Outlook.com/Hotmail vers des domaines stricts. Le diagnostic repose sur des tests ciblés (texte brut, client alternatif, inspection EML) et la correction consiste à normaliser les fins de ligne dans les clients, scripts et passerelles. À court terme, un contournement (autre adresse/client) peut rétablir la communication ; à long terme, harmonisez la chaîne d’envoi et la politique du serveur destinataire pour une conformité durable.

Rappel condensé

Cause : fin de ligne \n isolée (sans \r).
Où chercher : signature, copier‑coller, add‑ins, scripts, passerelles.
Premiers gestes : texte brut, autre client, EML en hexadécimal.
Correctifs : forcer \r\n, mettre à jour les composants, normaliser prudemment côté réception si nécessaire.

Outlook.com / Hotmail : erreur 5.6.11 « Bare Line Feeds » (CRLF) — diagnostic et correctifs