* domenica 28 gennaio 2007, alle 19:42, Giovanni P. Caruso scrive:
[l'isp bloccherebbe l'invio]
> Uhm quello non credo.. potrebbe però aver bloccato l'invio via smtp
> direttamente secondo te?
Senza una comunicazione, lo escludo (inadempienza contrattuale).
Di default? Escludo anche questo. Alcuni isp (libero, ad esempio),
bloccano il traffico outbound 25 per i loro clienti tranne che verso i
loro mail server appunto.
Qui, si sta dicendo che l'isp blocca il traffico outbound 25 verso il
proprio mail server. Improbabile, a meno di una comunicazione (visto che
qualunque servizio di connettivita` prevede l'uso dei mail server
dell'isp per l'invio).
E se io isp, devo litigare con un cliente, non ha senso farlo cosi: o
termino il contratto, o lo lascio "stare".
> Il provider in questione è fastweb (per la cronaca).
Ok, quindi un provider nazionale. A maggior ragione non vedo una pratica
"ad personam", quale invece potrebbe fare un piccolo isp.
> Diciamo che nell'header (di una mail inviata a me non da quell'indirizzo
> ma sempre tramite lo stesso SMTP) ho la seguente riga:
> ---------------------------------------------------------------------------
> Received-SPF: none smtp-in3.libero.it: domain indirizzo-negozio.com does
> not designate permitted sender hosts
>
> Poi me ne sono fatte mandare altre che danno indicazioni differenti...
> sembrerebbe un problema legato anche al confezionamento dell'email se
> non sbaglio:
> ----------------------------------------------------------------------
> X-Spam_score: 7.9
> X-Spam_bar: +++++++
> X-Spam_report: Spam detection software, running on the system
> "lx000000070008.gateway.mail", has
> identified this incoming email as possible spam. The original
> message
> has been attached to this so you can view it (if it isn't spam) or
> label
> similar future email. If you have any questions, see
> the administrator of that system for details.
> Content preview: [...]
> Content analysis details: (7.9 points, 3.0 required)
> pts rule name description
> ---- ----------------------
> --------------------------------------------------
> 1.8 INVALID_DATE Invalid Date: header (not RFC 2822)
> 2.3 BAD_ENC_HEADER Message has bad MIME encoding in the
> header
> 0.9 DATE_IN_PAST_12_24 Date: is 12 to 24 hours before Received:
> date
> 0.7 MIME_HTML_MOSTLY BODY: Multipart message mostly text/html
> MIME
> 0.0 HTML_MESSAGE BODY: HTML included in message
> 0.1 MPART_ALT_DIFF BODY: HTML and text parts are different
> 2.9 HTML_IMAGE_ONLY_04 BODY: HTML: images with 0-400 bytes of
> words
> 0.0 FROM_EXCESS_QP From: quoted-printable encoded
> unnecessarily
> -0.8 AWL AWL: From: address is in the auto
> white-list
> X-Spam-Flag: YES
>
> Altri messaggi indicano il rifiuto a consegnare l'email al destinatario:
> ------------------------------------------------------------
> "Diagnostic-Code: X-Postfix; host relay.fastweb.it[192.168.0.53] said:
> 554 Message refused (in reply to end of DATA command)"
>
> Senza però ulteriori informazioni...
Allora, analisi la fai su full header. Cosi non puoi dire niente di
serio salvo che:
- nel primo messaggio qualcuno usa un record spf
- nel secondo, qualcuno usa spammassassin
- che sembra un heder fasullo - visto che assegna un ip che non c'entra
niente con l'host dichiarato
Ma sopratutto, header contraffatti o meno, se non sai "chi" risponde
"cosa" a "chi", fai fatica eh. full header.
> L'unico un po' più verboso è stato questo messaggio automatico:
> -----------------------------------------------------------------
> " A message from ... to ....was considered unsolicited bulk e-mail (UBE).
> Our internal reference code for your message is 16297-14/gz8nBTj29Qci
>
> The message carried your return address, so it was either a genuine mail
> from you, or a sender address was faked and your e-mail address abused
> by third party, in which case we apologize for undesired notification.
>
> We do try to minimize backscatter for more prominent cases of UBE and
> for infected mail, but for less obvious cases of UBE some balance
> between losing genuine mail and sending undesired backscatter is sought,
> and there can be some collateral damage on both sides."
>
> --------------------------------------------------------------------
Anche questo non e` full header. Nota che questo messaggio, fa molto
appliance. Nota che, l'ip in blacklist potrebbe essere quello di fastweb
e non il "tuo". Appunto, senza full header non sappiamo quando stiamo
andando. Miagoliamo nel buio, gridando "perche` perche`?". La risposta
e` dentro di noi, ma e` sbagliata. (scusa non resistevo).
> Ok se mi dessi una dritta sugli headers che ho messo nell'email (o anche
> link a RTFM chiari sull'argomento) te ne sarei grato.
> Eventualmente i suddetti indirizzi verranno controllati opportunamente.
Mio primo consiglio: aumentare la qualita` dell'analisi dell'header. In
particolare, sono pochi gli header di cui puoi fare un meccanismo di
trust, e solo su quelli puoi fare valutazioni.
Secondo consiglio: togliamoci sto dubbio. Viene usato o no il relay del
provider? Se si: chiedere al provider. Se no, si usa un mta sul proprio
ip. Verificare lo stato del proprio ip e` facile: http://openrbl.org/ e
verifica. Pero` prima devi capire "bene" qual'e` la situazione, e farti
dare campioni *completi*.
HTH.
--
Maurizio - Tannoiser - Lemmo
Founder Member of ERLUG http://erlug.linux.it
-------------------------------------------------------------------------------
Era quello rosso il barattolo dello zucchero?
-- cena linuxmeeting 2002
|