éviter donc cette phrase

Chers étudiants,


Je vais vous donner une astuce pour connaître si votre destinataire a consulté vos mails envoyés, il suffit d'ajouter ".Confirm.To" a son @ mail

exp: "ridha.bouallegue@gmail.com" ==> "ridha.bouallegue@gmail.com.Confirm.To"
ceci vérifierai les phrases de type "Désolé je n'ai pas encore vue ton mail!" grâce au feedback de confirmation

( évitez donc cette phrase et synonymes)


Bonne continuation (faite le policier c'est rigolo)

Bonsoir,
Oh monsieur, j'admis vraiment vos connaissances en info :-) !

La seule chose dans ce monde qui s'amplifie lorsque tu en donnes, c'est la science......

Grand merci ..
Cet astuce est vraiment utile .

Est ce que ca fonctionne avec tous les serveurs smtp,tous les outils de messagerie (ie :outlook.. )?

Bonjour,
Je pense que oui, ça doit fonctionner avec tout les serveur dont CONFIRM.TO est active! C'est une astuce liée au serveur ( SMTP (Simple Mail Transfert Protocol), ou POP3 (Post Office Protocol) ou IMAP (Internet Message Access Protocol).
On peut désactiver cette fonctionnalité chez quelques serveurs, mais dans la plupart des cas elle est active par défaut.
Confirm.To est un serveur ! Ce serveur envoie un email de confirmation à l'expéditeur dès que son qu'il a envoyé est lu.
Pour mieux éclaircir les choses j'ai vous trouvé ceci :-) !


[Usage] I'd like to use .confirm.to service for every messages in Outlook Express? is there any convenient way ?
Append .confirm.to to your SMTP server address. For example, your SMTP email server should be 'mail.yourcompany.com.CONFIRM.TO'.
In Outlook Express, you can do this at Menu->Tool->Account->Mail->Server tabs.
In Netscape, at Menu->Edit->Preferences->Mail&Newsgroup->Mail Servers tabs.

Or, You can append .confirm.to to recipients addresses in your address book.


[Usage] Why use confirm.to ?
It is the most convenient way to send important business and personal correspondence. Confirm.to complements various aspects of security in internet email, especially among users sending sensitive or confidential email.


[Usage] Confirm.to supports attachments, MHTML, MIME and S/MIME (digitally encrypted or signed message) ?
Yes. Confirm.to supports full internet standards on the e-mail message format.


[Usage] Can I use multiple meta e-mail addresses in single e-mail message ?
Of course, yes. You can designate multiple meta e-mail addresses anywhere in 'To','Cc' and 'Bcc' headers with normal (non-meta) e-mail addresses. You receive separate read receipt from each meta e-mail addressees. Treat meta e-mail addresses as if they are usual e-mail addresses.


[Usage] What if the recipients address is a group address or a mailing-list address ?
In that case, you receive as many read receipts as the number of member e-mail addresses of such an group e-mail address. To prevent read receipts overflooding, Confirm.to service set a threshold to the maximum number of read receipts issuable for one e-mail messages. Usually 5.

When the fifth read receipt is already issued, all the newly issued read receipts are not delivered to the sender as separate ones, but as single aggregate read receipt. We call it 'Group Read Receipt'.

Group read receipt has a periodically self-refreshing frame which displays HTML tables whose rows contain read status of each recipients. When the sender receives group read receipt, he/she should not expect any further separate read receipts from then on. He/she must open the group read receipt message for retrieving the latest group read status.

For more details, refer to 'group receipt' in the table of contents of the left frame.

And when there are more than 5 recipients in a single e-mail domain explicitly designated at posting time, you also get one group read receipt for them rightly after you post the email.


[Sender's right to know] I wish to always get the read receipt regardless of the recipients' situations.
Refer to 'ensured receipt' in the table of contents of the left frame. Confirm.to service provides the sender an option to place the real message body in the confirm.to relay server and send to the recipients only the pointer URL. To view the message body, the recipients must go online and download into his/her web brower the message pointed by the URL. At that moment, a read receipt is delivered to you automatically.


[Security] Is Confirm.To service secure?
Yes, your email is completely secure, ensuring privacy for both the sender and the recipient. We only relay ( or forward) messages, and never store them.

For very confidential message, you are recommened to encrypt your document before attaching it in your message using WINZIP or MS Word Encryption feature.


[Security] To secure our confidential e-mail messages, our company needs to host the confirm.to server in our local network. Is it against Your policy ?
No. You can have your own dedicated confirm.to relay server in your local network. All e-mail messages destined to your-email domain will be routed to the server.
Contact Postel at info@postel.co.kr.

Coooool
Merci bien AnomX pour ces infos..
En plus, elles contenaient déjà une réponse a une question que j'aller poser :

"Est ce qu'on peut recevoir l'accuse de réception sans que le destinataire ait la possibilité de confirmer,
En d'autre termes sans lui afficher un message de confirmation (par lequel il peut refuser l'envoi de l'accuse) ?"

Une solution donnée dans cet article consiste à obliger le récepteur de l'email de visiter une page web pour pouvoir lire le contenu du email, et cette page web informera automatiquement l'émetteur.
Pas mal comme idée.. Mais y-a t'il d'autres solutions..

Rq: tu as dit que : confirm.to est un serveur.
Je ne comprends pas ?

Bonsoir,

Oui, Confirm.To est un serveur. Interprétation, actions, et gestion d'information. Toutes les fonctionalité de confirm.to comme par exemple nous envoyer un email pour nous dire que notre email vient d'être lu. Celà necessite une action d'un serveur.
La dernière question du FAQ que j'ai poster le dit caréement ! :-) !


To secure our confidential e-mail messages, our company needs to host the confirm.to server in our local network. Is it against Your policy ?
No. You can have your own dedicated confirm.to relay server in your local network. All e-mail messages destined to your-email domain will be routed to the server.

Bon je ne sais pas quoi dire : Bonjour/Bonsoir ...elmouhimm:

Désole AnomX si je questionne bcps mais je veux comprendre,
Bon j'essaye de te comprendre mais je n'arrive pas..


Au début de la FAQ il était dit, et toi même tu l'as dit, que confirm.to est un service (active par défaut) d'un serveur smtp...
Je comprend alors que confirm.to n'est qu'une option du serveur de messagerie (celui ci fonctionne sous les protocoles smtp (pour l'envoi des email) et pop (pour la réception des email)...)
(que voudrai-je dire par une option ? c'est comme la fameuse option du serveur Apache concernant l'interpréteur PHP d'Apache : "Register_globals" qui se trouve dans php.ini ...)
(i assume you know that )

Bon je croix que je commence a comprendre, je m'explique :

Tout d'abord commancons par définir qu'est ce qu'un serveur?

Ismou 3la jismou : un serveur est une machine crée normalement pour fournir quelques services a des clients (autres machines dans le réseau) (ex des services : messagerie(mail,chat...),web,partage de ressources, etc).
Pour pouvoir fournir ces services, il (la machine serveur) doit contenir des logiciels programmes spécialement pour fournir ces services.(ex : l'ensemble des logiciels nomme 'Apache' est désigne pour fournir le service web(http,php,mysql..))
Ensuite, par raison de simplicité, on a pris la convention d'attribuer le nom "serveur" a ce type de logiciels.(ex : Apache est un serveur web <=>Apache est un ensemble de logiciels qui s'installe sur la machine serveur pour fournir le service web)

Voila en bref mes connaissances a propos de ce sujet, je les récite pour informer ceux qui ne savent pas et pour que tu puisse comprendre pourquoi je ne te comprend pas (oufff, j'écrit complique aujourd'hui)
Donc quand tu dit carrément "Confirm.to est un serveur" : je comprend que confirm.to est un logiciel fournissant le service de messagerie email avec feedback , alors que dans la FAQ il était dit que mettre le mot "Confirm.to" a la fin de l'email du récepteur suffit pour active la fonction du feedback..Donc tu voix ou est le prob : l'option Confirm.to est un serveur !! (n'est ce pas incomprehensible ca)

Sinon, pour la dernière question de la FAQ, je voix que dire "the confirm.to server" c'est vouloir dire "the server on whose the confirm.to option is activated" .. Si tu relies bien ce paragraphe tu me comprendras..

En tout cas, ça me plais beaucoup de discuter sur de tel sujet :-) Merci AnomX..
(J'attend ta réponse, en fait, a propos mes connaissances y a t il quelque chose d'incorrecte)

Hey les autres, veuillez intervenir même par des simples questions, on est la pour partager tous nos connaissances..
(Amma ghriba kifech UNIXSHELL m3atech yothhor ... WINEK YA UNIXSHELL , ste7ishnek barchaaaa )

et surtout n'oubliez pas que toute chose dans ce monde coûte un prix :
L'information ne coûte que d'aller la chercher ...

Bonjour,
Confirm.to n'est surement pas qu'une simple option à activer. Si tu veux que les choses soient plus précises c'est un service liée à un serveur web qu'on peut nommé confirm.to et ce serveur peut être inclu dans la structure de SMTP.
Tu as dit
"Apache est un serveur web <=>Apache est un ensemble de logiciels qui s'installe sur la machine serveur pour fournir le service web)
"
Ben confirm.to est un service tout entier ! :-)

Pour mieux éclaircir les choses tu peux visiter www.confirm.to tu touveras des schémas détaillés qui explique le fonctionnement de confirm.to.

Bon...pour ta definition de serveur, je ne sais pas trop! je ne pense pas qu'elle est 100% juste. Car un serveur peut être un seul logiciel.
Ma propre definition d'un serveur (Personnellement j'ai travaillé sur ce sujet en créant un client-serveur en C++, c'est une application simple qui n'a rien de professionel :-) ) se resume dans le faite qu'un serveur est software ou hardware dans un idle qui attend des declencheurs pour être eveillé (bon c'est la notion de sleep()).
Le serveur fait la gestions des taches selon les requêtes qui lui sont envoyé. Un serveur FTP, un serveur SSH, un serveur TELNET.....ce sont tous des serveurs lié à des protocole, comme en peut trouver des serveur programmer dans des différents environnement et qui servent selons les request qui leurs sont demandé. Comme les serveurs PHP (y a pas que l'APACHE), les serveurs ASP (Active Server Pages <== le nom de serveur y est déjà inclu), les serveurs CGI, ...etc !
Donc tu voies, je pense que c'est pourquoi tu ne m'as pas compris. Car tout simplement on n'a pas le même perpective envers la notion du serveur. :-) ! Je ne suis pas d'accord autour de ce que tu as défini. Tout peut être un serveur, s'il vérifie la condition général que j'ai déjà mentionné.

Anyway,
Merci Pour l'explication et pour le lien..

Je vois qu'AnomX me prend toutes les réponses, et je l’encourage. Ça me permettra d’admirer vos échanges.

Bonjour,
Merci bien monsieur le directeur.
C'est vraiment bien de partager les connaissances et d'apprendre de nouvelles choses. Mr qui sait tout n'existe pas :-)!
En faie, j'avais une ambiguité autour de Confirm.To, je savais son existence, mais quand vous l'avez mentionnée, je suis allé sur le net, et j'ai cherché à mieux la comprendre. Donc en conclusion, c'est vous qui m'avez stimuler à le faire :-)!

Absolument de ton avis, ou plutot de ta conviction :
celui qui sait tout n'existe pas sauf le bon dieu bien évidement