@sekil et moi avons travaillé sur le sondage framaforms évoqué lors des dernières réunions.
La 1ere version est disponible ici.
Le sujet sera évoqué à la réunion de lundi. Vos retours seront appréciés.
Bonne soirée et bon WE
Superbe ! 
Mes remarques :
Typo dans la description du sondage : « exéditeurs »
Quel serveur SMTP utilisez-vous en tant que serveur d’envoi ?
Autre serveur (préciser en commentaires)
Sauf qu’il n’y a pas de champ commentaire pour cette question 
Idem pour la question suivante :
Quelles techniques d’amélioration de réputation avez-vous mises en oeuvre ?
Il est peut-être pertinent de mettre juste un champ « texte libre » sur une seule ligne en dessous de ces questions, plutôt qu’un gros champ multi-lignes plus loin, pour avoir des réponses en lien direct avec les questions, et que les gens n’oublient pas de répondre.
Souhaitez-vous que le relai puisse collecter les statistiques suivantes sur les mails émis ?
Dans ce tableau, il serait utile de préciser dans la 4ème colonne « Mise à disposition de l’émetteur ET de la fédération », sinon on pourrait penser que ça ne serait que pour la fédération ? Ou alors c’est ça le sens ?
Dans ce tableau il y a une ligne :
Score de spam min/moy/max de chaque adresse réceptrice
Pas sûr de comprendre comment une adresse destinataire peut avoir un score de spam ?
Idem pour : « Score de spam min/moy/max de chaque domaine récepteur »
Souhaitez-vous que le relai puisse activer un log pour collecter les informations suivantes ?
Pour moi ça fait pas trop de sens de donner accès au contenu du mail à la fédération, donc peut-être mettre à part cette ligne là ?
Souhaitez-vous avoir un stockage de logs qui enregistre les données requises par la loi française ? (date, adresse IP et port source de la connexion au SMTP)
Je serais perso pour virer ça, car on n’en a pas besoin légalement en fait, comme vu plus haut.
Et du coup virer « collecte de logs réglementaires » dans « Quelles sont selon vous les fonctionnalités à prioriser dans ce projet ? ».
Souhaitez-vous que le service de relai puisse collecter et mettre à disposition les données suivantes ?
Pour la dernière ligne « Code et message SMTP retourné par le serveur SMTP » préciser « le serveur SMTP du destinataire » pour que ça soit clair.
Quels types de vérifications techniques souhaitez-vous sur le domaine émetteur ?
Je rajouterais un item « Présence sur listes de blocage (DNSBL) ».
Je pense qu’il manque aussi une question sur le déblocage des adresses en blocklist : « Est-ce que le relais doit pouvoir initier le déblocage des envois vers une adresse bloquée, en envoyant lui-même un message du type ‹ Cliquez ici pour confirmer que vous souhaitez recevoir des messages de l’adresse XX@YY.ZZZ › ? » → Non / Uniquement pour les hard bounce / Pour tout type de blocage / Pas d’avis.
Il manque aussi peut-être au début une définition du service projeté, et surtout que la notion de relais peut être simplement d’avoir un relais local, en bénéficiant des améliorations du service de relais fédéré, et donc pas forcément de relayer ses mails via un serveur tiers.
Merci pour tes retours
Ok, ok, je vais rajouter des champs texte 
Je me suis dis que la fédération englobe l’émetteur (si on considère que la fédération c’est émetteurs + relais) donc dans mon idée répondre fédération veut dire qu’on accepte une diffusion large de l’info. Mais c’est effectivement un raccourci.
Disons que je n’avais pas envie de complexifier avec une option de plus. Tu penses que c’est nécessaire ?
C’est vrai, je n’ai pas trop réfléchi, je l’ai mis pour être symétrique. Après on peut imaginer une adresse honeypot qui ne reçoit que du spam, mais j’admets que c’est tiré par les cheveux.
Si on va par là, pour moi logguer le contenu du mail est inacceptable dans tous les cas. J’ai du mal à voir le cas d’usage.
Ok, je suis entièrement d’accord.
Ok
Ok
Ok, je vais voir.
Nan je veux pas dire de rajouter une option, juste de préciser dans l’intitulé que fédération = émetteurs + relais. Parce que moi j’ai dû m’y reprendre à 3 fois pour comprendre que c’était « le niveau au dessus » et que ça comprenait les émetteurs.
Sinon oui il aurait fallut un tableau avec des checkbox au lieu des radio pour exprimer exactement ce qu’on veut comme combinaison, mais je sais pas si c’est possible. Et je sais pas si c’est souhaitable non plus.
Pour moi de toutes façons l’accès aux données par les émetteurs restera complètement optionnel, donc même si c’est logué/accessible « en théorie », ça veut pas dire que l’émetteur aura forcément un user/pass pour y avoir accès « en pratique ».
J’ai fait une partie des modifications.
Corrigé
Bon, si je rajoute des champs texte systématiquement il va y en avoir une bonne dizaine à ajouter (avec des règles d’affichage conditionnel). Ça va faire pas mal de boulot pour pas grand chose je trouve.
C’est toujours mieux d’être explicite effectivement. J’ai clarifié.
Malheureusement ce n’est pas possible effectivement.
Options retirées.
J’ai gardé comme ça parce que qui peut le plus peut le moins. Bon, et puis si quelqu’un répond fédération + émetteurs on pourra lui demander s’il est certain de sa réponse.
Retiré
Fait
Sur ce point, je n’ai pas modifié.
Il y a des listes de blocage basées sur les domaines ?
Ajouté
Je n’ai rien modifié sur ce point, à vrai dire la rédaction actuelle me convient. Si tu as une rédaction à proposer, n’hésite pas.
À mon avis ça sera plus facile à lire au niveau du résultat, avec des champs séparés qu’un seul champ fourre-tout où les retours seront dans le désordre, ou oubliés.
Oui, plusieurs, genre https://wiki.junkemailfilter.com/index.php/Spam_DNS_Lists
OK :
Compléments d’info pour le remplissage du sondage
Le service envisagé serait constitué d’un relais SMTP sortant, qui pourra faire office de « filtre » en local, et optionnellement être connecté à d’autres relais (« fédération ») pour bénéficier du partage de listes de blocage. Chaque connexion à un autre relais sera effectuée au cas par cas, selon les accords trouvés entre structures. Il est également envisagé de pouvoir utiliser ces relais « fédérés » pour relayer les messages envoyés.
Je dirais aussi que ça serait bien de penser à utiliser « blocklist » et « allowlist » au lieu de « blacklist » et « whitelist »
Formulaire modifié.
Attention, j’ai inversé le sens de la question « Quels impacts considérez-vous inacceptables sur vos serveurs mis à disposition comme relai ? »
Bon, j’ai ajouté des champs conditionnels, mais c’est vraiment parce que je suis sympa !
Ok, ajouté.
Ok, ajouté.
Ok, tu as raison.
J’ai modifié une occurrence dans le formulaire, j’essayerai d’y faire attention par la suite.
1 « J'aime »
@acnh38 @bohwaz On va peut-être pouvoir commencer à diffuser le formulaire ? Est-ce qu’il reste des modifications à apporter ?
Bonjour @Sekil,
Lors de la dernière réunion, on s’est dit qu’on attendait la prochaine (le lundi 9 septembre) pour valider avec tous les contributeurs que c’était Ok.
Si on s’aperçoit de boulette après diffusion, et si on décide de corriger le sondage, on risque de perdre des réponses …
A partir du 9, on imaginait laisser 3 semaines en délai pour répondre au sondage.
Pas facile de trancher entre le risque de démotivation des contributeurs et le temps nécessaire à faire les choses dans l’ordre en tenant compte des dispos de chacun.
Tout ceci peut se discuter…
Bonjour @acnh38
Au temps pour moi, je n’ai pas lu le compte-rendu !
Désolé pour ma remarque inutile.
Pas de souci 
Du coup c’est au moment de remplir le formulaire pour de vrai que je vois un souci ::
Dans le cas où le relai vérifie la signature DKIM, quelle doit être la politique à appliquer ?
- Le relai doit relayer le mail normalement
- Le relai doit refuser de relayer le mail
- Le relai doit être en mesure de pouvoir signer le mail (donc disposer de clés de signatures DKIM publiées pour ce domaine)
- Pas d’avis
Il manque une partie non ? Genre « dans le cas où le relais vérifie la signature DKIM, et que le message n’est pas signé, quelle doit être la politique à appliquer ? » ??
C’est sous-entendu. Si on vérifie la signature DKIM, c’est bien pour s’assurer que la signature existe et qu’elle est valide.
J’ai mis à jour le formulaire suite à la réunion d’hier. Je me suis permis de complètement remanier la section « Complément d’infos pour le remplissage du sondage » pour être plus claire.
J’espère que les modifications vous conviennent.
En répondant, je me suis posé plein de questions.
Mise à disposition de l’émetteur
Dans « Collecte de statistiques et d’informations », concernant « mise à disposition de l’émetteur », on peut voir 2 significations:
- la personne à l’origine du mail
- la personne qui gère un service qui utilise le relais
Liste de blocage
Quelle liste de blocage doit être utilisée pour la vérification des mails émis ?
Non
Liste globale fédérée
Liste globale par relai
Liste par émetteur fédérée
Liste par émetteur par relai
Pas d’avis
Je ne comprend pas ce que veut dire exactement « Liste globale par relai » , « Liste par émetteur fédérée » et « Liste par émetteur par relai »
Non c’est pas clair pour moi, la question pourrait comme ça pourrait impliquer que tu souhaite que la signature DKIM soit regénérée par le serveur si le client en fournit une, mais invalide, ce qui serait à mon avis une fausse bonne idée en terme de sécurité, au contraire ça devrait lever une alerte, car soit ça signifie un problème de sécurité, soit c’est un souci de config du client.
Effectivement, ce sont deux cas d’usage différents.
On peut penser dans le premier cas à la personne qui utilise un webmail. Et dans le second à la personne qui a configuré le webmail sur le serveur.
Pour moi la personne qui dispose de l’accès au relais (second cas) peut être considéré comme un admin du relais (et donc devrait de mon point de vue pouvoir activer les logs par exemple), car elle a déjà accès à tous les mails qui arrivent au relais.
Donc du coup son niveau d’accès se retrouve soit fusionné avec « mise à disposition de l’administrateur » ou alors c’est un nouveau niveau d’accès entre « mise à dispo de l’administrateur » et « mise à dispo de la personne à l’origine du message ».
Voici ce que je comprends perso :
- Liste par émetteur par relais = tous les destinataires à bloquer, auquel cet émetteur à écrit (et donc a reçu un bounce), via ce relais
- Liste par émetteur fédérée = tous les destinataires à bloquer, auquel cet émetteur à écrit, via n’importe quel relais avec lequel on fédère en direct
- Liste globale par relais = tous les destinataires à bloquer, qui ont été contactés par ce relais directement
- Liste globale par relais = tous les destinataires à bloquer, qui ont été contactés par n’importe quel relais du réseau fédéré direct ou indirect
Fédération directe = les relais avec lesquels tu choisis de fédérer (genre « je suis connecté avec le relais de framasoft, je transmet tous mes mails de newsletter via leur relais, on a un accord explicite, c’est configuré manuellement chacun de notre côté »). Équivalent un peu de la discussion sur Signal : chacun doit accepter de causer à l’autre.
Fédération indirecte = les relais avec lesquels ont est fédérés par « association ». Exemple : je choisi de fédérer avec framasoft, eux sont fédérés avec ARN. Je suis pas fédéré en direct avec ARN, mais je peux quand même recevoir la liste de blocage des hard bounces de ARN, via Framasoft. Par contre ces blocages ne pourront pas être associés à un expéditeur, vu qu’on n’a pas de fédération directe, il n’y a pas de partage de l’info sur l’expéditeur.
Enfin c’est comme ça que je le vois, peut-être Sekil a pas la même idée ?
@sekil @acnh38 je me demande si ça serait pas utile en plus de pointer sur le matrix, de pointer aussi sur cette discussion du forum si des gens ont des questions. Du coup il y aura peut-être déjà des réponses ici
La présentation a été faite hier à la réunion FFDN.
Le pouet est diffusé à l’instant sur Masto (Merci @margauxm pour la punchline d’enfer 
).
Bonne journée à tous.
1 « J'aime »
Super ! Pas de retour en particulier de la réunion FFDN ?
Relayé sur Mastodon.
Rajouté un nouveau sujet sur ce forum pour signifier qu’il faut aller répondre au sondage, suite au retour reçu en réunion CHATONS ce soir.