Problemi con l'infrastruttura di NGI

Ticket: Message-ID aggiunto in ogni mail in uscita

20 Nov 2006 10:00, Enrico:

Buongiorno,

inviando mail tramite smtp.ngi.it, viene aggiunto agli header un secondo Message-ID. Guardando un mio post in una mailing list, per esempio, negli header ci sono entrambi questi due Message-ID:

Message-ID: <20061119173303.GA29003@viaza>
Message-ID: <20061119173343.428261@smtpi1.ngi.it>

Alla mia ragazza è stato rifiutato da un server in Olanda l'invio di una mail a causa del Message-ID doppio:

Message-ID: <4560B871.9020300@ylin.org>
Message-ID: <20061119200300.558343@smtpi2.ngi.it>

Questo un estratto del messaggio di bounce che ha ricevuto:

Reporting-MTA: dns; fswlnx01.fsw.vu.nl
Received-From-MTA: smtp; mail.fsw.vu.nl ([127.0.0.1])
Arrival-Date: Sun, 19 Nov 2006 21:03:00 +0100 (CET)
Action: failed
Status: 5.6.0
Diagnostic-Code: smtp; 554-5.6.0 Reject, id=10114-17 - BAD_HEADER: Duplicate
554 5.6.0 header field: "Message-ID"
Last-Attempt-Date: Sun, 19 Nov 2006 21:03:00 +0100 (CET)

Guardando miei post in mailing list, fino al 13 novembre il Message-ID extra non veniva aggiunto, mentre dal 16 novembre in poi si. Dal 13 al 16 non ho spedito mail a liste e non posso controllare.

Visto che la cosa causa mail non accettate, vi prego di darci un'occhiata al piú presto.

Cordiali saluti,

21 Nov 2006 11:47, Enrico:

Questa non è una risposta, ma un'aggiunta.

Molti miei messaggi vengono ora categorizzati come spam: ho inviato un preventivo il 16 novembre e non è arrivato: questo è Male.

Inoltre, i messaggi che mando alle mailing list, a causa del Message-ID doppio incasinano l'organizzazione dei thread negli archivi delle liste: http://lists.alioth.debian.org/pipermail/debtags-devel/2006-November/thread.html

Mi piacerebbe che questo casino si risolvesse presto.

Mi piacerebbe anche non iniziare a pensare che NGI lascia dei ticket aperti per 24 ore senza risposta.

22 Nov 2006 10:57, Enrico:

Non vedendo risposta per alcun giorni, come work-around ho iniziato a inviare mail direttamente (visto che ho un IP statico) invece che tramite il vostro relay.

Coincidenza interessante: la gente a cui non arrivavano i miei preventivi e a cui arrivavano le mie e-mail marcate 'spam', proprio in questo periodo sta valutando offerte per la connessione a Internet, tra cui una di NGI. Sono interessati a seguire l'evolversi di ticket per valutare la qualità della vostra assistenza.

*29 Nov 2006 12:10, assistenza NGI":

Buongiorno,

Purtroppo può capitare che un smtp possa finire nelle spam list se chi lo utilizza abusa delle sue funzioni , probabilmente l'ip del server smtp.ngi.it è finito in una spamlist in questi casi la procedura dà fare è quella di mandare una mail ad abuse@ngi.it così dà attivare le procedure per la rimozione dell'ip dalla spam list.Se le dovesse ricapitare le consiglio di mandare la mail immediatamente.Per i ticket aperti su assistenza.ngi.it le consiglio in futuro di non aggiornarlo poiché altrimenti il ticket perde priorità infatti vengono sempre controllati i più vecchi.

Distinti saluti.

29 Nov 2006 12:22, Enrico:

Il problema principale non erano le blacklist, ma il Message-ID che veniva aggiunto a ogni messaggio, anche quelli che ce l'avevano già (come peraltro dice l'oggetto del ticket).

Alcuni server reagivano al doppio message id considerandolo sospetto (veda il bounce che ho riportato all'apertura del ticket).

Ad ogni modo, ho controllato e il problema del doppio message id sembra essere risolto.

Non mi sembra una gran politica penalizzare quei ticket di cui il submitter non si dimentica ma fornisce informazioni aggiuntive, o pinga per vedere se qualcuno risponde; a maggior ragione perché avete tolto numeri di telefono dalle pagine dell'assistenza. Ad ogni modo, son (discutibili) scelte vostre.

*11 Dec 2006 15:19, assistenza NGI":

Buongiorno, il numero di telefono è recuperabile in fono dell' homepage www.ngi.it

Ovviamente preferiamo avere un contatto tramite ticket con il cliente rispetto a quello telefonico, soprattutto per un discorso di tracciabilità dei problemi.

Chiudo il ticket, in quanto il problema risulta essere rientrato come da Sua indicazione.

Distinti saluti

Ticket: Retry time troppo brevi nell'SMTP in uscita

01 Jul 2008 16:33, Enrico:

Buon giorno,

ho avuto problemi a inviare mail verso host che usano graylisting. Investigando la questione con gli amministratori dell'host di destinazione, ne è uscito che NGI cancella i messaggi dalla coda dopo un giorno che non sono stati consegnati.

Questo è un estratto dal messaggio di bounce:

----- Transcript of session follows -----
... while talking to master.debian.org.:
>>> DATA
<<< 451-88.149.128.21 is not yet authorized to deliver mail from
<<< 451 <enrico@enricozini.org> to <madduck@debian.org>.
<madduck@debian.org>... Deferred: 451-88.149.128.21 is not yet authorized to deliver mail from
<<< 503 valid RCPT command must precede DATA
Message could not be delivered for 1 day
Message will be deleted from queue

Che mostra che il messaggio è stato tolto dalla coda dopo un solo giorno di mancata consegna.

Inoltre, da questo estratto dei log del mail server di destinazione si nota che NGI, oltre a non gestire la permanenza in coda secondo i dettami dell'RFC-2821, neanche fa retry come si deve:

/var/log/exim4/mainlog.3.gz:2008-06-27 23:32:47 H=smtpi2.ngi.it [88.149.128.21] F=<enrico@enricozini.org> temporarily rejected RCPT <madduck@debian.org>: greylisted.
/var/log/exim4/mainlog.2.gz:2008-06-28 21:22:29 H=smtpi2.ngi.it [88.149.128.21] F=<enrico@enricozini.org> temporarily rejected RCPT <madduck@debian.org>: greylisted.
/var/log/exim4/mainlog.2.gz:2008-06-28 21:23:07 H=smtpi2.ngi.it [88.149.128.21] F=<enrico@enricozini.org> temporarily rejected RCPT <madduck@debian.org>: greylisted.
/var/log/exim4/mainlog.2.gz:2008-06-28 21:25:17 H=smtpi2.ngi.it [88.149.128.21] F=<enrico@enricozini.org> temporarily rejected RCPT <madduck@debian.org>: greylisted.
/var/log/exim4/mainlog.2.gz:2008-06-28 21:25:59 H=smtpi2.ngi.it [88.149.128.21] F=<enrico@enricozini.org> temporarily rejected RCPT <madduck@debian.org>: greylisted.
/var/log/exim4/mainlog.2.gz:2008-06-28 21:27:18 H=smtpi2.ngi.it [88.149.128.21] F=<enrico@enricozini.org> temporarily rejected RCPT <madduck@debian.org>: greylisted.
/var/log/exim4/mainlog.1:2008-06-29 18:30:19 H=smtpi2.ngi.it [88.149.128.21] F=<enrico@enricozini.org> temporarily rejected RCPT <madduck@debian.org>: greylisted.

Cito le parti rilevanti da http://tools.ietf.org/html/rfc2821:

4.5.4.1 Sending Strategy

Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days. The parameters to the retry algorithm MUST be configurable.

[...]

Experience suggests that failures are typically transient (the target system or its connection has crashed), favoring a policy of two connection attempts in the first hour the message is in the queue, and then backing off to one every two or three hours.

Quindi, dove lo standard parla di due tentativi nella prima ora, retry ogni due o tre ore, con permanenza in coda di almeno 4 o 5 giorni, noi abbiamo osservato un comportamento tipo nessun tentativo di reinvio per almeno 22 ore, dopodiché uno o piú tentativi (quando un graylister normale ormai avrebbe fatto ripartire il conteggio), e poi subito via dalla coda.

Da uno dei migliori (e piú cari) provider d'Italia mi aspetterei di vedere un SMTP parlato come dio comanda. Cosí come mi aspetterei di poter aprire un ticket semplicemente inviando una e-mail.

14 Jul 2008 11:21, Enrico:

Ticket chiuso senza una spiegazione? Complimenti...

14 Jul 2008 12:27, assistenza NGI:

Buongiorno, come nell' altro ticket Le confermo lo stesso problema sul database.

Le rimando la risposta:

"Buongiorno, il nostro SMTP opera in questo modo:

Al momento non sono previste modifiche sulla configurazione dell' SMTP.

Distinti saluti"

14 Jul 2008 14:39, Enrico:

E cosa mi dite rispetto ai log che vi ho postato, che mostrano un comportamento diverso a quello che mi avete riportato?

15 Jul 2008 10:49, assistenza NGI:

Buongiorno, abbiamo verificato la configurazione dell' SMTP ed è corretta, non sò indicarLe la causa dell' anomalia da Lei riscontrata.

Distinti saluti

Ticket: La posta in uscita è censurata

08 Jul 2008 11:43, Enrico:

Buon giorno,

ho appena scoperto che smtp.ngi.it censura la posta in uscita. Questo è il tracciato della sessione SMTP:

-----------------------------------------
$ telnet smtp.ngi.it 25
Trying 88.149.128.13...
Connected to smtp.ngi.it.
Escape character is '^]'.
220 smtpi2.ngi.it ESMTP Sendmail 8.13.8/8.13.8; Tue, 8 Jul 2008 11:33:12 +0200
HELO enrico
250 smtpi2.ngi.it Hello 81-174-12-206.static.ngi.it [81.174.12.206], pleased to meet you
MAIL FROM: <enrico@enricozini.org>
250 2.1.0 <enrico@enricozini.org>... Sender ok
RCPT TO: <yuwei@ylin.org>
250 2.1.5 <yuwei@ylin.org>... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself

This is a test message. It mentions http://www.hackerspace.net/
.
554 5.7.1 This message has been blocked because it contains FortiGuard - AntiSpam blocking URL(s).(black url http://www.hackerspace.net/)
Connection closed by foreign host.
-----------------------------------------

http://www.hackerspace.net/ è il sito di un festival a Parigi. La mail che è stata bloccata conteneva un articolo per Linux Magazine UK sul suddetto festival. Tale articolo probabilmente non sarà pubblicato perché il mio provider (VOI) introduce sistemi di censura della posta in uscita senza farmelo sapere.

I casi sono due: o la mia posta esce non filtrata a partire da SUBITO, o passo a un altro provider, con un post su planet.debian.org che spiega perché.

Incazzato come una bestia, Enrico

08 Jul 2008 12:55, assistenza NGI:

Buongiorno, la Sua email è stata bloccata in automatico da FortiGuard, il sistema di protezione contro lo spam presente sui nostri firewall. Ho girato una segnalazione al responsabile delle infrastrutture, La aggiorneremo in merito appena possibile. Non facciamo alcuna censura attiva sulle email spedite.

Distinti saluti

08 Jul 2008 16:25, Enrico:

Mi definisce per cortesia cosa intende per "censura attiva"? E già che c'è, mi fa sapere come definite bloccare un messaggio solo perché contiene un URL che non vi piace in mezzo a un normalissimo articolo giornalistico? Cesura passiva? Censura casuale? Censura per errore? Censura per incompetenza? Censura per outsourcing a ditte di incapaci?

Configurate per favore il mio account in modo tale che la posta in uscita non sia filtrata in alcun modo. Siete in grado di farlo?

A me la posta serve che vada, senza intoppi: nel momento in cui voi mi create intoppi, io cambio provider. Semplice.

14 Jul 2008 11:21, Enrico:

Ticket chiuso senza una spiegazione? Complimenti...

14 Jul 2008 11:46, assistenza NGI:

Buongiorno, il reply era stato dato, abbiamo avuto problemi con il database.

Provo a riportarlo nuovamente:

"Buongiorno, il fitro per cui la Sua email è stata respinta è attivo da tempo sui nostri firewall.

Il sistema si basa su una RBL (real-time blacklist) la cui gestione non dipende nè da noi nè da Fortigate (produttore del firewall che utilizziamo), ma viene aggiornata dalla comunità internet stessa attraverso segnalazioni sottoposte dagli utenti dalla rete ai gestori delle RBL.

Il dominio da Lei indicato è stato filtrato dalla comunità a causa di problemi di spam.

Abbiamo effettuato diversi invii di test attraverso il fortiguard e la parola "hacker" non viene filtrata, viene proprio filtrato il dominio indicato.

Distinti saluti"

14 Jul 2008 12:06, Enrico:

Manca però una risposta a questa domanda che avevo fatto:

"Configurate per favore il mio account in modo tale che la posta in uscita non sia filtrata in alcun modo. Siete in grado di farlo?"

14 Jul 2008 12:10, assistenza NGI:

Impossibile, tutte le linee di tutti i clienti passano dal fortiguard per una questione di sicurezza della rete.

Nessuna eccezione è possibile.

Distinti saluti

19 Jul 2008 15:14, Enrico:

"per una questione di sicurezza della rete" è sempre la scusa che fa piú ridere di tutte, e io e il responsabile tecnico del provider al quale migrerò a settembre ci stiamo effettivamente divertendo molto.

Se ne ha delle altre, per favore posti pure.

21 Jul 2008 16:25, assistenza NGI:

Buongiorno, non ne ho altre da postare.

Semplicemente la configurazione della parte di sicurezza del nostro firewall è questa, univoca per tutti i clienti (su tutte le linee sono applicate le medesime policies, non esiste alcun tipo di eccezione per nessun cliente) e non è prevista una modifica al momento della politica aziendale in merito.

Procedo quindi con la chiusura della segnalazione.

Distinti saluti

21 Jul 2008 17:08, Enrico:

Ergo, non è una questione di sicurezza della rete, ma di politica aziendale.

La prossima volta, eviti di prendere in giro i clienti.

21 Jul 2008 19:39, assistenza NGI:

Non ho assolutamente preso in giro nessuno.

Le policies sul firewall prevedono il check tramite fortiguard su ogni VC cliente.

Tutti i clienti sono soggetti a queste policies, nessuno escluso, e quindi tutti passano dai vari check di sicurezza presenti sul fortigate.

La politica aziendale di cui parlavo, se rilegge bene la mia risposta, è quella di non escludere nessun cliente da queste policies.

"Semplicemente la configurazione della parte di sicurezza del nostro firewall è questa, univoca per tutti i clienti (su tutte le linee sono applicate le medesime policies, non esiste alcun tipo di eccezione per nessun cliente) e non è prevista una modifica al momento della politica aziendale in merito": la frase mi sembra univoca e senza possibilità di interpretazione. Tutti i clienti hanno lo stesse policies, nessuno escluso.

Sul nostro fortigate è attivo il fortiguard.

Tutti i clienti passano dal fortigate.

Nessun cliente è escluso, nè ha la possibilità di avere configurazioni particolari o "ad hoc".

Questa è la nostra politica aziendale.

Non capisco dove questa cosa "prenda in giro i clienti", nè dove "faccia ridere".

Non penso che un singolo cliente possa intervenire sulle policies di sicurezza presenti sui firewall di un ISP (se non consigliando eventuali modifiche utili all' intera "comunità", nel Suo caso non penso sia così perchè se tale host da Lei citato è finito in una blacklist internazionale un motivo c'è e la cosa non dipende da noi ma da un gruppo più o meno vasto di persone che si occupano di limitare lo spam sull' intera rete) nè ottenere una configurazione "ad hoc" (se fosse data la possibilità ad ogni cliente di richiedere una particolare configurazione sul firewall al cosa diventerebbe ingestibile)

Ho anche tentato di contattarLa telefonicamente, ma mi hanno informato che attualmente si trova all' estero.

In ogni caso, penso e spero di aver fugato ogni dubbio tramite questo mio reply.

22 Jul 2008 16:59, Enrico:

Certo, ha frugato ogni mio dubbio che http://www.ngi.it/F5/caratteristiche_tecniche_ADSL.asp sia ora una discreta pila di panzane, che l'avanguardia tecnologica l'avete lasciata al momento in cui quel pezzo è stato scritto, che NGI non vale piú lontanamente il prezzo che chiede, e che di offrire un buon servizio, né uno straccio di rispetto per i "power user" (come li chiamate voi), non ve ne importa piú un tubo (e per di piú, per "questioni di politica aziendale").

Volete un consiglio per tutta la comunità? Offrite servizio SMTP non filtrato previa autenticazione TLS. Come fanno, da tempo, vari provider seri.

Ma ve lo devo dire io? Allora non siete piú all'avanguardia tecnologica. CVD.

E finché non si scusa di aver tirato la fantastica panzana dei "motivi di sicurezza", non la ritengo un interlocutore credibile, né degno di ricevere i miei soldi.

A proposito, esistono issue tracker liberi che permettono agli utenti di aggiungere commenti senza riaprire il ticket: sono utili nei casi in cui il problema si ritenga chiuso, ma ci sia ancora qualcosa da dire. Ma voi che fate ricerca tecnologica cosí all'avanguardia, dovreste saperlo.

22 Jul 2008 17:34, assistenza NGI:

Mi pare che la parte tecnica del ticket sia stata più volte chiarita dai miei precedenti reply.

Il rispetto per il cliente (power user o utente "casalingo" che sia, nel campo rispetto a noi non fà differenza, viene portato a tutti nello stesso modo) Le è stato dato dal primo reply fino all' ultimo, come dimostrato dalla cronostoria.

Non era una "panzana" come Lei definisce la definizione "motivi di sicurezza", la spiegazione Le è stata chiaramente e inequivocabilmente data nell' ultimo reply, e per questo motivo non ritengo necessario replicarLe a riguardo nuovamente.

Tutto ciò che è scritto all' interno di http://www.ngi.it/F5/caratteristiche_tecniche_ADSL.asp è effettivamente presente all' interno della nostra rete, e quindi all' interno della nostra offerta. Ogni cliente, comunque, è ovviamente libero di operare le proprie scelte in base alle proprie esigenze e fare le proprie valutazioni economiche a riguardo, ritenendo il nostro prodotto più o meno conveniente/adatto rispetto ad altri.

Distinti saluti