2009-12-29 10 views
12

Scenario:
Ho un modulo di contatto sulla mia app Web, riceve molto spam.
Sto convalidando il formato degli indirizzi di posta elettronica in modo approssimativo ^[email protected]+\..+$
Sto utilizzando un servizio di filtro antispam (defensio) ma i punteggi di spam restituiti si sovrappongono a messaggi validi. A una soglia di 0.4 lo spam arriva e alcune domande del cliente vengono erroneamente gettato in un log e viene visualizzato un errore.Utilizzo di record MX per convalidare gli indirizzi e-mail

Tutti i messaggi di spam utilizzano indirizzi e-mail falsi, ad es. [email protected]

Dedicato server Linux PHP5 negli Stati Uniti, mysql, registrazione solo spam, invio di posta elettronica ai messaggi non spam (non memorizzati).

Proposta: Usa di checkdnsrr(preg_replace(/^[email protected]/, '', $_POST['email']), 'MX') php per verificare il dominio di posta elettronica si risolve in un indirizzo valido, accedere a file, quindi reindirizzare con un errore per i messaggi che non risolvono, procedere al servizio di filtro anti-spam come prima per gli indirizzi che si risolvono in base a checkdnsrr().

Ho letto (e sono scettico su questo anch'io) che non si dovrebbe mai lasciare questo tipo di convalida fino a ricerche remote, ma perché?

Oltre ai problemi di connettività, dove avrò comunque problemi maggiori rispetto a un modulo di contatto, si verificheranno dei falsi positivi/negativi?
Ci sarebbero alcuni tipi di indirizzi che non verranno risolti? indirizzi gov? indirizzi email ip?
Devo eseguire l'escape dell'hostname che passo a checkdnsrr()?

Soluzione: Una combinazione di tutte e tre le risposte (vorrei poterne accettare più di una come risposta composta).

sto usando:

$email_domain = preg_replace('/^[email protected]/', '', $email).'.'; 
if(!checkdnsrr($email_domain, 'MX') && !checkdnsrr($email_domain, 'A')){ 
    //validation error 
} 

tutto lo spam viene registrato e ruotato. Per l'aggiornamento a una coda di lavoro in un secondo momento.

Alcuni commenti sono stati fatti per chiedere al server di posta per l'utente di verificare, ho pensato che sarebbe stato troppo traffico e potrebbe avere il mio server bannato o in qualche modo in difficoltà, e questo è solo per tagliare la maggior parte del e-mail che venivano rimbalzate a causa di indirizzi di server non validi.

http://en.wikipedia.org/wiki/Fqdn e

RFC2821 
The lookup first attempts to locate an MX record associated with the name. 
If a CNAME record is found instead, the resulting name is processed as if 
it were the initial name. 
If no MX records are found, but an A RR is found, the A RR is treated as 
if it was associated with an implicit MX RR, with a preference of 0, 
pointing to that host. If one or more MX RRs are found for a given 
name, SMTP systems MUST NOT utilize any A RRs associated with that 
name unless they are located using the MX RRs; the "implicit MX" rule 
above applies only if there are no MX records present. If MX records 
are present, but none of them are usable, this situation MUST be 
reported as an error. 

Molte grazie a tutti (soprattutto ZoogieZork per la punta record di ripiego)

+0

+1 .. non ho mai sentito parlare di verifica di un indirizzo email valido controllando i record MX .. questo è una buona idea, credo. – Earlz

+3

Ricordarsi di controllare il record A se nessun record MX è elencato, come definito in RFC 5321. È raro, ma alcuni domini non hanno un record MX (per vari motivi). Maggiori informazioni: http://en.wikipedia.org/wiki/MX_record#History_of_fallback_to_A – ZoogieZork

+0

Cheers Zork, esattamente il tipo di trucchi che mi preoccupava. –

risposta

4

non vedo nulla di male a fare una ricerca MX con checkdnsrr() e ho anche non vedo come possono apparire falsi positivi. Non è necessario sfuggire al nome host, infatti è possibile utilizzare questa tecnica e prendere un po 'di più parlando con il MTA e testando se l'utente esiste in un dato host (tuttavia questa tecnica potrebbe e probabilmente ti porterà qualche falso positivi in ​​alcuni host).

+6

La maggior parte degli host SMTP che puoi trovare in natura non rispondono bene ai comandi VRFY (sia sempre OK che sempre ERROR sono le risposte che puoi aspettarti). L'uso di VRFY per la convalida degli indirizzi è altamente sconsigliato. – Guss

5

Le ricerche DNS possono essere lente a volte, a seconda della congestione del traffico di rete &, quindi è una cosa di cui essere a conoscenza.

Se fossi nei tuoi panni, testerei e vedremo come va. Per circa una settimana, registrare tutte le e-mail in un database o in un file di registro e includere un campo per indicare se verrà contrassegnato come spam o e-mail legittima. Dopo che la settimana è finita, dai un'occhiata ai risultati e verifica se sta funzionando come ti aspetteresti.

Questo approccio di registrazione/test offre la flessibilità necessaria per testarlo e non preoccuparsi di perdere le email dei clienti.

Ho preso l'abitudine di aggiungere un campo aggiuntivo ai miei moduli che è nascosto con CSS, se è compilato presumo che sia stato inviato da un bot antispam. Mi assicuro inoltre di usare un nome come "url" o "website_url" qualcosa che assomigli ad un nome di campo legittimo ad un bot di spam. Aggiungi un'etichetta per il campo che dice qualcosa come "Non compilare questo campo", quindi se il browser di qualcuno non lo rende correttamente, sapranno di non compilare il campo di spam. Finora funziona molto bene per me.

+1

Ri: campo nascosto - Buona idea! Per quanto riguarda la registrazione, accertati di registrare anche il tempo impiegato per risolvere il record DNS. Potresti scoprire che ci vuole troppo tempo e risultati un'esperienza utente scadente. – Guss

+0

Sto testando il campo nascosto ora, sembra funzionare bene, anche se alcuni ... gli utenti stanno scrivendo "Non so cosa mettere in questo campo" –

+0

Se gli utenti stanno digitando qualcosa nel campo, non è nascosto correttamente. Potrebbe esserci un bug nel tuo CSS che non nasconde il campo correttamente. faccio di solito qualcosa di simile: non ho visto alcun spam venire alle forme in cui ho implementato questo per un bel po 'di tempo. – bradym

0

Una ricerca MX è solo una parte dell'immagine, se si desidera assicurarsi che l'indirizzo di posta elettronica sia valido, è necessario tentare di inviare una e-mail a tale account.

L'altro scenario possibile è che qualcuno può semplicemente utilizzare account di posta dirottati da una macchina compromessa. Certo, probabilmente è un po 'meno probabile che si verifichi, ma lo è ancora.

Ci sono delle librerie di convalida degli indirizzi e-mail che fanno questo, semplicemente cercano la convalida e-mail.

Tutto questo può essere fatto in modo asincrono. Ho questa configurazione sul mio sito, nel qual caso l'e-mail viene salvata nel database (a scopo di controllo), un lavoro in coda, quindi quando il lavoro arriva il momento di eseguire, qualsiasi ulteriore convalida viene eseguita in quel momento. Scarica carichi pesanti su un altro thread.

Per l'utente, sembra che l'e-mail sia stata già inviata, che fosse (è nel database) e può essere visualizzata internamente, ma l'e-mail effettiva non verrà inviata fino a che il lavoro non viene eseguito che può essere immediatamente o una certa quantità di tempo a seconda del carico del server.

Walter

+0

Mi piace l'idea di una coda di lavoro di convalida –

+0

È una coda di lavoro, parte di quel lavoro è la convalida. Il problema con questo modello è che qualcuno può inserire un'email pensando che sia valida e inviata, e quindi quando viene elaborata in seguito, il sistema la rifiuterà. –

0
function mxrecordValidate($email){ 
     list($user, $domain) = explode('@', $email); 
     $arr= dns_get_record($domain,DNS_MX); 
     if($arr[0]['host']==$domain&&!empty($arr[0]['target'])){ 
       return $arr[0]['target']; 
     } 
} 
$email= '[email protected]'; 

if(mxrecordValidate($email)) { 
     echo('This MX records exists; I will accept this email as valid.'); 
} 
else { 
     echo('No MX record exists; Invalid email.'); 
} 
Problemi correlati