« SMTPSENT. BareLineFeedsAreIllegal"rapport de non-remise reçu par les utilisateurs Exchange Online ou EOP dans Office 365 dédié/ITAR

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 2998901
PROBLÈME
Les utilisateurs d'Exchange en ligne ou d'une Protection en ligne Exchange pas un message e-mail attendu. Si vous effectuez un suivi sur le message, vous trouvez que la remise du message a échoué et qu'un rapport de non-remise (NDR) qui contient le message d'erreur suivant a été généré :
SMTPSEND. BareLinefeedsAreIllegal ; le message contient des sauts de ligne vierge, qui ne peut pas être envoyé via des données
Les utilisateurs ne peuvent pas avez rencontré ce problème par le passé lorsqu'ils utilisés Forefront Online Protection for Exchange (FOPE).
CAUSE
Ce problème se produit si l'agent de transfert des messages (MTA) source n'a pas ajouter la combinaison de CR-LF attendue à la fin du message en procédant comme décrit dans RFC Request For Comments () 2822.
Solution
Pour résoudre ce problème, effectuez l'une des valeurs suivantes, selon votre situation :
  • Demande que l'expéditeur corriger le format du message. Cette erreur se produit fréquemment avec les expéditeurs en bloc et les messageries automatiques (par exemple, les rapports ou les factures).
  • Activer ESMTP (Extended SMTP) sur le serveur de réception pour que le message peut être envoyé à l'aide de CHUNKING ou la commande BDAT. Aucun des thesemethods dépend de la combinaison de CR-LF pour signaler la fin du message. Pour plus d'informations, reportez-vous à la section.Extensions de protocole SMTP.
  • Si l'expéditeur ne peut pas corriger les messages envoyés, ou si l'écart doit relier jusqu'à ce que le format du message est corrigé, le destinataire peut créer une règle de transport entrant pour ajouter une décharge de responsabilité aux messages d'un expéditeur qui pose problème. L'avis de non-responsabilité ajoutera la combinaison retour chariot-saut de ligne attendue pour le message afin qu'il puisse être remis. (Cette disclaimermay se composent d'un seul caractère comme un point ou un tiret).
Plus d'informations
Pour plus d'informations sur la façon d'effectuer un suivi des messages, reportez-vous à la section.Suivi d'un message électronique.

Pour plus d'informations sur la façon de créer des textes d'exclusion, consultez Exclusion de responsabilité à l'échelle de l'organisation, des signatures, des pieds de page ou les en-têtes.

Besoin d'aide ? Accédez à la Communauté Office 365 .

Avertissement : Cet article a été traduit automatiquement.

Propriétés

ID d'article : 2998901 - Dernière mise à jour : 01/17/2016 12:58:00 - Révision : 4.0

Microsoft Exchange Online, Microsoft Exchange Online Protection

  • o365e o365m o365p o365022013 o365 o365a eop kbmt KB2998901 KbMtfr
Commentaires