Caching and exposing pre-send data relating to the sender or recipient of an electronic mail message.

(54) Title: STORED IN CACHE MEMORY AND EXPOSURE OF PRE-SHIPMENT DATA RELATING TO THE SENDER OR RECEIVER OF AN EMAIL MESSAGE.

(54) Title: CACHING AND EXPOSING PRE-SEND DATA RELATING TO THE SENDER OR RECIPIENT OF AN ELECTRONIC MAIL MESSAGE.

(57) Summary

Technologies for caching and exposing pre-sent data that relate to the sender or receiver of an e-mail message are described here. A mail client program is configured to cache receiver and configuration mail tips on a client computer. Configuration mail tips can be retrieved from a server computer and cached when the mail client program is started. Receiver email tips can be retrieved and cached as each recipient of an email message is identified. When creating subsequent email messages, cached email tips for an email recipient are used instead of retrieving the email tips from the server computer. Cached email tips can be updated after a predefined period of time has elapsed. Cached email tips can also be used when the client program is offline or unable to establish a connection to the server computer.

(57) Abstract

Technologies are described herein for caching and exposing pre-send data relating to the sender or recipient of an e-mail message. A mail Client program is configured to cache recipient and configuration mail tips at a Client Computer. The configuration mail tips may be retrieved from a server Computer and cached when the mail Client program is started. Recipient mail tips may be retrieved and cached as each recipient of an e-mail message is identified. When subsequent email messages are created, cached mail tips for an e-mail recipient are utilized instead of retrieving the mail tips from the server Computer. The cached mail tips may be updated after a predefined period of time has elapsed. The cached mail tips may also be utilized when the Client program is offline or unable to establish a connection to the server Computer.

SAVED IN CACHE MEMORY AND DATA EXPOSURE

OF PRE-SHIPPING RELATED TO THE SENDER OR

RECEIVER OF AN EMAIL MESSAGE

BACKGROUND

Due to the asynchronous nature of email (e-mail) systems, email messages may not be successfully delivered to their intended recipients. In this regard, the delivery of email messages may fail for a variety of reasons. For example, an email message may be sent that is too large for the sender's or receiver's mailbox, the recipient's mailbox may be full, or too many recipients may address the email message prohibiting its transmission. Also, email senders frequently make embarrassing and potentially costly mistakes when composing email messages. For example, a private email message may be accidentally sent to a large audience, or an email message containing confidential material may be inadvertently sent to recipients outside of an organization. In both scenarios only after sending the email the sender is able to discover the error.

With respect to these and other considerations, the description made here is presented.

BRIEF DESCRIPTION OF THE INVENTION

Technologies for caching and exposing pre-send data that relate to the sender or receiver of an e-mail message are described here. In particular, through the use of the technologies presented here, data that may alert an email sender of potential risks associated with sending an email message or conditions that may cause delivery of the email message to fail retrieve, cache, and expose the email sender during the composition of an email message. Through the use of such information, the email sender can choose to remove recipients of the email message or to choose or not to send the message.

In accordance with an aspect presented here, an email client program is provided which is configured to retrieve, cache, and expose email tips (referred to here as email tips) to an email sender during composition of an email message. Email tips are properties that relate to a sender or receiver of an email message and that are exposed to the email sender before sending the email message. A category of email tips, referred to here as the recipient's email tips, relates to a recipient of an email message. For example, receiver email tips may indicate that a recipient's mailbox is full, the maximum message size that a recipient can receive, or that the recipient is currently out of office (OOF). Another category of email tips, called setup email tips, refers to a sender of an email message. Configuration email tips may indicate, for example, an email message is too large to be sent by the email sender, or a composing email message will cause the email sender's mailbox to exceed its limit sent.

According to other aspects, the mail client program is configured to cache the receiver and configuration mail tips on a client computer. In particular, in one mode the configuration mail tips are retrieved from a server computer and stored on the client computer when the mail client program is started. Receiver email tips are retrieved from the server computer and cached in the client computer as each recipient of an email message is identified. For example, recipient email tips for an email recipient can be retrieved from the server computer, cached, and presented to the email sender at the time the email sender provides the name of the email recipient. electronic. When creating subsequent email messages, email tips that were cached on the client computer for an email recipient are used instead of retrieving the email tips from the server computer.

According to other aspects, cached email tips can be updated periodically. For example, updated configuration email tips may be retrieved and cached after a predefined period of time (for example, 24 hours) that has elapsed since the configuration email tips were last retrieved. The cache of certain receiver email tips that are likely to change frequently can also be updated after a predefined period of time elapses. The cache of configuration mail tips and receiver mail tips can also be used when the client program is offline or unable to establish a connection to the server computer.

In accordance with other aspects, a user interface is provided to expose the email tips or an email sender. It should be appreciated that the subject matter described above can also be implemented as a computer controlled apparatus, a computer procedure, a computer system, or as an article of manufacture such as a computer readable medium. These and various other features will become apparent from a reading of the following detailed description and a review of the associated drawings.

This brief description is provided to introduce a selection of concepts in a simplified form which is further described below in the detailed description. This brief description is not intended to identify key features or essential features of the claimed topic, nor is this compendium intended to be used to limit the scope of the claimed topic. Furthermore, the claimed theme is not limited to implementations that address any or all of the disadvantages noted anywhere in this description.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a network and software architecture diagram showing aspects of an illustrative operating environment and various software components provided by the modalities presented herein;

Figures 2-5 are flow charts illustrating the operation of a mail client to retrieve, cache, expose, and update mail tips in various ways presented here;

Figures 6-8 are screen display diagrams showing various user interfaces to expose email tips to an email sender and to configure the display of email tips in modes presented here; and

Figure 9 is a computer architecture diagram showing an illustrative computer hardware and software architecture for a computer system capable of implementing aspects of modalities presented herein.

DETAILED DESCRIPTION

Introduced here are technologies for caching and exposing pre-send data that relate to the sender or receiver of an email message. While the subject matter described here is presented in the general context of program modules that run in conjunction with running an operating system and application programs on a computer system, those skilled in the art will recognize that other implementations can be performed in combination. with other types of program modules. Generally, program modules include routines, programs, components, data structures, and other types of structures that perform particular tasks or implement particular abstract data types. Furthermore, those skilled in the art will appreciate that the subject matter described herein can be practiced with other computer system configurations, including portable devices, multiprocessor systems, programmable consumer or microprocessor based electronics, minicomputers, macrocomputers, and the like,

In the following detailed description, reference is made to the accompanying drawings which form a part thereof, and which show specific embodiments or examples by way of illustration. Referring now to the drawings, where similar numbers represent similar elements across the various figures, aspects of a computing system, and methodology for caching and exposing pre-shipment data that relates to the sender or receiver of an email message will be described.

Turning now to Figure 1, details will be provided regarding an illustrative operating environment and various software components provided by the modalities presented herein. In particular, Figure 1 shows aspects of a system 100 capable of caching and exposing pre-send data that relates to the sender or receiver of an email message 114. System 100 includes a client computer 102 and a 104 server computer. As illustrated in Figure 1, client computer 102 and server computer 104 are interconnected through one or more local or wide area networks, such as network 106. It should be appreciated that many more network connections can used as illustrated in Figure 1. It should also be appreciated that although only an Individual client computer 102 and an individual server computer 104 were illustrated in Figure 1, many more computing systems can be used in the modalities.

As shown in Figure 1, the client computer 102 is configured to run a mail client 108. As is known in the art, the mail client 108 is a computer program configured to allow a user of the Client 102, referred to here as a sender, create and transmit a 114 mail message. In order for the mail client 108 to transmit a mail message 114, it must operate in conjunction with the mail server program 110 running on a server computer 104.

The mail server program 110 is configured to receive the request to transmit the mail message 114 from the mail client 108 and transmit the mail message 114 through appropriate server computers to deliver to its intended recipient. The mail client 108 is also configured to operate in conjunction with the mail server 110 to receive mail messages in the name of a user of the client computer 102. In this regard, the mail server 110 can maintain a mailbox 112 for storing incoming and outgoing messages for the user of the client computer 102. It should be appreciated that the mail client 108 and the mail server 110 can provide a more treatment of additional functionality regarding the sending and receiving of email messages different from the functionality presented here. An example of a mail client

108 is the OUTLOOK email client of MICROSOFT

CORPORATION of Redmond, Washington. An example of a 110 mail server is the EXCHANGE mail server, also from MICROSOFT CORPORATION. It should be appreciated, however, that the modalities presented here can be used with clients and mail servers of other vendors.

As briefly described above, the email client 108 provided here is also configured to receive, cache, and expose one or more email tips to an email sender during the composition of an email message. Email tips are properties that relate to a sender or receiver of an email message and that are exposed to an email sender before sending the email message. By exposing email tips to the sender of the email message before the email is sent, the user is made aware of the implications of sending the message before it is actually transmitted. In this way, a user can make informed decisions and potentially modify the recipients of the email message or choose not to send the message at all.

A category of email tips, referred to here as recipient email tips, refers to a recipient of an email message. For example, receiver email tips may indicate when a recipient mailbox is full, when a user has insufficient rights to send email to a restricted distribution mailbox or list, when the size of the outgoing message is greater than the size of maximum message that the recipient can receive, or when entering an email address domain that cannot be validated. Other examples of recipient email tips include email tips that indicate when a recipient email address is not part of the sender's organization, when a distribution list contains one or more email addresses that are not part of the sender's organization. organization, when the number of members of a distribution list is greater than a predetermined value, when a distribution list has a moderator that reviews and filters messages before transmitting them to members of the distribution list, when a recipient has indicated that they are out of the office, when a distribution list or mailbox has a common message defined per user, when an internal email address cannot be validated, or when the large message is attempted to be sent to a large number of recipients.

Another category of email tips here, referred to as setup email tips, are email tips that relate to a sender of the email message. The configuration tips may indicate, for example, that an email message is too large to be sent by the email sender, or that a composing email message will cause the email sender's mailbox to exceed its email limit. Shipping. It should be appreciated that the above receiver email tips and configuration email tips are merely illustrative, and that any other information regarding a recipient of an email message may be presented to a user in the form of a mail tip as described here.

In order to present the mail tips to a user of the client computer 102 before or during the composition of a mail message 114, the mail client 108 is configured to operate in conjunction with a web service 116 running on server computer 104. Web service 116 receives and answers calls from mail client 108 for mail advice associated with a sender or receiver of an email message 114. In particular, the web service 116 maintains a mail tip data storage 118. The configuration mail tips 120 are stored in the data store 118 corresponding to email senders. The receiver mail tips 112 are also stored in the data storage 118 corresponding to various receivers.

In an embodiment presented here, the mail client 108 is operational to receive the configuration mail tips 120 and the receiver mail tips 122 from the web service 116 and to cache the mail tips on the client computer 102 By caching email tips, email client 108 is able to reduce the amount of traffic transmitted on network 106 during the creation of an email message 114.

In one implementation, the mail client 108 stores the mail tips received from the web service 116 in a mail tip cache 126. According to one implementation, the configuration mail tips 120 are stored in a computer log. 102. In this mode, the email tips of the receiver 122 are stored in a random access memory of the client computer 102. However, it should be appreciated that the mail tip cache 126 may be stored in other ways in other ways, such as a mass storage device of the client computer 102. Other mechanisms to persist the mail tips received from the web service 116 can also be used by client computer 102.

As will be described in greater detail below, in an embodiment presented here the mail client 108 is configured to retrieve the configuration mail tips 120 from the web service 116 at the time the mail client 108 is started. It should be appreciated, however, that the configuration email tips 120 can be received from the web service 116 at any time before the composition of the email message 114. In accordance with other aspects, the recipient email tips 122 are retrieved from the web service 116 since each recipient of an email message 114 is identified by a user of the client computer 102. For example, receiver mail tips 122 can be retrieved from web service 116, cached in mail tip cache 126, and presented to a user of client computer 102 at the time the sender provides the name of each email receiver. In embodiments, a directory service 124 can be run on server computer 104 to resolve the names of email recipients. In one embodiment, the recipient email tips 122 are not retrieved from the web service 116 until the email recipient has been resolved, such as through the use of the directory service 124.

When creating subsequent email messages, the email tips that have been cached in the email tip 126 are used instead of retrieving the email tips from the web service 116 again. For example, if recipient email tips 122 were previously cached for a recipient, and that recipient is identified in a subsequent email message 114, email tips from the recipient of the email tip cache 126 are used instead of getting new email tips from recipient 122 of web service 116.

As will also be described in detail below, the mail tips stored in the mail tip cache 126 can be updated periodically. For example, updated configuration email tips 120 may be retrieved from web service 116 after a predefined period of time that has elapsed since configuration email tips 120 were last retrieved. For example, in one deployment, configuration email tips 120 are cached for no more than 24 hours. Configuration email tips 120 are updated at the time the first session with mail server 110 is established after the 24-hour period has passed. If a user is still in the same session since the last time configuration 120 email tips were cached when the 24-hour period passed, the 120 configuration email tips cached in mail tips 126 will be cleaned and web service 116 will be queried for 120 updated configuration mail tips. Similarly, in one embodiment, receiver mail tips 122 are cleaned each time mail client 108 is closed.

Certain receiver email tips 122 that are likely to change frequently can also be updated after a predefined period of time elapses. For example, a Mail Tip that corresponds to a full mailbox condition and a Mail Tip that corresponds to a user being out of the office can be updated from Web Service 116 after a predefined period, such as when 1 hour has passed. . Other email tips can also be updated in a similar way. In order to update these mail tips in such a program, a time record can be stored within the mail tip cache 126 for these mail tips. Additional details regarding the retrieval, caching, presentation, and updating of configuration email tips 120 and receiver email tips 122 will be provided below with regard to Figures 2-8.

According to other aspects, portions of the mail tip cache 126 can be used when the mail client 108 is offline and unable to establish a connection to the mail server 110 and the web service 116. For example, the configuration 120 email tips stored in the 126 tip mail cache can be used directly when the mail client 108 is offline.

In order to use recipient email tips 122 when email client 108 is offline, these email tips can be stored in an offline address book 128. As shown in Figure 1, the address book Offline addresses 128 identifies a contact number 130, including their email addresses, and may also include recipient email tips 122. When the mail client 108 is returned to an online state, the updated mail tips can be retrieved from the web service 116.

Referring now to Figure 2, additional details will be provided regarding the modes presented herein for caching and exposing pre-shipment data that relates to the sender or receiver of an email message. In particular, Figure 2 is a flowchart illustrating aspects of the mail client operation 108 to retrieve and cache the configuration mail tips 120. It should be appreciated that the logical operations described here are implemented (1) as a sequence of acts implemented by computer or program modules running in a computer system and / or (2) as interconnected machine logic circuits or circuit modules within the computer system. Implementation is a matter of choice that depends on the performance and other requirements of the computer system. Accordingly, the logical operations described here are variously referred to as state, device, act, or structural module operations. These operations, structural devices, acts, and modules can be implemented in software, in firmware, in special-purpose digital logic, and any combination thereof. It should also be appreciated that more or fewer operations can be performed than those shown in the figures and described herein. These operations can also be performed in a different order than those described here.

Routine 200 begins operation 202, when a user starts the mail client on client computer 102. Once mail client 108 is started, routine 200 continues operation 204, where a decision is made as to whether a predefined period has elapsed since configuration mail tips 120 was last retrieved. As discussed above, this predefined period is set to 24 hours in a deployment. However, it should be appreciated that any predefined period can be set to trigger the update of the configuration mail tips 120 stored in the mail advice cache 126. If, in step 204, the mail client 108 determines that it does not the predetermined time has elapsed, routine 200 continues to step 216, where it ends. However, if the predefined period has elapsed, routine 200 continues from step 204 to step 206.

At step 206, a determination is made as to whether web service 116 is available. If web service 116 is not currently available, routine 200 proceeds from step 206 to step 208, where mail client 108 is notified that web service 116 is not available. Additionally, web service 116 is queried again after a predetermined period of time, such as 15 minutes, has elapsed. After web service 116 is queried again, routine 200 continues at step 209 where another determination is made as to whether web service 116 is available. If web service 116 is not available, routine 200 proceeds from step 209 to step 208 described above. If web service 116 is available, routine 200 proceeds from step 209 to step 210. If, in step 206, mail client 208 determines that web service 116 is available, routine 200 proceeds from step 206 to step 210.

In operation 210, mail client 108 requests configuration mail tips 120 from web service 116. Routine 200 then continues operation 212, where mail client 108 receives configuration mail tips 120 from service. web 116. Once the configuration email tips 120 have been received, routine 200 continues to step 214, where the mail client 108 stores the configuration email tips 120 in the email advice cache 126. If the configuration email tips 120 were previously stored in the email tip cache 126, the previously stored configuration email tips 120 can be cleared before storing the updated configuration email tips 120 or simply overwritten. Once the configuration email tips 120 were stored in the email tips cache 126, routine 200 continues from operation 214 to operation 216, where it ends.

Referring now to Figure 3, an illustrative routine 300 will be described that illustrates operations performed by mail client 108 to retrieve, cache, and present receiver mail tips 122. Routine 300 begins operation 302, wherein a mail client user 108 enters recipient data for a new mail message 114. For example, the user can enter the name of the intended recipient or directly enter an email address for the intended recipient.

Once the user has entered the receiver data, routine 300 continues to step 304, where an attempt is made to resolve the entered receiver data to a valid email address. As discussed above, a directory service 124 may be queried in order to attempt to resolve the email address. In accordance with other embodiments, a nickname cache that stores information from mail messages 114 previously sent by the mail client 108 can also be used to assist in the resolution of the receiver data. Address book 128 or a global address book stored in server computer 104 can also be used to resolve the recipient's email address. Starting with step 304, routine 300 continues at step 306.

At step 306, a determination is made as to whether the receiver data was unambiguously resolved to a valid email address. If the receiver data was not unambiguously resolved, routine 300 proceeds to step 308, where the user is provided with an opportunity to assist in the resolution procedure. For example, the user may be allowed to retype the recipient data or select one of several recipient email addresses. If, in step 306, it is determined that the receiver data was unambiguously resolved, routine 300 proceeds from step 306 to step 310.

In step 310, the mail client 108 queries the web service 116 for any of the recipient's email tips 122 that corresponds to the identified recipient's email address. Routine 300 then continues step 310, where a determination is made as to whether any of the email tips apply to the recipient of the email message sender 114. If the mailing tips do not apply, routine 300 proceeds to step 320, where it ends. If any of the mail tips apply, routine 300 proceeds from operation 312 to operation 314, where any of the receiver 122 mail tips available from web service 116 are retrieved and cached in the mail advice cache 126. Routine 300 then proceeds to step 316, where a determination is made as to whether the mail client 108 submitted the recipient's result name. IF the resolved name has not yet been presented, routine 300 returns to operation 316. If the resolved name was presented, routine 300 proceeds to operation 318 where the configuration mail tips 120 and the receiver mail tips 122 for the mail message are presented. In performing decision operation 316, mail client 108 ensures that mail tips for a recipient are not presented until the recipient's resolved name has been submitted. An illustrative user interface for introducing email tips will be described below with respect to Figures 6-7. Starting with step 318, routine 300 continues step 320, where it ends.

Referring now to Figure 4, an illustrative routine 400 will be described that illustrates operations performed by the mail client 108 to update the contents of the mail tip cache 126 when creating a new message mail message tip 114. As briefly discussed in the above, the mail client 108 will update certain receiver 122 mail tips stored in the mail tip cache 126 that are likely to change frequently. As also briefly discussed in the foregoing, in order to do this, mail client 108 stores a registration date with each of these mail tips each time they are cached in mail tip 126. When a new mail message 114 is created, this log date is examined to determine if the recipient's mail tips need to be updated from web service 116. Routine 400 illustrated in Figure 4 shows this procedure in a mode presented here .

In step 402, a new mail 114 is created and the recipients of the mail message are identified. Routine 400 then continues operation 404 where the mail client

108 Determines whether recipient email tips 122 were previously cached for any recipient of new email messages. If not, routine 400 continues operation 414, where it ends. In this case, the web service 116 should be queried for any of the recipient email tips 122 that correspond to the recipients of the new email message and these email tips will be stored in the email tip 126 cache.

If recipient 122 mail tips were previously stored in mail tip 126 cache for any of the recipients of the new mail message, routine 400 continues to step 406. In step 406, mail client 108 determines if any of the expired mail council registration dates for recipient mail councils

122 stored in the mail tip cache. If so, routine 400 proceeds to step 408 where mail client 108 re-consults web service 116 for updated receiver mail tips 122. Routine 400 then proceeds to step 410 where any of the tips Updated receiver mail messages 122 retrieved from the web service 116 were cached in the mail tip 126 cache. The registration date associated with receiver mail tip 122 is also updated to reflect the time when the updated receiver mail tips 122 were retrieved from web service 116. Beginning with step 410, routine 400 proceeds to operation 412.

If, in operation 406, the mail client 108 determines that the mail tip registration date has not expired, routine 400 proceeds to step 412. In step 412, the receiver mail tips 122 stored in memory mail tip cache 126 for recipients of new mail message 114 are received and presented. As briefly discussed above, a user interface for submitting email tips will be described in greater detail below with respect to Figures 6-7. By operating from operation 412, routine 400 continues to operation 414, where it ends.

Now changing Figure 5, an illustrative routine 500 will be described that illustrates a procedure performed by the mail client 108 to update the contents of the mail tip cache 126 for a mail message 114 that is created but not left. sent. This routine is performed, for example, when a user of the client computer 102 creates an email message 114 but does not immediately send the email message 114. For example, the user may enter recipients for mail message 114 and leave focus on new message 114 but takes no further action for a period of time. Alternatively, the user can create a new mail message 114, enter the recipients for the new mail message 114, and change the focus to another application or to the operating system of the client computer 102. When the user returns the mail message 114, it may be necessary to update the contents of the mail tip cache 126. The routine 500 illustrated in FIG. 5 shows a procedure performed by the mail client 108 to do this.

Routine 500 begins at step 502, where the mail client 108 determines whether the focus has been returned to an unsent mail message that includes a receiver for which the receiver mail tips 122 were previously stored in memory mail tip cache 126. If the unsent mail message does not include receiver mail tips 122 for a receiver, routine 500 proceeds from step 502 to step 514, where it ends. However, if the unsent mail message includes a receiver for which the receiver mail tips 122 were previously cached, routine 500 continues at step 504,

At step 504, the mail client 108 determines whether a timer from another query has expired. In one implementation, the timing of another query is set by the mail client 108 to indicate when another query should be made to the web service 116 for receiver mail tips 122. In one mode, the other query timed by the client is run. mail 108 after 1 hour. However, it should be appreciated that any time period can be used. If the timer for another query has not expired, routine 500 branches from step 504 to step 512, described below. If the timer for another query has expired, routine 500 continues from step 504 to step 506.

In step 506, the mail client 108 determines whether the mail tip registration date has expired so that the receiver mail tips 122 are updated. As discussed above, the mail advice registration date is set to those recipient 122 email tips that can be changed frequently in time at the time those 122 recipient email tips are stored in the email tip cache. If the mail tip registration date has not expired, routine 500 proceeds from step 506 to step 512, described below. However, if the mailing council registration date has expired, routine 500 branches from operation 506 to operation 508.

In operation 508, mail client 108 re-consults web service 116 for updated receiver mail tips 122. Routine 500 then continues in operation 510, where the updated receiver mail tips 122 are received from the service web 116 and are cached in mail tip 126. The registration date associated with any of the frequently changed recipient mail tips 122 is also updated. Starting with step 510, routine 500 proceeds to step 512, where the mail client 108 retrieves the cached receiver mail tips 122 from the mail tip cache 126 for the recipients of the message. 114 unsent mail and presents them. An illustrative user interface for presenting email tips will be discussed below in relation to Figures 6-7. Starting with step 512, routine 500 proceeds to step 514, where it ends.

Referring now to Figure 6, an illustrative user interface 600 that is provided by the mail client 108 will be described. The user interface 600 shown in Figure 6 can be used in a traditional way to specify the recipients of a message. 114. For example, as shown in Figure 6, fields are provided to specify recipients of mail message 114, specify a subject, and Insert text in the message. In accordance with the implementations, user interface 600 is also used by mail client 108 to expose configuration mail tips 120 and receiver mail tips 122 to an email sender.

As shown in Figure 6, user interface 600 Includes a mail tip bar frame 602. The mail tip bar frame comprises the total area allocated to the mail tip manifestation. According to the modalities, the mail tip bar frame 602 can be presented in different colors depending on the severity of the mail tips that are presented. Furthermore, as will be described below with respect to Figure 7, the mail tip bar frame 602 can be expanded if multiple mail tips are to be presented or if a single mail tip is applied to multiple recipients.

User interface 600 also includes a mail tip icon 604. The mail tip icon 604 may vary depending on the severity of the mail tip being presented. Adjacent to mail tip cone 604 is mail tip message 606. Message 606 conveys the effect of the problem reported by the corresponding mail tip. An action button 608 is also provided that allows a user to execute an action to address the problem described by mail tip message 606. For example, in the implementation shown in Figure 6, action button 608 can be used to remove the recipient of the mail message 114. Other actions may also be exposed.

According to the modalities, the recipients of an email address are identified in the user interface 600. For example, a name 610 may be provided showing a name of one of the intended recipients of the email message 114. In one embodiment, recipients of an email message for which recipient email tips 122 apply can be highlighted, colored, or otherwise distinguished to indicate that an email tip is present for that particular user. In this way, the sender's attention can be directed from the recipient name 610 to the mail tip bar frame 602 where the mail tip message 606 was presented. A close button 612 may also be provided to hide the mail tip bar frame 602.

Turning now to Figure 7, additional details regarding the user interface described above with reference to Figure 6 will be provided to expose the configuration email tips 120 and receiver email tips 122, as briefly discussed in Above, the 602 mail tip bar frame can be expanded if more than two mail tips are to be submitted or if an individual mail tip applies to multiple recipients. This is illustrated in Figure 7. In particular, the mail tip bar frame 602 has been expanded to show mail tip messages for multiple recipients. Additionally, an Individual Mail Council that applies multiple recipients can be filed together. For example, in the example shown in Figure 7, the mail tip icon 704 is presented adjacent to a mail tip message corresponding to an out of office mail tip. Adjacent to this, the out-of-office message provided by multiple receivers has been presented. Action buttons are provided next to each of the email council messages so that a user can remove the corresponding recipient of the email message 114.

Referring now to Figure 8, an illustrative user interface 800 will be described that allows a user of the client computer 102 to adapt the mail tips presented by the mail client 108. In particular, the user interface 800 provides user interface controls that allow a user of the client computer 102 to specify the mail tips to be presented by the mail client 108. For example, the user may be able to select whether to present email tips for a restricted distribution list or a restricted recipient. The user may also be able to define whether undeliverable message mail tips may be presented, such as an invalid recipient address, an invalid external domain, message too large for the recipient, message too large to send, advice for Inbox mailbox if full.

The user infer 800 can also allow the user to define whether informative mail tips are presented by the mail client 108, such as when sending a message to a large distribution list or audience, sending a large message to a large audience, the recipient is out of the office, and an outside recipient is identified in a distribution list, or when a mailbox quota is to be exceeded. As also illustrated in

FIG. 8, a mail server administrator 110 may be able to lock the options presented in user interface 800. In this way, a mail server administrator

110 You can force email tips to be submitted by the email client 108, or prevent email tips to be submitted by the email client 108.

In accordance with other aspects, the user interface 800 includes user interface controls to allow a mail client user 108 to specify that the mail advice bar frame 602 is presented at all times or that it will never be displayed. introduce the 602 mail tip bar frame. A user interface control can also be provided to allow a user to specify that the mail tip bar frame 602 is presented only when a mail tip applies to a message. An option can also be provided to cause mail client 108 to automatically expand mail tip bar frame 602 when multiple mail tips apply an individual mail message 114. It should be appreciated that the user interface controls and design shown in Figures 6-8 are merely illustrative and that other types of user interface controls, designs and formats may be used.

Figure 9 shows an illustrative computer architecture that can be used to represent client computer 102. In particular, the computer architecture shown in Figure 9 illustrates a conventional desktop, laptop, or server computer and can be used to run any of the aspects of the software components presented here that were described as running on the client computer 102. It should be appreciated that the architecture shown in Figure 9 can also be used to represent server computer 104 and to execute the software components described herein as running on server computer 104. Other types of computer architectures can also be used to represent the various aspects presented here.

The computer architecture shown in Figure 9 includes a central processing unit 902 (CPU), system memory 908, including random access memory 914 (RAM) and read-only memory (ROM) 916, and a common system driver 904 that couples memory to CPU 902. A basic input / output system containing the basic routines that help transfer information between items within the client computer 102, such as during startup, is stored in ROM 916. The client computer 102 further includes a device for mass storage 910 for storing a 918 operating system, application programs, and other program modules, which are described here in greater detail.

Mass storage device 910 is connected to CPU 902 through a mass storage controller (not shown) connected to common driver 904. Mass storage device 910 and its associated computer readable media provide non-volatile storage for the computer Customer 102. Although the description of computer readable media contained herein refers to a mass storage device, such as a hard drive or CD32 drive

ROM, it should be appreciated by those skilled in the art that computer readable media can be any available computer storage media that can be accessed by the client computer 102.

By way of example, and not limitation, computer readable media may include volatile and nonvolatile, removable and nonremovable media implemented in any method or technology for information storage such as computer readable instructions, data structures, modules of program or other data. For example, computer readable media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROMs, Digital Versatile Discs (DVDs), HD-DVDs, Blue-ray, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other means that can be used to store the desired information and that can be accessed by the client computer 102.

According to various modalities, the client computer

102 it operates in a network environment that uses logical connections to remote computers through a network such as network 106. Client computer 102 can connect to network 106 through a network interface unit 906 connected to the common conductor.

904. It should be appreciated that the Network Interface Unit 906 can also be used to connect to other types of networks and remote computer systems. Client computer 102 may also include an input / output controller 912 for receiving and processing input from a number of other devices, including a keyboard, mouse, or electronic stylus (not shown in Figure 9). Similarly, an input / output controller can provide output to a display screen, printer, or other type of output device (also not shown in Figure 9).

As briefly mentioned in the foregoing, a number of program modules and data files can be stored in the mass storage device 910 and RAM 914 of the client computer 102, which includes a suitable operating system 918 to control the operation of a desktop, laptop, or network server computer. Mass storage device 910 and RAM 914 can also store one or more program modules. In particular, mass storage device 910 and RAM 914 can store mail client 108 and mail tip cache 126, each of which was described in detail above with respect to Figures 1-8. . Mass storage device 910 and RAM 914 can also store other types of program modules.

Based on the foregoing, it should be appreciated that technologies for caching and exposing pre-send data that relate to the sender or receiver of an e-mail message are provided here. Although the subject presented here was described in specific language to computer structural features, methodological acts, and computer readable media, it should be understood that the invention defined in the appended claims is not necessarily limited to the specific features, acts, or media here described. Instead, the specific features, acts and means are described as illustrative ways of implementing the claims.

The topic described above is provided by way of illustration only and should not be construed as limiting. Various modifications and changes may be made to the subject matter described herein without following the illustrated and described illustrative modalities and applications, and without departing from the true spirit and scope of the present invention, which is mentioned in the following claims.