text: as shown in fig1 , hardware and software components in an operational environment including an illustrative embodiment of the disclosed system include client systems 10 , 18 , 26 and 34 . each of the client systems 10 , 18 , 26 and 34 includes communication application client software , shown for purposes of illustration as client software 12 in client system 10 , client software 20 in client system 18 , client software 28 in client system 26 , and client software 36 in client system 34 . the communication application client software in each of the client systems of fig1 generates a user interface for a corresponding user , shown as user interface 14 generated by client software 12 for the originating user 16 , user interface 22 generated by client software 20 for the non - originating user 24 , user interface 30 generated by the client software 28 for the non - originating user 32 , and user interface 38 generated by the client software 36 for the non - originating user 40 . the user interfaces 14 , 22 , 30 , and 38 may be embodied as any specific type of user interface . for example , in one embodiment , the client software 12 , 20 , 28 and 36 , may be made up of dedicated client software associated with a communication application program , such as an electronic mail (“ e - mail ”) application program , or a calendaring and scheduling application program , and provide a user interface associated with that communication application program as part of a multi - window graphical user interface . alternatively , the client software 12 , 20 , 28 and 36 , may be made up of web browser programs operable to provide user interfaces to a web - based e - mail and / or calendaring and scheduling application program within a multi - window graphical user interface . the user interfaces generated by the client software components shown in fig1 may be navigated using any specific type of user interface device in their respective client system , such as a computer keyboard or mouse , and / or using voice commands or the like . the client systems 10 , 18 , 26 and 34 shown in fig1 may each be embodied as a computer system including , for example , at least one processor , program storage , such as memory , for storing program code executable on the processor , one or more input / output devices and / or interfaces , such as data communication and / or peripheral devices and / or interfaces , and may each further include appropriate operating system software . the client systems 10 , 18 , 26 and 34 may include any specific type of computer system or other type of client device , such as , for example , desktop computer systems , pdas ( personal digital assistants ), cell phones , tablet pcs , or any other appropriate device capable of providing user interfaces to a user . the client computer systems 10 , 18 , 26 and 34 of fig1 are communicably interconnected through a data communication network , such as the internet , a local area network ( lan ), or any other specific type of communication system or network . those skilled in the art will recognize that while only four client systems are shown in fig1 for purposes of concise illustration , the disclosed system is not limited to any specific number of interconnected computer systems . accordingly , the disclosed system may be embodied to support operation using any specific number of communicable computer systems . moreover , while client computer systems are shown in the illustrative embodiment of fig1 , the disclosed system is not limited to such an embodiment . accordingly , the functions described in connection with operation of the client systems shown in fig1 may alternatively be performed partly or wholly within one or more server computer systems and software components executing thereon . during operation of the illustrative embodiment shown in fig1 , the originating user 16 composes an initial message 42 using features provided through the user interface 14 . the initial message 42 composed by the originating user 16 may , for example , be an initial or original message on which a message thread is based . a message thread based on the initial message 42 composed by the originating user 16 is , for example , made up of that initial message 42 and a number of subsequent reply messages generated by recipients of that initial message , and potentially also by the originating user 16 . the initial message composed by the originating user 16 may also be referred to as the “ root message ” of a message thread built on that message . the recipients of the initial message 42 in the example of fig1 are shown including the non - originating user 24 , the non - originating user 32 , and the non - originating user 40 . the initial message 42 includes a number of thread recipient insertion / deletion control flags . the thread recipient insertion / deletion control flags contained in the initial message 42 control whether recipients can be added to or removed from the recipient list for the initial message 42 . the thread recipient insertion / deletion control flags in the initial message 42 are selected or otherwise indicated by the originating user 16 . in one embodiment , the thread recipient insertion / deletion control flags in the initial message 42 are mime ( multipurpose internet mail extension ) flags or the like contained in the initial message 42 . in one embodiment of the disclosed system , the thread recipient insertion / deletion control flags in the initial message 42 allow non - originating users to request permission from the originating user 16 to add a recipient into and / or delete a recipient from the recipient list contained in the initial message 42 . when such control flags are set in the initial message 42 , the non - originating users 24 , 32 and 40 can issue permission request messages 43 that are sent to the originating user 16 . when the permission requests 43 are received by the client system 10 , the originating user 16 is provided with a user interface screen that enables the originating user 16 to either allow or disallow the requested recipient addition and / or removal . in the event that the originating user 16 allows a request to add a recipient into and / or remove a recipient from the recipient list contained in the initial message 42 , an approval message for that request is sent to the client system of requesting non - originating user , which then operates to allow the non - originating user to perform the recipient insertion or removal for which permission was sought . in the event that the originating user 16 disallows the requested recipient insertion and / or removal , a rejection message for that request is sent to the client system of the requesting non - originating user , which then operates to prevent the non - originating user from performing the recipient insertion or removal for which permission was sought . controls over recipient insertion and / or deletion are maintained beyond first order replies to the initial message 42 , and extend to all subsequent messages generated in the message thread based on the initial message 42 . for example , the initial message 42 may be addressed to the set of recipients consisting of the non - originating user 24 , the non - originating user 30 , and the non - originating user 40 . after the initial message 42 is received by the non - originating user 32 , the non - originating user 32 may use a reply to all feature of the communication system to generate a new message based on the initial message 42 . that new message would accordingly be sent from the non - originating user 32 to each of the non - originating user 24 , the non - originating user 40 , and the originating user 16 . the new message generated by the non - originating user 32 , and sent using the reply to all feature , is an example of a message in the message thread based on the initial message 42 . the new message based generated by the non - originating user 32 , and based on the initial message 42 , is generated such that it includes the recipient insertion / removal control flags from the initial message 42 . when the new message generated by the non - originating user 32 is received , the non - originating user 24 may generate another new message in the thread using the reply to all feature of the communication system . the non - originating user 32 may attempt to add a recipient to or remove a recipient from the set of recipients indicated by the initial message 42 . however , since the thread recipient insertion / deletion control flags contained in the initial message 42 are also sent with each subsequent message contained in the message thread based on the initial message 42 , the settings of those flags are used by the client software 20 to control such attempted recipient insertion / removal operations . for example , when the non - originating user 24 generates a reply to the reply generated by the non - originating user 32 , for example again using the reply to all feature , the communication system will initially set up the message such that the recipients are the originating user 16 , the non - originating 32 , and the non - originating user 40 . if the non - originating user 24 then attempts to remove one of those recipients , or attempts to add a new recipient , the client software 20 will check whether the attempted operation is permitted , based on the thread recipient insertion / removal control flags contained in the reply message to the initial message 42 , and received from the non - originating user 32 . the recipient insertion / removal control flats in the reply to the initial message 42 were copied from the initial message 42 . accordingly , whether the non - originating user 24 is permitted to remove or add a recipient to the message recipients list is determined based on the settings of the recipient insertion / deletion flags contained in the reply of non - originating user 32 to the initial message 42 , which were in turn copied from the recipient insertion / removal control flags contained in the initial message 42 . fig2 is a simplified screen shot showing an example of a new message composition user interface 50 generated in an illustrative embodiment of the disclosed system . the user interface 50 is an example of at least part of the user interface 14 displayed to the originating user 16 by the client software 12 , and enables the originating user 16 to compose the initial message 42 shown in fig1 . as shown in fig2 , the user interface 50 includes a number of buttons 52 that enable the user to control functions performed by the client software , for example by clicking on the corresponding button using the mouse . the buttons 52 include a send button 54 that enables the user to send the message they have composed , a save as draft button 56 that enables the user to save the composed message as a draft , an attach button 58 that enables the user to attach a document to the message , a delivery options button 60 that enables the user to access a number of delivery options to be associated with the message , and an encrypt button 62 that enables the user 16 to cause the message to be encrypted . the new message composition user interface 50 further includes addressee fields 64 . the addressee fields 64 enable the user to list the recipients for the message . using the features of the disclosed system , accessed through the button 60 , the originating user 16 can control whether users are added to or removed from the set of recipients entered by the originating user 16 , when subsequent replies are generated in a message thread based on the message being composed using the user interface 50 . in the embodiment shown in fig2 , the addressee fields 64 include a to : field 66 and a cc : (“ carbon copy ”) field 68 . the disclosed system is not limited to embodiments including the specific addressee fields 64 shown in fig2 , but may alternatively be embodied using any specific set of address fields . further shown in the new message composition user interface 50 is a subject : field 70 for the originating user 16 to enter a subject line into with regard to the message being composed , and a message composition region 72 that enables the originating user 16 to enter text and / or other content to be included in the message being composed using the user interface 50 . fig3 is a simplified screen shot showing an example of a delivery options user interface 80 generated in an illustrative embodiment of the disclosed system , for example to the originating user 16 of fig1 in response to the originating user 16 clicking on the button 60 in the user interface 50 shown in fig2 . as shown in fig3 , the delivery options user interface 80 includes delivery options 82 . each of the delivery options 82 enables the originating user 16 to control an aspect of the delivery of the message composed using the user interface 50 shown in fig2 . while the delivery options 82 are shown as being provided through check boxes in the illustrative embodiment of fig3 , enabling the originating user 16 to select individual options by clicking on the corresponding check box , the disclosed system is not limited to such an embodiment . accordingly , any specific type of user interface construct may be used in the alternative to allow the originating user 16 to indicate which of the delivery options 82 are selected for a message . delivery options 90 , 92 , 94 , 96 , 98 and 100 enable the user to indicate thread recipient insertion / removal control settings . the delivery options 82 in the illustrative embodiment of fig3 include a “ request delivery receipt ” option 84 . if selected by the originating user 16 , the “ request delivery receipt ” option 84 causes a receipt confirmation message to be generated and sent back to the originating user 16 upon receipt of the message by each of the message recipients . the delivery options 82 further include a “ request read receipt ” option 86 . if selected by the originating user 16 , the “ request read receipt ” option 86 causes a read receipt confirmation message to be generated and sent back to the originating user 16 upon the message being read by each of its recipients . the delivery options 82 further include a “ prevent copying ” option 88 . if selected by the originating user 16 , the “ prevent copying ” option 88 prevents copying of the message by recipients of the message . the delivery options 82 further include a “ prevent all thread recipient insertion ” option 90 . if selected by the originating user 16 , the “ prevent all thread recipient insertion ” option 90 prevents any recipients to be added to the set of recipients listed in the addressee fields 64 ( fig2 ) for purposes of replying to the message being composed using the user interface 50 ( fig2 ), or for purposes of otherwise adding a message in any way to the message thread based on the message being composed using the user interface 50 . the delivery options 82 further include a “ prevent insertion of the following users as thread recipients :” option 92 . if selected by the originating user 16 , the “ prevent insertion of the following users as thread recipients :” option 92 prevents any of the recipients listed by the originating user 16 in the delivery options user interface 80 from being added to the set of recipients listed in the addressee fields 64 ( fig2 ) for purposes of replying to the message being composed using the user interface 50 ( fig2 ), or for purposes of otherwise adding a message in any way to the message thread based on the message being composed using the user interface 50 . the delivery options 82 further include a “ prevent all thread recipient removal ” option 94 . if selected by the originating user 16 , the “ prevent all thread recipient removal ” option 94 prevents any recipients from being removed from the set of recipients listed in the addressee fields 64 ( fig2 ) for purposes of replying to the message being composed using the user interface 50 ( fig2 ), or for purposes of otherwise adding a message in any way to the message thread based on the message being composed using the user interface 50 ( fig2 ). the delivery options 82 further include a “ prevent removal of the following thread recipients :” option 96 . if selected by the originating user 16 , the “ prevent removal of the following thread recipients :” option 96 prevents removal of the recipients listed by the originating user 16 in the delivery options user interface 80 from the set of recipients listed in the addressee fields 64 ( fig2 ) for purposes of replying to the message being composed using the user interface 50 ( fig2 ), or for purposes of otherwise adding a message in any way to the message thread based on the message being composed using the user interface 50 ( fig2 ). the delivery options 82 further include a “ require approval for thread recipient insertion ” option 98 . if selected by the originating user 16 , the “ require approval for thread recipient insertion ” option 98 requires approval be obtained from the originating user 16 for any non - originating user to add a new recipient to those recipients listed by the originating user 16 in the addressee fields 64 ( fig2 ) for purposes of replying to the message being composed using the user interface 50 ( fig2 ), or for purposes of otherwise adding a message in any way to the message thread based on the message being composed using the user interface 50 ( fig2 ). the delivery options 82 further include a “ require approval for thread recipient removal ” option 100 . if selected by the originating user 16 , the “ require approval for thread recipient removal ” option 100 requires approval be obtained from the originating user 16 for any non - originating user to remove a recipient from those recipients listed by the originating user 16 in the addressee fields 64 ( fig2 ) for purposes of replying to the message being composed using the user interface 50 ( fig2 ), or for purposes of otherwise adding a message in any way to the message thread based on the message being composed using the user interface 50 ( fig2 ). an “ ok ” button 102 enables the originating user 16 to submit the selected ones of the delivery options 82 to be applied to the message being composed through the user interface 50 of fig2 . during operation of the embodiment shown in fig2 and 3 , if any one of the non - originating recipients tom albert , john white , and / or bob ross , generates a reply to the message being composed in the user interface 50 , or to any subsequent message in the message thread based on the message composed through the user interface 50 , their ability to add or remove recipients would be controlled based on thread recipient insertion / removal control settings indicated through the delivery options user interface 80 . accordingly , any attempt to add a recipient to such a message consisting of a user other than tom albert , john white , bob ross , or sam walters , would be controlled by the indicated thread recipient insertion / removal settings . similarly , any attempt to remove one of the recipients tom albert , john white , bob ross or sam walters from the recipients of such a message would also be controlled by those thread recipient insertion / removal control settings . fig4 is a flow chart showing steps performed to send a message including thread recipient insertion / deletion flags in an illustrative embodiment . in the illustrative embodiment of fig1 , the steps of fig4 are performed by the originating user 16 through the user interface 14 , in order to send the initial message 42 . as shown in fig4 , at step 104 the originating user composes an e - mail message or calendar event invitation message . step 104 may , for example , be performed using the new message composition user interface 50 shown in fig2 . at step 106 , the originating user indicates thread recipient insertion / removal options to be applied to the message . for example , the originating user may indicate thread recipient insertion / removal settings through the delivery options user interface 80 of fig3 . at step 108 , the originating user sends the e - mail message or calendar event invitation including representations of the thread recipient insertion / removal settings indicated by the originating user at step 106 . for example , at step 108 a message is sent such as the initial message 42 shown in fig1 . the representations of the thread recipient insertion / removal settings in the message sent at step 108 may , for example , be mime flags set within the message , and corresponding to specific insertion / removal settings indicated by the originating user at step 106 . fig5 is a flow chart showing steps performed to prevent thread recipient insertion in an illustrative embodiment of the disclosed system . for example , the steps of fig5 may be performed by client software executing on the client system of a non - originating user , such as the client software 20 , 28 or 36 shown in the illustrative embodiment of fig1 . as shown in fig5 , at step 108 an e - mail message or calendar event invitation is received by one or more non - originating recipients , and includes an indication that recipients cannot be added to the list of recipients in the received message for messages in the message thread based on the received message . accordingly , when a message recipient generates a reply to the received message , that reply must be addressed to no more than the sender of the message and all other recipients of the received message . thus at step 110 message recipients are prevented from adding any new recipients to the original recipient list in the received message when generating a reply message , for example using a reply to all function or the like in their client software . fig6 is a flow chart showing steps performed to prevent thread recipient removal in an illustrative embodiment of the disclosed system . for example , the steps of fig6 may be performed by client software executing on the client system of a non - originating user , such as the client software 20 , 28 or 36 shown in the illustrative embodiment of fig1 . as shown in fig6 , at step 112 an e - mail message or calendar event invitation is received by one or more non - originating recipients , and includes an indication that recipients cannot be removed from the list of recipients in the received message for messages in the message thread based on the received message . accordingly , when a message recipient generates a reply to the received message , that reply must be addressed to no less than the sender of the message and all other recipients of the received message . thus at step 114 message recipients are prevented from removing any recipients from the original recipient list in the received message when generating a reply message , for example using a reply to all function or the like in their client software . fig7 is a flow chart showing steps performed to require recipients to seek permission to insert / remove thread recipients . at step 120 , an originating user composes an e - mail message or calendar event invitation . the originating user indicates through the message composition user interface that approval must be sought from the originating user before a recipient can be added to or removed from the recipient list provided by the originating user . for example , the originating user may indicate that permission must be obtained before a recipient can be added to the message recipient list , that permission must be obtained before a recipient can be removed from the message recipient list , or that permission must be obtained before a recipient is either added to or removed from the message recipient list . step 120 may , for example , be performed by the originating user 16 through the user interface 14 provided by the client software 12 in the client system 10 . at step 122 , a recipient of the original message generated at step 120 , or of a subsequent message in the message thread based on that original message , generates a reply message , e . g . through a reply to all feature . the original message recipient also attempts send the reply message to a set of users other than the set of users in the list of recipients in the original message . for example , the original message recipient may attempt to remove a recipient from the list of recipients in the original message , or may attempt to add a recipient to the list of recipients in the original message . however , the client software ( e . g . client software 20 , 28 or 36 of fig1 ) prevents the original message recipient from modifying the recipient list , based on the thread recipient insertion / removal control settings contained in the original message . for example , the recipient insertion / removal control settings may indicate that approval from the originating user must be obtained before additions and / or deletions can be made to the set of recipients . the client software accordingly sends a permission request message to the originating user , requesting permission to perform the addition to or removal from the recipient list . at step 124 , the originating user is presented with the permission request message , and is allowed to either grant or deny permission to make the requested modification to the recipient list . the originating user may be presented with the names of the recipient ( s ) that is / are to be removed from or added to the recipient list , and / or the name of the user requesting the recipient list modification . in the event that the originating user grants permission for the requested modification , then at step 124 a message granting the requested permission is conveyed back to the client software of the original message recipient that requested the permission . otherwise , in the event that the originating user denies the requested permission , then at step 124 a message denying the requested permission is conveyed back to the client software of the original message recipient . for purposes of illustration , at step 124 in the fig7 a message granting the requested permission is conveyed back to the client software of the recipient user that requested the permission . at step 126 , the client software of the recipient requesting permission to modify the recipient list receives the response to the request for permission to modify the recipient list . in the example of fig7 , the permission is granted , and the permission is received at step 126 to modify the recipient list . the client software of the recipient that requested permission to perform the modification to the recipient list then permits the requested modification operation ( adding or removing a recipient ) to be performed . in the event that the permission were denied , then at step 126 the client software of the recipient would prevent the requested modification operation from being performed . the present invention can be realized in hardware , software , or a combination of hardware and software . a system according to the present invention can be realized in a centralized fashion in one computer system , or in a distributed fashion where different elements are spread across several interconnected computer systems . any kind of computer system or other apparatus adapted for carrying out the methods described herein is suited . a typical combination of hardware and software could be a general purpose computer system with a computer program that , when being loaded and executed , controls the computer system such that it carries out the methods described herein . the figures include block diagram and flowchart illustrations of methods , apparatus ( s ) and computer program products according to an embodiment of the invention . it will be understood that each block in such figures , and combinations of these blocks , can be implemented by computer program instructions . these computer program instructions may be loaded onto a computer or other programmable data processing apparatus to produce a machine , such that the instructions which execute on the computer or other programmable data processing apparatus create means for implementing the functions specified in the block or blocks . these computer program instructions may also be stored in a computer - readable medium or memory that can direct a computer or other programmable data processing apparatus to function in a particular manner , such that the instructions stored in the computer - readable medium or memory produce an article of manufacture including instruction means which implement the function specified in the block or blocks . the computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the block or blocks . those skilled in the art should readily appreciate that programs defining the functions of the present invention can be delivered to a computer in many forms ; including , but not limited to : ( a ) information permanently stored on non - writable storage media ( e . g . read only memory devices within a computer such as rom or cd - rom disks readable by a computer i / o attachment ); ( b ) information alterably stored on writable storage media ( e . g . floppy disks and hard drives ); or ( c ) information conveyed to a computer through communication media for example using wireless , baseband signaling or broadband signaling techniques , including carrier wave signaling techniques , such as over computer or telephone networks via a modem . while the invention is described through the above exemplary embodiments , it will be understood by those of ordinary skill in the art that modification to and variation of the illustrated embodiments may be made without departing from the inventive concepts herein disclosed .