On Mon, 10 Jun 2002, Daniel Cordey wrote: > En g�n�ral, cette fonctionalit� est g�r�e par les MUA. Pourquoi ? Parceque > seuls ceux-ci savent QUAND un mail a vraiment �t� lu (pour les accus�s de > lecture). Par exemple, Kmail poss�de une fonction de "Delivery & Read > Confirmations". Mais ce n'est pas le seul MUA qui poss�de ce genre de > fonctionalit�.
Je parlais d'accus�s de r�ception. Il me semble que la notion d'accus� de lecture transgresse all�grement les droits sur la sph�re priv�e. > Bien s�r, un accus� de r�ception peut-�tre trait� par un MTA. Il ne doit pas > �tre tr�s difficile d'incorporer ce genre de fonction dans procmail, mais il > me semble que ce n'est pas la bonne place. En effet, la confirmation ne > devrait venir que lorsq ue l'on est certain que le mail est bien dans la mail > box du destinataire. Or, dans le cas d'un MTA, il n'y a aucune assurance > qu'il s'agit bien de la derni�re �tape : peut-�tre y-a-t-il encore un > fetchmail, pop3, imap... et il n'est pas juste de confirmer la r�ception si > le destinataire n'arrive pas � lire son mail parceque le serveur pop ne > fonctionne plus (par exemple). Tu as raison: Pour bien faire, il faudrait traquer (tail -f) le fichier le logs de sendmail (ou inetd ou xinetd, selon) et r�agir � la lecture par le MUA (pop ou imap) du mail concern�. De plus, il est vrai que la notion ``d'accus� de lecture'' permettrait � un attaquant de connaitre le chemin parcouru par son mail, sans que le destinataire ne soit n�cessairement inform�... Accus� de r�ception aussi, au fait... Excusez-moi, je r�fl�chis tout haut... Non: Suivant comment l'accus� de r�ception est con�u, on peut (doit) lui construire un header ad�quat... Merci Daniel! :-) -- F�lix Hauri - <[EMAIL PROTECTED]> - http://www.f-hauri.ch -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se d�sabonner aussi.
