Comment empêcher les gens d'utiliser mon domaine pour envoyer du spam?
Je reçois des messages de Mailer Daemon disant que certains e-mails échouent. Mon domaine est itaccess.org qui est administré par les applications Google. Existe-t-il un moyen d'identifier qui envoie des e-mails depuis mon domaine et comment ils le font sans que je crée un compte pour eux?
Delivered-To: [email protected]
Received: by 10.142.152.34 with SMTP id z34csp12042wfd;
Wed, 8 Aug 2012 07:12:46 -0700 (PDT)
Received: by 10.152.112.34 with SMTP id in2mr18229790lab.6.1344435165782;
Wed, 08 Aug 2012 07:12:45 -0700 (PDT)
Return-Path: <[email protected]>
Received: from smtp-gw.fsdata.se (smtp-gw.fsdata.se. [195.35.82.145])
by mx.google.com with ESMTP id b9si24888989lbg.77.2012.08.08.07.12.44;
Wed, 08 Aug 2012 07:12:45 -0700 (PDT)
Received-SPF: neutral (google.com: 195.35.82.145 is neither permitted nor denied by best guess record for domain of [email protected]) client-ip=195.35.82.145;
Authentication-Results: mx.google.com; spf=neutral (google.com: 195.35.82.145 is neither permitted nor denied by best guess record for domain of [email protected]) [email protected]
Received: from www20.aname.net (www20.aname.net [89.221.250.20])
by smtp-gw.fsdata.se (8.14.3/8.13.8) with ESMTP id q78EChia020085
for <[email protected]>; Wed, 8 Aug 2012 16:12:43 +0200
Received: from www20.aname.net (localhost [127.0.0.1])
by www20.aname.net (8.14.3/8.14.3) with ESMTP id q78ECgQ1013882
for <[email protected]>; Wed, 8 Aug 2012 16:12:42 +0200
Received: (from whao@localhost)
by www20.aname.net (8.14.3/8.12.0/Submit) id q78ECgKn013879;
Wed, 8 Aug 2012 16:12:42 +0200
Date: Wed, 8 Aug 2012 16:12:42 +0200
Message-Id: <[email protected]>
To: [email protected]
References: <20120808171231.CAC5128A79D815BC08430@USER-PC>
In-Reply-To: <20120808171231.CAC5128A79D815BC08430@USER-PC>
X-Loop: [email protected]
From: [email protected]
Subject: whao.se: kontot avstängt - account closed
X-FS-SpamAssassinScore: 1.8
X-FS-SpamAssassinRules: ALL_TRUSTED,DCC_CHECK,FRT_CONTACT,SUBJECT_NEEDS_ENCODING
Detta är ett automatiskt svar från F S Data - http://www.fsdata.se
Kontot för domänen whao.se är tillsvidare avstängt.
För mer information, kontakta [email protected]
Mvh,
/F S Data
-----
This is an automatic reply from F S Data - http://www.fsdata.se
The domain account "whao.se" is closed.
For further information, please contact [email protected]
Best regards,
/F S Data
Puisqu'il n'a pas encore été explicitement déclaré, je vais le dire.
Personne n'utilise votre domaine pour envoyer du spam.
Ils utilisent des données d'expéditeur usurpées pour générer un e-mail qui semble provenir de votre domaine. C'est aussi simple que de mettre une fausse adresse de retour sur un courrier postal, donc non, il n'y a vraiment aucun moyen de l'arrêter. SPF (comme suggéré) peut permettre aux autres serveurs de messagerie d'identifier plus facilement les e-mails qui en fait proviennent de votre domaine et les e-mails qui ne le font pas, mais tout comme vous ne pouvez pas m'empêcher de mettre votre adresse postale en tant qu'adresse de retour sur toutes les menaces de mort que je poste, vous ne pouvez pas empêcher quelqu'un de mettre votre domaine comme adresse de réponse sur son spam.
SMTP n'a tout simplement pas été conçu pour être sécurisé, et ce n'est pas le cas.
C'est la nature de SMTP (le protocole utilisé pour transférer le courrier) qu'aucune validation n'est effectuée sur l'adresse de l'expéditeur répertoriée dans un e-mail. Si vous souhaitez envoyer un e-mail qui semble provenir de [email protected]... vous pouvez aller de l'avant et faire cela, et dans de nombreux cas, personne ne peut rien faire pour vous arrêter.
Cela dit, si vous établissez enregistrements SPF pour votre domaine, il y a de meilleures chances que les systèmes de réception reconnaissent l'e-mail falsifié comme spam. Un enregistrement SPF identifie les systèmes autorisés à envoyer du courrier pour votre domaine. Tous les systèmes de réception ne prêtent pas attention aux enregistrements SPF, mais les grands fournisseurs de messagerie utiliseront ces informations.
J'approuve les réponses déjà données concernant le SPF (+1, chacun de vous!) Mais veuillez noter que si vous décidez de suivre cette voie - et c'est une bonne façon - il y a inutile à le faire à moins vous identifiez et faites de la publicité tous les hôtes qui sont autorisés à envoyer des e-mails pour votre domaine, et interdisez fortement tous les autres avec -all.
Non seulement ?all et ~all n'a pas l'effet escompté, mais certains administrateurs de messagerie sur SF les considèrent comme le signe d'un domaine d'expéditeur positif.
Sender Policy Framework (SPF) peut vous aider. Il s'agit d'un système de validation de courrier électronique conçu pour empêcher le spam par courrier électronique en vérifiant les adresses IP de l'expéditeur. SPF permet aux administrateurs de spécifier les hôtes autorisés à envoyer des messages à partir d'un domaine donné en créant un enregistrement SPF spécifique (ou TXT record) dans le système de noms de domaine (DNS). Les échangeurs de messagerie utilisent le DNS pour vérifier que le courrier provenant d'un domaine donné est envoyé par un hôte sanctionné par les administrateurs de ce domaine.
Il ne semble pas qu'un SPF aurait aidé dans cet exemple particulier. Une machine qui prenait la peine de vérifier les enregistrements SPF pour rejeter le courrier est peu susceptible d'être cassée au point d'accepter le courrier pour un domaine inexistant, puis de décider qu'elle ne peut pas le livrer et de générer le message de rebond. Si mail-gw01.fsdata.se, la machine acceptant le courrier pour whao.se, l'avait correctement renvoyé, votre message de rebond proviendrait d'un serveur Google SMTP.
Malheureusement, ce type de comportement cassé (accepter et générer plus tard un rebond) n'est pas si rare. Il n'y a rien que vous puissiez faire pour empêcher une machine aléatoire de prétendre qu'elle a un message à livrer de votre domaine. Il n'y a également rien à faire contre les rebonds retardés.
Vous pouvez cependant avoir moins de ces rebonds de rebond à lire. Si 7E949BA n'est pas un vrai utilisateur sur itaccess.org, comme je le pense, ce n'est peut-être pas le cas, vous recevez le message de rebond parce que votre adresse fourre-tout est activée. Un fourre-tout signifie que votre domaine acceptera les e-mails de tout utilisateur inexistant et vous les livrera. C'est principalement un bon moyen de développer votre collection de spams et de messages de rebond. Dans Google Apps, pour configurer votre fourre-tout, c'est sous "Gérer ce domaine" -> Paramètres -> E-mail, à mi-chemin environ.
Une idée non encore évoquée est de rejeter la rétrodiffusion. Tout ce que j'ai vu provient de relais de messagerie ouverts, et il y a deux listes de trous noirs que vous pouvez trouver utiles pour réduire la quantité de rétrodiffusion que vous recevez.
Backscatterer est un DNSBL qui répertorie explicitement les serveurs SMTP qui envoient des rappels de rétrodiffusion et d'expéditeur.
RFC-Ignorant est un DNSBL qui répertorie les serveurs SMTP qui n'obéissent pas à divers RFC importants.
L'ajout de ces (ainsi que plusieurs autres BL plus traditionnellement focalisés) a réduit la quantité de rétrodiffusion que je reçois de plus de 90%.
Ce à quoi vous faites référence s'appelle en fait une attaque BACKSCATTER. Maintenant, ce que c'est réellement est déjà expliqué bien ci-dessus.
Comment le résoudre ?
La rétrodiffusion peut être évitée avec des solutions auto-hébergées comme Postfix, qmail et exim, etc., mais pas avec googleapps, car il est populaire de ne pas avoir de protection pour traiter la rétrodiffusion, à l'exception uniquement des enregistrements SPF.
Comme les autres réponses l'ont mentionné, vous recevez des rebonds à partir des e-mails de quelqu'un d'autre. SpamCop n'a auparavant pas appelé ce spam, mais ces jours-ci, il accepte les rapports pour cela. Par exemple. J'ai copié le message que vous avez cité (et j'ai inclus mon compte Gmail pour déterminer mes hôtes de messagerie) et j'ai obtenu ce résultat (que j'ai annulé).
En résumé, vous pouvez utiliser SpamCop pour signaler les expéditeurs de ces rebonds. Cela n'arrête pas (directement) les initiateurs du problème, mais cela peut réduire ces rebonds.