Mailbox non esistenti ma soffocate dallo spam

Un lettore e webmaster ha eseguito un singolare esperimento di.. conteggio sullo spam in arrivo. Piaghe sempiterne

Roma - Scrive Julien: "Ciao Punto Informatico, ho un dominio da qualche anno e ho notato che arriva un sacco di spam anche a caselle inesistenti. Inoltre molti mandano spam usando il mio dominio come mittente e molto di questo spam torna indietro.

Mi sono allora fatto uno scriptino che "catcha" le email in una casella tipo "info@" (non attiva) per vedere cosa arrivava. Beh, se siete curiosi ecco il risultato: http://www.buratto.com/nospam.php.

Una lettura potrebbe essere questa: in poco meno di 7 giorni più di 1500 email sono arrivate per spam inviato con il dominio @buratto.com (il mio dominio). Ovviamente non è il nostro SMTP a spedire queste email, è solo spam inviato apponendo un indirizzo "nostro" come From"."
110 Commenti alla Notizia Mailbox non esistenti ma soffocate dallo spam
Ordina
  • ma forse ci vorrebbe una legge che senza togliere niente a nessuno stabilisca pochi punti.

    1) ogni ip deve possedere il relativo PTR
    2) ogni PTR deve iniziare per host.quello che vuoi.
    3) ogni server abilitato all'invio deve iniziare con mail.quello che vuoi.
    4) si apre la porta 25 solo a chi ne fa richiesta e sia in regola con il punto 3.

    a questo punto le RBL avrebbero a che fare solamente con i server regolarmente mantenuti e gli sforzi si concentrerebbero nel proteggere gli altri dai propri utenti.

    insomma ci ritroveremmo a battagliare 1 contro mille al posto di 1 contro milioni.

    non credo che questi suggerimenti si possano configurare come reali restrizioni.

    se le cose stessero cosi una sola regola si potrebbe eliminare il 90% dello spam e infettare i pc diventerebbe meno interessante.

    /^host\..*/ REJECT e poi si comincia a ragionare sul rimanente spam.

    non+autenticato
  • Il fenomeno del ritorno indesiderati dei messaggi ad utenti ignari si chiama backscatter.
    I server di mail dovrebbero rifiutare subito i messaggi destinati ad utenti inesistenti con un errore 5xx in fase edi connessione (durante il RCPT TO), senza generare NonDeliveryReport (NDR).

    Per la cronaca, non appena ho iniziato a controllare i destinatari sul mio relay esterno (anziché inoltrare tutto alla cieca al server Exchange interno), ho bloccato il 50% del traffico indesiderato e impedito la generazione di un numero corrispondente di NDR.
    non+autenticato
  • Molto interessante, non conoscevo il nome del fenomeno.
    non+autenticato

  • - Scritto da:
    > ..non appena ho iniziato a
    > controllare i destinatari sul mio relay esterno
    > (anziché inoltrare tutto alla cieca al server
    > Exchange interno), ho bloccato il 50% del
    > traffico indesiderato e impedito la generazione
    > di un numero corrispondente di
    > NDR.

    interessante, ma come hai fatto a far riconoscere la validità del destinatario al server di relay ?
    non+autenticato
  • Forse la cosa migliore sarebbe che l'SMTP che riceve, controlli da dove provenga realmente la connessione e che controlli che questo indirizzo corrisponda a quello dell'enveloper e in caso di errore sia utilizzato, come destinatario del messaggio d'errore, non il From del messaggio ma il from dell'enveloper.

  • - Scritto da:
    > Il fenomeno del ritorno indesiderati dei messaggi
    > ad utenti ignari si chiama
    > backscatter.
    > I server di mail dovrebbero rifiutare subito i
    > messaggi destinati ad utenti inesistenti con un
    > errore 5xx in fase edi connessione (durante il
    > RCPT TO), senza generare NonDeliveryReport
    > (NDR).
    >
    > Per la cronaca, non appena ho iniziato a
    > controllare i destinatari sul mio relay esterno
    > (anziché inoltrare tutto alla cieca al server
    > Exchange interno), ho bloccato il 50% del
    > traffico indesiderato e impedito la generazione
    > di un numero corrispondente di
    > NDR.

    qual'è il risultato per chi sbaglia indirizzo normalmente?

    non se ne accorgerà mai?

    (domanda seria!)
    non+autenticato
  • http://www.openspf.org/

    iniziare a rigettare per direttissima le email che non provengono da ip listanti nell'spf (anche se assente..A bocca aperta ) potrebbe sistemare molte coseA bocca aperta

    ...
    non+autenticato

  • - Scritto da:
    > http://www.openspf.org/
    >
    > iniziare a rigettare per direttissima le email
    > che non provengono da ip listanti nell'spf (anche
    > se assente..A bocca aperta ) potrebbe sistemare molte cose
    >A bocca aperta
    >
    > ...

    Il punto e' che la stessa procedura utilizzata da chi apre un nuovo indirizzo e-mail, puo' essere utilizzata da chi crea un nuovo indirizzo e-mail per spam (come si fa a distinguere, a priori, gli scopi di chi manda un e-mail).

    Questi sistemi valgono fino a quando non si scopre come aggirarli.

    Ed infatti e' da un po' di tempo che negli account di gmail un po' di e-mail spazzatura non mi vengono bloccati, proprio perche' hanno SPF passed
    non+autenticato
  • Fatal error: Call to undefined function: fetchrow() in /home/.sites/39/site17/web/nospam.php on line 30
    non+autenticato
  • Sorry per l'errore, come si suol dire una bella tabella corrotta fa primavera!
    DatiSpam     repair     info     Wrong bytesec: 0-0-0 at 176324; Skipped
    DatiSpam     repair     warning     Number of rows changed from 3135 to 3132
    DatiSpam     repair     status     OK
    non+autenticato
  • Risultato:
    Fatal error: Call to undefined function: fetchrow() in /home/.sites/39/site17/web/nospam.php on line 30
    non+autenticato
CONTINUA A LEGGERE I COMMENTI
1 | 2 | 3 | Successiva
(pagina 1/3 - 11 discussioni)