09/06/04 - Messaggi malformati e blocco dei client - 1

Novità , comunicazioni e FAQ

09/06/04 - Messaggi malformati e blocco dei client - 1

Postby IceWarp » Fri 15 Oct, 2004 16:37

Messaggi malformati e conseguente blocco degli antivirus lato client

Da qualche tempo riceviamo richieste di assistenza riguardo messaggi che bloccano lo scaricamento della posta da parte degli utenti.
Nonostante i nostri ripetuti interventi tramite l'e-mail di supporto e nel forum di discussione (http://forum.icewarp.it/viewtopic.php?t=122), sull'argomento regna ancora parecchia confusione.
Cercheremo adesso di chiarire la questione definitivamente...

A differenza di altri casi del passato, questa volta non è il client di posta elettronica ad andare in blocco, ma l'antivirus impiegato dall'utente sulla propria macchina, che effettua anche il controllo della posta in ingresso e in uscita.
Per correttezza e per evitare polemiche, in questa sede non menzioniamo i software che soffrono di questo grave malfunzionamento, ma si tratta di prodotti rinomati e molto diffusi.
Questo tipo di antivirus monitora costantemente il traffico in arrivo sulla porta 110 (POP3) e in uscita sulla porta 25 (SMTP) del client, in modo da intercettare eventuali messaggi infetti.
Sfortunatamente alcune malformazioni dei messaggi, come ad esempio la totale mancanza dell'header obbligatorio From: o la formattazione errata dell'header Message-ID:, possono provocare il blocco dell'antivirus, che probabilmente si aspetta dei messaggi perfettamente conformi allo standard e non è in grado di gestire situazioni anomale.

Poiché questo tipo di protezione antivirus è trasparente rispetto alle normali attività di invio e ricezione, agli occhi dell'utente ignaro il malfunzionamento sembra essere dovuto al client di posta elettronica o, più spesso, al mail server. Le lamentele vengono quindi indirizzate all'amministratore del sistema o all'ISP di competenza, che inevitabilmente si rivolge al nostro supporto tecnico.
Purtroppo (o per fortuna, a seconda dei punti di vista) Merak non ha nessuna responsabilità per questo genere di malfunzionamento.

Il software osserva scrupolosamente le norme tecniche RFC che, tra le altre, cose, stabiliscono quanto segue:

    RFC2821, SMTP - Simple Mail Transfer Protocol, (http://www.faqs.org/rfcs/rfc2821.html)
    Cap. 2.4: "... In general, a relay SMTP SHOULD assume that the message content it has received is valid and, assuming that the envelope permits doing so, relay it without inspecting that content."
    Cap. 3.7: "... As discussed in section 2.4.1, a relay SMTP has no need to inspect or act upon the headers or body of the message data and MUST NOT do so..."
Quindi il server SMTP non è responsabile per la correttezza formale e sintattica di un messaggio.
Esso ha solo l'obbligo di verificare la conformità della parte transazionale, tecnicamente l'envelope (la "busta" del messaggio).

Spesso utilizziamo il paragone tra la posta elettronica e il sistema postale tradizionale, che anche in questo caso è piuttosto calzante: il personale dell'ufficio postale non è autorizzato (salvo poche eccezioni) ad ispezionare la corrispondenza privata. Tra l'altro è un reato previsto dal Codice Penale, Art. 616.
Allo stesso modo, il comportamento predefinito di Merak è quello di accettare il messaggio, qualunque cosa esso contenga. Comprese le malformazioni, purtroppo!
Sarebbe come se il postino aprisse le vostre lettere e correggesse eventuali errori di sintassi o di grammatica prima di consegnarle al destinatario.

Pur avvenendo in buona fede e a vantaggio degli utenti, teoricamente qualsiasi modifica, alterazione o correzione del contenuto dei messaggi di posta elettronica non sarebbe consentita.
Questo è uno dei motivi per cui siamo sempre molto restii a fornire indicazioni su come attivare dei filtri in Merak in modo da rilevare e soprattutto per correggere particolari difetti.

Tornando al problema del blocco dell'antivirus, dopo alcune analisi dei messaggi incriminati, siamo giunti alla conclusione che le malformazioni che provocano il malfunzionamento sono essenzialmente due:

    1. Manca completamente l'header From: del messaggio, che tra parentesi è l'unico obbligatorio, insieme al Date:, secondo lo standard RFC2822.
    Come già detto, però, il mail server non è tenuto a verificarne l'esistenza.
    2. L'header Message-ID: contiene caratteri o sequenze di caratteri che "disorientano" l'applicazione client (l'antivirus del client, in questo caso).
    Uno dei difetti più diffusi si presenta come
    Message-ID: <?\[20
    dove al posto del punto interrogativo appare una lettera casuale.
ATTENZIONE: L'header From: del messaggio non deve essere confuso con il comando SMTP MAIL FROM: che indica il cosiddetto Reverse Path e che fa parte dell'envelope.
Anche se in linea di massima gli indirizzi e-mail indicati nei due casi coincidono, tale condizione non è assolutamente obbligatoria.
Un caso frequente, su cui regna confusione e disinformazione è il cosiddetto mittente nullo indicato nel Reverse Path:

MAIL FROM: <>

E' fondamentale comprendere definitivamente che tale indicazione è perfettamente lecita ed è implementata con un scopo ben preciso nello standard SMTP:

    RFC2821, SMTP - Simple Mail Transfer Protocol, (http://www.faqs.org/rfcs/rfc2821.html)
    Cap. 3.7 - Relaying
    Cap. 4.1.1.2 - MAIL
    Cap. 6.1: "...If there is a delivery failure after acceptance of a message, the receiver-SMTP MUST formulate and mail a notification message. This notification MUST be sent using a null ("<>") reverse path in the envelope."
Il mittente nullo è utilizzato nelle notifiche di spedizione e in tutte le comunicazioni di servizio generate dal server.
Non viene utilizzato un indirizzo "normale" nel Reverse Path perché in alcune situazioni si correrebbe il rischio di creare dei circoli viziosi, nei quali la segnalazione rimbalzerebbe avanti e indietro tra due sistemi.
Il mittente nullo è invece riservato a questo preciso utilizzo.
Pertanto evitate di chiederci come si respingono i messaggi provenienti da mittenti nulli.
E' una cosa assolutamente da evitare, per il buon funzionamento della posta Internet in generale.

Per tornare ancora una volta al blocco dell'antivirus, sfatiamo una convinzione: i messaggi con mittente nullo o privi dell'oggetto o con altri header mancanti, NON creano alcun problema.
In seguito a numerosi esperimenti, le uniche malformazioni che provocano il blocco del client sono quelle descritte in precedenza, ai punti 1. e 2.
Per farvi fronte, abbiamo realizzato un paio di Content Filters di Merak:

http://www.icewarp.it/ftp/CF-MandatoryHeaders.zip
http://www.icewarp.it/ftp/CF-CorruptedMessageID.zip

Raccomandiamo però di utilizzarli con estrema cautela e soprattutto non ci assumiamo responsabilità per eventuali problemi o danni provocati.
Questi filtri sono solo esemplificativi. Ognuno è invitato ad analizzarli attentamente per comprenderne il significato e ad apportarvi tutte le modifiche che ritiene opportune.
Sicuramente non sono un rimedio universale e definitivo ai problemi di malformazione dei messaggi, ma possono essere di aiuto a limitare i disagi per gli utenti della posta elettronica.
IceWarp Italia
support@icewarp.it
IceWarp
 
Posts: 640
Joined: Thu 20 Feb, 2003 16:13

Return to Annunci

Who is online

Users browsing this forum: No registered users and 1 guest

cron