R: [Openpec-devel] Ridondanza dei messaggi

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

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