openpec-devel — OpenPEC developers

Re: [Openpec-devel] Riepilogo chat OpenPEC del 2.08.2005

[Giacomo C. <gia...@ya...>]

ciao a tutti.
Ho finalmente fatto qualche prova sulla gestione delle connessioni tcp
da syslog ed i risultati mi sembrano promettenti.

Una premessa importante e' che, come probabilmente gia' sapete,
syslog-ng permette di definire sorgenti e destinazioni multiple
e di combinarle a piacere associando dei filtri.
Questo significa che posso selezionare tutti i messaggi prodotti
da un certo programma e/o contenenti una certa stringa e redirigere solo quelli.

Tenendo presente come avviene di solito il logging su db locale, ovvero:
$ mkfifo /var/log/mysql.pipe
$ mysql -u syslogadmin --password=$pwadmin syslog < /var/log/mysql.pipe

ho fatto alcune prove per inviare messaggi ad un host remoto ed inserirli 
su un db mysql in esecuzione su quell'host.
La cosa interessante e' chi riceve questi messaggi sull'host remoto.
Mi sono venute in mente tre soluzioni:
1) Da syslog-ng1 (macchina locale) a syslog-ng2 (con source tcp su macchina
   remota). syslog-ng2 invia poi a destination mysql

2) Da syslog-ng1 a client netcat su macchina remota in pipe su mysql

3) Da syslog-ng1 a client/servizio su macchina remota
   Si definisce un servizio inet sulla macchina remota che in questo modo
   viene avviato solo all'occorrenza. Il servizio si occupa di redirigere
   i dati verso syslog_mysql.sh o simili.

Lo scenario 1) permette di comportarsi come se tutto avvenisse localmente,
lasciando ai due syslog-ng il compito di gestire il transito dei messaggi
da un host all'altro.

Il secondo d'altra parte sembra funzionare molto bene nonostante la sua semplicita'.
Ho fatto alcune prove di resistenza :)
hostremoto> while true; do echo "restarting ..."; nc -l -p 3022 | mysql -u
syslogadmin --password=syslogadmin syslog; done

Avvio e kill del processo mysql:
restarting ...
Terminated
restarting ...

Avvio e kill del processo nc:
restarting ...
restarting ...

In entrambi i messaggi vengono correttamente loggati sul db remoto.
Sull'host locale syslog-ng logga messaggi di questo tipo:
Sep 09 15:44:16 gurky syslog-ng[21710]: Connection broken to
AF_INET(hostremoto:3022), reopening in 60 seconds


Giacomo


--- Luca De Santis <des...@ks...> wrote:

> Ciao Giacomo e ciao Andrea,
> 
> >> ... Si tratta di un sistema,
> >> che, come sappiamo, logga con un trasporto non affidabile (UDP) su rete.
> > 
> > Per fortuna syslog-ng supporta svariate sorgenti/destinazioni tra le quali
> > anche i socket tcp.
> 
> Confermo: 
> cfr. 
> http://www.balabit.com/products/syslog_ng/reference-2.0/syslog-ng.html/index
> .html#id2525640
> 
> Quindi sicuramente dovremo configurare il logging per andare su TCP/IP.
> 
> > Come avviene il logging su syslog da OpenPEC?
> > Viene utilizzato il modulo Unix::Syslog od altro?
> 
> Sì, la gestione dei log è affidata al modulo Opec::Log che a sua volta usa
> Unix::Syslog.
>  
> >> In una architettura distribuita si avrebbe quindi un logging su un
> >> sistema non controllabile (nell'ipotesi che il db di logging sia
> >> su un server separato per ridondanza e performances).
> > 
> > In effetti se ricordo bene nella chat di martedi non se ne e' parlato.
> > E' previsto che il logging su db possa essere su una macchina separata?
> 
> Credo che il tutto possa essere risolto tramite una configurazione di
> syslog-ng. Quindi questo potrà essere fatto o meno, così come il DB potrà
> esserci oppure no. I log "ufficiali" da ruotare saranno quelli riportati sui
> file: il DB faciliterà invece le analisi statistiche e i controlli.
> 
> In realtà il modo con cui syslog-ng parla con i DB mi sembra un po' debole.
> In pratica utilizza una pipe che viene poi letta dai programmi "client" che
> dialogano con i db (es. mysql, sqlplus, etc.). Quindi il DB può risiedere su
> una qualsiasi macchina, purché sia raggiungibile con i tradizionali
> applicativi client da quella su cui gira il syslog-ng.
> 
> Altre info si possono trovare qui: http://vermeer.org/docs/1
> 
> Ultima info di servizio per tutti: noi di Ksol mancheremo fino al 22/8,
> compreso Flazan-Sensei. Non stupitevi di eventuali nostri silenzi.
> 
> Salutoni, a presto
> Dex
> 
> -- 
> Luca De Santis
> Ksolutions spa, Gruppo KATAWEB
> via Lenin 132/26
> 56017 S. Martino Ulmiano (PI) - ITALY
> tel.: +39 050 898 563 (direct)
> mobile: +39 335 7376 153
> fax: +39 050 861 200
> email: des...@ks...
> web: http://www.ksolutions.it
> 
> 



	
		
______________________________________________________ 
Yahoo! for Good 
Donate to the Hurricane Katrina relief effort. 
http://store.yahoo.com/redcross-donate3/ 

Re: [Openpec-devel] Riepilogo chat OpenPEC del 2.08.2005

[Luca De S. <des...@ks...>]

Ciao Giacomo e ciao Andrea,

>> ... Si tratta di un sistema,
>> che, come sappiamo, logga con un trasporto non affidabile (UDP) su rete.
>=20
> Per fortuna syslog-ng supporta svariate sorgenti/destinazioni tra le qual=
i
> anche i socket tcp.

Confermo:=20
cfr.=20
http://www.balabit.com/products/syslog_ng/reference-2.0/syslog-ng.html/inde=
x
.html#id2525640

Quindi sicuramente dovremo configurare il logging per andare su TCP/IP.

> Come avviene il logging su syslog da OpenPEC?
> Viene utilizzato il modulo Unix::Syslog od altro?

S=EC, la gestione dei log =E8 affidata al modulo Opec::Log che a sua volta usa
Unix::Syslog.
=20
>> In una architettura distribuita si avrebbe quindi un logging su un
>> sistema non controllabile (nell'ipotesi che il db di logging sia
>> su un server separato per ridondanza e performances).
>=20
> In effetti se ricordo bene nella chat di martedi non se ne e' parlato.
> E' previsto che il logging su db possa essere su una macchina separata?

Credo che il tutto possa essere risolto tramite una configurazione di
syslog-ng. Quindi questo potr=E0 essere fatto o meno, cos=EC come il DB potr=E0
esserci oppure no. I log "ufficiali" da ruotare saranno quelli riportati su=
i
file: il DB faciliter=E0 invece le analisi statistiche e i controlli.

In realt=E0 il modo con cui syslog-ng parla con i DB mi sembra un po' debole.
In pratica utilizza una pipe che viene poi letta dai programmi "client" che
dialogano con i db (es. mysql, sqlplus, etc.). Quindi il DB pu=F2 risiedere s=
u
una qualsiasi macchina, purch=E9 sia raggiungibile con i tradizionali
applicativi client da quella su cui gira il syslog-ng.

Altre info si possono trovare qui: http://vermeer.org/docs/1

Ultima info di servizio per tutti: noi di Ksol mancheremo fino al 22/8,
compreso Flazan-Sensei. Non stupitevi di eventuali nostri silenzi.

Salutoni, a presto
Dex

--=20
Luca De Santis
Ksolutions spa, Gruppo KATAWEB
via Lenin 132/26
56017 S. Martino Ulmiano (PI) - ITALY
tel.: +39 050 898 563 (direct)
mobile: +39 335 7376 153
fax: +39 050 861 200
email: des...@ks...
web: http://www.ksolutions.it

Re: [Openpec-devel] Riepilogo chat OpenPEC del 2.08.2005

[Giacomo C. <gia...@ya...>]

ciao

--- an...@li... wrote:

> Credo che dovreste valutare se, legalmente, sia possibile utilizzare
> un sistema di logging come syslog-ng/syslog. Si tratta di un sistema,
> che, come sappiamo, logga con un trasporto non affidabile (UDP) su rete.

Per fortuna syslog-ng supporta svariate sorgenti/destinazioni tra le quali
anche i socket tcp.
Cerchero' di fare qualche prova anche da macchine diverse da quelle su cui
gira syslog-ng per verifica.

Come avviene il logging su syslog da OpenPEC?
Viene utilizzato il modulo Unix::Syslog od altro?

> In una architettura distribuita si avrebbe quindi un logging su un
> sistema non controllabile (nell'ipotesi che il db di logging sia
> su un server separato per ridondanza e performances).

In effetti se ricordo bene nella chat di martedi non se ne e' parlato.
E' previsto che il logging su db possa essere su una macchina separata?


ciao
Giacomo


> 
> > in file diversi: non so se ? possibile configurare syslog-ng per non fargli
> > mai "spezzare" un file di log), generer? la hash, la invier? alla TSA per
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Questa cosa dovrebbe essere gestita dal sistema operativo, tramite
> logrotate (in caso si parli di linux) o da cron di sistema. La si puo'
> rimuovere.
> 
> un saluto
> a.f.
> 
> -- 
> Andrea Fanfani
> "Ci sono 10 tipi di persone, quelli che capiscono i numeri binari...
> e quelli che non li capiscono."
> 					(Anonimo)
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Openpec-devel] Riepilogo chat OpenPEC del 2.08.2005

[<an...@li...>]

On Fri, Aug 05, 2005 at 04:59:38PM +0200, Luca De Santis wrote:
> Ciao a tutti, 
> la chat di marted? scorso ha ufficialmente dato il via alle attivit? di
> sviluppo per OpenPEC2.

[...]

> Ecco i punti principali dibattuti marted?:
> 
> # GESTIONE LOG E MARCA TEMPORALE #

Salve, mi permetto di intervenire nella discussione.


> 1. gestione dei file di log.
> Abbiamo deciso di valutare l'uso del servizio syslog-ng (cfr.
> http://www.balabit.com/products/syslog_ng/) che presenta i seguenti
> vantaggi:
> - essendo un'estensione del syslog non va toccato il codice attuale di
> OpenPEC

Credo che dovreste valutare se, legalmente, sia possibile utilizzare
un sistema di logging come syslog-ng/syslog. Si tratta di un sistema,
che, come sappiamo, logga con un trasporto non affidabile (UDP) su rete.
In una architettura distribuita si avrebbe quindi un logging su un
sistema non controllabile (nell'ipotesi che il db di logging sia
su un server separato per ridondanza e performances).

> in file diversi: non so se ? possibile configurare syslog-ng per non fargli
> mai "spezzare" un file di log), generer? la hash, la invier? alla TSA per
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Questa cosa dovrebbe essere gestita dal sistema operativo, tramite
logrotate (in caso si parli di linux) o da cron di sistema. La si puo'
rimuovere.

un saluto
a.f.

-- 
Andrea Fanfani
"Ci sono 10 tipi di persone, quelli che capiscono i numeri binari...
e quelli che non li capiscono."
					(Anonimo)

[Openpec-devel] Riepilogo chat OpenPEC del 2.08.2005

[Luca De S. <des...@ks...>]

Ciao a tutti,=20
la chat di marted=EC scorso ha ufficialmente dato il via alle attivit=E0 di
sviluppo per OpenPEC2.

In chat abbiamo cercato di fare il punto sull'analisi delle modifiche
proposte a OpenPEC per supportare le nuove regole tecniche.

Altro obiettivo era quello di dividere all'interno della comunit=E0 degli
utenti alcuni task (sia sviluppo che documentazione).
IMPORTANTE: il "recruiting" non =E8 concluso. Se potete/volete aiutare per
favore fatevi avanti scrivendo a:
info _AT_ openpec _DOT_ org
o in mailing-list.=20
Arigatou gozaimasu!

Il punto di partenza della chat =E8 stato il documento di analisi redatto da
flazan e disponibile alla URL:
http://www.openpec.org/docs/OpenPec2-ATTIVITA-0%203.pdf

Ecco i punti principali dibattuti marted=EC:

# GESTIONE LOG E MARCA TEMPORALE #

Le nuove linee guida impongono che i log vengano archiviati periodicamente
(almeno giornalmente: cfr. art. 10 dello schema di decreto del CNIPA) e che
vengano "marcati temporalmente".
L'apposizione della marca consiste nella produzione di un hash dal file e
nel suo invio a una TSA (Time Stamp Authority). La TSA restituisce la marca
temporale, ovvero l'hash firmato con la sua chiave privata. La marca
temporale viene aggiunta al file firmato originale, generando un nuovo file
con estensione '.m7m' in formato S/MIME (cfr. http://www.net4u.it/ntp.html)=
.

Per OpenPEC 2.0 abbiamo pensato di dividere il problema in due:

1. gestione dei file di log.
Abbiamo deciso di valutare l'uso del servizio syslog-ng (cfr.
http://www.balabit.com/products/syslog_ng/) che presenta i seguenti
vantaggi:
- essendo un'estensione del syslog non va toccato il codice attuale di
OpenPEC
- permette di memorizzare gli eventi non solo su file ma anche su DB (tra
gli altri sono supportati MySQL e Postgres). E' probabile (ma bisogna
approfondire) che sia possibile memorizzare gli eventi _contemporaneamente_
su file e su DB. Le informazioni del file saranno quelle "ufficiali", da
archiviare e su cui verr=E0 apposta la marca temporale. Il DB, il cui uso sar=
=E0
opzionale, potr=E0 invece essere utilizzato a fini statistici e di
monitoraggio.

2. processo di archiviazione e apposizione della marca temporale.
Sar=E0 necessario sviluppare un demone che periodicamente (impostazione da
configurazione) provveder=E0 a recuperare i file prodotti da syslog-ng nel
periodo di riferimento, li unir=E0 in un unico file (se per caso si presentan=
o
in file diversi: non so se =E8 possibile configurare syslog-ng per non fargli
mai "spezzare" un file di log), generer=E0 la hash, la invier=E0 alla TSA per
ottenere la marca temporale e generer=E0 il file .m7m .

Esiste uno standard Internet chiamato TSP (RFC-3161: cfr.
http://www.ietf.org/rfc/rfc3161.txt) che regola la comunicazione con una
TSA. TSP funziona con diversi protocolli di trasporto, es. socket e
HTTP/HTTPS.
Non =E8 chiaro per=F2 se i certificatori italiani utilizzano questo protocollo.
Per OpenPEC quindi sarebbe utile sviluppare un modulo Perl per la gestione
della marca temporale, possibilmente compatibile con TSP.

Nota bene: non =E8 chiaro se da un punto di vista legale _=E8 obbligatorio_
appoggiarsi a TSA esterne. Il costo di ogni marca temporale pare che si
aggiri intorno ai 0.30 EUR (info non confermata).

Da quanto detto si evince che il problema della gestione dei log in OpenPEC
2.0 =E8 solo in parte tecnico.
Per la parte di sviluppo Giacomo si =E8 offerto di dare una mano: per chiarir=
e
tutte le problematiche della marcatura c'=E8 bisogno del contributo di tutta
la comunit=E0. Se avete informazioni per favore fatevi avanti.


# ALTRI TASK DI SVILUPPO ASSEGNATI #

- interfacciamento con sistemi antivirus: =E8 attualmente in sviluppo da
flazan e dovrebbe essere pronto tra breve.

- gestione della firma mediante moduli HSM: questo =E8 il prossimo task in cu=
i
noi di Ksolutions (il mitico flazan in primis) saremo impegnati.

Tutti gli altri task indicati nel documento di analisi (es. il modulo di
gestione delle ricevute) non sono stati per ora assegnati.

PER FAVORE CHI FOSSE INTERESSATO A CONTRIBUIRE SI FACCIA AVANTI! TKS!



# DOCUMENTAZIONE #
Il task di produzione della documentazione di OpenPEC 2.0 non deve essere
sottovalutato: chi pu=F2 dare una mano per favore si faccia avanti sin da ora=
.

Da un punto di vista tecnico una prima cosa da chiarire sono le varie
possibilit=E0 di installazione di OpenPEC, ossia in presenza di altri domini
non certificati o solo per domini certificati, e ancora un solo dominio e
pi=F9 domini. Farebbe comodo un documento che faccia una chiara distinzione
fra questi casi.
Per questo task dovremmo aver trovato un volontario.

Inoltre dopo l'uscita del decreto farebbe comodo avere una guida per
spiegare ai gestori tutto quello che devono fare per certificarsi. Farebbe
anche comodo raccogliere dei documenti di esempio che devono essere
presentati al CNIPA, tipo il contratto da proporre agli utenti finali.


E' tutto: a risentirvi presto in ML o in chat!

Saluti a tutti/e, buone ferie a chi le far=E0,
Dex
--=20
Luca De Santis
Ksolutions spa, Gruppo KATAWEB
via Lenin 132/26
56017 S. Martino Ulmiano (PI) - ITALY
tel.: +39 050 898 563 (direct)
mobile: +39 335 7376 153
fax: +39 050 861 200
email: des...@ks...
web: http://www.ksolutions.it

[Openpec-devel] Informazioni sulla marca temporale

[Fanton F. <fa...@ks...>]

- Come funziona:
il client che ha bisogno di marcare temporalmente un file, crea un hash =
del file con un algoritmo standard compatibile con il server come SH1 o =
MD5, passa solo l'hash alla TSA (Time Stamp Authority), questa lo firma =
con la sua chiave privata e lo ritorna al client che ingloba il file =
originale con la firma ritornata dalla TSA in un file XML standard con =
estensione .m7m.
La comunicazione fra client e server =E8 tipicamente regolamentata dal =
RFC3161 anche se probabilmente qualche TSA fa storia a se.

- Chi fornisce il servizio
. Il servizio pu=F2 essere fornito da un'azienda (qualche nome fra tanti =
nCipher, infocamere, ...) tramite un server compatibile con RFC3161 o =
utilizzabile da client ad hoc dove si acquistano pacchetti di marche =
(10, 100, ...).=20

. Oppure si pu=F2 acquistare un prodotto certificato che produce marche =
certificate secondo quanto richiesto dalla normativa CNIPA =
(http://www.cnipa.gov.it/site/_contentfiles/01378900/1378935_DPCM%2013_01=
_2004.pdf).
Per semplicit=E0 riporto un estratto che elenca gli standard di =
sicurezza a cui il prodotto deve sottostare:

"Art. 49.
Sicurezza dei sistemi di validazione temporale=20
...
4. La conformit=E0 ai requisiti di sicurezza specificati nel presente =
articolo deve essere verificata secondo criteri di sicurezza almeno =
equivalenti a quelli previsti dal livello di valutazione E2 e robustezza =
dei meccanismi HIGH dell'ITSEC, o dal livello EAL 3 della norma ISO/IEC =
15408 o superiori. Sono ammessi livelli di valutazione =
internazionalmente riconosciuti come equivalenti.
..."

Quindi OpenPEC dovr=E0 essere sicuramente compatibile con RFC3161 e =
strutturato in modo da poter essere facilmente esteso per soluzioni =
proprietarie.

Interessante =E8 la sezione che riguarda le TSA del Politecnico di =
Torino (http://security.polito.it/ts/) in cui, oltre a descrivere =
l'argomento, c'=E8 un elenco dei fornitori del servizio a scopo di test.

Saluti,

*** Flavio Fanton - flazan
email: fanton at ksolutions.it
ICQ: #241547295

[Openpec-devel] Problema con domini virtuali

[Alberto Z. <al...@in...>]

Ho riscontrato un problema con le ricevute dei domini virtuali.
Sostanzialmente all'interno della ricevuta, l'email del destinatario
riporta il dominio principale e non quello virtuale.
Per esempio, mandando una e-mail ad "al...@al...", dominio ospitato
sul server "pec.intenet.net" la ricevuta ha come destinatario
al...@pe....
Qualche idea?
Ciao,
Alberto

[Openpec-devel] [Fwd: R: problema dell'orario OpenPEC]

[Alberto Z. <al...@in...>]

Sposto in lista una discussione privata come consiglia Flavio.
Riassumendo il tutto, stiamo riscontrando problemi sull'orario usando
OpenPEC su una distribuzione Gentoo.
Ho fatto quache esperimento per cui adesso ho fatto un po' d'ordine sul
casino che avevo combinato sul mio server. Come ha consigliato
Francesco, in rc.conf la variabile CLOCK è settata a GMT e il file
/etc/localtime è linkato alla timezione GMT. I server NTP sono i due di
Galileo Ferraris (ntp1.ien.it ntp2.ien.it). Così facendo tutte i log
vengono scritti con lora di riferimento GMT (non Italia).
In italia, in questo momento, siamo avanti di due ore rispetto al GMT:
una per l'ora legale e una per il fuso orario. Purtroppo OpenPEC
modifica l'ora aggiungendo arbitrariamente un "+100" che in questo
momento non è corretto; non sono un grande esperto di Perl, per cui ho
cercato un attimo in Internet e ho visto che settando la variabile
d'ambiente TZ alla corretta timezone, perl modifica l'ora correttamente:

#!/usr/bin/perl
$ENV{TZ} = '';
($Second, $Minute, $Hour, $Day, $Month, $Year, $WeekDay, $DayOfYear,
$IsDST) = localtime(time);
print "$Hour:$Minute - $IsDST\n\n";
$ENV{TZ} = ':/usr/share/zoneinfo/Europe/Rome';
($Second, $Minute, $Hour, $Day, $Month, $Year, $WeekDay, $DayOfYear,
$IsDST) = localtime(time);
print "$Hour:$Minute - $IsDST\n\n";

Francesco ha anche individuato il codice in cui si setta l'orario, però
non sappiamo se ci stiamo muovendo nella giusta direzione.
Ciao,
Alberto

[Openpec-devel] Credo di aver identificato il problema della mancata integrita' :

[Stefano Z. <ste...@ya...>]

Riassunto :

se da un client si manda una mail con attacchment firmata (test a.6) nel
momento in cui il server dell'utente a cui la mail era indirizzata la
rispedisce indietro in allegato al messaggio di avvenuta consegna il
check di integrita' dell' allegato (postacert.eml) fallisce.

non e' come credevo un problema di carriage return (in realta' sbagliavo
io esportando la mail prima di controllare) 

Questo avviene perche' quando openpec "disassembla" il messaggio di
trasporto e lo riassembla un paio di cose non sono come nell'originale
,  gli allegati in base 64 venivano disposti sempre in linee di 60
caratteri anziche' la dimensione originale ,credo che sia una
caratteristica del mime::base64  (oltre ad un newline mancante) e questo
fa' fallire i check del client di posta (dando la schermata nera col 
warning "messaggio alterato in outlook)

noi abbiamo risolto passando in pipe il file ad uno script che sistema
il tutto prima di scriverlo su disco in Sign.pm (un po' grezzo ma
funziona se volete lo posto ) nessun altro  ha riscontrato lo stesso
problema ?


saluti

R: R: [Openpec-devel] problemi di carriage return

[Fanton F. <fa...@ks...>]

> -----Messaggio originale-----
> Da: Stefano Zanarini [mailto:ste...@ya...]
> Inviato: venerd=EC 6 agosto 2004 12.29
> A: ope...@li...
> Oggetto: Re: R: [Openpec-devel] problemi di carriage return
>=20
> Alle 12:14, venerd=EC 6 agosto 2004, Fanton Flavio ha scritto:
> > Con Outlook Express 6 (ver. 6.00.2800.1123) non riesco a ricostruire =
il
> > problema, descrivimi dettagliatamente come devo procedere.
>=20
> - manda un mail da un indirizzo di posta certificata ad un altro =
(anche
> dello
> stesso dominio) usando outlook express,salva quindi una copia della =
mail
> su
> file.
>=20

Per salvare in formato testo una mail da Outlook Express faccio:
File->propriet=E0-> scelgo "Dettagli" -> clicco su "Messaggio =
originale..." -> seleziono tutto il test con CTRL-A -> lo copio su =
notepad -> salvo su file

Non conosco una modo migliore per ottenere il sorgente della mail.

Faccio lo stesso con l'allegato postacert.eml della ricevuta di =
consegna.

Di seguito i due file

+++++++++++++++++ MAIL ORIGINALE ++++++++++++++++++++++++++++++++++++++
From: "flazan opec3" <fl...@op...>
To: <bat...@de...>
Subject: caio
Date: Fri, 6 Aug 2004 12:31:58 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary=3D"----=3D_NextPart_000_002C_01C47BB1.5DAEA150"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441

This is a multi-part message in MIME format.

------=3D_NextPart_000_002C_01C47BB1.5DAEA150
Content-Type: text/plain;
	charset=3D"iso-8859-1"
Content-Transfer-Encoding: quoted-printable

flavio =3DE8
un parrucchiere
------=3D_NextPart_000_002C_01C47BB1.5DAEA150
Content-Type: text/html;
	charset=3D"iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3D3DContent-Type content=3D3D"text/html; =3D
charset=3D3Diso-8859-1">
<META content=3D3D"MSHTML 6.00.2800.1458" name=3D3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D3D#ffffff>
<DIV><FONT face=3D3DArial size=3D3D2>flavio =3DE8</FONT></DIV>
<DIV><FONT face=3D3DArial size=3D3D2>un =3D
parrucchiere</FONT></DIV></BODY></HTML>

------=3D_NextPart_000_002C_01C47BB1.5DAEA150--

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=


+++++++++++++++++ MAIL ORIGINALE DA RIC. CONS =
+++++++++++++++++++++++++++
Received: from Fanton (unknown [194.153.173.101])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by postacert.openpec.it (Postfix) with ESMTP id F234AB144
	for <bat...@de...>; Fri,  6 Aug 2004 12:30:58 +0200 =
(CEST)
Message-ID: <002f01c47ba0$9a7e78a0$65a...@ks...>
From: "flazan opec3" <fl...@op...>
To: <bat...@de...>
Subject: caio
Date: Fri, 6 Aug 2004 12:31:58 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary=3D"----=3D_NextPart_000_002C_01C47BB1.5DAEA150"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441

This is a multi-part message in MIME format.

------=3D_NextPart_000_002C_01C47BB1.5DAEA150
Content-Type: text/plain;
	charset=3D"iso-8859-1"
Content-Transfer-Encoding: quoted-printable

flavio =3DE8
un parrucchiere
------=3D_NextPart_000_002C_01C47BB1.5DAEA150
Content-Type: text/html;
	charset=3D"iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3D3DContent-Type content=3D3D"text/html; =
charset=3D3Diso-8859-1">
<META content=3D3D"MSHTML 6.00.2800.1458" name=3D3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D3D#ffffff>
<DIV><FONT face=3D3DArial size=3D3D2>flavio =3DE8</FONT></DIV>
<DIV><FONT face=3D3DArial size=3D3D2>un =
parrucchiere</FONT></DIV></BODY></HTML>

------=3D_NextPart_000_002C_01C47BB1.5DAEA150--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
+

Le modifiche presenti (due "=3D<cr-lf>") sono nella parte text/html e =
potrebbero essere state aggiunte o dagli MTA o dai MUA in fase di =
transazione o da OpenPEC in fase di estrazione del msg originale dal msg =
di trasporto e assemblaggio della ric. avv. consegna.

Voglio capire se OpenPEC ha originato il problema quindi:
. mi posiziono sulla dir temporanea dell'installazione di OpenPEC di =
destinazione (per capire quella che ha ricevuto il documento di =
trasporto)
. se NON sono arrivati altri messaggi, la dir + recente =E8 quella che =
contiene il doc. di trasp. che mi interessa.
. entra e guarda il file email.txt: contiene la mail ricevuta del MTA =
lasciata inalterata.
. nel mio caso il file =E8 identico a "MAIL ORIGINALE DA RIC. CONS"

Questo significa che OpenPEC non =E8 responsabile delle differenze ma il =
problema =E8 da trovare prima dell'arrivo del doc. di trasp a OpenPEC.

- flazan

> - quando arriva la ricevuta di avvenuta consegna estrapola la mail
> originale
> che e' in allegato e salvala su un altro file
>=20
> apri entrambi i files con vi dando un :
> " :set list"
> senza apici ovviamente.
>=20
> i carriage return a me appaiono differenti.
>=20
> (i ^M convertiti in $ )
>=20
>=20
> saluti
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes =
on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source =
Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Openpec-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openpec-devel

Re: R: [Openpec-devel] problemi di carriage return

[Stefano Z. <ste...@ya...>]

Alle 12:14, venerd=EC 6 agosto 2004, Fanton Flavio ha scritto:
> Con Outlook Express 6 (ver. 6.00.2800.1123) non riesco a ricostruire il
> problema, descrivimi dettagliatamente come devo procedere.

=2D manda un mail da un indirizzo di posta certificata ad un altro (anche d=
ello=20
stesso dominio) usando outlook express,salva quindi una copia della mail su=
=20
file.

=2D quando arriva la ricevuta di avvenuta consegna estrapola la mail origin=
ale=20
che e' in allegato e salvala su un altro file=20

apri entrambi i files con vi dando un :
" :set list"
senza apici ovviamente.

i carriage return a me appaiono differenti.

(i ^M convertiti in $ )


saluti

R: [Openpec-devel] problemi di carriage return

[Fanton F. <fa...@ks...>]

Con Outlook Express 6 (ver. 6.00.2800.1123) non riesco a ricostruire il =
problema, descrivimi dettagliatamente come devo procedere.

- flazan

> -----Messaggio originale-----
> Da: Stefano Zanarini [mailto:ste...@ya...]
> Inviato: venerd=EC 6 agosto 2004 11.46
> A: ope...@li...
> Oggetto: [Openpec-devel] problemi di carriage return
>=20
> Ho un problema di questo tipo :
>=20
> se mando una mail da un client sotto windows non ho problemi e viene
> processata correttamente da openpec,l'unico problema e' nella ricevuta =
di
> avvenuta consegna,che ha come allegato il messaggio originale.
> Il problema sembra proprio essere nel messaggio originale =
allegato,sembra
> che
> vengano sostituiti i carriage return dos in unix ed eventuali check di
> integrita' da parte dei client di posta falliscono (con relativi =
warning
> "il
> messaggio e' stato modificato"
> Visto che il messaggio arriva correttamente al destinatario (con i
> carriage
> corretti) credo che il problema sia dei Mime tools,ma non riesco a =
capire
> dove ....
>=20
> idee ?
>=20
>=20
>=20
> saluti
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes =
on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source =
Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Openpec-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openpec-devel

[Openpec-devel] Re: Bug nell' allegato xml ?

[Stefano Z. <ste...@ya...>]

Alle 19:40, gioved=EC 5 agosto 2004, hai scritto:

> Il codice originale va bene anche se potremmo fare meglio;
> mi spiego:
>
> Dal DTD (allegato tecnico par. 7.4):
> ...
> <!--Dati del messaggio di posta certificata-->
> <!ELEMENT dati (gestore-emittente,
> data,
> identificativo,
> consegna?,
> ricezione*,
> errore-esteso?)>
> ...
>
> Significa che il tag <dati> DEVE contenere
> gestore-emittente,
> data,
> identificativo,
> mentre PUO' contenere consegna, errore-esteso (? Sta per 0 o 1)
> e ricezione 0 o + volte.
>
> Quindi potremo eventualmente decidere di aggiungere il tag in un secondo
> momento.

in fase di test  [1]  mi e' stato segnalato come errore ,infatti e' stata u=
na=20
aggiunta fatta al volo,ho controllato velocemente l'allegato tecnico ,non h=
o=20
guardato a fondo ...  mi sono fidato del giudizio dei certificatori.

> Il ciclo che hai aggiunto POTREBBE andare bene visto che fortunatamente
> ogni ricevuta di consegna ha un solo destinatario, in caso contrario l'xml
> violerebbe il dtd; cmq mi pare sprecato.

se il campo non e' obbligatorio  credo non si ponga neanche il problema :-)


saluti

[Openpec-devel] problemi di carriage return

[Stefano Z. <ste...@ya...>]

Ho un problema di questo tipo :

se mando una mail da un client sotto windows non ho problemi e viene 
processata correttamente da openpec,l'unico problema e' nella ricevuta di 
avvenuta consegna,che ha come allegato il messaggio originale.
Il problema sembra proprio essere nel messaggio originale allegato,sembra che 
vengano sostituiti i carriage return dos in unix ed eventuali check di 
integrita' da parte dei client di posta falliscono (con relativi warning "il 
messaggio e' stato modificato"
Visto che il messaggio arriva correttamente al destinatario (con i carriage 
corretti) credo che il problema sia dei Mime tools,ma non riesco a capire 
dove .... 

idee ?



saluti

R: [Openpec-devel] I: Bug nell' allegato xml ?

[Fanton F. <fa...@ks...>]

> -----Messaggio originale-----
> Da: Fanton Flavio
> Inviato: gioved=EC 5 agosto 2004 19.18
> A: ope...@li...
> Oggetto: [Openpec-devel] I: Bug nell' allegato xml ?
>=20
>=20
>=20
> -----Messaggio originale-----
> Da: Stefano Zanarini [mailto:ste...@ya...]
> Inviato: mercoled=EC 4 agosto 2004 14.57
> A: Fanton Flavio
> Oggetto: Bug nell' allegato xml ?
>=20
> Nell'allegato tecnico leggo
> ""per le ricevute di consegna e di errore di consegna destinatario a =
cui
> e'
> stata effettuata/tentata la consegna"
>=20
> come descrizione del  tag <consegna> nell'xml,sembra che openpec non =
lo
> faccia ,non ho testato la 1.0 che avete appena rilasciato ma il codice =
non
> sembra cambiato.
> In Xml.pm c'e' :
>=20
> "_openCertInfo ($OPEC_CERTINFO_TYPE_DELIVERY);
>         _openIntestazione();
>         _setMittente ($objMsgOrig->sender->mailAddress);
>         foreach my $obj (@{$objMsgOrig->recips}){
>             _setDestinatario ($obj->mailAddress,$obj->certificate)}
>         _setOggetto ( unmime myChomp(
>             $objMsgOrig->header->get('Subject')));
>         _closeIntestazione();
>         _openDati();
>         _setGestoreEmittente ($adminName);
>         _openData ($timezone);
>         _setGiorno (actualDate());
>         _setOra (actualTime());
>         _closeData();
>         _setIdentificativo (myChomp(
>             $objMsgOrig->header->get('Message-ID')));
>         _closeDati();
>         _closeCertInfo();
>         $certInfoXml;"
>=20
>=20
> io ho aggiunto un  :
>=20
> foreach my $obj (@{$objMsgOrig->recips}){
>             _setConsegna ($obj->mailAddress,$obj->certificate) if
> $obj->certificate;
>        }
>=20
> prima della _closeData() e sembra funzionare.
>=20
> ciao
>=20
>=20

Il codice originale va bene anche se potremmo fare meglio;
mi spiego:

Dal DTD (allegato tecnico par. 7.4):
...
<!--Dati del messaggio di posta certificata-->
<!ELEMENT dati (gestore-emittente,
data,
identificativo,
consegna?,
ricezione*,
errore-esteso?)>
...

Significa che il tag <dati> DEVE contenere=20
gestore-emittente,
data,
identificativo,
mentre PUO' contenere consegna, errore-esteso (? Sta per 0 o 1)
e ricezione 0 o + volte.

Quindi potremo eventualmente decidere di aggiungere il tag in un secondo =
momento.

Il ciclo che hai aggiunto POTREBBE andare bene visto che fortunatamente =
ogni ricevuta di consegna ha un solo destinatario, in caso contrario =
l'xml violerebbe il dtd; cmq mi pare sprecato.

- flazan

>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes =
on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source =
Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Openpec-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openpec-devel

[Openpec-devel] I: Bug nell' allegato xml ?

[Fanton F. <fa...@ks...>]

-----Messaggio originale-----
Da: Stefano Zanarini [mailto:ste...@ya...]=20
Inviato: mercoled=EC 4 agosto 2004 14.57
A: Fanton Flavio
Oggetto: Bug nell' allegato xml ?

Nell'allegato tecnico leggo=20
""per le ricevute di consegna e di errore di consegna destinatario a cui =
e'=20
stata effettuata/tentata la consegna"

come descrizione del  tag <consegna> nell'xml,sembra che openpec non lo=20
faccia ,non ho testato la 1.0 che avete appena rilasciato ma il codice =
non=20
sembra cambiato.
In Xml.pm c'e' :

"_openCertInfo ($OPEC_CERTINFO_TYPE_DELIVERY);
        _openIntestazione();
        _setMittente ($objMsgOrig->sender->mailAddress);
        foreach my $obj (@{$objMsgOrig->recips}){
            _setDestinatario ($obj->mailAddress,$obj->certificate)}
        _setOggetto ( unmime myChomp(
            $objMsgOrig->header->get('Subject')));
        _closeIntestazione();
        _openDati();
        _setGestoreEmittente ($adminName);
        _openData ($timezone);
        _setGiorno (actualDate());
        _setOra (actualTime());
        _closeData();
        _setIdentificativo (myChomp(
            $objMsgOrig->header->get('Message-ID')));
        _closeDati();
        _closeCertInfo();
        $certInfoXml;"


io ho aggiunto un  :

foreach my $obj (@{$objMsgOrig->recips}){
            _setConsegna ($obj->mailAddress,$obj->certificate) if=20
$obj->certificate;
       }

prima della _closeData() e sembra funzionare.

ciao

Re: [Openpec-devel] =?iso-8859-1?Q?Termina?= =?iso-8859-1?Q?ta_la_seconda_sessione_dei_test_di_interoperabilit=E0?=

[<and...@ne...>]

On Thu, Jul 22, 2004 at 05:00:52PM +0200, Ferrara Umberto wrote:
> Salve a tutti
> =E8 terminata la seconda sessione dei test di interoperabilit=E0.=20
> Purtroppo non siamo riusciti a chiudere il discorso certifica per colpa=
 di UN SOLO TEST!!!

Locale della macchina ?=20

a.

[Openpec-devel] =?iso-8859-1?Q?Terminata_la_seconda_sessione_dei_test_di_interoperabili?= =?iso-8859-1?Q?t=E0?=

[Ferrara U. <fe...@ks...>]

Salve a tutti
=E8 terminata la seconda sessione dei test di interoperabilit=E0.=20
Purtroppo non siamo riusciti a chiudere il discorso certifica per colpa =
di UN SOLO TEST!!!

Vi spiego il problema in modo che tutti insieme possiamo cercare di =
sciogliere il nodo il=20
prima possibile.

Il test che =E8 fallito =E8 il test M.1 che prevede l'invio di una mail=20
	from: user1@domaincert1
	to: user2@domaincert2 =20
	con subject: Test M =
=EC=E8+=F2=E0=F9-<^=E8*=E7=B0=A7_>!"=A3$%&/()=3D?~'#
	e body: Test

Il problema si ha nella verifica della firma da parte di openssl.=20
Questo l'errore che si ottiene lanciando il comando manualmente:
	Verification failure
	23001:error:21071065:PKCS7 routines:PKCS7_signatureVerify:digest =
failure:pk7_doit.c:804:
	23001:error:21075069:PKCS7 routines:PKCS7_verify:signature =
failure:pk7_smime.c:265:

NOTARE BENE
----------------
1) il problema si presenta solo nelle mail inviate da certmail.rupa.it =
(ente certificatore) verso il ns dominio
e non viceversa dal ns dominio verso il loro

2) il problema non si presenta tra diverse installazioni di openpec

3) il problema non si presenta nel caso in cui i caratteri speciali =
siano nel body e non nel subject

4) la mail originale inglobata nell'anomalia di trasporto sembra =
corretta (in particolare il subject)

5) la stessa mail, inviata ad utenti esterni al dominio certificato, =
risulta corretta e correttamente verificata

6) tutti gli altri test hanno funzionato per cui il problema sembra =
legato proprio ai caratteri speciali

Inizialmente pensavamo che il problema fosse dovuto all'interferenza del =
postfix ma facendo un p=F2 di test
abbiamo escluso questa possibilit=E0.

In questo momento stiamo indagando sulla fase di salvataggio  della mail =
sul file system...

Il problema + grosso =E8 che non riusciamo a replicare il =
malfunzionamento e dobbiamo aspettare che gli=20
incaricati della certificazione ci inviino i msg di test

Idee?  Suggerimenti?

grazie a tutti

          umb

[Openpec-devel] OpenPEC inizia il persorso di Certificazione

[Ferrara U. <fe...@ks...>]

Salve a tutti,=20
visto che la data di rilascio delle nuove linee guida di si sta =
allontanando, abbiamo deciso=20
di intraprendere il cammino verso la certificazione di OpenPEC con le =
attuali norme.

Abbiamo preso contatti con il CNIPA ed a partire dagli ultimi giorni =
della settimana corrente
inizieremo le verifiche di interoperabilit=E0.=20

Visto che abbiamo rilasciato la versione 1.0 RC2 contenente cambiamenti =
di rilievo, vi chiediamo=20
un ultimo (per ora ;-) ) sforzo .....
Ci sarebbe di grande aiuto se tutti voi poteste scaricarvi la nuova =
versione, rieseguire i test=20
e segnalarci (con la solita precisione) gli eventuali bug.

Grazie a tutti i volenterosi ....

          Umberto

[Openpec-devel] Elenco degli utilizzatori di OpenPEC

[Luca De S. <des...@ks...>]

Ciao a tutti
vorremmo segnalare sul sito di www.openpec.org tutti coloro che in questi
mesi hanno installato OpenPEC e pensano di utilizzarlo in produzione.

Vorremmo fare una sezione degli "Utilizzatori" dando particolare enfasi agl=
i
"early adoppters", a tutti coloro cio=E8 che stanno seguendo OpenPEC gi=E0 da
queste fasi in cui la versione 1.0 del prodotto non =E8 ancora stata
ufficialmente rilasciata (per inciso: se le linee guida del CNIPA escono
presto, come si spera, non dovrebbe mancare molto al rilascio della 1.0
certificata).

Se volete essere citati in questa parte del sito vi invitiamo a segnalarci
all'indirizzo in...@op... i seguenti dati:
- informazioni sulla vostra azienda o, nel caso di singoli sviluppatori, su
di voi (denominazione, indirizzo, citt=E0, email e sito web)
- periodo indicativo di inizio di uso di OpenPEC (es. maggio 2004)
- come pensate di utilizzare OpenPEC

Vi ringraziamo per la collaborazione!

Buona giornata a tutti
Dex
--=20
Luca De Santis
Ksolutions spa, Gruppo KATAWEB
via Lenin 132/26
56017 S. Martino Ulmiano (PI) - ITALY
tel.: +39 050 898 563 (direct)
mobile: +39 335 7376 153
fax.: +39 050 861 200
email: des...@ks...
web: http://www.ksolutions.it

[Openpec-devel] Cerificati inerenti la PEC

[Fanton F. <fa...@ks...>]

Vorrei chiarire la questione dei certificati inerenti una infrastruttura =
completa di PEC.

Occorrono 2 tipologie di certificati:
. uno o piu' certificati per le connessioni TLS (IMAPS, POPS, SMTPS e =
HTTPS)
. un certificato tipo x509 (S/MIME) per ogni dominio di PEC

Per le connessioni TLS e' sufficiente un certificato a 40bit per la =
crittografia (quelli comunemente usati per l'e-commerce).

Per firmare le mail occorre un certificato x509, generalmente usato dai =
singoli utenti per firmare le mail in uscita (Certificati Digitali per =
persone).

FAQ
Q. In questo caso il certificato x509 non fa riferimento ad un individuo =
ma ad un server quindi ci sono implicazioni?
A. No, quello che serve e' un certificato x509 di classe 1 (in cui viene =
verificata solo l'esistenza dell'indirizzo email che da Allegato Tecnico =
e' posta-certificata@<dominio-pec>): nella sottoscrizione del contratto =
al posto dell'individuo verra' indicato chi fornisce il servizio di PEC =
(un'azienda per esempio).

Q. Richiedendo un solo certificato per le connessioni TLS siamo =
costretti a implementare tutti i servizi su un'unica macchina?
A. In generale, per le architetture bilanciate, si utilizza un solo =
certificato relativo al host+dominio del bilanciatore copiato su tutte =
le macchine bilanciate; dal punto di vista legale =E8 necessario =
l'acquisto di un certificato ed un numero di licenze pari al numero =
delle macchine bilanciate.
Per HTTPS =E8 necessario che sui webserver delle macchine bilanciate =
siano configurati dei virualhost in modo che al browser del client =
arrivi sempre lo stesso host+dominio.
Per SMTPS-IMAPS-POPS =E8 sufficiente che host+dominio del certificato =
sia lo stesso di quello impostato sul MUA quindi nessun problema di =
alias qualunque sia la macchina su cui =E8 installato il certificato.

Saluti, flazan

RIF: [Openpec-devel] Ridondanza dei messaggi

[Marcheselli E. <mar...@ks...>]

L'ID della macchina serve solo per essere sicuri di generare ID di =
messaggio unici.
Se basi l'ID solo sul timestamp, con macchine sincronizzate via NTP =
pu=F2 succedere che due messaggi arrivati lo stesso momento abbiano lo =
stesso ID, quindi si genera casino. Un campo aggiuntivo serve per =
identificare univocamente il messaggio quando si va alla ricerca del suo =
stato di elaborazione (se c'=E8).=20

Spero di aver chiarito.

Emilio


-----Messaggio originale-----
Da:	Fanton Flavio
Inviato:	mer 16.06.2004 09:17
A:	ope...@li...
Cc:=09
Oggetto:	R: [Openpec-devel] Ridondanza dei messaggi

Direi che aggiungere l'ID della macchina e' un errore.

In architetture ridondate non sappiamo a priori a quale OpenPec l'MTA =
girera' la mail; magari la prima volta andra' all'instanza n e la =
seconda all'instanza m quindi entrambe dovranno poter generare lo stesso =
ID partendo dal contenuto della mail.=20

Potremo aggiungere il nome della macchina magari a titolo informativo =
(per eventuali monitor) ma in posizione ben definita in modo da non =
stravolgere quanto detto.


-----Messaggio originale-----
Da: Fanton Flavio=20
Inviato: marted=EC 15 giugno 2004 18.12
A: ope...@li...
Oggetto: R: [Openpec-devel] Ridondanza dei messaggi

In fondo credo anche io che la soluzione di un file per mail sia la =
soluzione + pulita; inoltre pensavo di mappare lo stato della mail =
direttamente nel nome del file in modo da ridurre le operazioni di IO.

Con i file non esistono problemi di concorrenza o latenze varie in piu' =
risulta semplice fare uno script che monitora le mail da rielaborare e =
la fase in cui =E8 stato generato l'errore.

Per l'ID in ambienti ridondati credo basti semplicemente aggiungere un =
ID della macchina in fase di configurazione: 1 per il server 1 e 2 per =
il secondo server, il timestamp fa il resto.

-----Messaggio originale-----
Da: Marcheselli Emilio =
[mailto:ope...@li...] Per conto di =
Marcheselli Emilio
Inviato: marted=EC 15 giugno 2004 18.00
A: ope...@li...
Oggetto: RIF: [Openpec-devel] Ridondanza dei messaggi

L'ID generato dal timestamp+l'id della macchina =E8 una buona soluzione. =
L''id della macchina =E8 un codice univoco generato in fase di =
installazione del sw ed =E8 necessario in architetture ridondate per =
evitare di generare ID uguali.

Va comunque memorizzato lo stato associato alla mail. Se non =E8 =
possibile aggiungere questa informazione alla mail stessa (modificando =
l'header) possiamo pensare di usare un file su una directory condivisa o =
una db o l'LDAP. Io sono per la prima ipotesi che =E8 molto semplice da =
implementare e non richiede grosse risorse. Come soluzione pi=F9 pulita =
userei l'LDAP che =E8 una componente esterna che va comunque gestita. =
Scarterei l'ipotesi di un DB.

Emilio




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Openpec-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openpec-devel



-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Openpec-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openpec-devel

R: [Openpec-devel] Ridondanza dei messaggi

[Fanton F. <fa...@ks...>]

Direi che aggiungere l'ID della macchina e' un errore.

In architetture ridondate non sappiamo a priori a quale OpenPec l'MTA =
girera' la mail; magari la prima volta andra' all'instanza n e la =
seconda all'instanza m quindi entrambe dovranno poter generare lo stesso =
ID partendo dal contenuto della mail.=20

Potremo aggiungere il nome della macchina magari a titolo informativo =
(per eventuali monitor) ma in posizione ben definita in modo da non =
stravolgere quanto detto.


-----Messaggio originale-----
Da: Fanton Flavio=20
Inviato: marted=EC 15 giugno 2004 18.12
A: ope...@li...
Oggetto: R: [Openpec-devel] Ridondanza dei messaggi

In fondo credo anche io che la soluzione di un file per mail sia la =
soluzione + pulita; inoltre pensavo di mappare lo stato della mail =
direttamente nel nome del file in modo da ridurre le operazioni di IO.

Con i file non esistono problemi di concorrenza o latenze varie in piu' =
risulta semplice fare uno script che monitora le mail da rielaborare e =
la fase in cui =E8 stato generato l'errore.

Per l'ID in ambienti ridondati credo basti semplicemente aggiungere un =
ID della macchina in fase di configurazione: 1 per il server 1 e 2 per =
il secondo server, il timestamp fa il resto.

-----Messaggio originale-----
Da: Marcheselli Emilio =
[mailto:ope...@li...] Per conto di =
Marcheselli Emilio
Inviato: marted=EC 15 giugno 2004 18.00
A: ope...@li...
Oggetto: RIF: [Openpec-devel] Ridondanza dei messaggi

L'ID generato dal timestamp+l'id della macchina =E8 una buona soluzione. =
L''id della macchina =E8 un codice univoco generato in fase di =
installazione del sw ed =E8 necessario in architetture ridondate per =
evitare di generare ID uguali.

Va comunque memorizzato lo stato associato alla mail. Se non =E8 =
possibile aggiungere questa informazione alla mail stessa (modificando =
l'header) possiamo pensare di usare un file su una directory condivisa o =
una db o l'LDAP. Io sono per la prima ipotesi che =E8 molto semplice da =
implementare e non richiede grosse risorse. Come soluzione pi=F9 pulita =
userei l'LDAP che =E8 una componente esterna che va comunque gestita. =
Scarterei l'ipotesi di un DB.

Emilio




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Openpec-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openpec-devel

R: [Openpec-devel] Ridondanza dei messaggi

[Fanton F. <fa...@ks...>]

In fondo credo anche io che la soluzione di un file per mail sia la =
soluzione + pulita; inoltre pensavo di mappare lo stato della mail =
direttamente nel nome del file in modo da ridurre le operazioni di IO.

Con i file non esistono problemi di concorrenza o latenze varie in piu' =
risulta semplice fare uno script che monitora le mail da rielaborare e =
la fase in cui =E8 stato generato l'errore.

Per l'ID in ambienti ridondati credo basti semplicemente aggiungere un =
ID della macchina in fase di configurazione: 1 per il server 1 e 2 per =
il secondo server, il timestamp fa il resto.

-----Messaggio originale-----
Da: Marcheselli Emilio =
[mailto:ope...@li...] Per conto di =
Marcheselli Emilio
Inviato: marted=EC 15 giugno 2004 18.00
A: ope...@li...
Oggetto: RIF: [Openpec-devel] Ridondanza dei messaggi

L'ID generato dal timestamp+l'id della macchina =E8 una buona soluzione. =
L''id della macchina =E8 un codice univoco generato in fase di =
installazione del sw ed =E8 necessario in architetture ridondate per =
evitare di generare ID uguali.

Va comunque memorizzato lo stato associato alla mail. Se non =E8 =
possibile aggiungere questa informazione alla mail stessa (modificando =
l'header) possiamo pensare di usare un file su una directory condivisa o =
una db o l'LDAP. Io sono per la prima ipotesi che =E8 molto semplice da =
implementare e non richiede grosse risorse. Come soluzione pi=F9 pulita =
userei l'LDAP che =E8 una componente esterna che va comunque gestita. =
Scarterei l'ipotesi di un DB.

Emilio

RIF: [Openpec-devel] Ridondanza dei messaggi

[Marcheselli E. <mar...@ks...>]

L'ID generato dal timestamp+l'id della macchina =E8 una buona soluzione. =
L''id della macchina =E8 un codice univoco generato in fase di =
installazione del sw ed =E8 necessario in architetture ridondate per =
evitare di generare ID uguali.

Va comunque memorizzato lo stato associato alla mail. Se non =E8 =
possibile aggiungere questa informazione alla mail stessa (modificando =
l'header) possiamo pensare di usare un file su una directory condivisa o =
una db o l'LDAP. Io sono per la prima ipotesi che =E8 molto semplice da =
implementare e non richiede grosse risorse. Come soluzione pi=F9 pulita =
userei l'LDAP che =E8 una componente esterna che va comunque gestita. =
Scarterei l'ipotesi di un DB.

Emilio


-----Messaggio originale-----
Da:	Fanton Flavio
Inviato:	mar 15.06.2004 16:03
A:	ope...@li...
Cc:=09
Oggetto:	R: [Openpec-devel] Ridondanza dei messaggi

Possibili soluzioni
Per mantenere la mail in coda ed effettuare nuovi tentativi in caso di =
errore dobbiamo tenere traccia delle fasi che la mail supera con =
successo.
Cio' implica:
1. aggiungere ad OpenPec una coda
2. associare ad ogni mail un identificativo che ci permetta di tracciare =
le=20
fasi dell'elaborazione per non replicarle in caso di insuccesso
  =20
La prima ipotesi implica ripensare l'architettura di base ed aggiungere =
un=20
processo che sovrintende all'amministrazione della coda: OpenPec =
comincerebbe ad assomigliare sempre piu' ad un MTA vero e proprio ed =
avrebbe un overhead da considerare.

La seconda ipotesi non e' cosi' banale: trovare un ID che mi permetta di =

identificare la mail in maniera univoca e di riconoscerla quando l'MTA =
la=20
ripropone.

Consideriamo che la mail arriva ad OpenPec tramite, per adesso, =
transazione=20
SMTP quindi, per costruirci l'ID, non abbiamo altre informazioni che =
quelle=20
contenute nella mail stessa.
Ricordiamoci che non possiamo basarci su "Message-ID" visto che non e' =
reso=20
obbligatorio da nessun RFC e se viene aggiunto dal MUA, l'MTA non lo =
tocca.
Lo stesso riguarda il campo "Date".

Una soluzione potrebbe essere far aggiungere un header fittizio dal MTA =
ma=20
per alcuni di loro potrebbe implicare un costo: per Sendmail credo basti =

smanettare un po' con sendmail.cf mentre per Postfix dobbiamo usare un=20
programma esterno (con content_filter).

Il problema pero' e' limitato solo alle mail provenienti dal MUA =
(direttamente dal mittente) ossia al punto di accesso mentre per i =
rimanenti casi avremmo a che fare con documenti di trasporto che, da =
specifiche, hanno l'header "Message-ID" garantito univoco sul dominio.

Tutto sommato sembra che la seconda soluzione sia la migliore:
. l'MTA dovra' aggiungere a tutte le mail provenienti dal canale sicuro =
un header fittizio (andrebbe bene un timestamp)
. OpenPec si crea un ID dal haeder e lo utilizza per ricordarsi i passi =
compiuti dalla mail

-----Messaggio originale-----
Da: Fanton Flavio=20
Inviato: marted=EC 15 giugno 2004 16.01
A: ope...@li...
Oggetto: R: [Openpec-devel] Ridondanza dei messaggi

Una semplice soluzione al problema e' restituire al MTA un codice =
d'errore di tipo 5 che manifesta il verificarsi di un problema non =
risolvibile con la=20
conseguenza di eliminare la mail dalla coda.

Facciamo pero' un'ulteriore considerazione:
un sistema di posta certificata e' un sistema a valore legale che =
garantisce=20
il mittente dall'inalterabilita' del messaggio e lo tutela nei confronti =
della consegna dello stesso: il sistema deve essere affidabile.

Affidabilita' significa anche operare il massimo sforzo affinch=E8 la =
mail=20
raggiunga il destinatario.

-----Messaggio originale-----
Da: Fanton Flavio=20
Inviato: marted=EC 15 giugno 2004 16.00
A: ope...@li...
Oggetto: [Openpec-devel] Ridondanza dei messaggi

Salve,

vorrei esporre un problema che =E8 venuto fuori durante l'analisi=20
dell'architettura di OpenPec: la possibile ridondanza dei messaggi.

Il punto della situazione:
l'MTA inoltra a OpenPec le mail che arrivano in ingresso;
OpenPec riceve la mail e tiene aperta la connessione con l'MTA fino a =
che non=20
ha terminato l'elaborazione.

Le situazioni a cui ci possiamo trovare davanti possono essere cosi'=20
sintetizzate:

1. punto di accesso
   . emissione ricevuta di accettazione (sempre locale)
   . generazione doc. di trasp.
   . delivery doc. di trasp.

2. punto di ricezione
   . emissione (eventuale) ricevuta di presa in carico (sempre remota)
   . emissione (eventuale) anomalia di trasp.

3. punto di consegna
   . consegna doc. di trasp. (sempre locale)
   . emissione ricevuta di avv. cons.

Il problema
Supponiamo che (punto 1) la ric. di acc. venga emessa correttamente e si =
verifichi=20
un errore nella generazione o nel delivery del doc. di trasp.;=20
se restituiamo al MTA un errore di tipo 4 la mail viene mantenuta in =
coda e=20
ripresentata successivamente provocando una nuova emissione della =
ricevuta fino a=20
problema concluso: il risultato finale e' che il mittente si ritrovera' =
un numero di=20
ricevute di acc. pari al numero dei problemi + 1.
A parte la confusione del mittente ricordiamo che ogni ricevuta ha =
valore legale.

Lo stesso problema si presenta nel punto di ricezione e consegna: =
soprattutto in=20
quest'ultimo potrebbe ingenerarsi una ben piu' grave emissione anomala =
di=20
documenti di trasporto identici non coerenti con le ric. di avv. cons..

Ricordiamo inoltre che OpenPec non scinde "fisicamente" i tre punti =
summenzionati per=20
ottimizzare le prestazioni:=20
per mail locali->locali i punti 1 e 3 utilizzano la stessa connessione =
con MTA,
lo stesso per mail remote->locali (punto 2 e 3).
Questo significa che se il problema si verifica nell'ultima fase tutte =
quelle precedenti=20
vengono nuovamente eseguite non appena l'MTA ripropone la mail.

flazan




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Openpec-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openpec-devel




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Openpec-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openpec-devel




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Openpec-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openpec-devel