Bonjour,
Mon domaine est htek.be
et j'ai la solution MXPLAN 200 hosting
J'ai mis en place des redirections (via https://www.ovh.com/manager/#/web/email_domain/htek.be) du type xxx@htek.be -> xxx.htek@gmail.com (avec copie en + chez ovh)
Cela fonctionne pour la plupart des mails mais certains arrivent dans la boîte ovh mais pas jusqu'à gmail. Cela semble ne concerner que certains mails de certains envoyeurs (par ex on ne reçoit systématiquement pas les notes d'enlèvement d'un certain fournisseur, mais d'autres mails du même fournisseur peuvent passer).
J'ai fouillé gmail à la recherche des mails, sans succès (j'ai regardé partout où j'ai pu, dossiers spams et autres)
Je n'ai pas de message d'erreur ni chez l'envoyeur ni sur ovh ni sur gmail.
Je n'arrive pas non plus à déterminer ce qu'il y a de particulier dans les mails (et/ou les envoyeurs) qui ne sont pas redirigés, et je ne sais pas reproduire le problème (mes mails de test passent).
J'ai également fouillé ovh manager à la recherche d'un log salvateur mais je n'ai rien trouvé qui pourrait détailler ces non-redirections fantômes.
J'ai une sélection de mails problèmatiques que je peux joindre si c'est utile (ou juste les metadata)
Merci pour votre aide !
Cela semble ne concerner que certains mails de certains envoyeurs
Bonjour,
Comme vous conservez une copie chez OVH, ça va nous aider.
Merci d'extraire les en-têtes SMTP d'un de ces mails qui n'a pas été transmis vers Gmail.
En particulier les en-têtes X-VR-SPAMCAUSE et similaires sont utiles.
Bonjour,
Merci pour votre réponse rapide. Voici :
Return-Path:
Delivered-To: contact@htek.be
Received: from localhost (HELO queue) (127.0.0.1)
by localhost with SMTP; 29 Sep 2022 14:40:21 +0200
Received: from unknown (HELO output48.mail.ovh.net) (192.168.13.112)
by 192.168.9.27 with AES256-GCM-SHA384 encrypted SMTP; 29 Sep 2022 14:40:21 +0200
Received: from vr40.mail.ovh.net (unknown [10.101.8.40])
by out48.mail.ovh.net (Postfix) with ESMTP id 4MdXyD72BpzPNNR7x
for ; Thu, 29 Sep 2022 12:40:20 +0000 (UTC)
Received: from in39.mail.ovh.net (unknown [10.101.4.39])
by vr40.mail.ovh.net (Postfix) with ESMTP id 4MdXyD5PpNz7t9D
for ; Thu, 29 Sep 2022 12:40:20 +0000 (UTC)
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=81.246.31.146; helo=descobarracuda01.desco.be; envelope-from=comptoir.liege@desco.be; receiver=contact@htek.be
Authentication-Results: in39.mail.ovh.net; dkim=none; dkim-atps=neutral
Received: from descobarracuda01.desco.be (descobarracuda01.desco.be [81.246.31.146])
by in39.mail.ovh.net (Postfix) with ESMTPS id 4MdXyD4N09z1s1GQb
for ; Thu, 29 Sep 2022 12:40:20 +0000 (UTC)
X-ASG-Debug-ID: 1664455211-14352b63f3106b0005-2jUd9j
Received: from DESCOMAIL01.desco.be (DESCOMAIL01.desco.be [10.1.50.46]) by descobarracuda01.desco.be with ESMTP id uYbATqU9tRE6Y9a8 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 29 Sep 2022 14:40:13 +0200 (CEST)
X-Barracuda-Envelope-From: comptoir.liege@desco.be
X-Barracuda-RBL-Trusted-Forwarder: 10.1.50.46
Received: from DESCOMAIL02.Desco.be (10.1.50.47) by DESCOMAIL01.desco.be
(10.1.50.46) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Thu, 29 Sep
2022 14:40:12 +0200
Received: from DESCO.BE (10.1.50.113) by relay.desco.be (10.1.50.47) with
Microsoft SMTP Server id 15.1.2375.31 via Frontend Transport; Thu, 29 Sep
2022 14:40:12 +0200
X-Barracuda-RBL-Trusted-Forwarder: 10.1.50.46
Date: Thu, 29 Sep 2022 14:36:34 +0200
X-Barracuda-RBL-Trusted-Forwarder: 10.1.50.47
From: Comptoir Liege 5
Subject: =?utf-8?Q?Note_d=C2=B4enl=C3=A8vement=3A_13887462_SCLESSIN?=
To:
X-ASG-Orig-Subj: =?utf-8?Q?Note_d=C2=B4enl=C3=A8vement=3A_13887462_SCLESSIN?=
Message-ID:
MIME-Version: 1.0
Importance: Normal
X-Priority: 3 (Normal)
X-Mailer: SAP NetWeaver 7.03
Content-Type: multipart/mixed; boundary="=_0050568E2E711EDD8FFE7B5B22ED1409"
X-KSE-ServerInfo: DESCOMAIL01.desco.be, 9
X-KSE-AntiSpam-Interceptor-Info: protection disabled
X-KSE-AttachmentFiltering-Interceptor-Info: protection disabled
X-KSE-Antivirus-Interceptor-Info: scan successful
X-KSE-Antivirus-Info: Clean, bases: 29/09/2022 10:43:00
X-KSE-BulkMessagesFiltering-Scan-Result: protection disabled
X-Barracuda-Connect: DESCOMAIL01.desco.be[10.1.50.46]
X-Barracuda-Start-Time: 1664455212
X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256
X-Barracuda-URL: https://descobarracuda01.desco.be:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at desco.be
X-Barracuda-Scan-Msg-Size: 443
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.101065
Rule breakdown below
pts rule name description
---- ---------------------- --------------------------------------------------
X-OVH-Remote: 81.246.31.146 (descobarracuda01.desco.be)
X-Ovh-Tracer-Id: 10535045431694430594
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvfedrfeehtddgheeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucenucfjughrpeffhffuvffkgggkrffotgesmhdtggerredtjeenucfhrhhomhepvehomhhpthhoihhrucfnihgvghgvucehuceotghomhhpthhoihhrrdhlihgvghgvseguvghstghordgsvgeqnecuggftrfgrthhtvghrnhepvedugfffieduhefggffhfeehvddvkeegveehgefhfeevheekkeefkeeuveeuvdegnecukfhppeekuddrvdegiedrfedurddugeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepuggvshgtohgsrghrrhgrtghuuggrtddurdguvghstghordgsvgdpihhnvghtpeekuddrvdegiedrfedurddugeeipdhmrghilhhfrhhomheptghomhhpthhoihhrrdhlihgvghgvseguvghstghordgsvgdpnhgspghrtghpthhtohepuddprhgtphhtthhopegtohhnthgrtghtsehhthgvkhdrsggvpdhsphhfpehprghsshdpughkihhmpehnohhnvgdpghgvohfkrfepuefgpdfovfetjfhoshhtpehvrhegtd
X-Ovh-Spam-Status: OK
X-Ovh-Spam-Reason: vr: OK; dkim: disabled; spf: disabled
X-Ovh-Message-Type: OK
X-Ovh-Spam-Status: OK
X-Ovh-Spam-Reason: vr: OK; dkim: disabled; spf: disabled
X-Ovh-Message-Type: OK
Ce mail n'est pas considéré comme du spam. Donc OVH a certainement dû tenter de le faire suivre.
Cependant les redirections cassent le protocole SPF si le serveur qui fait la redirection ne modifie pas l'adresse de l'expditeur.
Dans votre cas: aaa@desco.be comme adresse d'expéditeur, ça ne peut pas sortir des serveurs d'OVH. C'est Desco qui l'impose dans son SPF et son DMARC.
Il faut que OVH modifie l'adresse d'expéditeur par exemple par :
si on implémente le protocole SRS
SRS0=xyzt=desco.be=aaa@htek.be
ou solution bricolage
contact+redir@htek.be
Ainsi le serveur récepteur voit un mail qui provient de OVH et du domaine htek.be, et votre SPF autorise les serveurs d'OVH à envoyer du mail. Donc c'est tout bon.
S'il n'y a pas de réécriture, le serveur d'en face voit un mail de desco.be mais qui provient d'installations non autorisées par Desco ==> instruction donnée de refuser ce mail qui est une possible falsification.
Au cas où l'adresse du destinataire n'existe pas dans votre redirection, ou bien la boîte est pleine, un message d'erreur sera généré.
Dans le cas de la redirection SRS, il est possible de reconstituer l'adresse d'origine chez Desco et lui renvoyer le message d'erreur.
Dans le cas de la redirection bricolage, le message d'erreur restera chez vous.
Je me rends compte que la matière est complexe, en résumé ça montre la fragilité des redirections.