Question Pourquoi ne puis-je pas m'envoyer un mail à: MyEmail@74.125.235.55?


j'ai ouvert cmd et tapé ping gmail.com. Il me montre:

C:\Windows\system32>ping gmail.com

Pinging gmail.com [74.125.235.55] with 32 bytes of data:
Reply from 74.125.235.55: bytes=32 time=6ms TTL=56
Reply from 74.125.235.55: bytes=32 time=6ms TTL=56
Reply from 74.125.235.55: bytes=32 time=6ms TTL=56
Reply from 74.125.235.55: bytes=32 time=215ms TTL=56

Ping statistics for 74.125.235.55:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 6ms, Maximum = 215ms, Average = 58ms

C:\Windows\system32>

j'ai un Gmail compte, alors je me suis envoyé un email mais au lieu de email@gmail.com j'ai utilisé email@74.125.235.55.

Réponse:

Ceci est un généré automatiquement   Notification d'état de livraison

CECI EST UN MESSAGE D'AVERTISSEMENT SEULEMENT.

VOUS N'AVEZ PAS BESOIN DE RENVOYER VOTRE   MESSAGE.

Livraison au destinataire suivant   a été retardé:

xxxxxx@74.125.235.54

Le message sera retenté pour 2 autres   journées)

Détails techniques de temporaire   échec: le serveur destinataire n'a pas   accepter nos demandes de connexion. Apprendre   Plus à    http://mail.google.com/support/bin/answer.py?answer=7720&hl=fr   [74.125.235.54 (1): connexion   refusé]

----- Message original -----

MIME-Version: 1.0 Reçu: par   10.223.93.196 avec l'ID SMTP w4mr3261626fam.44.1309944998035; Mer,   06 juil. 2011 02:36:38 -0700 (PDT)   Reçu: par 10.223.104.194 avec HTTP;   Mer 6 Jul 2011 02:36:37 -0700 (PDT)   Date: mer. 6 juil 2011 17:36:37 +0800   ID du message:      Objet: test De: Joseph    À:   xxxxxx@74.125.235.54 Type de contenu:   multipart / alternative;   limite = 20cf3054a49348815504a763560c

testtest

Je n'ai pas reçu l'e-mail. Pourquoi?

Pourquoi je ne peux pas simplement substituer le gmail.com se séparer 74.125.235.55?


120
2017-07-06 11:01


origine




Réponses:


Parce que 74.125.235.55 n'est pas le MX (échange de courrier) pour gmail.com.

Si vous ping gmail.com, ping utilise le Un enregistrement pour effectuer sa tâche, mais l'envoi d'emails (souvent) intègre d'autres serveurs.

Vous pouvez utiliser l'outil dig (sous Windows: nslookup -q=mx gmail.com comme grawity mentionné dans les commentaires) pour voir ceux DNS enregistrements:

Probe:~ trurl$ dig -t ANY gmail.com

; <<>> DiG 9.6.0-APPLE-P2 <<>> -t ANY gmail.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65087
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 9

;; QUESTION SECTION:
;gmail.com.         IN  ANY

;; ANSWER SECTION:
gmail.com.      3519    IN  MX  30 alt3.gmail-smtp-in.l.google.com.
gmail.com.      3519    IN  MX  5 gmail-smtp-in.l.google.com.
gmail.com.      74086   IN  NS  ns4.google.com.
gmail.com.      3519    IN  MX  10 alt1.gmail-smtp-in.l.google.com.
gmail.com.      74086   IN  NS  ns3.google.com.
gmail.com.      3   IN  A   209.85.148.18
gmail.com.      3519    IN  MX  40 alt4.gmail-smtp-in.l.google.com.
gmail.com.      3   IN  A   209.85.148.83
gmail.com.      3   IN  A   209.85.148.17
gmail.com.      74086   IN  NS  ns1.google.com.
gmail.com.      3   IN  A   209.85.148.19
gmail.com.      3519    IN  MX  20 alt2.gmail-smtp-in.l.google.com.
gmail.com.      74086   IN  NS  ns2.google.com.

Comme vous pouvez le voir, il existe même plusieurs serveurs gérant des e-mails pour gmail.com et chacun de ceux-ci ont des priorités différentes (le nombre dans la dernière colonne).

Et si vous continuez, vous verrez que gmail-smtp-in.l.google.com (la première mx dans la liste ci-dessus) pointe vers une adresse IP différente:

;; QUESTION SECTION:
;gmail-smtp-in.l.google.com.    IN  ANY

;; ANSWER SECTION:
gmail-smtp-in.l.google.com. 42  IN  A   74.125.39.27

Donc, vous devriez utiliser recipient@[74.125.39.27] (c'est la bonne syntaxe, comme JdeBP mentionné dans les commentaires).


MAIS Google n'acceptera pas ces mails:

Jul  6 13:25:15 lofi postfix/smtp[31213]: C6FXXXXXXX: to=<REMOVED@[74.125.39.27]>,
relay=74.125.39.27[74.125.39.27]:25, delay=3.4, delays=0.16/0.01/0.15/3.1, dsn=5.1.1,
status=bounced(host 74.125.39.27[74.125.39.27] said:
550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 http://mail.google.com/support/bin/answer.py?answer=6596 REMOVEDg.99
(in reply to RCPT TO command))

Penser plus loin à ce sujet: Google ne veut pas ou ne peut pas accepter ces mails car ils ne savent pas à qui vous aimez l'envoyer. Le serveur derrière 74.125.39.27 pourrait gérer les emails pour gmail.com, google.com, picasa.com (etc, etc ...), il n'y a donc aucun moyen de distinguer l'utilisateur.


152
2017-07-06 11:17



Vous avez oublié de mentionner cela email@74.125.39.27 serait de toute façon la mauvaise syntaxe, conformément à la RFC 5322 § 3.4.1. - JdeBP
Section RFC pertinente. - Humphrey Bogart
nslookup donnera des informations similaires sur les machines Windows. - MikeJ-UK
nslookup -q=mx gmail.com pour être précis. - grawity


Lorsque vous envoyez un courrier électronique à user@domain.com, le serveur de courrier sortant utilise le Enregistrement MX DNS du domaine de destination pour déterminer quelle adresse IP est responsable du traitement du courrier dans ce domaine. Cela peut ne pas être la même adresse IP renvoyée lors d'un ping normal.

En utilisant l’outil 'dig' sous Linux, je peux déterminer que l’enregistrement MX de gmail.com est résolu comme suit:

gmail-smtp-in.l.google.com.
alt1.gmail-smtp-in.l.google.com.
alt2.gmail-smtp-in.l.google.com.
alt3.gmail-smtp-in.l.google.com.
alt4.gmail-smtp-in.l.google.com.

qui produisent des résultats de ping complètement différents:

$ ping gmail-smtp-in.l.google.com.
PING gmail-smtp-in.l.google.com (209.85.227.27) 56(84) bytes of data.
64 bytes from wy-in-f27.1e100.net (209.85.227.27): icmp_req=1 ttl=50 time=12.8 ms

Si vous pouvez envoyer des e-mails directement à cette adresse IP dépend de votre client de messagerie et de votre serveur de messagerie, vous devrez peut-être mettre l’adresse entre crochets, conformément à type de fentela réponse.


25
2017-07-06 11:20





Essayez d'utiliser:

email@[74.125.235.55]

11
2017-07-06 11:10



Cela pourrait ne pas fonctionner, comme le montre l'analyse des gars, mais cela vaut peut-être la peine d'essayer. - slotishtype
L'adresse "xxxxx @ [74.125.235.55]" dans le champ "À" n'a pas été reconnue. Assurez-vous que toutes les adresses sont correctement formées. - Pacerier
Je sais que c'est un paramètre spécifique à gmail. Vous pouvez l'envoyer à partir d'un autre client de messagerie, mais il ne peut pas l'envoyer. - slotishtype
Je suis curieux de savoir quelle est la raison qui vous a fait penser que cela fonctionnerait? - Pacerier
@[ip] est une syntaxe spéciale dans la RFC définie comme contournant la recherche MX. - Random832


74.125.235.55 n'est pas une passerelle Gmail. Si vous vous dirigez vers l'adresse IP de votre navigateur, celle-ci ne sera pas accessible sur le site Web de Gmail. ça ira à Google, donc ça pourrait être un point.


7
2017-07-06 11:11



Alors, quelle est la passerelle gmail? pour reformuler, quels numéros dois-je taper dans le navigateur pour obtenir la page que je vois habituellement sur gmail.com? - Pacerier
@Pacerier, les serveurs Web afficheront différentes pages en fonction du nom de domaine que vous utilisez pour y accéder. Par exemple, j'administre iconsf.org et iconsfinc.com. Ils sont sur le même serveur à la même adresse IP, mais la page Web que vous voyez dépend du nom que vous tapez. Si vous utilisez simplement l'adresse IP, vous verrez toujours iconsf.org. - CarlF


Tout d'abord, cette adresse IP elle-même ne va pas être répertoriée comme un enregistrement DNS MX (même si vous avez utilisé l'adresse IP correcte du serveur de messagerie), comme les autres l'ont dit, elle ne trouvera donc pas le serveur ne va pas non plus router en fonction de cette adresse IP en tant que @thedomain est juste utilisé pour les recherches). Même si vous utilisiez Telnet pour vous connecter directement au serveur (c'est ainsi que les experts testent directement les e-mails), cela échouerait pour la raison suivante:

Chaque fois que je configure un système de messagerie, et j'en fais beaucoup avec Microsoft Exchange ou d'autres, il faut toujours lui indiquer quels sont les domaines qu'il accepte. J'entre toujours @thedomain.com, ce qui signifie qu'il n'acceptera que les emails pour ce domaine. Depuis @74.125.235.55 n'est pas un domaine, et certainement pas dans la liste des domaines acceptés, même si vous étiez directement connecté au serveur de messagerie, il le rejettera quand même.


6
2017-07-06 11:29



Réellement, 74.125.235.55  est un domaine (selon RFC 5322 § 3.4.1 ce n'est pas la syntaxe d'une adresse IP dans un addr-spec). C'est un domaine inexistant, mais c'est un domaine, au grand dam de plusieurs opérateurs de serveurs DNS de contenu. Notez également que plusieurs MTS vont automatiquement accepter le courrier adressé aux adresses IP de leurs serveurs relais SMTP (de manière syntaxiquement correcte). C'est ce que font les anciennes versions d'exim.  Donc, qmail. - JdeBP
@JdeBP Je ne suis pas un expert de cette RFC, et quand je l'ai regardé, par la tête voulait exploser, mais ne devrait-il pas avoir un .com ou .net pour être réellement un domaine? Dans tous les cas, à toutes fins pratiques, ce n’est pas un domaine et n’est certainement pas dans la question donnée. - KCotreau
Cela fait partie du problème: il est un domaine dans la question, surtout à des fins pratiques. C'est juste que le questionneur est comme vous et ne le réalise pas. Dans un addr-spec la séquence de caractères 74.125.235.55 est un domaine, avec les étiquettes 55, 235, 125, et 74 en ordre décroissant de la racine. En 2008, Duane Wessels et al. placer ces noms de domaine inexistants comme causant quelque 3,8% des requêtes sur le serveur DNS de contenu racine "K" de l'ICANN. Il est maintenant temps de lire le RFC 4697 § 2.9. - JdeBP
J'aurais dû dire domaine "résolvable" dans mon premier commentaire. Oui, il essaie d'être résolu, mais sans le .com, etc., il échouera toujours. - KCotreau


Le problème est de savoir ce qu'est une adresse e-mail est.

Dans de nombreux schémas de protocoles, la syntaxe des adresses xxx@example.com signifie simplement "se connecter à l'hôte Internet example.com et spécifier (pour le protocole concerné) l'utilisateur xxx". SSH, FTP, SCP et autres suivent ce modèle: example.com est juste un nom de fantaisie pour une adresse IP (qui est résolu de la même manière ping). Pour les emails, c'est différent. La chaîne complète xxx@example.com est ici une adresse email, le domaine fait partie de l'adresse, n'est pas seulement le serveur auquel se connecter pour l'envoyer; ce serveur s'appelle le "relais", et il est obtenu, à partir de cet hôte, par une requête DNS spéciale (enregistrements MX) comme expliqué dans d'autres réponses, mais gardez à l'esprit:

  1. il peut coïncider ou non avec l'adresse IP "normale" pour example.com (A record). fréquemment ils sont différents.

  2. une fois que le client a découvert le relais et s’y est connecté, il doit toujours indiquer l’adresse mail complète "Je veux envoyer un mail à xxx@example.com"(le même relais peut traiter des messages pour différents domaines).

BTW, le deuxième point (mais pas le premier) s'applique également à HTTP, depuis 1.1: le domaine est utilisé pour résoudre l'adresse IP de l'hôte, mais il est également utilisé pour spécifier la ressource.


3
2017-07-06 17:00





Rappelez-vous que les serveurs de messagerie de destination regardent le adresse complète, y compris le nom qui suit le @ signe. Les serveurs de messagerie Gmail achemineront uniquement les messages se terminant par @gmail.com, rejeter ou rejeter toutes les autres adresses[1].

L'adresse IP du serveur de messagerie de Gmail est 74.125.45.27. Mais l'adresse tyler@gmail.com n'est pas la même chose que tyler@74.125.45.27. Gmail disait "Je sais qui est tyler@gmail.com, mais je n'ai jamais entendu parler du nom tyler@74.125.45.27", et décide qu'il ne pouvait pas livrer à la deuxième adresse.


[1]Oui, je sais que ce n'est pas tout à fait vrai, et oui, je connais Google Apps.


2
2017-07-06 23:04