Invio LART: other or undefined security status

[parnas]

Ciao,

da qualche giorno sto provando il tool di zello con alcuni degli UCE che mi arrivano quotidianamente... in alcuni casi l'invio della mail all'abuse va a buon fine, e mi arriva la risposta automatica che mi notifica che indagheranno sul problema. Nella maggior parte dei casi, però, il server SMTP mi rimanda indietro un messaggio di "Delivery Status Notification" (il tipico messaggio che indica che non è stato possibile consegnare la mail), contenente il testo:

- These recipients of your message have been processed by the mail server:
abuse (at) comcast.net; Failed; 5.7.0 (other or undefined security status)

Ovviamente l'indirizzo di abuse riportato è solo un esempio... il server SMTP è quello di Libero, non capisco quale possa essere il problema. Non ho provato per ora a usare un altro server SMTP per vedere se cambia qualcosa... nessun altro ha riscontrato inconvenienti di questo tipo ?

Saluti,
Parnas

[Mikizo]

Semplice, a volte la casella dell'abuse desk è stracolma di posta e non accetta più messaggi... banalmente perchè dall'altra parte se ne fo***no e non c'è alcun omino che li legge.
Oppure, caso più raro ma possibile, l'indirizzo potrebbe essere sbagliato.
Molto più la prima che la seconda, in ogni caso.

[zello]

(Comcast sta diventando veramente amica-amica dello spam, ci sono un casino di openproxies nella loro rete - ricevo almeno 3 spam al giorno con origine comcast. Leggevo su nanae che da Comcast arrivano tentativi di proxy hijacking quotidiani, che ognitanto prendono contro a qualche honeypot, ma Comcast se ne frega altamente)

Tutto questo premesso, i casi sono due:
- hanno chiuso la casella dell'abuse (per quello che serviva...)
- hanno piazzato un filtro in entrata sull'account abuse che serve a limitare lo spam in entrata (è ovviamente una stupidaggine - come puoi notificare dello spam se lo spam viene filtrato?)

L'indirizzo comunque va bene:

Codice: Seleziona tutto

C:\>whois -s whois.abuse.net comcast.net
abuse<at>comcast.net (for comcast.net)


[parnas]

Mi sono dato una rapida guardata al RFC 1893, e riguardo a quel codice di errore dice:

Something related to security caused the message to be
returned, and the problem cannot be well expressed with any
of the other provided detail codes. This status code may
also be used when the condition cannot be further described
because of security policies in force.

Sicuramente non è un problema di mailbox piena, perchè per quello ci sono dei codici di errore appositi... detto così, effettivamente sembrerebbe proprio che hanno messo un filtro anti-spam sull'indirizzo di abuse...

Però spiegami una cosa, Zello... guarda i risultati di questo whois su un' altra mail di spam che mi è arrivata: http://www.samspade.org/t/whois?a=attbi.com&server=whois.networksolutions.com
Da qui sembrerebbe che l'abuse di comcast sia abuse (at) attbi.com... o forse questa è un'altra comcast omonima della prima ?
Se l'indirizzo era effettivamente sbagliato, può anche essere comprensibile che la mail venga scambiata per spam dal loro server e torni indietro con quell'errore.

Questo indirizzo qua comunque funziona...

Ciao Ciao,
Parnas

[parnas]

Ehm... scusate, mi rispondo da solo...

Ho fatto un giretto sui newsgroup, e pare che quell'errore sia dovuto a un filtro installato sul server SMTP di Libero, che serve a prevenire l'invio di mail non autorizzate da parte dei vari bugbear, klez et similia... in sostanza il software analizza la mail che riceve, e se sospetta che possa essere frutto di un qualche worm la rigetta al mittente con quell'errore.

Ora io non so se il filtro vada a guardare la struttura degli header della mail, che magari è un po' troppo semplificata rispetto a quella inviata da un vero mail-reader, o se va a matchare qualche stringa nel corpo della mail (magari lo spam forwardato incidentalmente contiene qualche frase usata anche dai worm...). Comunque a me con Libero il 90% delle mail che cerco di mandare con Abuse viene rimandato indietro con quell'errore.... se uso il server di Tin il problema non si presenta (anche se non ho provato estensivamente).

Bè, buonanotte...
Parnas

[parnas]

Ciao, altro piccolo aggiornamento sul problema della posta rifiutata...

ho fatto qualche prova con il server SMTP di Libero, e ho scoperto che le mail tornano indietro con quell'errore relativo alla security (5.7.0) se nell'header del messaggio stesso non è stato inserito il campo "Date:";
ti chiederei quindi di modificare il programma per inserire questa riga nelle intestazioni della mail in uscita, così da renderla compatibile con i filtri di Libero.
Pensavo anche che magari la mancanza di qualche header SMTP potrebbe essere il motivo per cui il NAV, a quel che leggevo in altri post, si arrabbia... io per sicurezza aggiungerei anche gli header:

MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

se non ci sono già (non ho guardato i sorgenti del tool).

Ciao e grazie,
Parnas

[zello]

Strano:
- io mando Date:, in formato RFC (822 bis? vado a memoria) compliant, almeno dalla versione 1.0.2.11. Puoi decidere se mandarlo o no dal tab Smtp delle opzioni
- mail.libero.it non si è mai lamentata neanche prima, comunque (ho sempre usato quello, per i test...)
- per gli headers standard: da smtp.cpp

Codice: Seleziona tutto

_data+="MIME-Version: 1.0\n";
//Content-Type & charset
_data+="Content-Type: text/plain; charset=\"iso-8859-1\"\n";


Mando un charset europeo, e non specifico l'encoding. Sarebbe meglio come dici tu, ma cmq un utente giapponese mi ha chiesto di rendere configurabile questa parte.