Newsgroup: it.news.net-abuse
Titolo: FORGED_RCVD_HELO, come mai?

; Mon, 28 May 2007 
18:12:57 +0200 (CEST)
A me sembra a posto.
Dà problemi l'ultimo (che poi è il primo) "Received: from localhost 
(localhost [127.0.0.1])"?
Dà problemi il penultimo "Received: from 
dominioservermittente.it
 
(indirizzo.del.mio.server [1.2.3.4])" anche se sia 
dominioservermittente.it
 che indirizzo.del.mio.server vengono risolti 
come 1.2.3.4 (1.2.3.4 come esempio, i numeri reali sono chiaramente 
diversi)?
Spero in una risposta, vi ringrazio.

 la chiave FORGED_RCVD_HELO?
Credo che il post sia piuttosto OT qui.. ad ogni modo..
se non posti le info originali (IP, helo ecc..) sarà dura
riuscire ad aiutarti; tra l'altro non capisco tutta questa
"segretezza" se il mailserver è pubblicato e se il dominio
è registrato.. le informazioni sono COMUNQUE pubbliche
per cui.. non vedo il motivo di nasconderle cosa che tra
l'altro rende difficile darti una risposta; sai, le sfere di
cristallo di questi tempi sono merce preziosa :D

> se non posti le info originali (IP, helo ecc..) sarà dura
Be' fai finta che il server di ricezione fosse davvero 
mail.dominiodestinatario.it
 , che il destinatario fosse davvero  
destin...@dominiodestinatario.it
 ecc. Cosa ti cambia? Credo che per 
capire cosa faccia scattare il FORGED_RCVD_HELO sia più che sufficiente.
Ho pensato anche di fare un reverse engineering del sorgente di 
spamassassin. Però se riesco ad evitarmi almeno questa ulteriore (dopo i 
vari tuning sulla configurazione del server di spedizione, tuning utili 
ma non ancora sufficienti) gatta da pelare sono più contento...
La cosa che mi delude di più è che il mio server non invia affatto spam 
ma per la cronaca invia conferme di iscrizione ad una newsletter in 
doppio opt-in.
Fa specie che proprio io debba dedicare ore per 
studiare+capire+provare+risolvere questi falsi positivi. Mi chiedo se 
anche gli spammer incontrino ostacoli che ragionevolmente dovrebbero 
essere maggiori. Mi chiedo se magari invece ci sto andando di mezzo io a 
differenza degli spammer. Mah.

[cut]
Ecco, il "doppio opt-in" non esiste, è terminologia da spammer ;)
E' "opt-in" e basta, è ovvio che il server deve chiedere la conferma.
Gabriele

 
destin...@dominiodestinatario.it
 ecc. Cosa ti cambia?
cambia cambia.. anche perchè in quel modo non posso
verificare se la "trinità" sia rispettata :D detto in poche parole
supponiamo che il tuo server si annunci al server destinatario
in questo modo
HELO 
mail.miodominio.it
e diciamo che il tuo server (il MITTENTE, SEMPRE il mittente)
abbia un indirizzo IP 1.2.3.4; ora.. il server destinatario vede
tale IP ed ha il nome usato per l'HELO e la verifica più rapida
è quella sul forward / reverse per cui
se 
mail.miodominio.it
 non viene risolto in 1.2.3.4 e se 1.2.3.4
non ha un PTR che viene risolto in 
mail.miodominio.it
 la vedo
dura riuscire a passare il check :)
(si ok.. il PTR è un altro check ma tanto vale verificarlo)

 doppio opt-in.
Che l'opt-in sia singolo, doppio o triplo, spamassassin nulla ne sa o ne
può sapere (il che, dovrebbe apparire evidente, è un grosso limite
dell'approccio contenutisctico se lo si applica a newsletter e non a BOT
spam...ma è altro discorso).
Gli score che citi sono legati a problemi di configurazione del mailserver.
Se fornisci la locazione del mailserver, gli si dà un occhio e ti si può
indicare in cosa la configurazione sia migliorabile.
Sennò noi si campa lo stesso, che tanto il problema è il tuo ;-)
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGW+BX8THo01J+SBERAhotAJ4m3QneR2bd6jPdctSNBoF4V4Gi8QCgqiDH
piDsI1pmZDSfoy+0ZWEX1U8=
=oORH
-----END PGP SIGNATURE-----

 FORGED_RCVD_HELO sia più che sufficiente.
no

 l'IP si potevano controllare anche altre cose non ti pare ?
Nei campi receive puoi vedere che si presenta come 
"
mail.dominiodestinatario.it
". Seconda riga received dal basso.
Ho fatto ulteriori aggiustamenti e adesso si presenta come 
altrodominio.it
 dove 
altrodominio.it
 viene risolto con l'ip del server 
di posta di invio.
Ma il FORGED_RCVD_HELO permane.
Allora ho fatto in modo che l'invio dell'email dal software php via 
socket al server di posta di invio si presenti con helo 
"stringadelcavolo" ma anche così il problema permane. Ho provato anche 
ad usare come helo "
pluto.it
" dove 
pluto.it
 viene risolto con l'ip del 
server di posta di invio e il problema persiste.
Bah.
Mi è quasi sorto un dubbio.
Siccome dai campi received vedo uno strano scambio di posta nel server 
DESTINATARIO, non sarà magari che il FORGED_RCVD_HELO esca a causa di 
"Received: from localhost (localhost.localdomain [127.0.0.1])" o 
"Received: from 
mail.dominiodestinatario.it
 ([127.0.0.1])"???
Sarebbe il colmo che le email venissero flaggate con FORGED_RCVD_HELO 
per colpa di campi receive sballati lasciati dal server DESTINATARIO mal 
configurato.

 non ha un PTR che viene risolto in 
mail.miodominio.it
 la vedo
Ma 1.2.3.4 non una un ptr che viene risolto in 
mail.miodominio.it
 .
E' così grave? E' un problema bloccante? Non c'è modo di aggirare la 
cosa? E' questo che mi flagga le email come FORGED_RCVD_HELO?

 
mail.miodominio.it
 viene risolto in 1.2.3.4 .
senti.. facciamo cosě; tu posti il nome del dominio e l'IP e
ti si da una mano, in caso contrario.. beh, mi dispiace
scriverlo ma ... arrangiati; dopotutto nessuno garantisce
che tu non sia uno spammer per cui PRIMA di aiutarti
credo sarebbe il caso di capire chi tu sia
ciao

> Ho pensato anche di fare un reverse engineering del sorgente
se hai il sorgente non fai un r.e.
i miei 2 centesimi