Transférer des e-mails d'un domaine à un autre sur un autre domaine?


2

Je gère un petit serveur Debian à la maison et il héberge deux sites Web. Je souhaite également recevoir des courriers électroniques sur ce domaine, sur ce serveur, mais également sur nos adresses électroniques réelles. Essentiellement, s’ils envoient un courrier électronique anything@domain.com, il le transfère à canadianluke@otherdomain.comun autre domaine. Est-ce possible, ou ai-je besoin d'un programme de serveur de messagerie FULL sur mon serveur pour le faire?

Mon registraire est Canspace.ca et je ne vois aucune option de messagerie, sauf pour spécifier mon enregistrement MX, que je signalerais à mon serveur. Actuellement, aucun courrier électronique n'est hébergé sur mon serveur, mais l'objectif est que tous les courriers électroniques destinés à mon nom de domaine soient envoyés à mon adresse électronique habituelle.

J'ai envoyé un courrier électronique à la registraire, qui a déclaré qu'à moins d'acheter le package d'hébergement pour le site Web et tout le reste, aucun service de messagerie n'est offert, mis à part pointer le record MX quelque part. Donc, pour revenir à la question initiale, quelle est la plus petite chose que je puisse faire à mon serveur Debian pour obtenir le courrier qui lui est envoyé, automatiquement transféré vers mon compte principal, sans le stocker sur mon serveur?


2
Je suis surpris que votre gestionnaire de domaine (la société qui s’occupe de vos enregistrements de domaine) ne l’offre pas, probablement gratuitement. Namecheap a un transfert de courrier électronique gratuit.
Allquixotic

Hmm ... Je vais vérifier le panneau de contrôle, mais je ne pense pas qu'il a été offert. Avec le nom, je contrôle les dns, et cela semble être le cas
Canadian Luke

Il indique que le serveur est en cours d'exécution à la maison. Je ne vois aucune mention d'une société d'hébergement (pour le moment). Cela dépend donc de son fournisseur de services Internet et de sa connexion. À moins, bien sûr, que plus de détails puissent être fournis… Cette question a vraiment, vraiment besoin d'éclaircissements.
Avery Payne

@AveryPayne Quelqu'un ou quelque chose doit héberger le serveur DNS faisant autorité. Il est tout à fait raisonnable de supposer que l'hébergement DNS est fourni par le registraire ou le revendeur. De nombreux hôtes DNS fournissent également des services supplémentaires, notamment le transfert de courrier électronique (où ils ajoutent des enregistrements MX pointant vers leurs propres serveurs), ce dont parle allquixotic. Votre réponse suppose que les enregistrements MX pointent déjà vers le serveur local, ce qui est une autre approche. Soit est valide.
Bob

Mise à jour de la question, espérons que cela aide, @allquixotic, Avery et Bob
Canadian Luke

Réponses:


3

Il y a un certain nombre de façons de le faire.

Tout d’abord, permettez-moi de commencer par ceci: bien qu’il soit supposé que vous avez un service de messagerie installé, vous n’avez pas indiqué que c’était le cas. Tous les exemples ici supposent que le service est installé. Il existe d'autres méthodes qui n'exigent pas un serveur de messagerie complet, mais ce sont des cas particuliers et vous avez généralement une livraison immédiate sans file d'attente.

Debian est généralement livré avec un agent de transfert de courrier déjà installé, qui est une version d'Exim (dépend de votre version de Debian). Vous pouvez utiliser d'autres MTA, tels que Sendmail, Qmail ou Postfix, en les installant. En dehors de cette liste, je connais très bien Postfix, mes réponses tendent donc à utiliser / configurer Postfix.

fichiers .forward

Pour ce faire, le premier moyen / easyiest / cheesy consiste à placer un .forwardfichier dans le répertoire de base du compte recevant le courrier électronique. Le .forwardfichier consiste en une seule ligne, comme suit:

someuser@someserver.net

Lorsque le courrier électronique est livré, le .forwardfichier est vérifié et, le cas échéant, le contenu utilisé pour transférer le courrier électronique à l'adresse indiquée. Cela était à l'origine destiné à transférer temporairement les e-mails vers une nouvelle adresse, à l'époque de Ye Olde Days, lorsque de vrais utilisateurs étaient hébergés sur des systèmes de style réel * nix. Dans votre cas, cela ne fonctionnera probablement pas parce que (a) je doute que vous ayez réellement un compte d'utilisateur configuré pour l'adresse, (b) le "standard" est supposé être supporté par tous les MTA, mais il y a aucune garantie, et (b) l'adresse du serveur de site Web ne correspond pas correctement à l'adresse du serveur de messagerie. Il existe donc d'autres déconnexions qui empêchent cette transition.

Bien entendu, il va sans dire que rien @ somedomain.net ne sera transmis; il veut une adresse complète, résolvable. Donc, cela ne fonctionnera pas pour vous .

Utiliser un MDA

M tous les D IVRAISON A gents sont spécifiquement destinés à effectuer des livraisons aux boîtes aux lettres locales. Compte tenu du libellé limité que vous avez fourni, je ne peux que supposer que vous devez envoyer le courrier électronique à un autre serveur. Donc, ce n'est pas pour vous non plus.

Utiliser un MTA

Le deuxième option consiste à installer un M tout T ransports A gent, ce que les gens appellent généralement « service de messagerie ». La plupart d'entre eux offrent généralement la possibilité de rediriger les messages en fonction d'une série de recherches. Dans le cas de Postfix, vous pouvez router tous les messages d'un domaine donné vers une autre adresse. Tout message correspondant à cette règle est réinjecté dans le pipeline de Postfix, ce qui entraîne une livraison à la nouvelle adresse. Vous pouvez le faire en créant un mappage de l'adresse sur votre adresse de destination, puis en informant Postfix du changement.

Un autre avantage de l'utilisation d'un MTA est que le message sera mis en file d'attente pour être remis. en cas de problème (perte de connectivité à Internet, par exemple), le MTA continuera à tenter la remise jusqu'à ce que le message soit remis ou qu'un délai expiré ait été atteint, auquel cas le message sera renvoyé.

Je recommande cette approche. Cela fournit non seulement un peu de robustesse (utilisation de files d'attente), mais également une flexibilité (vous pouvez avoir plusieurs domaines mappés de cette façon).


1

Donc, j'ai ce semi-résolu. Laissez-moi passer par ce que j'ai fait.

Tout d'abord, j'ai dû installer un service pour recevoir les emails; J'ai choisi postfix, selon la suggestion d'Avery Payne. J'ai suivi les instructions sur le site Web de Debian pour l'installer et travailler localement au sein de mon réseau. J'ai pu envoyer et recevoir du courrier, mais sans utiliser le nom de domaine complet. J'ai pensé qu'il s'agissait d'un problème de DNS ou de transfert de port.

Pour configurer postfix:

apt-get install postfix
cat /var/log/mail.log
postconf -e "myorigin = example.com"
postconf -e "myhostname=server1.example.com"
postconf -e "relay_domains = example.com, example2.com, example3.com"
postfix reload

Ensuite, je l'ai testé localement:

$ telnet localhost 25
>Trying 127.0.0.1...
>Connected to localhost.localdomain.
>Escape character is '^]'.
>220 server1.example.com ESMTP Postfix (Debian/GNU)
mail from:<you@youremail.com>
rcpt to:<user@example.com>
data
To: user@example.com
From: you@youremail.com
Subject: Hey my first email
This is my first email on debian postfix after installing configuring it.
It was easy.

J'ai fini le message et envoyé en appuyant sur Enter, ., Enter.

Je suis ensuite sorti et j'ai vérifié mon courrier sur mon compte:

mail
>You have 1 new mail!

Je l'ai lu et supprimé. J'ai ensuite essayé les instructions ci-dessus pour transférer les messages, mais cela ne serait pas envoyé. Bien, peut-être que quelque chose a été bloqué. J'ai essayé de le telnet mail.example.com 25connecter et je pouvais me connecter à partir de mon portable (pas sur le Wifi). Donc, je suppose que Shaw (mon FAI) ne le bloque pas. J'ai envoyé un email à mon adresse, mais le serveur ne le recevait pas. Je suis revenu sur le Wifi, et il a envoyé le courrier! Il y a donc quelque chose qui bloque le projet, mais il faudra poser une autre question.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.