Un moyen pour l'enregistrement DNS de dire «ce domaine n'a pas de serveur de messagerie»?

8

Quelle est la façon appropriée de configurer un enregistrement DNS qui dit "ce domaine n'a pas de serveur de messagerie"?

Je suppose que j'ai besoin d'un enregistrement MX spécial pour ce faire, sinon on supposera que l'enregistrement A est la réponse.

Je pose cette question car il semble qu'il serait préférable d'arrêter le courrier en première ligne, il ne revient donc pas au serveur Web de rejeter le courrier pour le domaine en question.

— Bryan Field
source

1

Je suis tenté de dire que définir quelque chose comme MX 0 localhost. ça rebondirait à l'expéditeur.

— Zoredache

3

Ne lancez pas de serveur de messagerie.

— Michael Hampton

3

@Zoredache Bad mail admin! Violation RFC.

— HopelessN00b

1

L'adresse @ d'abus est facultative. Seule une adresse e-mail administrative est requise et ne doit pas nécessairement se trouver sur le même domaine.

— John Gardeniers

1

Le serveur Web n'est jamais responsable du traitement des e-mails. Un serveur Web ne recevrait en fait des tentatives de connexion SMTP que s'il se trouvait sur l'adresse d'enregistrement A du domaine, il n'y a pas d'enregistrement MX et il écoute sur le port 25. Même dans ces circonstances, parce que le serveur Web ne parle pas SMTP, ces tentatives de connexion serait silencieusement ignoré.

— John Gardeniers

8

En raison de la possibilité de contacter directement un hôte via ses enregistrements d'adresse, un seul enregistrement "null MX" de "MX 0". est le moyen apparemment préféré d'indiquer que l'hôte n'accepte pas le courrier électronique. Ceci est similaire à un enregistrement "SRV nul" ("SRV 0 0 0") qui marque spécifiquement un service comme non disponible (selon le RFC 2782 SRV-RR).

Cela a été normalisé par RFC 7505 (en décembre 2017, il s'agit d'une norme proposée ).

"MX 0 localhost." (ou une étiquette équivalente pointant sur :: 1 et 127.0.0.1) est également acceptable mais plus appropriée pour un hôte qui doit envoyer du courrier à lui-même (par exemple, sortie de tâche cron) qui n'accepte pas de courrier externe. Ces hôtes peuvent avoir un serveur de messagerie opérationnel qui est protégé par pare-feu d'Internet, mais d'autres services sont accessibles.

Ne pas avoir d'enregistrement MX et bloquer le port SMTP n'empêche pas les gens de gaspiller leur bande passante entrante en essayant de contacter un serveur inexistant. Les méthodes d'enregistrement MX unique ci-dessus empêchent un tel trafic car les enregistrements de type adresse ne sont jamais essayés quand au moins un enregistrement MX est présent. Cela n'empêchera probablement pas certains spammeurs d'essayer de contacter un hôte directement via ses enregistrements d'adresse. Cependant, comme cela empêche le trafic légitime d'essayer, vous pourrez identifier les sources de spam avec une certitude à 100%.

L'utilisation d'adresses privées ne doit pas être utilisée car on ne peut pas dire où elles finiront. L'utilisation d'autres adresses réservées (par exemple l'adresse de documentation de 192.0.2.0/24) est également inappropriée, sauf si elle essaie d'identifier et de piéger les spammeurs au sein de son propre réseau lorsqu'ils tentent de se connecter.

— Mr. X
source

3

Je ne sais pas quelle est la méthode "standard", mais voici celle que j'ai rencontrée: définissez une MX recordsur une adresse de bouclage .

Je suppose que n'importe quelle adresse IP privée (ou autrement IP "invalide" 0.0.0.0) ferait l'affaire. Personnellement, je pense que c'est une chose moche à faire, mais cela ferait ce que vous voulez. Vous pouvez le coupler avec un nom d'hôte comme thisdomaindoesntacceptemail.sostopsendingitun service à l'administrateur de messagerie qui se retrouvera avec le ticket pour "e-mail en panne" car votre domaine n'acceptera pas les e-mails. :)

Cependant, pourquoi ne pas simplement supprimer le MX record, et définir vos règles de pare-feu sur leA record pour bloquer SMTP et TLS (et tout autre port de messagerie)?

Cela ferait passer le message, et tout administrateur qui effectue une recherche ne verra pas MX record, et les connexions refusées sur la solution de rechange A recordélimineront tout doute sur l'intention de votre configuration, si quelqu'un regardait de plus près après avoir vu non MX record.

— HopelessN00b
source

4

Si vous êtes méchant, vous pouvez TARIFIER les ports SMTP. > :)

— Zoredache

1

@Zoredache Ou pour un mal encore plus déroutant, utilisez le serveur SMTP de quelqu'un d'autre comme votre MX record.

— HopelessN00b

@Zoredache haha je vais le faire :))

— Golja

2

Pour citer votre propre commentaire "Bad mail admin! RFC violation".

— John Gardeniers

@JohnGardeniers Soyez juste. J'ai dit que je pensais que c'était une chose moche à faire, et j'ai également suggéré une meilleure solution, conforme aux RFC. Mais nous ne sommes pas ici pour empêcher les gens de souffler les pieds, si c'est ce qu'ils décident de faire, après avoir eu la possibilité de prendre une décision en toute connaissance de cause.

— HopelessN00b

3

Un simple enregistrement TXT fera cela pour vous, définissez les enregistrements SPF pour qu'ils aient une valeur nulle avec un échec dur:

@ IN TXT "v=spf1 -all"
* IN TXT "v=spf1 -all"

C'est ainsi que je m'assure qu'un domaine ne peut pas être hameçonné que j'utilise pour des services internes ou non-mail.

— Matt Mc
source

1

Je pense que spécifier un nom DNS inexistant comme hub de messagerie de domaine (MX) suffirait.

UPD. : Et enfin il y a http://tools.ietf.org/html/draft-delany-nullmx-00

UPD. 2 : Cela a finalement évolué vers une norme proposée par l' IETF maintenant: RFC 7505: Un enregistrement de ressource de service «Null MX» pour les domaines qui n'acceptent aucun courrier

— poige
source

Les RFC permettent de revenir à l'enregistrement A s'il n'existe aucun enregistrement MX. en.wikipedia.org/wiki/MX_record#History_of_fallback_to_A

— Zoredache

1

Oui, ajoutons une autre configuration DNS cassée à Internet.

— John Gardeniers du

@Zoredache, dit-il en l' absence de MX.

— poige

@JohnGardeniers, qui s'en soucie? Vous? Pourquoi? Soit vous avez une meilleure idée, soit vous avez des visions vraiment horribles de la raison pour laquelle la mienne serait trop mauvaise pour ne jamais y penser. Alors, quelle est la tienne? Ni?

— poige

@poige Bonne idée avec ce projet, mais malheureusement, il n'est jamais allé nulle part, il n'y a donc pas de façon "officielle" de le dire this domain doesn't accept email.

— HopelessN00b