ACOMBA

SMTP — distinguer fournisseur, chiffrement, authentification et autorisations

SMTP — distinguer fournisseur, chiffrement, authentification et autorisations

Article historique révisé

La procédure a été réécrite ou complétée avec les sources indiquées ci-dessous. L’ancienne fiche est conservée dans les archives éditoriales du lot; les précautions Uni-Action restent distinctes des instructions des éditeurs.

SMTP — distinguer fournisseur, chiffrement, authentification et autorisations

Contexte : Envoi depuis un logiciel d’entreprise vers Microsoft 365/Exchange Online ou Outlook.com. Compatibilité Acomba à vérifier pour la version et le mode utilisés.

Validation : Paramètres et contrôles de plateforme officiels. Aucun bulletin ACCEO privé ni authentification Acomba réelle examiné.

Solution documentée

Microsoft distingue soumission authentifiée, relais et Direct Send. Exchange Online documente smtp.office365.com, le port 587 recommandé et TLS; Outlook.com documente smtp-mail.outlook.com, 587, STARTTLS et OAuth2. Dans Exchange Online, les paramètres SMTP AUTH par boîte et par organisation, ainsi que les stratégies de sécurité, sont des vérifications distinctes.

Procédure et diagnostic proposés par Uni-Action

  1. Identifier le mode réel : message remis à un client local ou envoi SMTP direct. Relever la version précise du logiciel et le service hébergeant la boîte.
  2. Comparer le serveur, le chiffrement et l’authentification à la documentation du fournisseur, sans réutiliser un ancien tableau d’opérateurs comme liste actuelle.
  3. Pour Microsoft 365, faire examiner par l’administrateur les politiques et la boîte concernée. Une vérification réseau réussie n’établit pas le droit d’envoyer.
  4. Tester un seul message fictif vers une boîte autorisée et conserver séparément refus de connexion, refus d’identité, refus d’expéditeur et absence de pièce jointe.

Précautions

Ne pas désactiver MFA ou les protections globales. Ne pas ouvrir de relais public. Si un mode est interdit par politique, faire choisir une intégration autorisée plutôt que contourner cette politique.

Contrôle

Confirmer réception, expéditeur réel et ouverture de la pièce jointe; éviter toute répétition de factures réelles pendant les essais.

Limites

Pas de calendrier Basic Auth affirmé, pas de promesse de compatibilité Acomba 16.x sur la foi d’un bulletin recopié dans un forum. POP/IMAP entrant ne définit pas le serveur sortant.

Procédures internes

Sources et niveau de validation

Vérifiez le produit et la version indiqués avant de suivre ce guide. Les étapes synthétisent les sources ci-dessous; les contrôles et précautions Uni-Action sont des ajouts éditoriaux.

  • Exchange Online — activer ou désactiver SMTP AUTHofficial_platform · Ne pas transformer une explication du paramétrage en consigne de désactiver les protections de toute l’organisation. · Consulté le 2026-09-29
  • Microsoft 365 — envoi SMTP d’une applicationofficial_platform · Aucune compatibilité de version Acomba n’est certifiée par cette documentation Microsoft. Le calendrier exact de retrait Basic Auth n’a pas été vérifié ici. · Consulté le 2026-09-29
  • Outlook.com — paramètres SMTP et OAuth2official_platform · Compte personnel Outlook.com; ne pas transposer ses paramètres à Exchange Online. La phrase générique sur l’identité des serveurs contredit le tableau; utiliser les entrées explicitement nommées SMTP. · Consulté le 2026-09-29