Simon

Et/ou : https://www.wistee.fr/configuration-nom-domaine/modifier-fichier-hosts.html

visiblement pas de pb avec le mail reçu à première vue. Est-ce que ça fait ça ça pour toutes les adresse gmail ou juste une de test ? Si adresse de test, est-ce qu'une redirection est faite sur cette adresse ?

Matthieu, Si tu envoies un email comme tu le fais pour les mails reject par gmail, sur l'adresse ming.mankiewicz@magicopedia.com et un à test-a6zuw@mail-tester.com je pourrai te filer plus d'infos sur ce qui cloche Simon

Bonjour Alain, Ces infos n'aident pas beaucoup plus, pouvez-vous coller ici l'ensemble des entêtes de mail reçu ? En anonymisant au besoin la local part de l'adresse From et To, mais en conservant les domaines en clair.

Bonsoir, Sur les hébergements mutualisés, ce ne sera pas possible d'installer ces composants. Discourse est en Ruby et les hébergements Yulpa ne proposent pas de prise en charge Ruby de ce que je sais. Quant à Docker, impossible d'installer ça sur un hébergement mutualisé, c'est exclu, au minimum sur un VPS, il me semble que c'est quelque chose que Yulpa peut proposer, à voir avec eux peut-être dans un ticket support ? shawn.arildsen@wormedia.com

Non, la limitation ici est imposée par Facebook, ils ne proposent aucune solution permettant de définir un nom de domaine personnalisé sur une page. S'ils ne le permettent pas, Yulpa est ici impuissant, il faudrait absolument que Facebook accepte ton domaine, et le route sur la bonne page. On ne peut fixer une entrée A que sur une adresse IP, pas sur une URL. Donc en faisant pointer ton domaine sur leur IP, tu aurait l'accueil Facebook affiché, pas du tout ta page à toi.

Tu ne peux pas faire pointer un nom de domaine à toi sur une page Facebook, ils ne permettent pas ce genre de chose, et ne gèrent pas les noms de domaines externes. Ce que tu peux faire en revanche, c'est effectuer une redirection web de ton domaine vers ta page FB, mais dans ce cas ton domaine n'apparaîtra plus dans la barre d'adresse après redirection. Ou bien inclure la page FB dans une iframe (je ne sais pas si FB le prévoit dans leurs ToS ?...)

simon$ dig +short txt 717._domainkey.mail.jakubowicz.me il n'y a en effet aucun enregistrement DKIM présent sur le sous domaine 717._domainkey.mail.jakubowicz.me, c'est ici que devrait se trouver la clé publique DKIM. Pour ce qui est de l'ip dynamique, les providers mails utilisent des DNSBL qui identifient les ips publiques d'ISP, et identifient les mails comme potentiellement douteux. (https://www.dnsbl.info/dnsbl-details.php?dnsbl=dul.dnsbl.sorbs.net par exemple) Beaucoup d'ordinateurs infectés (botnets) envoient des mails de façon incontrôlée via des ips dynamiques, le risque est donc fort, donc les emails présentant ce type de patterns sont beaucoup plus susceptibles d'être livrés en spambox

c'est quoi ton adresse from ? c'est quoi ton selecteur dkim ? dans l'idéal, tu peux nous filer le lien vers le résultat mail tester ?

Les deux ne sont pas compatibles, ce n'est pas une limitation Yulpa ici. Une entrée CNAME veut dire "redirige tout le trafic vers la cible du CNAME, quel que soit le type. Donc tout le trafic MX, A, TXT, etc... Est rédigé vers la cible du CNAME. Avoir une entrée MX et CNAME sur la même zone dns du même host est techniquement faisable mais un non-sens car le trafic est rédigé et l'entrée MX de la zone ne serait pas utilisée.

tout dépend du serveur mail utilisé. Sur Debian + Postfix, le nom du serveur mail est défini par défaut par le contenu de /etc/mailname dans la variable "myorigin" de main.cf Cf https://postfix.traduc.org/index.php/BASIC_CONFIGURATION_README.html#myorigin

Hello Jul, On parle ici d'un VPS Yulpa ? Et du coup d'une IP Yulpa ?

Hello ! les headers semblent légitimes ici, le mail a été signé via la clé DKIM de mail.paypal.fr et correctement validé par le serveur entrant de Yulpa, l'expéditeur a donc la main sur la clé privée DKIM de Paypal, donc probablement légitime. epsl1.com est visiblement le prestataire gérant les mails Paypal : mail.paypal.fr. 3599 IN MX 5 pmx1.epsl1.com. le whois du domaine paypal-communication.com : Registry Registrant ID: Registrant Name: Domain Administrator Registrant Organization: PayPal Inc. Registrant Street: 2211 North First Street, Registrant City: San Jose Registrant State/Province: CA Registrant Postal Code: 95131 Registrant Country: US Registrant Phone: +1.8882211161 Registrant Phone Ext: Registrant Fax: +1.4025375774 Registrant Fax Ext: Registrant Email: hostmaster@paypal.com

Hello ! Pour info, Gmail ne loade pas d'images externes dans son webmail, toutes les images des mails sont mises en cache sur un proxy Google et Gmail affiche cette image cachée par un serveur Google, via https. D'où le cadenas vert car il n'y a pas d'éléments non https dans les mails affichés sur Gmail.

Hello ! Juste, on parle de quoi ici ? Tu as un exemple en ligne du pb ? Quelque chose que l'on peut voir quelque part ? Je n'ai pas compris ton problème ici Simon

Tu n'as pas accès aux différents graphs ici https://app.doyoucheck.com/p/monitoring_http/monitor/be25019078682462889b807411f1b354 ? Cette page te fournit les informations que tu souhaites avoir

Hello Alex, Tu veux parler desquelles de stats ? Des temps réel ? Des stats par heure ? Par jour ? Les stats sont agrégées pour permettre une rétention plus importante. Quel type de data serait intéressant pour toi ? Simon

Je viens d'ajouter SF et Londres pour ton site, tu pourras comparer Alex.

Hello Alex/Simon, En effet, les sites d'Alex sont monitorés depuis la France uniquement, via Scaleway et OVH. On peut ajouter une sonde à San Francisco sur ces sites pour voir si on se rapproche des temps d'accès de Pingdom Alex. Tu me diras, je l'ajouterai si tu veux. Mais oui, clairement ici, le délai supplémentaire doit être dû à la traversée de l'Atlantique

Hello Alex, C'est vrai que pour l'instant nous n'avons pas envisagé l'option de suppression totale des sondes, je vais voir comment nous pouvons faire ça Ce ne sera pas dispo avant au moins une bonne semaine par contre.

Oui, là pour le coup, c'est free qui fait n'importe quoi C'est exactement ce que je fais, une adresse poubelle qui sert pour mes inscriptions à des sites/services, sur laquelle je m'attends à recevoir les mails d'inscription aux services + toute la merde qui s'en suit avec les reventes d'adresses, de listes. Et une perso, qui me sert à échanger avec les vrais gens Tu peux faire ça avec 2 adresses propres à ton domaine à la limite, je pars de plus en plus vers ça, je peux contrôler ce qui est émis en mon nom au moins, via une entrée DMARC + DKIM + SPF

Hello Philippe, Ta réaction est complètement compréhensible, sache toutefois que le monde de l'email n'est pas figé, et bien que le protocole SMTP commence à prendre des rides, il y a en permanence des évolutions liées à la sécurité et la protection des données. Plus les spammers s'améliorent, plus il y a besoin de restreindre l'usage afin de protéger l'ensemble. Lorsque tu parles d'adresses externes, ce sont des adresses fournies gratuitement par des providers ? Du genre Orange.com, gmail.com, et j'en passe ? Si tel est le cas, sache que pouvoir utiliser ces adresses en dehors de leur serveur d'origine va devenir de plus en plus restreint avec la démocratisation du DMARC, qui restreint l'utilisation d'un domaine aux seuls serveurs autorisés pour ce domaine. En résumé, il ne sera bientôt possible de n'utiliser une adresse @gmail.com qu'à partir des serveurs SMTP de Google, sinon ça va bouncer. Yahoo a déjà mis en place une politique très restrictive sur son enregistrement DMARC, les autres gros vont suivre, et c'est une bonne chose d'un point de vue émission de spams. Il est difficile sur une infrastructure email partagée, comme la solution Zimbra proposée par Yulpa, d'identifier le ou les comptes à l'origine d'une tâche sur la réputation des adresses IP d'expédition. Bien plus que l'on peut l'imaginer Simon pour les curieux : _dmarc.gmail.com. 599 IN TXT "v=DMARC1\; p=none\; rua=mailto:mailauth-reports@google.com" on voit ici la première étape d'implémentation du DARC gmail, la prochaine sera sans doute un p=quarantine, puis un p=reject mis en place afin de se protéger. ici Yahoo: _dmarc.yahoo.com. 1799 IN TXT "v=DMARC1\; p=reject\; pct=100\; rua=mailto:dmarc_y_rua@yahoo.com\;" Bref, ça bouge ! Pour les plus curieux, une nouvelle implémentation ARC qui est en train de se démocratiser https://dmarc.org/2017/07/new-arc-implementations-at-ietf-99-hackathon/

Hey Maître du monde, à dispo en pv si besoin d'aide sur les déliv mails

Hello, A titre de comparaison, il y a actuellement 18 sites hostés par Yulpa qui sont monitorés par Doyoucheck, et seuls 3 remontent des lenteurs régulières. Pour Ultimaterra, le pattern de slow est toujours le même : https://app.doyoucheck.com/p/detail_incident/token/23a70761b4f4bbfadee1ffb2dd6980d8 La lenteur semble se situer après la génération du contenu, et c'est le seul site Yulpa qui semble présenter ce pb.

Hello ! Adrien, oui, pour le moment le service est en bêta ouverte, gratuit, et nous allons débuter la commercialisation en Septembre avec un coût inférieur à Pingdom par exemple. Un service gratuit forever n'est pas quelque chose d'envisageable pour nous au vu des coûts d'infrastructure et du temps investi Un Raspberry Pi fait le job, tant qu'on ne lui demande pas d'être 100% fiable, ni redondant, ni multi-lieux, ni dépendant du réseau de la maison, ni du traffic réseau consommé par la TV à la demande Mais yes, ça peut suffire dans certains cas. Chacun son besoin, ses compétences, son temps à investir dedans et son envie de bidouille au final. Il faut de tout, et le modèle Saas est assez intéressant je pense.