Faire le dossier de suppression expliquer le changement
Un crédible liste de blocage La demande de suppression est une courte chaîne de preuves : l'opérateur a identifié un objet particulier, le propriétaire responsable a enquêté sur le comportement concerné, une action corrective a résolu la cause et les observations ultérieures soutiennent l'amélioration revendiquée. Une longue déclaration selon laquelle l’entreprise est légitime ne remplace pas cette chaîne. Il n’y a pas non plus de capture d’écran montrant qu’un contrôle d’authentification sans rapport a réussi.
Préparez le dossier avant d’ouvrir un formulaire de soumission. Cet article décrit un workflow de préparation interne, et non une demande terminée. Aucune recherche d'annonce, message externe, soumission de suppression, paiement ou modification de compte n'a été effectuée. Le propriétaire responsable doit examiner à la fois les faits techniques et les informations qui peuvent être partagées avec l'opérateur.
Établir l'opérateur et l'objet répertorié
Enregistrez le nom de l'opérateur, la liste ou l'ensemble de données, l'adresse IP exacte, le domaine ou tout autre objet, la référence de la liste si disponible et l'horodatage. Un expéditeur peut utiliser un domaine, une adresse IP partagée et des domaines de liens intégrés dans le même message ; ce ne sont pas des objets interchangeables. Le client d'un fournisseur peut également ne pas avoir le pouvoir de demander la suppression de l'infrastructure appartenant à ce fournisseur. Résolvez la question de la propriété et des contacts avant de rédiger une réclamation concernant le contrôle.
Les directives générales de Spamhaus orientent les demandes via son vérificateur et exigent que le propriétaire enregistré agisse ou que le client implique le fournisseur de services. Il s'agit d'une procédure spécifique à Spamhaus et non d'une règle universelle pour chaque liste. Les instructions actuelles de l'opérateur doivent déterminer le canal applicable et les preuves demandées. Questions générales Spamhaus.
Distinguer une cause démontrée d'une cause plausible
Le dossier doit indiquer ce que l’enquête a réellement établi. « Une boîte aux lettres compromise a envoyé des messages non autorisés pendant l'intervalle enregistré » nécessite une preuve de compte et de message à l'appui. « L'adresse IP est partagée et le fournisseur enquête » décrit un état différent et incomplet. Ne transformez pas les soupçons en certitude simplement pour donner l’impression qu’un formulaire est complet. Une cause honnête non résolue est plus utile qu’un récit inventé pour remédier à la situation.
Préserver le lien entre la cause et l’action. Une modification de mot de passe n'explique pas une liste de stratégies pour une plage d'adresses qui n'est pas destinée à envoyer du courrier directement vers MX. Un changement DNS n'explique pas pourquoi une application a cessé d'envoyer du courrier indésirable. Si le problème observé concerne un service d'envoi mutualisé, identifiez ce que le prestataire a confirmé et ce qui reste hors de visibilité du client.
Reliez chaque action corrective à une observation datée
Pour chaque action revendiquée, enregistrez son propriétaire, sa portée, son délai d'exécution et les preuves à l'appui. Séparez un plan approuvé d'une modification exécutée et une modification exécutée d'une vérification réussie. « L'équipe examinera les règles de transfert » n'équivaut pas à « les règles ont été révisées » et ne prouve pas non plus que le transfert non autorisé a cessé.
Spamhaus demande la cause, les mesures correctives, le calendrier et les mesures préventives, et prévient qu'une demande ne garantit pas la suppression. Utilisez cela comme un exemple concret des attentes d'un opérateur en matière de preuves, et non comme une promesse que les quatre mêmes champs satisfont à chaque service. Évitez les expressions vagues telles que « tout est réglé » lorsqu’une affirmation plus précise peut être appuyée. Questions générales Spamhaus.
Préparez un dossier de preuves fictives
Imaginez un expéditeur fictif dont les informations d'identification de l'application ont été utilisées de manière abusive en raison d'une intégration compromise. Le projet de paquet identifierait le flux concerné, l'objet répertorié confirmé par l'opérateur, la fenêtre d'incident, la décision de confinement autorisée et la réparation d'intégration. Il ne joindrait que les preuves approuvées et pertinentes et indiquerait toute lacune en matière de surveillance. Ceci est une illustration de la structure du disque ; aucun compromis de compte ou inscription n’a été observé.
Un paquet fort distinguerait la preuve de confinement du propriétaire de l'identité des journaux d'envoi du fournisseur de messagerie et du statut de l'opérateur de liste. Si l'équipe n'a réinitialisé qu'un seul mot de passe alors que l'accès à l'intégration reste non résolu, le paquet doit rester incomplet. Si un fournisseur possède l'adresse IP répertoriée, le paquet doit être préparé pour examen par ce fournisseur plutôt que soumis dans le cadre d'une revendication de propriété inventée.
Ne pas confondre suppression et acceptation du destinataire
Les listes ont des objectifs et des cycles de vie différents. SpamCop décrit une liste automatisée d'adresses IP associées aux courriers signalés et supprimées automatiquement à mesure que les rapports cessent. Sa documentation reconnaît également les faux positifs et conseille une utilisation prudente. Ne lui appliquez pas le timing, le processus manuel ou l'offre commerciale d'une autre liste. La page elle-même indique que sa description détaillée peut changer. Explication de la liste de blocage SpamCop.
Le récepteur concerné peut utiliser d'autres signaux après qu'un opérateur ait supprimé une entrée. Préservez l’intégralité des réponses SMTP , la portée du fournisseur ou du destinataire et les temps d’observation. Un achèvement final positif après les données du message établit un transfert SMTP , et non un placement dans la boîte de réception ou l'absence de filtrage ultérieur. Un contrôle du statut d'opérateur et un nouveau test de livraison appartiennent donc à des domaines différents. RFC 5321 , section 4.2.5.
Minimisez la divulgation et évitez les engagements prématurés
Préparez un enregistrement compact contenant ce dont l'opérateur a besoin, avec le contenu des messages sensibles et les données de destinataire sans rapport supprimées de la copie de travail. Protégez les journaux originaux afin que la rédaction ne masque pas les preuves en interne. N’incluez jamais de mots de passe, de jetons, de clés privées ou de détails de paiement dans un récit de suppression. Toute divulgation ou soumission spécifique à un compte nécessite l’autorisation appropriée.
Si l'opérateur propose un service payant, traitez son coût, ses conditions et sa portée comme une décision distincte. Le paiement ne constitue pas une preuve que la cause a été corrigée et ne peut garantir la livraison chez chaque fournisseur. De même, des demandes répétées ne devraient pas remplacer l’achèvement de l’enquête. Conservez une chronologie claire et la référence du cas pertinente afin que les réviseurs ultérieurs puissent comprendre ce qui a changé entre les contacts.
Décidez si le paquet est prêt à être soumis
L'examen du propriétaire doit répondre à trois questions : les allégations sont-elles fondées, s'agit-il de l'itinéraire actuel de l'exploitant et la divulgation proposée est-elle approuvée ? Les faits non résolus devraient rester étiquetés plutôt que cachés. Si l'itinéraire correct de l'opérateur est inaccessible, arrêtez cette étape de soumission et continuez à préparer des preuves qui ne dépendent pas de l'accès.
Une liste confirmée par l'opérateur et une cause documentée, une action corrective et un nouveau test de livraison. Cette exigence exacte du catalogue reste ouverte. La carte de paquets personnalisée ci-dessous contient uniquement les champs proposés. Aucune liste confirmée par l'opérateur, aucune mesure corrective exécutée, aucune soumission autorisée ou nouveau test de livraison contrôlée n'accompagne ce projet, et aucun résultat de suppression ou de récupération n'est promis.