Mail non délivrés ou en spam chez nos clients

Bonjour,
Il me faudrait une entête complète pour analyser son contenu et voir ce qui peut être bloquant ainsi que le nom de domaine et l'IP de la connexion internet qui envoie les mails (en message privé de préférence).
Merci d'avance et bonne journée.
Th.T

Bonjour,
le souci c'est qu'il s'agit des mails qu'on envoie, dans outlook 2010 je ne vois pas les entetes du mail envoyé, je les vois uniquement sur les mails qu'on reçoit.

Vous avez moyen de voir quelque chose si je vous indique l'ip de notre serveur Exchange et la boite mail source et destination ?

Bonjour,
Tu peux demander à un des destinataires ayant reçu en spam d'extraire l’entête. Ce sera le seul moyen d'avoir un diagnostic cohérent.
Bien à toi,
Th.T

Malheureusement demander ce genre de chose a une secrétaire de 50 ans qui ne comprend strictement rien a tout cela est impossible. Pour eux (les destinataire des emails) le problème c'est nous car _ils n'ont pas de problème avec les autres_, et ça ne va pas plus loin.

Ce que je peux faire c'est vous donner un lien de résultat 1tester.comtester.com du mail qu'on envoie, avec le lien obtenu on peut voir l'entête du mail envoyé. Mais ca n'expliquera en rien pourquoi leur serveur de messagerie nous blackliste...surtout qu'avec 1tester.comtester.com on a en général 9/10, on perd 1 point à cause du DKIM qu'on ne peut intégrer au serveur Exchange 2013.

Bonjour,
Voici ce que le technicien support d'ARUBA, hebergeur de la messagerie qui pose problème nous indique:
They said that you should modify your server's header with the real FQDN, because otherwise it could be identified as spammer.

j'ai regardé et dans nos entete de mail on voit : S3169.EX3169.lan
Je crois qu'on a en face un type têtu et incompétent qui nous raconte n'importe quoi pour ne pas avoir a toucher à la config de sa messagerie.
Lors de nos premiers échanges il a dit que le problème venait de notre IPV6 qui commence par : **2001:41d0** maintenant ce serait le FQDN...Alors que sur 1tester.comtester.com le seul "souci" qui nous fait perdre 1 point, c'est l'absence de DKIM.

Qu'est-ce que je peux faire au milieu de tout cela ? nous sommes 2 informaticiens dépendants chacun de nos hébergeurs de messagerie, on fait boite au lettre entre les 2 hébergeurs et cette histoire prend un temps fou, en attendant cela créé de graves dysfonctionnements dans nos sociétés respectives...

Bonjour,

Il n'y aurait pas la possibilité qu'il ajoute votre IP à la "white list" de leur protection antispam étant donné que que vous travaillez avec eux et que vous êtes donc une source de confiance.

cdlt

Alors c'était l'une des 1eres choses que j'ai proposé, mais le sujet a été ignoré.
En fait je pense que dans cette histoire il y a beaucoup d’incompétence à plusieurs niveaux...

En fait 1 email est envoyé à 5 personnes de la même société. certains le recoivent dans leurs SPAM, d'autres disent qu'ils ne l'ont pas recu...

A partir de là je me dis que ceux qui ne l'ont pas recu doivent très certainement l'avoir dans leur SPAM et n'ont pas regardé dedans. Et c'est la que les incompétences et la mauvaise fois commence.
Les gens ne veulent pas s'emm...der a regarder dans leurs spam donc a nous de trouver une solution pour ne pas qu'ils aillent dans ce dossier...

Lorsque j'explique a leur chef de service, qu'il suffit d'ajouter l'expéditeur ou mieux, le domaine de l'expéditeur dans la whitelist d'outlook, sur tous les postes de travail des personnes concernées...silence radio pour moi, et "on l'a déjà fait" lorsque la personne qui envoie les emails le leur dit au téléphone...Moi je n'en crois pas un mot.

Maintenant si on part du principe qu'ils ont effectivement fait cela, alors ou sont passé les emails qu'ils ne recoivent pas ? lorsqu'un mail n'est pas délivré on recoit un message d'erreur du serveur de messagerie avec la raison pour laquelle le mail n'a pas été délivré. Hors, on ne recoit jamais rien...ce qui, à mon sens, confirme que l'email est bien délivré mais que celui qui le recoit ne regarde pas ses spams et n'a pas non plus configuré son client comme indiqué...

La dessus Arrive le tech de ARUBA, qui gère le serveur de messagerie. A aucun moment il indique clairement pourquoi un message passe en spam ou pourquoi il n'est pas délivré.
il dit que le problème pourrait provenir de notre IPV6 qui commence par "2001:41d0" sans dire la raison...puis ensuite que le problème pourrait venir du FQDN indiqué dans nos entêtes : S3169.EX3169.lan et qui ne correspond pas à notre domaine...
Donc ce n'est que des suppositions, à aucun moment il ne fait l'analyse de pourquoi le mail X n'a pas été délivré.

En fait il devrait y avoir une discussion entre OVH et ARUBA les 2 hebergeurs des messageries...Mais la situation actuelle c'est plutôt ça :
OVH --> MOI <---> LE CLIENT <-- un prestataire informatique <-- ARUBA
Donc le dialogue se fait par mail entre les intermédiaires comme une partie de ping pong, on se transfert ce que notre hebergeurs nous disent et ca n'avance pas...

Par ailleurs OVH, lorsque j'ouvre un ticket c'est 1 réponse par 24h...

En fait, les antispam fonctionne par "scoring" du mail. C'est à dire que le mail est analysé et des points sont ajoutés ou retirés en fonction de plusieurs critères.
Votre adresse IP a aussi un scoring (ou plutôt une réputation) qui évolue sur leur antispam et qui peut par exemple limiter le nombre de mails / heure acceptés venant de vous.
Il faudrait vraiment avoir l'entête d'un des message reçu dans les spam. essayez de savoir quel client mail ils utilisent et envoyez leur un tuto pour trouver l'entête du message. C'est en général assez facile à trouver.
Après

La dessus Arrive le tech de ARUBA, qui gère le serveur de messagerie. A aucun moment il indique clairement pourquoi un message passe en spam ou pourquoi il n'est pas délivré

Parce qu'il n'en sait rien.

Vos mails sont des faux positifs et si le tech de ARUBA ne collabore pas un peu plus, cela va être compliqué. S'il n'a pas le temps de vous aider à adapter vos envois de mail à leur antispam qui met à tort des mails dans les spams, il peut toujours vous mettre dans une liste blanche.

Bon courage.

, le domaine de l'expéditeur dans la whitelist d'outlook,

ce n'es tpas leur client de messagerie outlook qui met en dans les spams mais leur serveur de messagerie et plus précisément, leur antispam.
Je pense qu'il faut insister pour avoir des raisons plus précises de la mise en spam des mails.

Bon ca avance un peu de leur côté, côté OVH silence radio.
J'ai regardé l'entête d'un de leur email et en fait ils nous demandent de faire des trucs qu'ils n'appliquent même pas à eux-même.
on envoie nos emails à @teklog.it
et voici un bout de l'entête d'un mail que eux nous envoient:
> Received: from mail.servizioemail.it (mail.servizioemail.it [151.1.252.20])
> by in23.mail.ovh.net (Postfix) with ESMTPS id D82E8A5941;
> Thu, 16 Nov 2017 16:01:48 +0100 (CET)
> Received: from kerio.azzurraconsorzio.it (UnknownHost [193.219.102.173]) by mail.servizioemail.it with SMTP

ils nous reprochent que le FQDN de notre serveur de messagerie ne correspond pas à notre domaine, mais que dire du leur !?

J'en ai donc informé le prestataire de notre client qui m'a répondu ceci:

> I'm waiting for a phone call from Aruba, in order to get better support.

> What you saw on our mail header is a little bit different because we use Aruba just for incoming emails that are forwarded to our local mailserver (kerio.azzurraconsorzio.it, which manage several domains) and then are delivered to clients.
> I'm the sysadmin of this last email server (Kerio Connect that act as MS exchange), and server side I've already set an antispam rule that should allow all emails from you XXXXXXXX.fr:
>

> According to this rule, there is no need for clients to set custom antispam rules in MS Oulook or other mail clients.
> Unfortunately your email are tagged as spam directly on Aruba server, that shouldn't did it, because we've disabled the antispam features, but according to their support there are some general antispam rules anyway that cannot be modified by customers.

> Outgoing emails from clients goes to Kerio Connect and then are delivered from an external SMTP auth server (mail.servizioemail.it) because Aruba's service was unreliable.

> I hope they'll call me ASAP to fix this trouble, otherwise we're planning to move our MX server away.

Voilà, donc lui il a bien compris que le problème ne vient pas de chez nous, maintenant il faut convaincre ARUBA...

Le spf de votre domaine est bien configuré ?
Si vous testez sur mail tester à combien est le score ?

notre SPF est parfaitement configuré, j'ai 9/10 sur mail-tester
je perds 1 point a cause de l'absence de DKIM que l'on ne peut configurer sur Exchange 2013.

Il me semble que mail tester ne fonctionne qu'en ipv4, du coup il faut peut être ajouter à la main les ipv6..

Bonjour,

ARUBA ne serait pas un peu susceptible parfois ?

Cf : http://travaux.ovh.net/?do=details&id=26947

Cordialement, janus57

@Buddy
notre SPF à bien IPV4 et IPV6 de renseigné.
"v=spf1 a mx ip4:188.165.xxx.xxx ip4:188.165.xxx.xx ip6:2001:41d0:x:xxxx::1 ip6:2001:41d0:xxxx:xxxx::BCA5:938E include:spf.mailjet.com ~all"

@janus57 merci pour l'info...Apparemment nous n'avons pas de souci pour recevoir leurs emails, ils passent et ne sont pas taggués SPAM.

3 jours d'attente pour avoir une réponse d'OVH complètement à côté de la plaque:

_L'erreur est peut en effet être dû à l'absence d'un champs SPF dans la zone_
_DNS de votre nom de domaine xxxxxxxx.fr._
_"v=spf1 include:mx.ovh.com ~all"_
_voir : https://docs.ovh.com/fr/emails/le-champ-spf/_

Hors je ne suis pas en MUTUALISÉ mais en offre EXchange 2013 DEDIÉ...
Par contre mon champ n'est pas de TYPE TXT mais de TYPE SPF...

Bonjour,

je vous conseil de faire le champ SPF en TXT.

sources :
1 - https://tools.ietf.org/html/rfc7208#section-3.1
2 - https://webmasters.stackexchange.com/a/61062

Cordialement, janus57

et si je mets les 2 types ? ca va faire un conflit ?

Merci pour l'info !

Bonjour,

il est préférable de supprimer le champ SPF et de garder que le TXT car d'après les RFCs le champ SFP est obsolète et le SPF **doit** être déclaré en TXT.

[quote]
SPF records **MUST** be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035] only.
[/quote]

Cordialement, janus57

Ok merci pour ces précisions. Je corrige, on va voir...

Par contre c'est curieux que 1tester.comtester.com ne dit rien à ce sujet...
http://www.1tester.com/web-zrhxktester.com/web-zrhxk
je viens de refaire un test: 9/10

comme suggéré par mail-tester.com je viens d'ajouter un champ DMARC

Bien ou pas bien ?

Je viens de refaire un test est visiblement ça passe :

Bonjour,
ce matin j'ai fait un test sur une boite mail qui rejetait nos mail pour cause de spam (au niveau du serveur de messagerie, donc retour de l'entete à l'expéditeur avec code erreur), maintenant ca semble passer...
Merci a **Janus57**
Si le problème était le record type TXT au lieu de SPF je me demande pourquoi OVH le propose, vu qu'il est devenu obsolete. Leur tutorial aussi est à revoir : https://docs.ovh.com/fr/emails/le-champ-spf/

Problème réglé chez nos clients qui étaient à l'origine de l'ouverture de ce topic.
Merci encore à **Janus57** pour avoir vu juste ;-)

il faut donc que le **SPF** soit dans un champ de type **TXT**.

Hello Jallate,
J'ai apparement également le même soucis que toi, un bon quart de mes client reçoivent mes mails dans les indésirables... J'ai essayé de me démerder avec les quelques infos que t'as mis à ce sujet mais je n'arrive pas à faire la manip et à tout configurer !

Est-ce que c'est possible d'avoir un mini tuto des étapes stp ?! Ça me dépannerait bien !
Merci d'avance !

Bonjour,
@DeterM il suffit juste de créer un champ TXT dans la zone DNS et d'y insérer le contenu de ton SPF.
En fait ce que tu fait dans un champ SPF, fait le dans un champ TXT, tout simplement.

Hello Jallatte et merci pour ta reponse.
J'y pipe franchement pas grand chose.
Si t'as le temps de me filer ce rapide coup de main contre un paypal fait moi signe !

ou tu indiques ton domaine
ou tu teste sur 1tester.comtester.com qui t'expliquera ce qui ne va pas et te suggérera le Sfp utile si besoin

J'ai 2 SPF, je ne sais pas lequel copié.


De plus, qu'est ce qu'il faut mettre dans "sous-domaine", TTL et valeur ? Dans le champ TXT si j'ai bien compris il faut mettre le contenu du spf.



Je vous remercie pour votre aide !
Et surtout merci OVH hein...

supprime SPF, c'est périmé depuis longtemps mais ovh ne doit pas le savoir

ajoute une entrée **TXT**
sous-domaine vide
TTL: 600
valeur: `v=spf1 include:mx.ovh.com ~all`

Merci pour la rapidité !
Je viens de faire la manip


En espérant que ça va rétablir le soucis !
Je ferais un mail tester dès demain.

désolé je me suis trompé d'hébergeur: la valeur ok est:
`v=spf1 include:mx.ovh.com ~all`

inutile d'attendre plus d'une heure pour tester

Arf, 4,9/10 même pas la moyenne.
Doit y avoir un ajustement à faire pour que tout soit ok :

oui mais là c'est le contenu de tes mails qui pose soucis

pour le DKIM, tu ne pourras en avoir avec Ovh

C'est good, je viens de refaire un test avec un contenu de mail "normal", tout est ok !
J'arrive à 9/10 ! Je vais voir avec mes clients si désormais tout est ok. Merci beaucoup.
En espérant que ça aide d'autres personnes.

> J'arrive à 9/10

voilà, c'est le maxi avec Ovh

Bjr
Je rencontre un pb similaire, car de nombreux mails de ma BAL OVH arrivent en SPAM chez mes clients.
Or, nous sommes 4 associés au bureau à utiliser ces adresses créées et hébergées pas OVH, mais seule la mienne semble être bloquée...
Que faire ?
Merci +++
Renaud.
renaud.delaubier@1slk.frslk.fr