EN
Copied
Modules

Vérification emails

Vérification emails

Le module verify_emails vérifie que les adresses d'une liste peuvent recevoir du courrier. Il contrôle la syntaxe, repère les fautes de frappe évidentes, résout les enregistrements MX, ouvre une sonde vers le serveur récepteur, et écarte les domaines jetables et les préfixes suspects (test@, noreply@, abuse@ et assimilés).

Fonctionnalité réduite pendant l'alpha, pour des raisons de coût technique. Les contrôles de syntaxe, de fautes de frappe, de domaines jetables, de préfixes suspects et de MX tournent pour chaque adresse. La sonde de boîte (SMTP) part de notre serveur, avec plusieurs essais et la détection du catch-all et du greylisting. Les grands fournisseurs de messagerie grand public (Gmail, Outlook, Yahoo, Orange, Free, SFR, La Poste, iCloud et d'autres) refusent ces sondes : leurs adresses ressortent en skipped. Certains serveurs récepteurs ne répondent pas clairement à notre serveur, ce qui donne des lignes unknown. Si le port de sonde est fermé de notre côté, le job passe en mode MX seul et marque les lignes unknown avec la catégorie mx_only.

Il s'exécute après une étape d'enrichissement ayant produit des emails, ou contre une liste importée. Le job est parallèle : il ne consomme pas de slot sur la file multi-proxy et peut tourner en même temps que des jobs d'extraction.

Les domaines jetables sont détectés, tandis que les services d'alias de confidentialité (Apple, DuckDuckGo, Proton) sont reconnus comme de vraies boîtes et jamais rejetés comme jetables. Les domaines catch-all sont remontés comme des cas où l'acceptation n'est pas une garantie.

Inputs

Champ Requis Source
email oui issu d'un job emails précédent, ou importé
nom non transmis en passe-plat vers la sortie
telephone non transmis en passe-plat
site_web non transmis en passe-plat

needs: ['email']. Les items sans @ sont écartés à la création du job. La déduplication se fait sur l'adresse en minuscules. Le job accepte entre 1 et 10000 items par appel.

source_job_id est optionnel et pointe vers le job emails dont la sortie est vérifiée. L'UI expose ce sélecteur en from_jobs_of_type: 'emails'.

Outputs

Le job produit un rapport de vérification. Chaque ligne porte l'adresse vérifiée et le verdict ; les colonnes d'entrée sont conservées.

Colonne Type Signification
email string Adresse en minuscules telle que soumise
status string Verdict de délivrabilité (voir valeurs ci-dessous)
category string Comment le verdict a été obtenu : smtp, syntax, disposable, suspect, big_provider, no_mx, mx_only, error
reason string Explication lisible du verdict
suggested_fix string Correction suggérée en cas de typo évidente, si détectée (optionnel)
smtp_code string Code de réponse SMTP brut de la sonde, si un check SMTP a eu lieu
catch_all string yes, no ou unknown : le domaine accepte-t-il n'importe quelle adresse
nom string Transmis depuis l'entrée
telephone string Transmis depuis l'entrée
site_web string Transmis depuis l'entrée

status prend l'une des valeurs :

Valeur Signification
valid Le serveur récepteur a accepté l'adresse
valid_catch_all Accepté, mais le domaine est catch-all : l'acceptation n'est pas une garantie
invalid Le serveur a rejeté l'adresse
greylisted Différé temporairement par le serveur ; réessayable plus tard
unknown Indéterminable (délai dépassé, sonde bloquée, mode MX seul)
filtered Rejeté avant l'étape SMTP : syntaxe, jetable, préfixe suspect ou pas de MX (voir category)
skipped Grand fournisseur grand public (Gmail, Outlook, Orange, etc.) qui refuse les sondes : boîte non vérifiable

Les colonnes de signal (status, category) sont déclarées dans le registre des modules sous produces. Ce sont les colonnes sur lesquelles les nœuds filter et sort en aval peuvent brancher.

Cycle de vie

États de job standard. Voir Cycle de vie des jobs. La progression est rapportée par email (progress_unit: 'emails').

Pipeline

Le module déclare le contrat suivant :

Propriété Valeur
needs email
produces status, category
category verify
pipelinable true
supports_veille false

Dans un pipeline, verify_emails accepte tout nœud amont qui émet email (typiquement emails ou import). Sa sortie verified peut alimenter un nœud filter ou sort en aval : filtrez sur status pour ne garder que les lignes acceptées (par exemple status ∈ valid, valid_catch_all). Le constructeur de pipeline n'accepte pas de nœud d'enrichissement après verify_emails.

Endpoints

Créer un job

POST /api/jobs/verify-emails

Body :

{
  "items": [
    { "email": "alex@example.com", "nom": "Alex", "site_web": "https://example.com" },
    { "email": "contact@example.org" }
  ],
  "source_job_id": "f3c2…"
}

source_job_id est optionnel. items est requis, avec au moins un enregistrement et au plus 10000.

Réponse : JobPublic (l'enveloppe de job standard).

Lire un job

Les endpoints de job standard s'appliquent :

GET  /api/jobs/{id}
GET  /api/jobs/{id}/events     # flux SSE
GET  /api/jobs/{id}/download   # CSV

Pour les caps par job et par compte, voir Limites. Le débit est plafonné à 15 vérifications par seconde sur 4 workers, avec jusqu'à 3 essais SMTP par adresse, pour que l'IP sortante ne soit pas signalée par les fournisseurs mail. En mode MX seul (sans sonde SMTP), le plafond passe à 80 par seconde. Concurrence : le job tourne sur le pool de workers parallèle ; un verify_emails ne bloque jamais un scraping et n'est jamais bloqué par lui.

Erreurs

Code Condition
400 Aucun email valide dans la liste : items vide, toutes les entrées sans @, ou toutes en doublon
400 Quota dépassé : coût estimé supérieur à MAX_EF_PER_JOB
401 L'appelant n'est pas un utilisateur actif
422 Le payload ne correspond pas à VerifyEmailsJobCreateRequest

Les échecs par item (timeout MX, sonde SMTP refusée, etc.) ne font pas échouer le job. La ligne est écrite avec status = unknown et le job avance.

Pour aller plus loin