• G
    User •

    hard bounce

    Ciao, sto facendo un programmino in python che legge i log del server di posta e ne tira fuori dei risultati (solo per gli hard bounce).
    Ma effettivamente quante sono di preciso le tipologie degli hard bounce?
    Attualmente il software filtra per: hardBounce = ["Fail","Server says","error","socket"] e salva un file che importato in un excel crea due colonne email e errore.
    Mi servirebbe però qualcosa di più preciso che mi salvi solamente gli hard bounce.
    Conoscete quali sono esattamente?
    Su un sito ho trovato questi due, sono corretti, manca qualcosa?

    hardBounce = ["Failed: ","Please try increasing the Timeout Setting for this Account","Account is not active","Invalid Email Address","550 Unrouteable address","The email account that you tried to reach does not exist","sorry, no mailbox here by that name","Undelivered","Undelivereable","Nondeliverable","NDN","Failure Notice","Failed Delivery","Failed Mail","Recipient address rejected"]

    hardBounce ["5.0.0","5.1.0","5.1.1","5.1.2","5.1.3","5.1.4","5.1.5","5.1.6","5.1.7","5.2.3","5.2.4","5.3.0","5.3.2","5.3.3","5.3.4","5.4.0","5.4.1","5.4.2","5.4.3","5.4.4","5.4.6","5.4.7","5.5.0","5.5.1","5.5.2","5.5.4","5.5.5","5.6.0","5.6.1","5.6.2","5.6.3","5.6.4","5.6.5","5.7.0","5.7.1","5.7.2","5.7.3","5.7.4","5.7.5","5.7.6","5.7.7","9.1.1"]

    grazie
    giorgio

    0
  • B
    User Attivo •

    Noi per analizzare i bounce abbiamo una trentina di "analizzatori" di formati bounce diversi e qualche centinaio di pattern per il riconoscimento dei singoli errori. Quindi non puoi sperare di ottenere qualcosa di molto preciso facendo il match di qualche parola. Ad esempio "Undelivereable" secondo me lo trovi anche in messaggi non "hard". "Please try increasing the Timeout Setting for this Account" non mi sembra hard.

    9.1.1 non esiste.

    Considera che i codici X.X.X sono presenti solo in caso di server smtp che supporta gli "enhanced status codes": in molti casi non sono presenti. Alcune volte il codice non corrisponde alla realtà e per quallo specifico server bisogna interpretare diversamente il messaggio (capita, e non di rado, che un server dica "5.1.1 casella piena" quando invece 5.1.1 è il codice di errore della casella inesistente ma l'errore reale è che la casella è piena).. ci vuole tanto tempo e voglia per tenere questi "pattern" aggiornati.

    Se intendi seguire questa strada dovrai fare vari controlli a mano e farti una suite di test dove per ogni messaggio di esempio ti memorizzi qual è la classificazione giusta e quando cambi la configurazione ti assicuri di non aver "rotto" la classificazione di messaggi precedenti.

    0
  • N
    User Attivo •

    Cosa intendi esattamente per hard bounce? Te lo chiedo perché noi, essendo un ESP, dobbiamo prestare particolare attenzione alla categoria "hard bounce", intesa come indirizzi non esistenti in quanto sono il primo indicatore di liste acquisite in maniera non corretta.
    Da quello che vedo probabilmente con "hard bounce" tu intendi un qualsiasi messaggio della categoria "permanent failure" (5.x.x) in opposizione alla "transient failure" (4.x.x) ovvero i messaggi che possono essere consegnati semplicemente riprovando successivamente

    L'RFC di riferimento per quanto riguarda gli enhanced status codes è questa https://tools.ietf.org/html/rfc3463 e, come puoi vedere nel riepilogo finale, nella la categoria 5.x.x c'è praticamente di tutto (in particolare i codici 5.1.7 e 5.1.8 denotano un problema relativo al mittente più che al destinatario).

    Se ti interessa intercettare i messaggi non consegnabili, per qualsiasi motivo, allora ti consiglio di controllare solo quelli che iniziano con 5.

    Se invece ti interessa riconoscere una casella non esistente non è assolutamente cosa semplice: noi abbiamo circa 200 regular expression solo per questo e verifichiamo costantemente i nostri sistemi di reportistica per identificare falsi positivi (attività da un indirizzo identificato in passato come HB) e i falsi negativi (indirizzi che restituiscono un bounce che noi non classifichiamo come HB per almeno X mesi di fila).
    E' veramente un'attività da spaccarsi la testa, se non sei un ESP probabilmente non ne vale la pena. Conversando con altri colleghi durante meeting internazionali la soluzione più semplice parrebbe essere quella di considerare come hard bounce tre bounce consecutivi di tipo 5xx nell'arco di Xgg (dipende anche dalla frequenza dei tuoi invii). Alla fine il numero di falsi positivi - se non hai grossi problemi di delivery per spam - è irrilevante rispetto al tempo risparmiato per l'analisi.

    0
  • G
    User •

    Grazie mille per le vostre risposte. Sicuramente grazie a voi avrò un bel pò di materiale da poter cercare e studiare.

    @Nazzareno, con il termine hb mi riferisco, o vorrei fare riferimento, alle sole mail che non possono essere consegnate per problemi dovuti al mittente: errori di sintassi, mail disattivata o non più attiva, etc... sicuramente farò riferimento agli RFC con 5.x.x tutto questo per iniziare l'epurazione 😉

    Attualmente il software fatto in python che legge i log del server fa proprio questo e, molti test a campione sembrerebbero trovare riscontro.

    0
  • B
    User Attivo •

    Non ho capito se stai guardando solo i log dell'SMTP di invio o stai analizzando anche i bounce: alcuni server rispondono tramite bounce e quindi tu vedi che il messaggio è stato consegnato con successo ma poi il server destinatario ti manda una email per dirti che non è stato consegnato e il relativo motivo. Anche qui ci sarebbe una RFC (https://tools.ietf.org/html/rfc3464). Inoltre bisognerebbe usare tecniche tipo VERP (https://en.wikipedia.org/wiki/Variable_envelope_return_path) per assicurarsi di sapere a chi si riferisce un bounce.

    Ricorda che l'RFC viene seguita da meno della metà dei server e in alcuni casi è implementata in maniera errata. Quindi il problema è interpretare tutti i casi "non standard". Arrivare ad identificare il 50% degli errori è banale, identificarne il 90% abbastanza fattibile, arrivare al 99 e passa per cento è da "spaccarsi la testa", come dice Nazzareno.

    0
  • G
    User •

    Utilizzo Groupmail, questo, per ogni invio crea più report: status report (report generale), errors report, filtered report. Solo nello status ho il report di tutto l'invio es:

    Delivery Started

      • GroupMail v5.03.134*
      • Delivery Console v5.03.134*
      • Delivery Engine v7.1.0.1*

    Sending (Job: xxxxxxxxxxxxxxxxxxxxxxxxx)
    Subject: Lorem Ipsum
    To: nome_gruppo
    Account: account_che_spedisce
    From Address: xxx
    Delivery Started 07/03/2016 13:16:51
    Send Mode: Direct :: Retries on error: 0
    Domain: nome.nomedominio.it
    Connections: 40
    Sending to: xxxx1
    *Queued: *xxxx1
    *Sending *xxxx2
    *Queued: *xxxx2
    *Sent: *xxxx1
    *Sent: *xxxx2
    *Failed: *xxxx3

    • - error with dns lookup: **xxxx3**     - code:1 : Invalid Email Address*

    il software elabora il log, leggendo ogni riga ed evidenziando "Failed:", fa un parse di tutto e salva un file che importato su excel (o altri eventuali), crea due colonne email ed errore riscontrato
    filtrando il file per tipologia d'errore si evidenzia ciò che si vuole. Ovviamente è ancora in fase di sviluppo, ma se già riuscissimo ad evidenziare una minima percentuale solo delle mail con syntax error, pec, invalid recipent, etc già sarebbe un ran risultato.

    [spf = pass, dkim = pass, dmarc = pass]

    0
Effettua l'accesso per rispondere