Email: Estrai da HTML (5 strategie)

Descrizione

Estrattore enterprise di indirizzi email da HTML — il pattern è universalmente noto come "email harvesting" ma in versione legitimate-only per use case authorized: lead generation B2B da siti aziendali pubblici, contact discovery di referenti commerciali dichiarati pubblicamente sui siti corporate, verifica del proprio sito che renda contatti accessibili senza JavaScript per accessibility, audit di siti cliente per compliance privacy (pre-GDPR pages che leakano email non protected). Cinque strategie parallele di parsing che coprono il 95%+ dei modi in cui le email sono encoded nel HTML reale: (1) mailto: links — il pattern canonico HTML <a href="mailto:[email protected]">, semplice da parsare via querySelector ma rappresenta solo il 40% dei casi reali perché gli admin web tipicamente nascondono le email per anti-spam; (2) Cloudflare anti-spam decoder — Cloudflare offre la feature "Email Address Obfuscation" che sostituisce le email con span data-cfemail="abc123" e un JavaScript runtime che decodifica al caricamento — il nodo implementa il decoder XOR algorithm di Cloudflare per leggere le email server-side senza eseguire JS; (3) HTML entities decode — l'admin sostituisce @ con &#64; e . con &#46; per evitare crawler naïve (es. mario&#64;acme&#46;com) — il nodo decoda le entities e poi applica regex match; (4) Regex plain — match standard RFC 5322 simplified su testo plain decoded (vari pattern fallback per edge case come email con plus addressing [email protected]); (5) Obfuscation testuale humano — "mario [at] acme [dot] com", "mario AT acme DOT com", "mario(@)acme(.)com" — pattern usato da admin che pensano "i bot non sanno parsare questo" ma il nodo li riconosce. Filtri noise enterprise per evitare false positive che inquinerebbero il dataset: blocklist di domini noti non-deliverable (example.com, test.com, localhost, domain.tld template placeholder), prefix blocklist (noreply@, no-reply@, donotreply@, mailer-daemon@, postmaster@ — generic non-personal endpoint), regex pattern blocklist per UUID-like local parts (es. 0a1b2c@... che è tipicamente tracking ID non email reale). Output: email primaria (la più probabile da contattare — ranking euristico basato su position nel documento header > body, presence in section "Contatti" vs footer generic, length del local-part) + lista completa con confidence score 0-1 per ognuna (mailto = 1.0, regex plain = 0.7, obfuscation = 0.85, entities = 0.95, cloudflare = 0.92). Use case: lead-gen B2B con contact discovery sistematico da siti aziendali (loop su sitemap_crawler URL → fetch pagina /contatti or /chi-siamo → harvest emails); raccolta indirizzi pubblici per import CRM autorizzato (es. la lista pubblica dei broker assicurativi del proprio settore); verifica del proprio sito contatti che renda email leggibile senza JavaScript per audit accessibility WCAG 2.2; deduplica email da pagine staff/team enterprise prima di outreach per evitare di scrivere al CEO + CTO + HR + Operations Manager dello stesso azienda con stessa proposta; signal di "is this still active" pre-outreach (se il dominio non risponde con email = candidato per skip senza sprecare token cold email).

⚙️ Parametri di configurazione

Campi mostrati nell’editor quando si configura il nodo. Generati direttamente dal NodeDefconfigFields.

⬆️ Output del nodo

Campi disponibili nei nodi successivi via $node.<alias>.json.<field>:

• primary_email
• all_emails
• counts
• has_emails

💡 Esempio configurazione

Snippet JSON del nodo come compare nel workflow. I valori sono derivati daidefaultValue e dai parametri required.

{
  "id": "node-action_email_harvest-1",
  "defId": "action_email_harvest",
  "label": "Email: Estrai da HTML (5 strategie)",
  "config": {
    "html": "{{$node.fetch_page.json.content}}",
    "preferredLocalParts": "commerciale,sales,info,contact",
    "strictNoise": true
  }
}

🔗 Nodi correlati nella stessa categoria