Indice del forum Emilia Romagna Linux Users Group
i forum di ERLUG
torna alla home page di ERLUG
 
 Forum SubscriptionsForum Subscriptions   FAQFAQ   CercaCerca   Lista utentiLista utenti   GruppiGruppi   RegistratiRegistrati 
 ProfiloProfilo   Messaggi privatiMessaggi privati   Log inLog in 

Crollo dello spam
Vai a Precedente  1, 2, 3, 4, 5  Successivo
 
Nuovo argomento   Rispondi    Indice del forum -> ERLUG
Precedente :: Successivo  
Autore Messaggio
Andrea Zonato
Ospite





MessaggioInviato: Mar 08 Mag 2007 18:04    Oggetto: Crollo dello spam Rispondi citando

Alle martedì 8 maggio 2007, Davide Bolcioni ha scritto:
Citazione:
Salve a tutti,
ho l'impressione che da una o due settimane ci sia stato un crollo
verticale nella quantità di spam che ricevo, non compensato da una
crescita del phishing su poste.it che pure c'è stata. Non ho
statistiche sottomano, ma la sensazione è di una riduzione di oltre
il 50%. Conferme o smentite ?

confermo. sia per quanto riguarda lo spam inviato direttamente sui miei
indirizzi, sia per quello che arriva su varie caselle tipo tin.it o
libero e che recupero con fetchmail.


ciao
_________________
Andrea
Top
m
Ospite





MessaggioInviato: Gio 10 Mag 2007 11:53    Oggetto: Crollo dello spam Rispondi citando

* Fabio Muzzi (kurgan@xxxxxx.xyz) [070508 16:40]:
Citazione:

Citazione:
- Sono solo io che sento una gran puzza di deadlock (superabile con
qualche timer, per carità, ma sempre deadlock)

Secondo me si`. non ci sono deadlock possibili, al limite c'e` un rifiuto
di una mail "buona", ma nulla di piu` disastroso.


server A1, A2 --- sistema di balancing che riferisce come MX di livello
piu` basso, l'uno o l'altro, o stessa priorita`, per il dominio A

server B1, B2 --- sistema di balancing che riferisce come MX di livello
piu` basso, l'uno o l'altro, o stessa priorita`, per il dominio B

1) usera@A manda una mail a userb@B: arriva casualmente su B1

2) B1 controlla se esiste usera@A e tenta di spedire ad A2 (per esempio)

3) A2 controlla se esiste userb@B e tenta di spedire a B2 (per esempio)

4) B2 controlla se esiste usera@A e tenta di spedire ad A1 (per esempio)

cosa fa A1 ?

nota che adesso A1 e` ancora in attesa di sapere se puo' spedire sta
cazzo di email a B1 e gli arriva la richiesta di riverificare userb@B
(perche` cosi` fa B2 al passo 4)

torna al passo 1 ? fa un detect del loop (see.... e come ?), gliela da a
mucchia ?

bisognerebbe vedere se i dettagli dell'implementazione escludono questi
scenari o se potrebbero anche complicarsi nel caso il traffico arrivi o
esca con domini mascherati, e in questo caso il ciclo potrebbe essere
anche piu` breve ... non so, ma non sono convinto che non si presentino
deadlock, ma so una cosa: che se si presentassero, da diagnosticare e
risolvere sarebbero un'ecatombe spaventosa ...

poi, magari, rimane un'idea discreta, in certi ambiti, perche` i casi
limiti poi non si presentano

non so ...

_________________
.*. finelli
/V\
(/ \) --------------------------------------------------------------
( ) Linux: Friends dont let friends use Piccolosoffice
^^-^^ --------------------------------------------------------------
Top
ap



Registrato: 07/05/07 14:55
Messaggi: 197
Residenza: Bologna

MessaggioInviato: Gio 10 Mag 2007 12:05    Oggetto: Crollo dello spam Rispondi citando

On 10 May 2007, at 12:53, m@xxxxxx.xyz wrote:

[deadlock su callback verification]

Citazione:
bisognerebbe vedere se i dettagli dell'implementazione escludono
questi
scenari

Forse il metodo più semplice e brutale per evitare deadlock è
lasciare passare la mail se il sottosistema di callback verification
non risponde entro un certo tempo.

Questo sarebbe comunque un sistema che si scavalca (mettendosi nei
panni dello spammer) con una semplicità disarmante.

Ciao,

- ap_______________________________________________
Erlug mailing list
Erlug@xxxxxx.xyz
http://erlug.linux.it/cgi-bin/mailman/listinfo/erlug
-----------------------------------------------------------
ErLUG webzine: http://erlug.linux.it
Manuali FDL:
LinuxFacile - http://www.linuxfacile.org
Linux Da Zero - http://erlug.linux.it/linuxdazero/
Connettivita' offerta da Ehiweb.it - http://www.ehiweb.it/
-----------------------------------------------------------
Top
Profilo Invia messaggio privato HomePage
m
Ospite





MessaggioInviato: Gio 10 Mag 2007 12:09    Oggetto: Crollo dello spam Rispondi citando

* Andrea Paolini (ap@xxxxxx.xyz) [070510 13:06]:
Citazione:

Forse il metodo più semplice e brutale per evitare deadlock è
lasciare passare la mail se il sottosistema di callback verification
non risponde entro un certo tempo.

Questo sarebbe comunque un sistema che si scavalca (mettendosi nei
panni dello spammer) con una semplicità disarmante.


ma infatti, se cosi` fosse, sarebbe semplice: il mio mail era proprio
per capire se un deadlock come quello ipotizzato avesse possibilita` di
avverarsi, o no

_________________
.*. finelli
/V\
(/ \) --------------------------------------------------------------
( ) Linux: Friends dont let friends use Piccolosoffice
^^-^^ --------------------------------------------------------------
Top
Fabio Ferrero
Ospite





MessaggioInviato: Gio 10 Mag 2007 12:23    Oggetto: Crollo dello spam Rispondi citando

On 10/mag/07, at 12:53, m@xxxxxx.xyz wrote:
Citazione:
Citazione:
Secondo me si`. non ci sono deadlock possibili, al limite c'e` un
rifiuto
di una mail "buona", ma nulla di piu` disastroso.
server A1, A2 --- sistema di balancing che riferisce come MX di
livello
piu` basso, l'uno o l'altro, o stessa priorita`, per il dominio A
server B1, B2 --- sistema di balancing che riferisce come MX di
livello
piu` basso, l'uno o l'altro, o stessa priorita`, per il dominio B
1) usera@A manda una mail a userb@B: arriva casualmente su B1
2) B1 controlla se esiste usera@A e tenta di spedire ad A2 (per
esempio)
3) A2 controlla se esiste userb@B e tenta di spedire a B2 (per
esempio)
4) B2 controlla se esiste usera@A e tenta di spedire ad A1 (per
esempio)
cosa fa A1 ?

Scusa... se i due sistemi sono in balancing si spera siano anche
coerenti.

Questo vuol dire che:
1) usera@A manda una mail a userb@B, arriva a B1
2) B1 fa un VRFY di usera@A, qualunque server becchi (A1, A2, An) se
l'utente viene verificato, B1 accetta la mail
3) An non puo' fare un callout di verifica perche' il MAIL FROM e' <>

Fine...

_________________
Fabio "Nutella" Ferrero
--------------------------------------------
Internet Images srl || http://www.interim.it
email: ferrero@xxxxxx.xyz || info@xxxxxx.xyz
Tel://051.627.26.79 |||| Fax://051.376.41.07
Top
Fabio Ferrero
Ospite





MessaggioInviato: Gio 10 Mag 2007 12:27    Oggetto: Crollo dello spam Rispondi citando

On 10/mag/07, at 13:23, Fabio Ferrero wrote:
Citazione:
Questo vuol dire che:
1) usera@A manda una mail a userb@B, arriva a B1
2) B1 fa un VRFY di usera@A, qualunque server becchi (A1, A2, An)
se l'utente viene verificato, B1 accetta la mail
3) An non puo' fare un callout di verifica perche' il MAIL FROM e' <>

Nel punto 2, VRFY non e' inteso come comando SMTP...

_________________
Fabio "Nutella" Ferrero
--------------------------------------------
Internet Images srl || http://www.interim.it
email: ferrero@xxxxxx.xyz || info@xxxxxx.xyz
Tel://051.627.26.79 |||| Fax://051.376.41.07
Top
m
Ospite





MessaggioInviato: Gio 10 Mag 2007 12:31    Oggetto: Crollo dello spam Rispondi citando

* Fabio Ferrero (ferrero@xxxxxx.xyz) [070510 13:23]:
Citazione:

Scusa... se i due sistemi sono in balancing si spera siano anche
coerenti.


si spera, ma non e` mica detto

Citazione:
Questo vuol dire che:
1) usera@A manda una mail a userb@B, arriva a B1
2) B1 fa un VRFY di usera@A, qualunque server becchi (A1, A2, An) se
l'utente viene verificato, B1 accetta la mail
3) An non puo' fare un callout di verifica perche' il MAIL FROM e' <>


e a questo punto, potrebbe pero` decidere che se il MAIL FROM e` <>
rifiuta la mail, proprio perche` non puo' fare sender verification ...

_________________
.*. finelli
/V\
(/ \) --------------------------------------------------------------
( ) Linux: Friends dont let friends use Piccolosoffice
^^-^^ --------------------------------------------------------------
Top
Fabio Muzzi
Ospite





MessaggioInviato: Gio 10 Mag 2007 21:40    Oggetto: Crollo dello spam Rispondi citando

Hello m,

Thursday, May 10, 2007, 12:53:37 PM, you wrote:

Citazione:
server A1, A2 --- sistema di balancing che riferisce come MX di livello
piu` basso, l'uno o l'altro, o stessa priorita`, per il dominio A

Citazione:
server B1, B2 --- sistema di balancing che riferisce come MX di livello
piu` basso, l'uno o l'altro, o stessa priorita`, per il dominio B

Citazione:
1) usera@A manda una mail a userb@B: arriva casualmente su B1

Ok.

Citazione:
2) B1 controlla se esiste usera@A e tenta di spedire ad A2 (per esempio)

Ok.

Citazione:
3) A2 controlla se esiste userb@B e tenta di spedire a B2 (per esempio)

No, questo passo non accade. la catena si ferma al passo precedente. A2
riceve una mail con mittente vuoto e destinatario "user@A". A2 non puo`
controllarne il mittente, si limita a considerarla un delivery error, la
accetta (se esiste user@A) e quindi B1 e` sereno, user@A esiste.

Ti ricordo che il "check del mittente si svolge cosi`:

B1 fa:

mail from: <>
rcpt to: <user@A>

Se A2 ora mi dice "OK, vai" allora ho verificato e quitto prima del DATA.

A2 non potra` MAI fare un check indietro, perche` il mittente e` nullo.

Quello che mi e` successo e` che il remoto mi abbia detto "non accetto
mail con mittente nullo", ma in questo caso lui sta violando lo standard.

Io accetto sempre mail con mittente nullo, a meno che non siano in CC o
BCC. Un solo destinatario per il mittente nullo.




_________________
Fabio "Kurgan" Muzzi

Chi e'? Giaaaanniiii! L'ottimismo vola!!
Vedo cani che si masturbano, commesse che hanno un buon sapore!
Top
Fabio Muzzi
Ospite





MessaggioInviato: Gio 10 Mag 2007 21:43    Oggetto: Crollo dello spam Rispondi citando

Hello Andrea,

Thursday, May 10, 2007, 1:05:53 PM, you wrote:

Citazione:
Forse il metodo più semplice e brutale per evitare deadlock è lasciare
passare la mail se il sottosistema di callback verification non risponde
entro un certo tempo.


Il mio sistema funziona cosi`, pero` non e` cosi` facile ingannarlo.

Se il dominio del mittente non esiste, rifiuto.

Se esiste e mi risponde "l'utente non esiste", rifiuto.

Se esiste e il suo MX va in timeout, allora accetto la mail. Questo pero`
vuole dire che lo spammer deve mettere su un dominio con un MX che va in
timeout (o allora, per farla piu` facile, con un MX che accetta qualsiasi
cosa).

Pero` questo sembra essere troppo costoso per lo spammer normale, il quale
al limite, appunto, si limita ad usare mittenti esistenti a caso...




_________________
Fabio "Kurgan" Muzzi

La diagnosi del tecnico:
I cavi troppo intrecciati fra loro provocano la perdita della
sequenzialita` dei pacchetti
Top
Fabio Muzzi
Ospite





MessaggioInviato: Gio 10 Mag 2007 21:44    Oggetto: Crollo dello spam Rispondi citando

Hello m,

Thursday, May 10, 2007, 1:31:40 PM, you wrote:

Citazione:
e a questo punto, potrebbe pero` decidere che se il MAIL FROM e` <>
rifiuta la mail, proprio perche` non puo' fare sender verification ...

e rompe lo standard.


_________________
Fabio "Kurgan" Muzzi

La diagnosi del tecnico:
La stampante e` convinta di essere un router
Top
tannoiser



Registrato: 02/04/07 10:06
Messaggi: 621

MessaggioInviato: Gio 10 Mag 2007 22:22    Oggetto: Crollo dello spam Rispondi citando

* giovedì 10 maggio 2007, alle 22:40, Fabio Muzzi scrive:
Citazione:
mail from: <>
rcpt to: <user@A>

Se A2 ora mi dice "OK, vai" allora ho verificato e quitto prima del DATA.

A2 non potra` MAI fare un check indietro, perche` il mittente e` nullo.

Quello che mi e` successo e` che il remoto mi abbia detto "non accetto
mail con mittente nullo", ma in questo caso lui sta violando lo standard.

Io accetto sempre mail con mittente nullo, a meno che non siano in CC o
BCC. Un solo destinatario per il mittente nullo.

Scusa, mi riprometto di non incedere ulteriormente, perche` si sta un
po` svaccando nel "dimostratemi che ho torto a fare quello che mi
pare"[1], ma:

Dove, esattamente, l'rfc (visto che si parla di standard) dice che si
*devono* accettare mail from: <>? Dice che sono _accettabili_ e che
servono in un caso ben preciso (che non e` il tuo), per evitare loop in
double bounce (cosi` come non c'e` scritto da nessuna parte che devo
accettare tutta la posta, altrimenti, ogni messaggio che rifiuti ti
rende il mailer fuori standard?).

Giusto perche`:

- E` perfettamente lecito decidere che posta tu vuoi e che posta non
vuoi.

- Lo e` meno, definire come fuori standard, tutti quelli che non fanno
come vuoi tu.

Detto questo, ti espongo due casi, che credo, interessanti:

- diversi server smtp, danno un "finto" ok, a comando mail, e fanno
reject alla fine di data (e non all'inizio). Ci sono buoni motivi per
fare questo, ed e` un comportamento accettabile per lo standard.
Ne hai tenuto conto?

- posta da utente@xxxxxx.xyz la accetti? Considera che tale
fqdn (www.erlug.linux.it) NON ha un mx record. Fingiamo per un
momento che www.erlug.linux.it, a cui dovresti per definizione
considerare mx == host (da rfc), non accetti connessioni sulla 25 (non
e` vero, la nostra macchina le accetta, ma e` per fare un esempio). In
questo caso, vai in timeout, e la posta passa, giusto? Non mi pare
quindi cosi` difficile far passare la posta, men che meno c'e` bisogno
di creare mx fittizi che non ti rispondano.


[1]
Ovviamente non hai torto. My house, my rule. Se si discute di questo, io
non discuto. Se si discute di standard, o di "e` impossibile che",
allora qualche opinione in merito, penso di averla. ;)

_________________
Maurizio - Tannoiser - Lemmo
Founder Member of ERLUG http://erlug.linux.it
-------------------------------------------------------------------------------
Wesley: "This box must be destroyed."
Xander: "I need a volunteer to hit Wesley."
--Buffy the Vampire Slayer: Choices
Top
Profilo Invia messaggio privato
ap



Registrato: 07/05/07 14:55
Messaggi: 197
Residenza: Bologna

MessaggioInviato: Ven 11 Mag 2007 16:26    Oggetto: Crollo dello spam Rispondi citando

On 8 May 2007, at 12:29, Andrea Paolini wrote:

[greylisting]

Citazione:
Citazione:
Piu` il greylist
si diffonde, piu` il software di emissione dello spam, si adattera` a
fare secondi tentativi,

Qualche giorno fa ravanavo sui log, e ho visto che ultimamente
qualche bot riprova la spedizione quando incontra un 4xx.
I tentativi successivi avvengono dopo pochi secondi, e per ora non
riescono a superare i filtri, ma è solo questione di tempo.

Oggi un bel penny stock spam arrivato da un IP dinamico di un ADSL
turca (un bel PC zombizzato) ha onorato il 450, ha pazientemente
atteso 10 minuti e rimandato la mail.

Festa finita.

- ap_______________________________________________
Erlug mailing list
Erlug@xxxxxx.xyz
http://erlug.linux.it/cgi-bin/mailman/listinfo/erlug
-----------------------------------------------------------
ErLUG webzine: http://erlug.linux.it
Manuali FDL:
LinuxFacile - http://www.linuxfacile.org
Linux Da Zero - http://erlug.linux.it/linuxdazero/
Connettivita' offerta da Ehiweb.it - http://www.ehiweb.it/
-----------------------------------------------------------
Top
Profilo Invia messaggio privato HomePage
ap



Registrato: 07/05/07 14:55
Messaggi: 197
Residenza: Bologna

MessaggioInviato: Ven 11 Mag 2007 16:36    Oggetto: Crollo dello spam Rispondi citando

On 10 May 2007, at 22:44, Fabio Muzzi wrote:

Citazione:
Citazione:
Forse il metodo più semplice e brutale per evitare deadlock è
lasciare
passare la mail se il sottosistema di callback verification non
risponde
entro un certo tempo.


Il mio sistema funziona cosi`, pero` non e` cosi` facile ingannarlo.

[...]

Citazione:
Se esiste e il suo MX va in timeout, allora accetto la mail.
Questo pero`
vuole dire che lo spammer deve mettere su un dominio con un MX
che va in
timeout (o allora, per farla piu` facile, con un MX che accetta
qualsiasi
cosa).

No lo classificherei tra le cose difficili... Becchi una terza parte
innocente che accetta mail senza verificare il destinatario a livello
di sessione, e non te ne frega niente nemmeno se viene flood-ato
dalle verifiche da mezzo mondo (male che vada va in timeout, e lo
spam passa).

Citazione:
Pero` questo sembra essere troppo costoso per lo spammer normale,

makemoneyfast@xxxxxx.xyz ...

- ap_______________________________________________
Erlug mailing list
Erlug@xxxxxx.xyz
http://erlug.linux.it/cgi-bin/mailman/listinfo/erlug
-----------------------------------------------------------
ErLUG webzine: http://erlug.linux.it
Manuali FDL:
LinuxFacile - http://www.linuxfacile.org
Linux Da Zero - http://erlug.linux.it/linuxdazero/
Connettivita' offerta da Ehiweb.it - http://www.ehiweb.it/
-----------------------------------------------------------
Top
Profilo Invia messaggio privato HomePage
m
Ospite





MessaggioInviato: Ven 11 Mag 2007 16:56    Oggetto: Crollo dello spam Rispondi citando

* Andrea Paolini (ap@xxxxxx.xyz) [070511 17:26]:
Citazione:

Oggi un bel penny stock spam arrivato da un IP dinamico di un ADSL
turca (un bel PC zombizzato) ha onorato il 450, ha pazientemente
atteso 10 minuti e rimandato la mail.


to la prima margheritina invernale !

Citazione:
Festa finita.

e` primavera ... svegliatevi bambine ...

_________________
.*. finelli
/V\
(/ \) --------------------------------------------------------------
( ) Linux: Friends dont let friends use Piccolosoffice
^^-^^ --------------------------------------------------------------
Top
ram5456
Ospite





MessaggioInviato: Mer 16 Mag 2007 12:54    Oggetto: Crollo dello spam: dopo le Poste, la Polizia Rispondi citando

Salve a tutti,
come probabilmente avrete già notato da oggi un
sedicente capitano di polizia Prisco Mazzi
impazza per la rete mandando questo messaggio (mi
scuso per il messaggio in HTML):

Citazione:
Avviso
Sono capitano della polizia Prisco Mazzi. I
rusultati dell'ultima verifica hanno rivelato che
dal Suo computer sono stati visitati i siti che
trasgrediscono i diritti d'autore e sono stati
scaricati i file pirati nel formato mp3. Quindi
Lei e un complice del reato e puo avere la
responsabilita amministrativa.

Il suo numero nel nostro registro e 00098361420.

Non si puo essere errore, abbiamo confrontato
l'ora dell'entrata al sito nel registro del
server e l'ora del Suo collegamento al Suo
provider. Come e l'unico fatto, puo sottrarsi
alla punizione se si impegna a non visitare piu
i siti illegali e non trasgredire i diritti
d'autore.

Per questo per favore conservate l'archivio
(avviso_98361420.zip parola d'accesso: 1605)
allegato alla lettera al Suo computer,
desarchiviatelo in una cartella e leggete l'accordo
che si trova dentro.

La vostra parola d'accesso personale per l'archivio: 1605

E obbligatorio.

Grazie per la collaborazione.

Ovviamente il messaggio contiene un
bell'eseguibile che mi sono guardato bene
dall'aprire. Ma quanti non saranno stati altrettanto astuti?
Guardando gli headers dei 6 messaggi identici che
mi sono arrivati solo oggi, vedo:

Citazione:
Received: from [219.252.77.53] ([219.252.77.53])
by mx2.acantho.net
(8.13.4/8.13.4/Debian-3sarge1) with ESMTP id l4G0TFwR019258
for <giacovelli@xxxxxx.xyz>; Wed, 16 May 2007 02:29:21 +0200
X-Icontrol: Sent by Inrete Icontrol
Received: from skts-m054 (skts-m054 [219.252.77.53])
by skts-m054 (8.12.8p1/8.12.8) with ESMTP id i84DCA4F336D71
for <giacovelli@xxxxxx.xyz>; Wed, 16 May 2007 18:28:29 +0900
(envelope-from prisco_m@xxxxxx.xyz)

Citazione:
Received: from [219.252.77.53] ([219.252.77.53])
by mx1.acantho.net
(8.13.4/8.13.4/Debian-3sarge1) with ESMTP id l4G0SW8e032673
for <giacovelli@xxxxxx.xyz>; Wed, 16 May 2007 02:28:38 +0200
X-Icontrol: Sent by Inrete Icontrol
Received: from skts-m054 (skts-m054 [219.252.77.53])
by skts-m054 (8.12.8p1/8.12.8) with ESMTP id iAAA354338D649
for <giacovelli@xxxxxx.xyz>; Wed, 16 May 2007 18:28:37 +0900
(envelope-from priscomaz@xxxxxx.xyz)

Citazione:
Received: from [211.246.169.11] ([211.246.169.11])
by mx2.acantho.net
(8.13.4/8.13.4/Debian-3sarge1) with ESMTP id l4G9b8sX022371
for <ram5456@xxxxxx.xyz>; Wed, 16 May 2007 11:37:16 +0200
X-Icontrol: Sent by Inrete Icontrol
Received: from samsung-vku3ubm (samsung-vku3ubm [211.246.169.11])
by samsung-vku3ubm (8.12.8p1/8.12.8) with ESMTP id i9EC19C9C4CA16
for <ram5456@xxxxxx.xyz>; Thu, 17 May 2007 03:36:21 +0900
(envelope-from prisco_mazzi@xxxxxx.xyz)

Citazione:
Received: from [211.246.169.11] (unknown [211.246.169.11])
by epistola.iperbole.bologna.it (Postfix) with ESMTP id 47D374E14A2
for <ram5456@xxxxxx.xyz>; Wed,
16 May 2007 11:36:37 +0200 (CEST)
Received: from samsung-vku3ubm (samsung-vku3ubm [211.246.169.11])
by samsung-vku3ubm (8.12.8p1/8.12.8) with ESMTP id i60B0246D916FB
for <ram5456@xxxxxx.xyz>; Thu, 17 May 2007 03:36:35 +0900
(envelope-from prisco_m@xxxxxx.xyz)

Citazione:
Received: from [211.222.161.193] ([211.222.161.201])
by mx2.acantho.net
(8.13.4/8.13.4/Debian-3sarge1) with ESMTP id l4G9ajE0021921
for <ram5456@xxxxxx.xyz>; Wed, 16 May 2007 11:36:54 +0200
X-Icontrol: Sent by Inrete Icontrol
Received: from jshuh (jshuh [172.2.102.34])
by jshuh (8.12.8p1/8.12.8) with ESMTP id i0026DB72E4F1B
for <ram5456@xxxxxx.xyz>; Thu, 17 May 2007 03:48:44 +0900
(envelope-from prima@xxxxxx.xyz)

e, infine:

Citazione:
Received: (from root@localhost)
by mx1.acantho.net (8.13.4/8.13.4/Debian-3sarge1) id l4G9aIv7000350
for <ram5456@xxxxxx.xyz>; Wed, 16 May 2007 11:36:18 +0200
Received: from [211.222.161.193] ([211.222.161.201])
by mx1.acantho.net
(8.13.4/8.13.4/Debian-3sarge1) with ESMTP id l4G9a5WT032553
for <ram5456@xxxxxx.xyz>; Wed, 16 May 2007 11:36:11 +0200
X-Icontrol: Sent by Inrete Icontrol
Received: from jshuh (jshuh [172.2.102.34])
by jshuh (8.12.8p1/8.12.8) with ESMTP id iF82FD692DB7C5
for <ram5456@xxxxxx.xyz>; Thu, 17 May 2007 03:48:55 +0900
(envelope-from pris_mazzi@xxxxxx.xyz)

Beh, che dire? Almeno qualcuno s'e' preso la
briga di cambiare ogni volta la mail dell'amico.
Grazie per l'attenzione, Stefano Giacovelli
Top
Mostra prima i messaggi di:   
Nuovo argomento   Rispondi    Indice del forum -> ERLUG Tutti i fusi orari sono GMT + 1 ora
Vai a Precedente  1, 2, 3, 4, 5  Successivo
Pagina 4 di 5

 
Vai a:  
Non puoi inserire nuovi argomenti
Non puoi rispondere a nessun argomento
Non puoi modificare i tuoi messaggi
Non puoi cancellare i tuoi messaggi
Non puoi votare nei sondaggi


Powered by phpBB © 2001, 2005 phpBB Group
phpbb.it

torna alla home page di ERLUG
Per informazioni o problemi, contattare info@erlug.linux.it.
La connettività per questo sito e per gli altri nostri servizi è offerta da Ehiweb.it