Je réponds aux points soulevés ici, ne pas hésiter à déplacer mon message si c’est pas le bon endroit
Amazon est un GAFAM : MailJet est hébergé par Google Cloud et Outlook, donc pas vraiment de différence pour le coup, ils n’ont pas leur propre infrastructure
@ljf : j’ai modifié pour avoir « Votre adresse ne sera jamais vendue ou cédée à des tiers ». Le sens de cette phrase ici est que nous ne vendons ni ne cédons pas les données des associations, par exemple pour gagner des sous via du sponsoring, etc. L’adresse peut être transmise à des prestataires tiers, comme indiqué dans les mentions légales, on a un tableau que je pense assez clair. J’espère que c’est plus clair avec cette modif, merci.
la question de l’impact dans les structures hébergées est intéressante. De notre point de vue, nous sommes prestataire de la structure, qui est 100% responsable de ses données. On pourrait fournir un modèle de « charte RGPD » aux structures hébergées, mais elles devraient donc l’adopter et la communiquer à leurs membres. Si on change de presta demain, cette charte serait caduque et n’aurait donc plus de valeur, je ne sais pas si c’est important. Je ne pense pas que plus qu’une poignée d’assos réutiliseraient ce modèle, la plupart des assos n’ont aucune notion du RGPD malheureusement. Un point à voir et discuter au sein de Paheko en tout cas, merci du retour.
gérer deux services de mail différents serait un peu lourd à mettre en place, car ça voudrait dire devoir gérer les divers blocages / dysfonctionnements de notre serveur SMTP et donc retomber dans une gestion manuelle des mails, très chronophage, même si ce n’est que pour certaines assos, on retomberait dans le même souci d’énergie / temps qui est pris là-dessus.
Edit : j’ai rajouté un modèle de charte RGPD pour les assos, qui renvoie à nos mentions légales du coup.
Pour moi ces tournures restent susceptibles d’induire en erreur les utilisateurices d’autant plus qu’elles émanent désormais d’un chaton. « Votre adresse ne sera jamais vendue ou cédée à des tiers »
et plus bas « Vos données ne servent qu’à votre inscription. Elles ne sont jamais communiquées à des tiers. »
En réalité, l’adresse email, les destinataires, le sujet, le corps de message (contenant peut être des infos) et l’heure d’envois sont bien transmises à un tiers d’envergure, qui de surcroît s’appelle symboliquement Amazon.
J’estime que tu pourrais simplement afficher: « En raison du volume de mail à envoyer, Paheko n’a pour l’instant d’autres choix que d’utiliser le service d’Amazon pour envoyer les mails. En savoir plus. »
Certes c’est mettre en avant une faiblesse du service, mais Paheko a de nombreuses autres forces. Et puis la transparence est aussi une force.
Est ce que tu as une estimation de la quantité d’emails qui pourraient être envoyés par IPv4 et par Ipv6 ?
J’envoie peu d’emails, mais si avec d’autres, nos serveurs pouvaient servir de relais (via un VPN comme ça on voit rien), il faudrait qu’on soit combien?
Oui, ça obligerait à :
Créer autant de VPN que d’aides
Ajouter les IP sortantes des VPN au niveau des enregistrements SPF
Adapter les autres enregistrements DNS, peut être aussi des trucs à faire au niveau du partenaire.
C’est vrai que c’est éventuellement plus simple de juste faire relai, mais ça permettrait de connaître trop de trucs à notre goût concernant les emails.
@ljf merci du retour, c’est ce qu’il y a déjà dans les mentions légales, les CGV et à plusieurs autres endroits de la doc. J’ai peur qu’une telle mention induise en erreur, comme quoi on vendrait notre fichier d’adresses email à Amazon pour envoyer du spam. Je vais réfléchir à trouver à partir de ton exemple la formulation la plus claire qui soit, et on en discute à la prochaine réunion intra-Paheko dans l’été, là je suis pas dispo avant une semaine environ
@LautreG : j’ai rien compris désolé, quel est le rapport entre VPN, IPv6 et quantité de mails envoyés ?
il y a déjà un sujet sur des projets de mutualisation de l’envoi de mails, il y a eu un atelier au camp chatons, et on va créer un GT sur ce sujet, avec le but de développer une solution qui permette en premier lieu d’améliorer la qualité des envois des chatons : identifier les adresses invalides, s’assurer que les mails suivent les meilleures pratiques d’envoi (rate limiting, entêtes list-unsubscribe et lien de désinscription pour les mails collectifs, etc.), identifier un utilisateur de chatons qui abuserait, où dont le compte aurait été hacké, et bloquer les envois rapidement, etc.
Dans un second temps oui on pourra mettre en commun nos IPs pour lisser le volume d’envoi et éviter les blocages, mais perso j’ai identifié que le plus important pour les hébergeurs c’est d’améliorer la qualité des envois pour réduire les blocages.
Le problème principal du mail sans passer par un AWS ou similaire c’est que ça prend beaucoup de temps et d’énergie. Ça n’est pas un problème technique : techniquement je sais gérer un serveur de mail, je le fait encore pour mes mails et ceux de mon asso et du support Paheko. Le problème c’est le temps que ça prend donc on va essayer de tout faire pour améliorer la situation pour tous les CHATONS
Oui, j’avais lu, je sais que tu maitrise la gestion des services emails.
Mais je ne retrouve plus les fils de discussions sur la mutualisation des envois emails.
Chez koumbit.org on offre les courriels avec l’hébergement. Ça inclus les mécanismes SPF/DKIM/DMARC. On a aussi des listes de courriels avec les entêtes « Unsubscribe » et tout, quoique il y aurait place à l’amélioration de ce côté (il y a certains services de spam qui tiquent sur certaines de nos entêtes).
Mais en effet, c’est beaucoup de travail et ça prend une surveillance 24/7. De temps en temps une boîte se fait pirater et il faut réagir rapidement pour l’arrêter. Et après ça demander le délistage auprès des service qui font la détection de spams.
La difficulté est qu’il faut que l’adresse IP du serveur se bâtisse une réputation, ce qui demande du temps et une grande quantité de courriels valides envoyés.
Par exemple, on a un serveur avec seulement quelques boîtes de courriel et l’une s’est fait piratée et à envoyé très rapidement 30k courriels frauduleux. Certains services (cough Microsoft) refusent de le délister parce que genre 10% des courriels envoyés ever de ce serveur étaient du spam.
Merci pour le retour, voici ce qu’on a adopté après notre réunion :
Nous sommes une association à but non lucratif,
vos données restent confidentielles.
Nous utilisons des prestataires pour certains services, dont l’envoi des e-mails.
Ces prestataires sont tenus contractuellement à la confidentialité de vos données.
Consultez nos mentions légales pour les détails.
Scaleway a sorti son service d’envoi d’emails transactionnels par API cette année. Ils proposent aussi des webhook pour le renvoi du statut de délivrance.
Une alternative intéressante à AWS pour Paheko?
Merci j’avais vu à la sortie, mais non, car 95% de notre trafic c’est du mail de masse (newsletter, invitation à assister à une AG, etc.), donc pas couvert par Scaleway
Je suis tombé sur https://smtpserver.com l’offre a l’air intéressante mais ça a limite l’air d’être suspect vu le marketing du site, des gens connaissent ?
Pas du tout, mais j’ai transmis à Luc et Thomas: « Boite en Lettonie, les tarifs sont impressionnants mais quid de la réputation et de la délivrabilité ? »
Bref, va sans doute falloir que des gens testent (et se cassent peut être les dents dessus) pour avoir une meilleure idée.
(Je crois que je l’avais dit, mais nous on avait contacté des boites comme Relais SMTP sécurisé pour emails transactionnels - Alinto et d’autres, mais notre trafic était trop important pour elles)
Oui en Lettonie, avec des dévs Lettons et Ukrainiens.
Mais ce qui me met la puce à l’oreille c’est l’absence complète de doc technique. Ils ont une API, mais elle n’a pas de doc…
On dirait en plus qu’il n’y aucun moyen d’avoir une remontée automatique des bounces :-/
Je les ai contactés. À mon avis ça correspond pas à nos besoins à nous, mais si on a juste besoin d’un serveur SMTP sans des services plus avancés comme nous (complaints, webhook pour les bounces), ça peut être intéressant. Il semble qu’ils veillent d’assez près à la réputation de leurs IP dans ce que j’ai lu, mais bon faut voir.
