Prenons un seul message. Une boutique imaginaire, Bright Parcel, vient de voir un visiteur s'inscrire avec l'adresse quietfox42@veylax.com, et son système appuie, si l'on peut dire, sur Envoyer pour un e-mail de confirmation. Un peu plus tard, ce message s'affiche sur l'écran du visiteur, et un jour après, il n'existe plus nulle part sur le service de boîtes. Cet article le suit sur tout son trajet.
Alors, comment fonctionne le mail temporaire ? Il emploie la mécanique ordinaire du courrier sur Internet, avec une particularité : le côté réception accepte le courrier pour n'importe quel nom d'utilisateur de ses domaines et ne le garde que brièvement. Le serveur de l'expéditeur cherche l'enregistrement MX du domaine dans le DNS, se connecte à l'hôte indiqué en SMTP sur le port 25 et remet le message. Le système de mail temporaire l'analyse ensuite, l'affiche dans une boîte et le supprime selon un calendrier. Sur VookMail, les enregistrements MX des domaines pointent vers un prestataire de distribution du courrier, qui reçoit la session SMTP et transmet chaque message à VookMail par HTTPS.
Étape 1 : le départ de chez l'expéditeur
L'application de Bright Parcel construit le message. Un message est du texte structuré, organisé selon l'Internet Message Format (RFC 5322) : des en-têtes comme From, To et Subject, puis une ligne vide, puis le corps. L'application ne le livre généralement pas elle-même. Elle le confie à un service d'envoi, soit par une connexion SMTP authentifiée sur le port 587 (ou 465 avec TLS dès le début), soit par l'API web de l'entreprise d'envoi.
Le premier retard peut survenir dès ici. Beaucoup d'applications placent le courrier sortant dans une file de tâches et le traitent par lots, en particulier les plateformes d'e-mailing. Le moment où un site affiche « vérifiez votre e-mail » peut donc précéder de loin celui où le message part réellement. Dans notre exemple, disons que la file prend vingt secondes. Rien n'est encore arrivé côté destinataire, et aucun service de mail temporaire ne peut le voir ni l'accélérer.
Étape 2 : trouver où veylax.com reçoit son courrier
Le serveur sortant lit la partie après le @, ici veylax.com, et demande au DNS les enregistrements MX de ce domaine. Un enregistrement MX (mail exchanger) désigne un serveur qui accepte le courrier du domaine. En notation de fichier de zone, voici à quoi pourraient ressembler les enregistrements d'un domaine. Les noms sont inventés pour l'illustration :
example-temp.com. 3600 IN MX 10 mx1.mail-provider.example.
example-temp.com. 3600 IN MX 20 mx2.mail-provider.example.
Le 3600 est le TTL (time to live), le nombre de secondes pendant lesquelles un résolveur peut garder cette réponse en cache. Le 10 et le 20 sont des préférences : les expéditeurs essaient d'abord le nombre le plus bas et se rabattent sur le plus élevé s'ils n'arrivent pas à joindre le premier. Le nom d'hôte doit avoir son propre enregistrement A (IPv4) ou AAAA (IPv6). Un enregistrement MX doit pointer vers un nom d'hôte, et non directement vers une adresse IP ni vers un alias CNAME.
Vous pouvez faire cette requête vous-même pour n'importe quel domaine :
| Système | Commande |
|---|---|
| Invite de commandes Windows | nslookup -type=mx example.com |
| Windows PowerShell | Resolve-DnsName example.com -Type MX |
| macOS et Linux | dig MX example.com +short |
Les systèmes antiabus emploient cette même requête pour repérer les domaines qui acheminent le courrier vers une infrastructure jetable connue. C'est l'une des raisons pour lesquelles certains sites reconnaissent les domaines de mail temporaire, même quand le domaine lui-même est récent.
Deux cas limites du DNS
Un domaine sans enregistrement MX n'est pas automatiquement injoignable. La RFC 5321, la norme SMTP, définit une solution de repli : l'expéditeur peut traiter l'enregistrement A ou AAAA du domaine comme un hôte de messagerie implicite. Un domaine qui ne veut aucun courrier peut le dire avec un MX nul (RFC 7505), c'est-à-dire un enregistrement MX de préférence 0 avec un simple point comme hôte. Les domaines de mail temporaire publient bien sûr des enregistrements MX normaux, puisque recevoir est toute leur raison d'être.
Le cache peut aussi gêner quand un service ajoute un domaine. Les résolveurs qui ont récemment reçu la réponse « aucun enregistrement » peuvent la garder jusqu'à la fin de la durée du cache négatif, fixée par l'enregistrement SOA du domaine (RFC 2308). Un domaine tout neuf peut donc mettre un moment à recevoir de façon fiable depuis tous les expéditeurs.
Étape 3 : la conversation entre deux serveurs
Le serveur sortant de Bright Parcel ouvre maintenant une connexion TCP vers l'hôte MX préféré sur le port 25. SMTP est un protocole textuel : le client envoie des commandes et le serveur répond par des codes numérotés. Voici une session simplifiée pour notre message, où S: est le récepteur et C: l'expéditeur. Les hôtes et le chiffre de taille appartiennent à cet exemple inventé.
S: 220 mx1.mail-provider.example ESMTP ready
C: EHLO out.brightparcel.example
S: 250-mx1.mail-provider.example
S: 250-STARTTLS
S: 250 SIZE 26214400
C: STARTTLS
S: 220 Ready to start TLS
(poignée de main TLS, puis nouvel EHLO)
C: MAIL FROM:<bounce@brightparcel.example>
S: 250 OK
C: RCPT TO:<quietfox42@veylax.com>
S: 250 OK
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: (en-têtes, ligne vide, corps, puis une ligne avec un seul point)
S: 250 Queued as 8F2A1C
C: QUIT
S: 221 Bye
| Commande | Rôle | Ce que cela signifie pour le mail temporaire |
|---|---|---|
EHLO | Identifie l'expéditeur et demande ce que le serveur prend en charge | La réponse énumère des extensions comme STARTTLS et la taille maximale SIZE |
STARTTLS | Passe la connexion en TLS (RFC 3207) | Protège ce seul saut. Ce n'est pas du chiffrement de bout en bout |
MAIL FROM | Fixe l'expéditeur de l'enveloppe, là où partent les rebonds | Diffère souvent de la ligne From visible, surtout pour les expéditeurs en masse |
RCPT TO | Nomme un destinataire | Un récepteur fourre-tout répond 250 pour n'importe quel nom d'utilisateur de ses domaines |
DATA | Démarre le contenu du message | Se termine par un point seul sur une ligne |
QUIT | Ferme la session | La livraison était déjà réglée par le 250 après DATA |
Le moment où la responsabilité change de mains
Ce dernier 250 est la ligne la plus importante de la session. Jusque-là, le message appartient au serveur de Bright Parcel, qui réessaie si la connexion tombe. Après, le récepteur a accepté la responsabilité. Le tableau de bord de l'expéditeur affichera alors en général « livré », ce qui signifie seulement que ce saut a réussi. Cela ne veut pas dire qu'une personne a vu quoi que ce soit.
Les codes de réponse expliquent une bonne part des comportements observés :
- 2xx signifie le succès, et
250veut dire accepté. - 3xx est une étape intermédiaire, et
354dit à l'expéditeur de transmettre le message. - 4xx est un échec temporaire, par exemple
421ou451. L'expéditeur garde le message dans sa file et réessaie. - 5xx est un échec définitif, par exemple
550(boîte indisponible ou rejetée) ou552(trop volumineux). L'expéditeur abandonne et génère généralement un message de rebond.
La différence entre 4xx et 5xx explique la plupart des courriers « lents ». Si le récepteur avait répondu 451 à ce stade, peut-être à cause d'un greylisting (RFC 6647), notre message attendrait dans la file de Bright Parcel, ni perdu ni livré. La RFC 5321 conseille un intervalle de nouvelle tentative généralement d'au moins 30 minutes et un délai d'abandon d'au moins quatre à cinq jours, même si les systèmes réels fixent leurs propres calendriers, et que beaucoup réessaient plus tôt. C'est pourquoi une confirmation peut apparaître au bout de quelques secondes et la suivante au bout de vingt minutes, sans que rien ne soit anormal dans l'un ou l'autre cas.
Deux séries d'adresses
SMTP a deux niveaux d'adressage. L'enveloppe, MAIL FROM et RCPT TO, sert aux serveurs pour l'acheminement. Les en-têtes, From:, To: et Subject:, font partie du contenu du message et sont ce que vous voyez à l'écran. Ils peuvent différer. Une newsletter peut afficher To: subscribers alors que le destinataire de l'enveloppe était votre adresse temporaire. Un système récepteur classe donc les messages selon le destinataire de l'enveloppe, la valeur fiable. C'est aussi pourquoi l'en-tête Return-Path, ajouté à la livraison finale, enregistre l'expéditeur de l'enveloppe plutôt que l'adresse From visible.
Étape 4 : pourquoi quietfox42 n'avait pas besoin d'exister
Au moment du RCPT TO, un serveur de messagerie normal vérifie si la boîte existe et répond 550 si ce n'est pas le cas. Un domaine de mail temporaire fait l'inverse. Il fonctionne comme un récepteur fourre-tout, ou joker : chaque partie locale (ce qui précède le @) est acceptée.
Ce seul choix rend possibles les adresses instantanées. Quand VookMail vous montre une adresse aléatoire, rien n'a eu à être créé sur un serveur de messagerie. Quand vous appuyez sur Nouveau, saisissez votre propre nom d'utilisateur, choisissez un domaine et appuyez sur la flèche, ce nom « existe » déjà, puisque le domaine accepte tous les noms. L'application n'a qu'à vous montrer les messages dont le destinataire correspond à l'adresse affichée à l'écran.
Deux petites règles s'appliquent à ces noms. La norme dit qu'une partie locale peut être sensible à la casse, mais presque tous les systèmes réels traitent Test@ et test@ comme une seule boîte, et un système de mail temporaire normalise donc sagement la casse pour éviter que la capitalisation d'un expéditeur ne scinde une boîte en deux. Et la RFC 5321 limite la partie locale à 64 octets, avec une limite pratique de 254 caractères pour une adresse entière, de sorte que les noms générés doivent rester bien en deçà.
Étape 5 : du protocole de messagerie à la requête web
Notre message a maintenant été accepté par une machine qui parle SMTP. Le site qui affiche la boîte est une application web. Quelque chose doit relier les deux.
Faire tourner un serveur de messagerie exposé à tout Internet est un vrai travail : TLS, afflux de connexions, files d'attente, logiciels malveillants, entretien d'une bonne réputation. Beaucoup d'applications modernes confient donc le côté SMTP à un prestataire de réception spécialisé et reçoivent les messages sous forme de requêtes web, un schéma souvent appelé webhook d'analyse entrante (inbound parse webhook). VookMail utilise ce modèle. Voici comment cela se passe :
- Les hôtes MX du prestataire acceptent le message du serveur de l'expéditeur, comme dans la session ci-dessus.
- Le prestataire le met en forme, soit en source MIME brute, soit en champs déjà analysés comme l'expéditeur, les destinataires, l'objet, le texte, le HTML et les pièces jointes.
- Il envoie ce paquet dans une requête HTTPS POST vers un point d'accès géré par l'application de mail temporaire, ce qui chiffre le contenu entre ces deux points.
- L'application répond par un statut de succès. Si elle est injoignable ou renvoie une erreur, un prestataire sérieux réessaie selon sa propre politique.
- L'application valide la requête, associe le destinataire à une adresse et stocke le message temporairement.
| Point d'attention | Récepteur SMTP auto-hébergé | Prestataire de réception plus HTTPS |
|---|---|---|
| Exposition | Port 25 ouvert à tous les hôtes d'Internet | Le prestataire prend le trafic SMTP, et l'application ne voit que des requêtes HTTPS |
| Pics de trafic | L'exploitant doit prévoir la capacité | L'infrastructure du prestataire absorbe les pointes |
| Analyse MIME | L'exploitant écrit ou entretient un analyseur | Souvent faite par le prestataire, même si la source brute reste utilisable |
| Adaptation à une application web | Demande un pont entre la file du courrier et l'application | Le message arrive comme n'importe quelle requête d'API |
| Dépendance | Moins d'intervenants extérieurs | Dépend de la disponibilité et de la configuration du prestataire |
La dernière ligne est un vrai coût. Si un prestataire de réception subit une panne ou un problème de configuration, la livraison vers tous les domaines placés derrière lui peut s'arrêter jusqu'à ce que ce soit réglé, même si le site de mail temporaire fonctionne normalement. Les messages refusés avec une erreur temporaire pendant ce temps peuvent encore passer quand les expéditeurs d'origine réessaient, selon la durée pendant laquelle leurs files les retiennent.
Protéger le point d'accès
Un point d'accès de webhook est une URL publique, donc n'importe qui pourrait tenter d'y poster un faux message. Les implémentations soignées combinent couramment plusieurs défenses :
- La vérification de signature, où le prestataire signe chaque requête et l'application rejette celles qui ne correspondent pas.
- Un chemin secret ou un jeton connu seulement du prestataire et de l'application.
- La restriction des requêtes aux plages d'adresses publiées par le prestataire, quand elles existent.
- Des limites de taille, qui rejettent tôt les charges trop volumineuses pour protéger la mémoire et le stockage.
- L'idempotence. Les prestataires réessaient, donc le même message peut arriver deux fois, et un Message-ID ou un identifiant d'événement du prestataire évite les doublons.
Étape 6 : démonter le message
Ce qui arrive n'est pas encore quelque chose qu'une personne peut lire confortablement. Le MIME (Multipurpose Internet Mail Extensions, RFC 2045 et suivantes) permet à un même message de porter plusieurs parties dans des formats différents. Notre e-mail de confirmation pourrait être organisé ainsi, avec une facture ajoutée à titre d'exemple :
| Partie | Ce qu'elle contient |
|---|---|
multipart/mixed | Le conteneur extérieur quand il y a des pièces jointes |
multipart/alternative | Le même contenu en double, en text/plain et en text/html. Le lecteur affiche la forme la plus riche qu'il gère |
multipart/related | Du HTML regroupé avec des images intégrées, référencées par des identifiants cid: |
| Partie pièce jointe | Un en-tête Content-Disposition: attachment et un nom de fichier, puis les données encodées du fichier |
Au-dessus se trouvent les en-têtes, dont Message-ID, Date et les lignes de trace Received, qui consignent chaque serveur traversé par le message. Si vous voulez savoir où un retard s'est produit, les horodatages des lignes Received sont l'endroit où chercher.
Un analyseur doit aussi défaire plusieurs encodages. Le Base64 transporte les pièces jointes binaires et les gonfle d'un tiers environ, si bien qu'un fichier de 10 Mo devient un message d'environ 13 à 14 Mo. Le quoted-printable gère le texte surtout ASCII en écrivant les caractères spéciaux sous la forme =XX. La valeur charset= indique comment le texte est encodé, souvent en UTF-8, ce qui compte beaucoup pour un service utilisé dans de nombreuses langues. Et les objets contenant des caractères non ASCII emploient la syntaxe =?UTF-8?B?...?= ou =?UTF-8?Q?...?= de la RFC 2047.
Rendre le HTML sûr à afficher
Le HTML des e-mails est écrit par des inconnus, et un lecteur ne doit donc pas le laisser exécuter du code dans le contexte du site. Les implémentations soignées suppriment en général les scripts, les attributs de gestion d'événements et les schémas d'URL dangereux, et affichent le message dans un cadre isolé pour que ses styles et son contenu ne puissent pas affecter la page environnante.
Les images distantes demandent aussi réflexion. En charger une indique à son émetteur que le message a été ouvert, et c'est ainsi que fonctionnent les pixels espions. VookMail supprime les pixels espions cachés et garde les images désactivées tant que vous ne les autorisez pas.
Un lecteur peut aussi tirer un parti utile du texte analysé. Pour notre message de confirmation, VookMail affiche le code de vérification ou le lien de confirmation au-dessus du message, pour que personne n'ait à faire défiler un long modèle pour le trouver.
Pièces jointes
Les pièces jointes sont décodées et stockées temporairement pour pouvoir être téléchargées. Sur VookMail, les fichiers de programme courants comme .exe, .bat et .apk sont refusés, les archives comme .zip s'accompagnent d'une mise en garde, et des tailles maximales s'appliquent. Les pièces jointes sont supprimées avec les messages. Rappelez-vous que la sûreté d'un fichier n'a rien à voir avec l'endroit où il a été stocké : un document avec macros est tout aussi dangereux téléchargé depuis une boîte temporaire.
Étape 7 : l'arrivée à l'écran
Notre message est maintenant stocké, mais le navigateur qui affiche quietfox42@veylax.com ne le sait pas encore. Les applications web ont plusieurs moyens de l'apprendre :
| Technique | Fonctionnement | Avantages et inconvénients |
|---|---|---|
| Interrogation courte (short polling) | La page interroge le serveur toutes les quelques secondes | Simple et fiable, mais multiplie les requêtes |
| Interrogation longue (long polling) | Une requête reste ouverte jusqu'à ce qu'il y ait du nouveau ou qu'un délai expire | Moins de réponses vides, plus de connexions ouvertes |
| Server-Sent Events | Un flux durable du serveur vers le navigateur | Efficace dans un seul sens, se reconnecte tout seul |
| WebSockets | Une connexion persistante dans les deux sens | Pleinement interactive, demande une infrastructure dédiée |
La boîte de VookMail vérifie l'arrivée du courrier toutes les quelques secondes, et le bouton Actualiser le vérifie à la main, par exemple après la mise en veille de votre appareil ou une coupure de réseau. Ces quelques secondes sont généralement la partie la plus courte du voyage. Si le courrier semble lent, le temps a presque toujours été perdu plus tôt, dans la file de l'expéditeur ou lors d'une nouvelle tentative.
La création d'une adresse passe aussi par une petite protection contre les robots : un court calcul dans le navigateur du visiteur, connu sous le nom de preuve de travail (proof of work). Il ne coûte presque rien à un visiteur normal, et il rend plus coûteuse la création d'adresses en masse.
L'adresse peut aussi être ouverte ailleurs. Comme l'adresse elle-même identifie la boîte, la passer sur un autre appareil demande seulement de transmettre l'adresse. Le bouton QR de VookMail l'affiche sous forme de code qu'un téléphone peut scanner, ce qui permet d'y ouvrir la même boîte, et les applications Android et Huawei affichent le courrier de la même façon. C'est pratique, et cela montre aussi pourquoi ces boîtes offrent peu de confidentialité : quiconque connaît ou devine une adresse peut ouvrir cette boîte. Une adresse aléatoire est le choix le plus sûr, car elle est bien plus difficile à deviner qu'un nom court.
Étape 8 : la suppression
Environ un jour après l'arrivée de notre confirmation, elle disparaît. La conservation dans un système de mail temporaire est généralement mise en œuvre avec un horodatage sur chaque message stocké et une tâche programmée qui supprime tout ce qui dépasse la limite. Les pièces jointes conservées comme fichiers séparés partent en même temps. D'autres conceptions utilisent l'expiration au niveau du stockage, où la base de données elle-même supprime les anciens enregistrements grâce à un réglage de durée de vie. Les tâches par lots expliquent en partie que les services décrivent l'expiration comme « environ » une journée, puisque le moment exact dépend de l'exécution de la tâche. Sur VookMail, les messages, les pièces jointes et les adresses sont supprimés en 24 heures environ, et le bouton Supprimer vous permet de tout effacer plus tôt.
La courte conservation répond à deux objectifs à la fois. Elle protège la vie privée, et c'est aussi une nécessité de capacité : les boîtes jetables reçoivent beaucoup de courrier publicitaire, et le garder longtemps ne servirait personne. Notre politique de confidentialité et notre page de méthodologie détaillent la gestion des données.
Notez ce que la suppression ne touche pas. Bright Parcel a toujours l'adresse dans sa table de clients, et ses journaux indiquent toujours « livré ». Seule a disparu la copie côté boîte.
Tout le trajet dans un tableau
| Étape | Composant | Protocole ou mécanisme | Port ou format habituel |
|---|---|---|---|
| Rédaction | Application ou client de messagerie | Message RFC 5322, MIME | Texte avec en-têtes et parties |
| Soumission | Service de messagerie de l'expéditeur | Soumission SMTP ou API d'envoi | 587 ou 465 |
| Recherche d'acheminement | Résolveur DNS | Requêtes MX, puis A ou AAAA | DNS, port 53 |
| Relais | Du serveur de l'expéditeur au MX du destinataire | SMTP avec STARTTLS opportuniste | 25 |
| Réception entrante | Prestataire de distribution du courrier | Acceptation fourre-tout pour les domaines | Réponses 250, 4xx, 5xx |
| Transfert | Du prestataire à VookMail | Requête HTTPS | 443 |
| Traitement | Application de mail temporaire | Analyse MIME, nettoyage, stockage | Base de données et stockage de fichiers |
| Affichage | Navigateur ou application mobile | Vérification toutes les quelques secondes, plus Actualiser manuel | HTTPS |
| Expiration | Nettoyage programmé | Règle de conservation | Environ une journée sur VookMail |
Où interviennent SPF, DKIM et DMARC
Ces trois sigles reviennent dans presque toutes les discussions sur l'e-mail, il est donc utile de préciser où ils se situent sur ce trajet. Tous concernent la preuve de l'identité de l'expéditeur. Aucun ne décide si une adresse temporaire peut recevoir le message.
SPF (RFC 7208) est un enregistrement DNS TXT qui liste les serveurs autorisés à envoyer en utilisant un domaine comme expéditeur de l'enveloppe, et les récepteurs comparent l'IP de connexion à cette liste. DKIM (RFC 6376) est une signature cryptographique que le domaine expéditeur ajoute à certains en-têtes et au corps, vérifiée grâce à une clé publique dans le DNS. DMARC (RFC 7489) est une politique qui indique aux récepteurs que faire quand un message échoue à l'alignement SPF et DKIM avec le domaine From visible, et où envoyer les rapports.
Pour notre message, ces contrôles ont lieu vers l'étape 3. Le serveur de Bright Parcel a été comparé à son enregistrement SPF, et sa signature DKIM peut être vérifiée avec sa clé publiée. Le prestataire récepteur peut utiliser ces résultats pour signaler l'usurpation. Le transfert complique un peu les choses : une signature DKIM survit tant que le message n'est pas modifié, alors qu'un résultat SPF ne concerne que le dernier serveur connecté. Quand le courrier est relayé, ARC (Authenticated Received Chain, RFC 8617) peut consigner les résultats antérieurs. En fin de compte, pourtant, ce sont l'enregistrement MX et l'acceptation du récepteur qui font arriver le message.
Quand un message n'arrive jamais
Chaque étape ci-dessus est un endroit où un message peut s'arrêter. Remonter depuis l'extrémité de l'expéditeur est généralement le moyen le plus rapide de trouver le problème.
| Étape | Ce qui a mal tourné | Ce que vous voyez ou faites |
|---|---|---|
| Avant l'envoi | Une faute de frappe dans l'adresse | Le courrier est parti ailleurs ou a rebondi. Utilisez le bouton Copier |
| Départ de chez l'expéditeur | Le message est en file d'attente, ou les lots sont lents | Une minute ou deux est normal pour certains services. Patientez |
| Départ de chez l'expéditeur | Le site ignore discrètement les domaines jetables | Rien n'arrive. Respectez-le et utilisez une adresse permanente ou un alias pour ce site |
| SMTP | Une réponse 4xx puis une nouvelle tentative | Le message arrive après un délai qui peut aller de quelques minutes à davantage |
| SMTP | Le message dépasse la limite de taille | Un rejet 552 et un rebond vers l'expéditeur |
| Prestataire de réception | Une panne ou un problème de DNS | La livraison vers tous les domaines peut s'interrompre jusqu'à la résolution |
| Boîte | Le délai est écoulé, ou l'adresse a été supprimée | Le message arrive trop tard pour être vu |
Lire un échec quand vous gérez l'envoi
Si vous testez votre propre application, vous voyez bien plus de choses qu'un utilisateur, et notre guide sur l'e-mail temporaire pour les développeurs approfondit la conception des tests. Voici un ordre de vérification raisonnable :
- Ouvrez les journaux de messagerie de votre application ou le tableau de bord de votre prestataire d'envoi. Le message a-t-il été accepté, et quel statut final affiche-t-il ?
- Cherchez les rebonds ou les événements de webhook signalant un 5xx côté destinataire. Le texte après le code en donne souvent la raison.
- Résolvez les enregistrements MX du domaine destinataire depuis le réseau de votre serveur, avec les commandes ci-dessus. Un problème de résolveur à cet endroit peut ne se voir nulle part ailleurs.
- Vérifiez que votre domaine d'envoi a SPF, DKIM et DMARC configurés, car certains récepteurs traitent avec méfiance le courrier non authentifié.
- Envoyez un petit message en texte brut pour écarter un filtrage lié à la taille ou au contenu.
- Utilisez un nom d'utilisateur distinct par test pour savoir quelle exécution a produit quel message.
Si un message arrive tard dans la boîte, lisez ses en-têtes Received de bas en haut. Un long écart entre deux horodatages montre quel saut l'a retenu, en tenant compte d'un éventuel décalage entre les horloges de ces serveurs.
Pourquoi autant de domaines ?
VookMail vous laisse choisir parmi plus de 30 domaines. Il y a à cela des raisons pratiques. Les testeurs peuvent séparer des projets ou des suites de tests par domaine. Si un domaine a un problème de DNS ou de livraison, les autres peuvent continuer à fonctionner. Et on dépend moins d'un seul nom, ce qui aide quand les systèmes d'envoi jugent les domaines destinataires autant que les expéditeurs.
Les domaines multiples ne sont pas un outil pour contourner les sites qui refusent délibérément les adresses jetables. Si un service rejette un domaine de mail temporaire, il signale qu'il veut un contact permanent, et le bon choix est votre vraie adresse ou un alias permanent pour ce service. Le refus peut venir au niveau du formulaire, par une liste de domaines ou une requête MX comme celle de l'étape 2, ou plus tard, quand l'expéditeur renonce à envoyer.
Ce que le trajet vous apprend sur la sécurité
Après avoir suivi le message, vous voyez exactement jusqu'où va chaque protection.
Le chiffrement s'applique saut par saut. STARTTLS protège chaque tronçon entre serveurs quand les deux côtés le prennent en charge, et il est souvent opportuniste, si bien qu'une connexion peut retomber en texte clair sauf si une politique comme MTA-STS (RFC 8461) l'impose autrement. HTTPS protège les tronçons de transfert et de consultation. Rien de tout cela n'est du chiffrement de bout en bout : tous les systèmes qui traitent le message peuvent le lire.
L'accès est l'autre moitié. Sans mot de passe, connaître l'adresse suffit pour entrer, alors ne faites jamais envoyer quoi que ce soit de confidentiel à cette adresse. Une courte conservation limite les dégâts de toute exposition, mais elle signifie aussi que la boîte ne peut pas servir d'archive. Et comme le contenu n'est pas fiable, le phishing et les logiciels malveillants peuvent arriver dans cette boîte comme dans toute autre. Une boîte temporaire protège votre vraie adresse, et elle fait peu pour votre appareil si vous ouvrez un mauvais fichier. Les usages appropriés sont la confidentialité, la maîtrise du spam et les tests, comme le précisent nos conditions générales, et les comptes importants sont à placer ailleurs.
Ce que cela donne sur VookMail
Toute la mécanique ci-dessus est en place avant votre arrivée. Quand vous ouvrez VookMail, une adresse est prête. Vous pouvez appuyer sur Nouveau pour saisir un nom d'utilisateur et choisir un domaine, ou utiliser le bouton jaune « Aléatoire » décrit dans notre guide pour utiliser VookMail. Il n'y a rien à enregistrer, car le domaine accepte déjà tous les noms. Quand un expéditeur livre du courrier, le prestataire derrière les enregistrements MX le reçoit en SMTP et le transmet en HTTPS, et il apparaît dans votre boîte avec ses pièces jointes éventuelles à la prochaine vérification de la page. Environ un jour plus tard, il a disparu.
Le service est aussi disponible sous forme d'application sur Google Play et Huawei AppGallery.
Quelques questions techniques de plus
Quel port le courrier entrant utilise-t-il ?
La livraison entre serveurs de messagerie utilise SMTP sur le port TCP 25. Les ports 587 et 465 servent à soumettre le courrier sortant à votre propre fournisseur, ils apparaissent donc à l'étape 1 et non à l'étape 3. C'est aussi pourquoi une connexion domestique qui bloque le port 25 peut en général continuer à envoyer par l'intermédiaire de son fournisseur.
Un service de mail temporaire peut-il voir mes messages ?
Techniquement, oui. Le message parvient au service sous forme lisible, car c'est ainsi qu'il peut vous le montrer, et il en va de même pour le prestataire de distribution qui le traite en chemin. C'est vrai aussi du courrier hébergé ordinaire, sauf si le contenu est chiffré de bout en bout. C'est une raison de plus de tenir tout contenu sensible hors d'une boîte temporaire.
Pourquoi l'expéditeur peut-il croire qu'un message a été livré alors que je ne vois rien ?
Parce que « livré » sur le tableau de bord d'un expéditeur renvoie à la réponse 250 du serveur récepteur. Les événements postérieurs, comme l'étape de transfert ou une arrivée tardive après le vidage de la boîte, sont invisibles pour l'expéditeur.
Un expéditeur peut-il savoir que mon adresse est de type fourre-tout ?
Souvent. Un outil de vérification peut tester un nom d'utilisateur inventé sur le domaine, et si le serveur l'accepte, le domaine est probablement de type fourre-tout. Cela ne prouve pas à lui seul que le domaine est jetable, puisque beaucoup de domaines d'entreprise ordinaires sont configurés de la même façon, et ces outils le combinent donc généralement avec d'autres signaux.
Les réponses au message fonctionnent-elles ?
Les réponses de votre part ne sont pas le but de la conception, puisque la boîte sert surtout à recevoir. Si vous avez besoin d'un échange dans les deux sens, une boîte e-mail ordinaire ou un service d'alias qui gère les réponses convient mieux.
Pour en savoir plus sur le produit lui-même, consultez notre FAQ. VookMail fait partie du réseau d'outils gratuits PAYATE.