CA2375935A1 - System and method for re-routing of e-mail messages - Google Patents

Abstract

A method and apparatus for the re-routing of e-mail sent to a prior address (or an address that is non-working, or temporarily inconvenient) to the new address of an intended recipient. E-mail that is to be sent to a recipient is sent to the former Internet Service Provider (ISP). Because the recipient is no longer a subscriber to the old ISP, or because the address at the old ISP
is temporarily inconvenient, the e-mail is re-routed to a re-route server of the present invention. The re-route server then causes the e-mail to be sent to the correct address through a variety of processes. Alternatively, new e-mail addresses are made available at the old ISP. The old ISP can then forward e-mail messages directly to the new ISP.

Description

WO 00!79740 PCT/US00/17406 Title: System and Method for Re-routing of E-mail Messages 1 Background Of The Invention 2 The present invention is directed to a method and apparatus for redirecting network 3 traffic. More particularly, the present invention is directed to a method and apparatus of 4 re-routing electronic mail (or "e-mail") messages transmitted via the Internet.
Background Art 6 One of the most basic services offered by Internet Service Providers (or "ISPs") is a 7 private or corporate e-mail account that a customer may use for transmitting and receiving 8 electronic mail (e-mail) messages via the Internet. Each of these e-mail accounts has a unique 9 address.
Internet service customers are notoriously fickle in their choice of ISPs. The customer 11 turnover rate is typically 50% each year for most ISPs (those ISPs that do not have 12 meaningful market competition have lower turnover, of course). When a customer closes an 13 account at one ISP and opens a new account at another ISP, the customer cannot maintain the 14 same e-mail address. This is a natural result of the currently used e-mail addressing convention wherein part of the address includes an identification of the ISP.
Thus, when the 16 ISP changes, at least a part of the e-mail address must also change.
17 This is inconvenient because e-mail gets lost. In the prior art, e-mail messages sent to 18 a defunct address (belonging to an inactive account) are either acknowledged as being 19 undeliverable or they are simply ignored. Colloquially, acknowledgement by an ISP that the 2o message is undeliverable as addressed is known as "bouncing" the message back to the 21 sender. Although this doesn't get the message to the intended recipient and it fails to inform 22 the sender of a correct address (if any exists) for the intended recipient, at least it puts the 23 sender on notice that they have attempted to use an inaccurate e-mail address.
24 Simply ignoring an undeliverable message, as is done by some ISPs, is quite non-helpful because the sender remains ignorant that the message was sent to an inaccurate 26 address.

28 The present invention is a method and apparatus for the rerouting of e-mail from a prior 29 or non-working address to the new address of a recipient. In general, two basic re-route methods 3o are employed, varying as noted more fully below. E-mail that is to be sent to a recipient is sent 31 to the former Internet Service Provider (ISP). Since the recipient is no longer a subscriber to ' . ~~~5 r, ~y 7 ~, ~ 6 i ~~n~
~CT «vu 1 the old ISP, the e-mail is re-routed to a re-route server of the present invention. The re-route server 2 then causes the e-mail to be sent to the correct address through a variety of means. This 3 embodiment provides privacy with respect to the new address of the recipient since it is 4 known only to the re-route server and NOT to the old ISP.
Alternatively, new e-mail addresses are made available at the old ISP. The old ISP can 6 then forward e-mail directly to the new ISP. This has the advantage of a direct route from the 7 old ISP to the new ISP. However, privacy of the new e-mail address for the recipient is less 8 since the address is now known to the old ISP.
9 In either case, a business model arises that allows this process to occur.
As noted above, to there is a tremendous turnover in subscribers to any particular ISP.
Realizing that, just as e-mail 11 may be forwarded AWAY from an ISP, so can e-mail to other ISP's be forwarded TO the old ISP
12 for new subscribers. Thus it is to all ISP's advantage to forward e-mail where possible. In 13 addition, user fees will be paid for this service. Those entities running re-route servers could 14 easily share revenue with the ISP's that are registered with the re-route service. Thus not only will a valuable service be performed, but the ISP's can generate additional revenues from 16 participation.

18 Figure 1 illustrates the request handler for the ".forward" implementation of the 19 present invention.
2o Figure 2 illustrates the request handler for the alias table implementation of the present invention.
21 Figure 2A illustrates the e-mail re-route path through the re-route server for the alias '; - . 22 table and .forward implementations.
23 Figure 2B illustrates the direct e-mail re-route path for the alias table and .forward ...,w-r 24 implementations.
Figure 3 illustrates the e-mail handler for a re-route customer.
26 Figure 3A illustrates the e-mail re-route path for the re-route customer.
27 Figure 4 illustrates the request handler for the DNS table implementation of the 28 present invention.
z9 Figure 4A illustrates the e-mail re-route paths for the DNS table implementation.

1 Figure 4B illustrates the direct e-mail re-route path for the DNS table implementation 2 of the present invention.
3 Figure 5 illustrates a seize and forward implementation for re-route of messages.
4 Figure SA illustrates the e-mail path for the seize and forward implementation of the present invention.
6 Figure 6 illustrates the request handler for the SMTP wrapper implementation of the 7 present invention.
8 Figure 6A illustrates the e-mail handler for the SMTP wrapper implementation of the 9 present invention.
Figure 6B illustrates the e-mail re-route path for the SMTP wrapper implementation 11 of the present invention.
12 Figure 7 illustrates the e-mail handler for bounced mail.
i3 Figure 7A illustrates the e-mail re-route path for bounced mail.
14 Figure 8 illustrates the request handler for IPv6 address implementation of the present invention 16 Figure 8A illustrates the e-mail re-route path for the IPv6 address implementation.
17 Figure 8B illustrates the direct e-mail re-route path for the IPv6 address 18 implementation.
19 Figure 9 illustrates the X.500 database implementation of the present invention.
2o Figure 9A illustrates the e-mail re-route path through the re-route server for the X.500 21 implementation of the present invention.
22 Figure 9B illustrates the direct e-mail re-route path for the X.500 database 23 implementation of the present invention.
24 Figure 10 illustrates the re-route symbol implementation of the present invention.
Figure 10A illustrates the e-mail handler for the re-route symbol implementation of 26 the present invention.
27 Figure lOB illustrates the e-mail re-route path for the e-route symbol implementation 28 of the present invention.
29 Figure 11 illustrates e-mail handler for the re-route extension implementation of the 3o present invention.
31 Figure 11A illustrates the e-mail re-route path for the re-route extension 32 implementation of the present invention.

1 Figure 12 illustrates the Lightweight Directory Access Protocol (LDAP) client flow 2 of the present invention.
3 Figure 12A illustrates the e-mail re-route path for the LDAP implementation of the 4 present invention.
Figure 12B illustrates the direct e-mail re-route path for the LDAP
implementation of 6 the present invention.
7 Figure 13 illustrates request handler for the Return Code implementation of the 8 present invention.
9 Figure 13A illustrates the e-mail re-route path for the Return Code implementation of 1 o the present invention.
11 Figure 13B illustrates the direct e-mail re-route path for the Return Code 12 implementation of the present invention.
13 Figure 14 illustrates the client plug in module implementation of the present 14 invention.
Figure 14A illustrates the e-mail re-route paths for the client plug in module 16 implementation of the present invention.
17 Figure 14B illustrates the direct e-mail re-route paths for the client plug in module 18 implementation of the present invention.
19 Figure 15 illustrates a Re-route Add Request protocol according to the present invention.
21 Figure 16 illustrates a Re-route Delete Request protocol according to the present 22 invention.
23 Figure 17 illustrates a Re-route Edit Request protocol according to the present 24 invention.
DETAILED DESCRIPTION OF THE INVENTION
26 In the following description, the different embodiments of the invention are explained 27 from the point of view of analyzing how e-mail sent to a single invalid (or undesired) e-mail 28 address is forwarded to a currently valid e-mail account. This is a simplification of the general 29 case, and is done for ease of explanation. In the general case, an individual may have left 3o behind a string of abandoned e-mail accounts that all need to be forwarded to their currently 31 valid address. When the simplified case is extrapolated to the general case, any of the 32 embodiments described below may be combined with one another to handle messages sent to 33 different ones of the plural abandoned e-mail accounts.

1 Also for clarity of explanation, the convention is adopted that the ISP that is 2 forwarding e-mails is called the "old ISP" and the ISP that hosts the currently valid account is 3 called the "new ISP." The account for which the e-mail address is no longer current is called a the "FROM account" and the current account, to which mail needs to be forwarded, is called the "TO account." By choice of this convention, the term "old ISP" is not meant to limit the disclosure to situations where an email account has been permanently terminated or 7 abandoned at that ISP. Rather, the term "old ISP" is intended to encompass situations wherein 8 a user having plural current e-mail accounts wishes to have e-mail addressed to one of those accounts temporarily forwarded to another one of his or her accounts.
to 12 The .forward File Embodiment 13 According to one embodiment of the invention, e-mail is forwarded from the old ISP
14 to the new ISP by means of a ".forward" file. The old ISP maintains the FROM account and inserts a .forward file that contains the TO account. As a result, all e-mail is still routed to the 16 old ISP. The message passes through the old ISP's sendmail and the sendmail connects to the 17 machine at the new ISP to deliver the message to the TO account (contained in the forward 18 file) at the new ISP. This is implemented using U1'IX.
19 This embodiment requires that the old ISP keep the FROM account open after the user 2o has abandoned it.
21 The E-Mail Alias Embodiment 22 According to another embodiment of the invention, the old ISP aliases the FROM
23 account to the TO account with an /etc/aliases entry. This uses a lookup table. All e-mail is 24 still routed to the old ISP. The message passes through the old ISP's sendmail and the sendmail connects to a new machine. A consistent address, e.g., user@re-route.com, is used 26 for all customers, although this specific format is not meant as a limitation. Other formats are 27 possible for this alias embodiment. A customer who cancels their re-route service agreement 28 will still have his/her e-mail sent to another consistent address, e.g., cheapskate@re-29 route.com. This procedure should be supported in all Internet systems, as explained in RFC
(request for comment) 1123, which is incorporated by reference herein, in its entirety.
31 This embodiment permits the old ISP to close the FROM account after the user has 32 abandoned it.

2 The Transfer of Mail Exchange Authority with Pass-Through Sendmail Embodiment 3 According to another embodiment of the invention, the ISPs give MX Authority to a 4 Re-route Central Authority entity (e.g., re-route.com). All e-mail destined for ISPs that have signed up with re-route.com are first routed to re-route.com. For those customers who have 6 informed re-route.com of a change of address, the e-mail is routed to the TO
account.

7 Otherwise, the e-mail messages pass through the re-route.com system to the ISP to which 8 they are nominally addressed.

9 One result of this embodiment is that all e-mail for all ISPs that subscribe to this to system would need to pass through servers for the Re-route Central Authority entity.
11 The Mail Exchange Routing Embodiment 12 According to another embodiment of the invention, a fundamental change is made to 13 the way that e-mail is routed on the Internet. The change is that client name resolver libraries 14 use the entirety of the addresses -- both the user portion and the fully qualified domain name portion -- for queries. Based on this change of address interpretation, Mail Exchange Re-route 16 Directory (MXRRD) keys can be used by Domain Name Servers to hold entries for 17 individuals' e-mail accounts.
18 There are two alternate sub-embodiments of this re-route arrangement. One is that the 19 Re-route Central Authority can be the Mail Exchange Authority and distribute a master copy of a re-route mapping database. The other is that the ISPs maintain their respective Mail 21 Exchange Authorities and rely on the Re-route Central Authority to trigger updates to the re-22 route mapping database.
23 Seize and Forward Embodiment 24 In the "seize and forward" embodiment of the present invention, the ISP
retains all of the customer account information. However, for those customers that have left the ISP's 26 service, all e-mail for such customers is stored at the ISP for a time. At regular intervals, the 27 server of the present invention logs onto the server of the ISP and seizes all of the e-mail that 28 is being stored for those accounts that are no longer active at the ISP.
This "seized" or 29 downloaded e-mail is sorted by the present invention and for those accounts that have 3o registered with the re-route server, the e-mail is forwarded to the new account at the new ISP.
31 Simple Mail Transfer Protocol (SMTP) Wrapper Embodiment 32 The SMTP wrapper embodiment may be implemented via software or via hardware.
33 In the software implementation, the SMTP wrapper a a software wrapper around an ISP's 1 message transport system such as "sendmail," program that determines how that wrapped 2 code is to be executed. In the hardware implementation, the SMTP wrapper is a device 3 disposed, preferably, between an ISP and the Internet, to intercept e-mail messages. Thus, the SMTP wrapper determines how the sendmail transport program of the ISP is to operate. In this case, the wrapper passes through e-mails that are bound for those individuals who 6 formerly had an account at the ISP. E-mails that are passed through the ISP
are sent to the 7 server of the present invention for forwarding to the individual at the new ISP.
8 Bounced Mail Embodiment 9 The bounced mail embodiment of the present invention allows those ISP's that l0 "bounce" mail, that is, return mail to a sender when the party to whom it is addressed is no 11 longer available for any reason, to bounce the mail instead to the re-route server of the present 12 invention. In this embodiment, any mail that cannot be delivered by an ISP
is bounced to, for 13 example, bounced@re-route.com. The re-route server then reviews the bounced mail to 14 determine if it is for a person or entity that is a registered re-route user. If so, the mail is forwarded to the new address on file at the re-route server.
16 lPv6 Embodiment 17 A pressing problem that now exists is the potential for shortages of Internet addresses.
18 The most viable candidate to replace the current Internet Protocol is Internet Protocol Version 19 6 (IPv6). This protocol allows a huge number of new IP unique addresses to be possible 2o together with new routing schemes. DNS can resolve fully qualified domain names into 1P
21 addresses. Assuming that everyone will be able to have a unique IPv6 address in the future, 22 traffic can be re-routed to individuals based on their respective IPv6 addresses.
23 OSI X.500 Embodiment 24 The Open Systems Interconnect (OSI) model is a model of network architecture and a suite of protocols to implement it developed by ISO as a framework for international 26 standards in heterogeneous computer network architecture. X.500 (the set of ITU-T standards 27 covering electronic directory services, such as white pages, Knowbot, and whois.) can support 28 alternate addresses for individuals/recipients of e-mail. Such an X.500 system connected to 29 the Internet e-mail system could re-route e-mail to the alternate addresses once they have been 3o so designated by a user. In this instance the X.500 system receives e-mail at fromAccount. If 31 the user has a toAccount entry, the mail is re-routed.
32 "Forwarding" Symbol in Local-Part Embodiment 1 Internet Standard RFC-822 defines the Internet standard format for electronic mail 2 message headers. By using the "local part" of the mail message header, e-mail can be 3 forwarded. For example, the address @gstead@mlj.com contains a symbol "@"
before the name to designate a forwarding symbol. Alternatively a new symbol such as "rr!" might be s designated as the universal re-route symbol for e-mail. While this does not designate a 6 specific address, it does indicate to any server that the mail is to be re-routed if possible. Then 7 certain of the other methods for re-route described herein can be used such as forwarding mail 8 to the re-route server. In this instance, the sendmail systems must be programmed to 9 recognize and treat a universal symbol as meaning re-route.
1o Re-route Extensions Embodiment 11 The re-route extension embodiment allows users to simply append the extension ".re-12 route.com" to an e-mail address (e.g., user@oldisp.com.re-route.com). This will provide 13 automatic re-routing of e-mail if a recipient has so registered. If no re-route information has 14 been provided, the e-mail is simply passed through to the original address.
In this case the re-15 route server becomes the MX authority for re-route.com e-mail, thus all e-mail having the 16 extension is re-routed to the re-route server to be reviewed.
17 LDAP Embodiment 18 The Lightweight Directory Access Protocol (LDAP) is a protocol for accessing on-19 line directory services. The e-mail client can download the fromAccount, toAccount list 2o directly into e-mail client software for addressing e-mail. Thus, changing addressing from one 21 account another, by acquiring the correct e-mail address, can be done at the client computer.
22 Routing of the e-mail to the correct address can then be accomplished.
23 SMTP Return Codes 24 It is possible for SMTP implementation to verify that e-mail addresses are deliverable 25 during the sending process. If a given e-mail is not deliverable to a first, old address, the e-26 mail can be delivered to a second host, assuming that the appropriate address at the new 27 second host is known. This forwarding is done directly by the old ISP, which forwards the 28 message either to a re-route server (and then, indirectly, on to the user's new address) or 29 directly to the user's new account at a new ISP. These direct and indirect methods are 3o explained in further detail below.
31 Client E-mail Plugin 32 This embodiment takes advantage of the common practice of many ISPs to bounce 33 undeliverable emails back to the sending computer. A software plugin or wrapper is provided 2506-EM001 _ v~~ ~ ~ OCT 2Qu0 i at the sending computer, which handles e-mail messages that are bounced back to it. When an 2 e-mail message is bounced back, the e-mail plugin prompts the user to ask them if they would 3 like to attempt to re-route the bounced email using any of the methods described herein. This is done, for example via a graphical user interface having a "re-route" button that the user may click on. In the event the user chooses to click the re-route button, thereby choosing to 6 attempt a rerouting of the e-mail message, the e-mail message is then resent, this time 7 addressed to the re-route server. The re-route server then forwards the message on to the 8 correct current e-mail address for the intended recipient, assuming that the intended recipient's new e-mail address is registered with the re-route server.
1 o As noted above, the present invention comprises a method and apparatus for rerouting 11 e-mail destined for a person or entity formerly located at a given ISP and forwarding that e-12 mail to the new e-mail address for the recipient who may be located at a subsequent ISP.
13 Referring to Figure 1, the request handler for the ".forward"
implementation of the present 14 invention is illustrated. The user who desires to have its e-mail redirected registers with the re-route server of the present invention. The re-route server sends a re-route request to the 16 old ISP. The request is received at the old ISP 10, which is usually accompanied by a digital 17 signature of the requesting party. The digital signature is decoded 12, and the request along 18 with the digital signature is provided to a process for determining whether the re-route request 19 message is a valid one 14. If the message is determined not to be valid, as in the case of an 2o individual who is not a client or former client of the old ISP, for example, an error is noted 21 and the process ends 16.
r,'"22 If the message is a valid one, the request to re-route the e-mail is decrypted 18 and a 23 determination.is made whether authentication is required 20. If authentication is required, the ...
24 user is authenticated 22. If the authentication is successful 26, the address to which the user would like mail forwarded is written to a ".forward" file 24 in the storage of the old ISP. If the 26 user can not be authenticated, the process is terminated and an authentication error is sent to 27 the requesting party 30. On the other hand, once the new address is written to the .forward file 2s of the old ISP, the request process is completed 28, and the server simply waits for e-mail 29 traffic addressed to the old address of the user.
3o Referring to Figure 2A, a first embodiment of the e-mail re-route path is illustrated.
31 This figure illustrates the path of re-routed e-mail after an authenticated request is processed.
32 Sender computer 32 sends e-mail to a recipient at the old ISP address 34 of the recipient. The 33 old ISP 34 recognizes that the recipient is no longer subscribing to that ISP, and designates .. .......i i ~r~~US ~r~J j'~~~6 2506-EM001 ,_ 1 any mail for that recipient to be sent to the re-route server 36 based upon the .forward file 2 stored at the old ISP and designating the re-route server as the location in the .forward file.
3 Old ISP 34 therefore forwards the recipient's e-mail over the Internet 42 to the re-route server a 36. The old ISP 34 reviews the accounts of its subscribers and matches the incoming e-mail for the recipient to an address in its .forward file, which in this implementation is at the re-6 route server 36. Thereafter, the e-mail is re-addressed to the re-route server 36, which in turn 7 associates that e-mail with the new address of the recipient at the new ISP.
The re-route 8 server 36 then forwards the e-mail to the new ISP 38 which stores the e-mail until downloaded by the recipient's computer 40. As noted above this implementation provides 1 o security for the new address of the recipient in that the address is known to the re-route server t 1 but not to the old ISP.
12 Referring to Figure 2B, a direct e-mail re-route path of the present invention is 13 illustrated. In this instance, re-route server 36 is notified by a user of the intent to re-route 14 mail as described in Figure 1 above. Re-route server provides a re-route request to the old ISP
as described in Figure 1. In this case however, that information to the old ISP comprises the 16 new address of the recipient at the new ISP 38. Thereafter, a sender computer 32 sends an e-17 mail message to the prior address of the recipient at the old ISP 34. ISP
34 has been notified 1 s by the re-route server 36 of the new address of the recipient. The old ISP
34 then reviews its 19 .forward files, fords the re-route request of the recipient, designates mail coming to the 2o recipient's old address with the new ISP address. The message is then forwarded over the z 1 Internet 42 to the new ISP 38, which generally stores the e-mail until downloaded by the 22 recipient 40.
r ~23 . teferring to Figure 2; the e-mail alias embodiment of the re-route request handler is 24 illustrated. Again, a user registers with the re-route server of the present invention. The re-route server then sends a re-route request to the old ISP. This alternative embodiment re-26 route request handler functions in a similar fashion as described in Figure 1 (above), except 27 that when a decrypted request 18 is determined to either require authentication 20, thus 28 resulting in an authenticated user 22 and the determination that the authentication was 29 successful 26, or alternatively, authentication is not required, an alias table is created in the old ISP wherein the recipient's former Internet address is mapped to a new address in the 31 table.
to -:~Lp S'~E~f 1 Referring to Figure 2A, the e-mail re-route path of the alternative embodiment 2 described in Figure 2 is shown. In this instance the sender has registered with the re-route 3 server 36 and the re-route server 36 has sent its re-route request to the old ISP naming the re-4 route server as the entity to be listed in the alias file of the old ISP for e-mail sent to the user.
The sender's computer 32 sends an e-mail message addressed to the recipient's old e-mail 6 address at the old ISP 34. The old ISP 34 recognizes that this is a message to be re-routed 7 since there is a valid re-route request stored at the old ISP. The old ISP
reviews its alias table 8 and fords that the alias for the recipient is the address of the re-route server 36. The old ISP
passes the message through its sendmail to the re-route server 36. The re-route server looks at l0 its alias table for the recipient, and determines the recipient's new e-mail address. The mail is 11 then forwarded via the Internet 42 to the new ISP 38, where it is stored until downloaded by 12 the recipient's computer 40.
13 Referring to Figure 2B, the direct e-mail re-route path of the e-mail alias embodiment 14 shown in Figure 2 is illustrated. In this instance, re-route server 36 provides the alias for the recipient to the old ISP 34. Thereafter, a sender's computer 32 sends an e-mail message to the 16 recipient addressed to the old ISP 34. Old ISP 34 reviews its alias table to determine the new 17 e-mail address of the recipient and re-addresses the mail directly to the new ISP 38, which in 18 turn sends it on to the recipient 40 via the Internet 42.
19 Referring to Figure 3, the mail exchange authority with pass-through sendmail alternative embodiment re-route handler is shown. In this embodiment, the re-route server 21 becomes the MX authority for the ISP(s) that register with the service. In this instance, the 22 figure illustrates a situation where the re-route server functions as a gateway for all e-mail 23 destined for a number of different ISPs. In this instance, various ISPs subscribe to the re-route 24 service, and all e-mail destined for any of the ISPs that are subscribers initially are routed to the re-route server. In this instance, e-mail is received at the re-route server 44. The server 26 checks to see if the recipient is a re-route customer 46. A re-route customer is an individual 27 who has signed up with the re-route server to have his or her e-mail forwarded to a new 28 address. If the recipient is not a re-route customer 46, the re-route server takes no action with 29 respect to the e-mail, but simply allows it to go forward to the recipient's ISP 48. If, however, 3o the recipient is determined to be a re-route customer, the e-mail is forwarded to the recipient's 31 "toAccount" address which has been provided by the re-route customer to the re-route server 32 50.

1 Referring to Figure 3A, the e-mail re-route path of the alternative embodiment of 2 Figure 3 is shown. Sender computer 32 addresses e-mail to a recipient. That e-mail goes 3 directly to re-route server 36, which makes the determination as to whether the recipient is a re-route customer or not. If the individual is not a re-route customer, the e-mail is simply sent on its way to the old ISP 34. If, however, the re-route server 36 determines that the recipient 6 is a re-route customer, the e-mail is forwarded to the new ISP 38 over the Internet 42 for 7 storage and subsequent download. to the recipient 40.
8 Referring to Figure 4, the request handler of yet another alternative embodiment of 9 the present invention is illustrated. This request handler operates in the same respect as 1o Figures 1 and 2, except that, after successful authentication 20, 22, 26, or, in the case where 11 authentication is not required, a re-route customer's "toAccount" is written to a DNS table 23, 12 thereby providing an address for the recipient different from that to which messages might be 13 sent. In this instance, a sender might realize that a recipient has moved but does not know the 14 address of the recipient. In this case, the sender sends messages directly to the re-route server in anticipation that this message will be forwarded to the recipient.
16 Referring to Figure 4A, the e-mail re-route path of the present invention is illustrated.
17 In this instance, sender's computer 32 sends an e-mail message directly to the re-route server 18 36 which has the DNS table associated with the new address of the recipient stored therein.
19 Thereafter, re-route server 36 re-addresses the e-mail to the recipient at the new ISP 38 for 2o delivery to the recipient 40 over the Internet 42.
21 Referring to Figure 4B, the e-mail direct re-route path noted in Figure 4 is illustrated.
22 Here, the sender computer sends its message to the re-route server 36. In this instance, 23 however, the re-route server 36 provides the new address to the sender's computer 32.
24 Thereafter, the sender's computer 32 can send e-mail to the new ISP address of the recipient 38, which is then forwarded to the recipient 40 over the Internet 42.
26 Referring to Figure 5 the seize and forward implementation of the present invention 27 is illustrated. The process is initiated 52. The timer is next initialized 54 to set the frequency 28 with which e-mail is retrieved from the ISP at which a user's e-mail is located. The system at 29 the re-route server determines whether the initialized timer has expired 56, thereby signaling 3o that retrieval of e-mail must take place. If the timer has not expired, the re-route server waits 31 58 and continues to query the timer.

1 If the timer has expired, the re-route server logs onto the old ISP 60 from which mail 2 must be retrieved. The re-route server inquires if there is mail for the specific re-route 3 customer 62. If e-mail is present, the e-mail is retrieved by the re-route server 64 and 4 forwarded to the customer's toAccount 66 which is known to the re-route server. Thereafter the process begins again and waits until the next retrieval time. If there is no e-mail for the 6 re-route customer, the re-route server simply waits until the next time interval for retrieval to 7 be attempted.
8 Referring to Figure SA the e-mail re-route path for the seize and forward 9 implementation is illustrated. Sending computer 32 send e-mail to the re-route customer at to the old ISP. The old ISP recognizes that this is a former subscriber and stores the e-mail. Re-11 route server 36 makes in retrieval inquiry with the former ISP 34. Mail is then downloaded to 12 the re-route server 36 where it is forwarded to the new address at a new ISP 38 over the 13 Internet 42. Thereafter, the recipient/re-route customer 40, retrieves the e-mail in the normal 14 course of activities.
Referring to Figure 6, the request handler for yet another alternative embodiment of 16 the present invention is illustrated. Again, this request handler fimctions in exactly the same 1 ~ manner as that described in Figure 1 (above), except that rather than writing the "toAccount"
1s to a .forward file or to an alias file, the toAccount is written to a private alias file for 19 subsequent use in forwarding e-mail to the new ISP.
Referring to Figure 6A, the e-mail handler of the alternative preferred embodiment 21 described in Figure 6 is illustrated. E-mail for the recipient is received 68, and a 22 determination is made by the re-route server whether the recipient is in the private alias file 23 70. If the individual is not in the private alias file, the e-mail is presented to the old ISPs e-24 mail software 72. If, however, the recipient is in the private alias file 70, then the e-mail is forwarded to the recipient's "toAccount" 74.
26 The e-mail re-route path of the embodiment of Figure 6 is illustrated in Figure 6B.
27 This re-route path is similar in all respects to that described in Figure 2A, except that re-route 28 server 36 has a private alias file which determines the address to which mail for the recipient z9 will proceed.
3o Referring to Figure 7, another alternative embodiment of the present invention is 31 illustrated. In this instance, ISPs subscribe to the service of the re-route invention. When an 32 old ISP bounces mail that is sent to a former recipient who was a subscriber to the old ISP, a ~~s ::.r ~:. t~~ °;'''',rr~-'~' 1 bounced mail message is sent both to the sender's computer and to the re-route server.
2 Thereafter, if the re-route server determines that the mail is destined for a recipient who is a 3 re-route customer, it is forwarded appropriately. For example, mail is received at the re-route 4 server 76. The re-route server determines if the mail is bounced mail 78 coming from an old ISP. If the mail coming to the re-route server is not bounced mail 80, the process terminates.
6 If the mail reaching the re-route server is bounced mail, the re-route server determines if the 7 mail is addressed to a recipient who is a re-route customer 82. If the person to whom the 8 bounced mail is addressed is not a re-route customer, the process is terminated 84. If, 9 however, the e-mail is destined to a re-route customer having a "toAccount"
with the re-route to server, that mail is forwarded to the recipient's latest e-mail address 86.
11 Referring to Figure 7A, the e-mail re-route path of the embodiment noted in Figure 7 12 is illustrated. In this instance, sender's computer 32 sends e-mail destined to the old e-mail 13 address of a recipient to the old ISP 34. Old ISP 34 is a subscriber to the re-route service of 14 the present invention. It sends a bounced mail message to the sender's computer 32 and also to the re-route server 36. If the recipient to whom the mail is addressed is a customer of the 16 re-route server 36, the re-route server checks to determine the new e-mail address of the 17 recipient and forwards the e-mail over the Internet 42 to the new ISP 38.
New ISP 38 then 18 forwards the mail to the recipient 40.
19 Referring to Figure 8, yet another alternative embodiment of the present invention is 2o illustrated. In this instance, the request handler operates in the same manner as first noted in 21 Figure 1 (above). However, after appropriate authentication processes 20, 22, 24 the 22 toAccount and IP address of the recipient is updated 29.
23 Referring to Figure 8A, the re-route path for the embodiment described in Figure 8 is 24 shown. In this instance, a sending computer 32 sends an e-mail addressed to the old ISP 34.
The old ISP 34, knowing that the recipient has moved, forwards the message to the re-route 26 server 36. The re-route server 36 has had its toAccount and IP address for the recipient 27 updated. The e-mail address is changed by the re-route server 36 and directed to the new ISP
28 38 for deliver over the Internet 42 to the recipient 40.
29 Referring to Figure 8B, the e-mail re-route direct path is shown. In this instance, re-3o route server 36 provides the appropriate toAccount and 1P address update to the old ISP 34.
31 Thereafter, when the sending computer 32 sends an e-mail message to the recipient's address 1 at the old ISP 34, the old ISP 34 can forward that e-mail to the new ISP 38 over the Internet 2 42 for delivery to the recipient 40.
3 Referring to Figure 9, an alternative embodiment of the present invention is shown. In 4 this instance, request handler functions in the same manner as noted in Figure 1 (above).
s However, after appropriate authentication processes 20, 22, 26, the toAccount is updated and 6 written to a X.500 database. The database is subsequently provided to the old ISP for 7 processing of re-routed e-mails.
8 Referring to Figure 9A, the indirect e-mail re-route path of the embodiment of Figure 9 is illustrated. In this case, re-route server 36 provides the updated X.500 database to the old 1o ISP 34. Thereafter, a sender's computer 32 sends an e-mail to a recipient at the old ISP 34.
11 Old ISP 34 matches the incoming e-mail with the X.500 database and.forward the e-mail on 12 to the re-route server 36 via the Internet 42. The re-route server 36 then handles sending the e-13 mail to the recipient. The e-mail is re-addressed and sent to the new ISP
38 over the Internet 14 42 for subsequent delivery to the recipient 40.
1s Referring to Figure 9B, the direct e-mail re-route path of the embodiment of Figure 9 16 is illustrated. In this instance, re-route server 36 provides the updated X.500 database to the 17 old ISP 34. Thereafter, a sender's computer 32 sends an e-mail to a recipient at the old ISP 34.
18 Old ISP 34 matches the incoming e-mail with the X.500 database and new address for the 19 recipient. Thereafter, the e-mail is re-addressed and sent to the new ISP
38 over the Internet 20 42 for subsequent delivery to the recipient 40.
21 Referring to Figure 10, an additional alternative embodiment of the present invention 22 is illustrated. In this instance, an old ISP receives e-mail 52. The server of the old ISP reviews 23 the e-mail to determine if the e-mail contains a symbol indicative of the fact that this e-mail is 24 to be re-routed to another location 54. If there is no re-route symbol, processing of the e-mail 25 continues in the normal fashion 56. In the event that there is a re-route symbol associated with 26 the e-mail message, the message is forwarded to the re-route server 58.
27 Referring to Figure 10A, e-mail handling in the re-route server is illustrated. The re-28 routed e-mail is received at the e-mail handler of the re-route server 60.
The re-route server 29 determines if the re-route symbol is present 62. If there is no re-route symbol, processing 3o ceases. If there is a re-route symbol present, the re-route server determines if the recipient of 31 the message is a re-route customer 66. If the recipient is not a re-route customer, processing 1 terminates 68. If the individual is a re-route customer, the e-mail is forwarded to the 2 recipient's toAccount 70.
3 Referring to Figure 10B, the e-mail re-route path is shown. Sender 32 sends an e-mail message that is knows must be re-routed to the recipient. However, the sending computer 32 only knows the recipient's old e-mail address. Therefor, the e-mail is addressed to the old ISP
6 34. However, the message also comprises a re-route symbol. Old ISP 34 recognizes the re-route symbol and sends the e-mail on to the re-route server 36. Re-route server 36 determines 8 if the recipient is a re-route customer and, if so, forwards the e-mail to the new ISP 38 over the Internet 42 for delivery to the recipient's computer 40.
Referring to Figure 11, yet another embodiment of the present invention is illustrated.
11 In this instance, e-mail is received 72 at the re-route server. The re-route server determines if 12 there is a re-route extension on the e-mail address 74. If the extension is not present, 13 processing ceases 76. If a re-route extension is present on the e-mail message, the re-route 14 server determines if the recipient is a re-route customer 78, that is, an individual who is registered for the re-route service. If the individual is not a re-route customer, the message is 16 delivered to the original ISP 80. If, however, the recipient is a re-route customer, the e-mail is 17 forwarded to the recipient's toAccount, as stored by the re-route server 82.
18 Referring to Figure 11A, the e-mail re-route path of the embodiment illustrated in 19 Figure 11 is shown. Sending computer 32 sends an e-mail message with a re-route extension 2o to the re-route server 36. Re-route server 36 determines if the individual to whom the 21 message is sent is a re-route customer. If the individual is not a re-route customer, the 22 message is sent to the old ISP 34. If the individual is a re-route customer, the message is re-23 routed to the new ISP 38 over the Internet 42 for delivery to the recipient 40.
24 Referring to Figure 12, the LDAP client functionality is shown. A request is first made to obtain an address for a recipient 84 that a sender knows has moved.
The re-route 26 LDAP server is queried 86 for the re-route address. The re-route server determines if a re-27 route address is available 88. If no address is available, the client can not re-route the e-mail 28 90. If a new e-mail address is available, the "to" address for the recipient is updated in the 29 client computer 92. Thereafter, the address update is completed and e-mail messages can be sent.
31 Referring to Figure 12A, the e-mail re-route path of the embodiment noted in Figure 32 12 is illustrated. Sending computer 32 queries the re-route server computer 36 for a re-route 1 address for a recipient. This is the instance where the sending computer knows that the 2 recipient has moved, but is unaware of the new address. If there is a re-route address for the 3 recipient, the mail is forwarded to the new ISP 38 over the Internet 42 for delivery to the 4 recipient 40. In addition, the re-route server notifies the sender's computer to update its "to"
address file.
6 Referring to Figure 12B, the direct e-mail re-route path is shown. This is fairly simple 7 after the "to" file for the recipient is updated by the re-route server 36.
Thereafter, the sending 8 computer 32 has the appropriate address of the new ISP 38 and mail can be forwarded to the new ISP 38 over the Internet 42 to the recipient 40.
1 o Referring to Figure 13, a re-route request handler of yet another embodiment of the 11 present invention is illustrated. This request handler operates in the same fashion as first 12 noted in Figure 1 (above). However, after the authentication procedures 20, 22, 26, the 13 toAccount for the recipient is written to an SMTP table. This SMTP table 31 holds the new 14 address for receiving e-mail.
Referring to Figure 13A, the e-mail re-route path is illustrated. Sending computer 32 16 sends an e-mail message to the recipient's last known e-mail address at the old ISP 34. The 17 old ISP 34, recognizing that this recipient is no longer at the ISP, forwards the message to the 18 re-route server. The re-route server receives the toAccount information for the recipient and 19 matches it to the entry in the SMTP table stored at the re-route server 36.
Thereafter, the 2o message is re-addressed and sent to the new ISP 38 over the Internet 42 for delivery to the 21 recipient 40.
22 Referring to Figure 13B, the e-mail re-route direct path is illustrated. In this instance, 23 the old ISP 34 contains the SMTP table and associated address relating to the toAccount of 24 the recipient. The sending computer 32 sends the e-mail address to the recipient's address at the old ISP 34. Old ISP 34 matches the toAccount information to the SMTP table and 26 forwards the e-mail over the Internet 42 to the new ISP 38 for delivery to the recipient 40.
27 Referring to Figure 14, a client plug-in module for the re-routing of e-mail is 28 illustrated. E-mail is received at the client 96. The e-mail is then reviewed to determine if it is 29 bounced e-mail 98. If the e-mail is not bounced, the client plug-in performs no further 3o processing 100. If the e-mail is bounced, the user is prompted to re-route the e-mail 102. The 31 user then decides whether to re-route the e-mail 104, and if not, processing terminates 106. If 32 the user wants to re-route the e-mail, the e-mail is forwarded to the re-route server 108.

1 Referring to Figure 14A, the e-mail re-route path is shown. Sending computer 2 sends an e-mail to the old ISP 34. Old ISP 34 notes that the recipient is no longer present and 3 bounces the e-mail back to the sending computer 32. Sending computer 32 notes that the e 4 mail is bounced e-mail, and therefor forwards it to the re-route server 36.
Re-route server 36, recognizing that the recipient is a re-route customer, forwards the e-mail to the new ISP 38 6 over the Internet 42 for delivery to the recipient 40.
7 Referring to Figure 14B, the e-mail re-route path that is more direct is shown. In this 8 instance, sending computer 32 sends an e-mail to the old ISP address for the recipient 34. The old ISP bounces the e-mail back to the sending computer 32, having the new e-mail address l0 via its plug-in module, then sends e-mail to the new ISP 38 over the Internet 42 for delivery 11 to the recipient 40.
12 Referring to Figure 15, the Re-route Add Request flow is illustrated. A
user creates 13 the user data 200 that indicates the new e-mail address to which the user would like e-mail 14 forwarded. The user data 200 may, alternatively, be created by the user's new ISP on the user's behalf. This user data 200 is sent to the re-route server, which comprises software for 16 receiving and processing user data 202.
17 The re-route server checks the user data 204 to insure that all necessary information is 18 present to form the re-route request and to register the user with the re-route server. If the 19 data is in any way deficient, the re-route request is denied and a message so indicating is sent 206 to the user's computer (or the user's new ISP, as the case may be). If the data is 21 sufficient, a re-route request is formulated 208 and sent to the re-route request handling 22 routine 210 at the old ISP.
23 Once a re-route request is receive at the old ISP from the re-route server, the old ISP
24 checks to determine if the request has the necessary data 214 to be acted on by the old ISP.
This involves the old ISP checking its own user records 212 to determine if the user is a 26 subscriber to the old ISP, to update its subscriber records regarding the status of the user, as 27 well as to update the e-mail tables 216 at the old ISP to reflect the action needed for e-mail 28 destined for the user. Such action has been described in detail in a variety of embodiments 29 (above).
If the request is satisfactory in all respects, the re-route request is accepted and an 31 acceptance message 220 is sent to the re-route server, and the e-mail re-route request is 32 confirmed to the user 224 (or the user's new ISP, as the case may be). If the data supplied to 1 the old ISP is not satisfactory in all respects, a re-route denial message 218 is sent to the re-2 route server, and a ''re-route denied" message 222 is sent to the user (or the user's new ISP, as 3 the case may be).
Referring to Figure 16, the Re-route Delete Request flow is illustrated. Part of any re-route request of a user is a length of time for which the re-route request is to be in force.
6 This may be set by the user or may be a standard amount of time set by the re-route server 7 business rules. Once the time duration for the re-route request has expired, the re-route server 8 generates an extension request 228 that is sent to the user's mailbox 226 or to the user's last 9 known ISP. The system then waits for a user's response 230.
to If there is no response from the user within a given amount of time, a re-route delete 11 request 232 is automatically generated by the re-route server and forwarded to the request 12 handler 234 of the old ISP. The old ISP then updates its e-mail tables 236 by deleting the 13 forwarding address for the user.
14 After updating its e-mail tables 236, the old ISP sends an acknowledgment message 238 to the re-route server. The re-route server accepts the message 240, ends its re-route 16 service for the user 242, and forwards a message so indicating to the user's mailbox 244 at 17 the user's computer (or the user's ISP, as the case may be).
18 Referring to Figure 17, the Re-route Update Request flow is illustrated. A
user 19 creates the updated user data 250 that indicates the updated e-mail address to which the user 2o would like e-mail forwarded. The updated user data 250 may, alternatively, be created by the 21 user's new ISP on the user's behalf. This updated user data 250 is sent to the re-route server, 22 which comprises software for receiving and processing updated user data 252.
23 The re-route server checks the updated user data 254 to insure that all necessary 24 information is present to form the re-route update request and to register the user's updated data with the re-route server. If the data is in any way deficient, the re-route update request is 26 denied and a message so indicating is sent 256 to the user computer (or the user's new ISP, as z7 the case may be). If the updated data is sufficient, a re-route update request is formulated 258 28 and sent to the re-route update request handling routine 260 at the old ISP.
29 Once a re-route update request is received at the old ISP from the re-route server, the old ISP checks to determine if the re-route update request has the necessary data 264 to be 31 acted on by the old ISP. This involves the old ISP checking its own user records 262 to 1 determine if the user was (or is) a subscriber to the old ISP, to update its subscriber records 2 regarding the status of the user, as well as to update the e-mail tables 266 at the old ISP.
3 If the request is satisfactory in all respects, the re-route update request is accepted and an acceptance message 270 is sent to the re-route server, and the e-mail re-route update request is confirmed to the user 274 (or the user's new ISP, as the case may be). If the 6 updated data supplied to the old ISP is not satisfactory in all respects, a re-route update denial 7 message 268 is sent to the re-route server, and a "re-route update denied"
message 272 is sent 8 to the user (or the user's new ISP, as the case may be).
9 The re-route server is implemented as follows. The e-mail re-route server receives e-to mails from the Internet and re-routes them according to the rules described above. The e-mail 11 server is based on known, robust, Internet e-mail server architectures.
Preferably, the re-route 12 server is one or more Unix-based machines running the sendmail mail software. In addition to 13 typical e-mail processing, the re-route server's mail software performs additional, optional i4 operations. These additional operations include:
- interfacing to the re-route subscriber database/tables to query information on 16 subscriber preferences (status, spam filtering, sender notification, virus checking, etc.) 17 - interfacing to the re-route subscriber database/tables to insert information about 18 current events (e-mail status, sender, date, etc.). This information will be used for 19 billing and report generation.
- Additional e-mail processing (spam filtering, virus checking, sender 21 notification, etc.) 22 Hardware requirements depend on the number of customers, however as an example, a 23 system that handles a moderate number of re-route subscribers includes a Sun server running 24 the Solaris (Unix) operating system.
A database server holds information about each customer, and about the e-mails 26 received by the mail re-route server. This information is used for billing and report 27 generation. The database server is based on known, robust, database server architectures.
28 Preferably, this server is a Unix-based machine running Oracle or MySQL
database server 29 software.
3o The present invention has been described in terms of a number of preferred 31 embodiments. However, it will be understood by those of ordinary skill in the art that various 32 modifications and improvements may be made to the invention as described, without departing from the scope of the invention. The scope of the invention is limited only by the appended claims.

Claims (64)

We Claim:

1. A method of re-routing e-mail comprising:
a recipient registering with a re-route server;
the re-route server sending a re-route request to an old ISP;
the old ISP receiving and processing the re-route request; and the old ISP re-routing e-mail for the recipient to a new ISP after the receipt and processing of the re-route request.

2. The method of re-routing e-mail of claim 1, wherein:
the re-route server sending a re-route request to an old ISP further comprises the re-route server sending a new address for the recipient to the old ISP.

3. The method of re-routing e-mail of claim 2, wherein the new address for the recipient comprises the address of the new ISP at which the recipient is located.

4. The method of re-routing e-mail of claim 2, wherein the new address for the recipient comprises the address of the re-route server.

5. The method of re-routing e-mail of claim 2, further comprising the old ISP
maintaining a "FROM" account for the recipient;
inserting a ".forward" file comprising a "to" account comprising the new address for the recipient; and forwarding e-mail for the recipient to the new address when it is received at the old ISP.

6. The method of re-routing e-mail of claim 2, further comprising the old ISP
maintaining and aliasing a FROM account for the recipient with an alias entry comprising the new address for the recipient; and forwarding e-mail for the recipient to the new address when it is received at the old ISP.

7. The method of re-routing e-mail of claim 6, wherein the alias entry is stored in a look up table.

8. The method of re-routing e-mail of claim 2, further comprising the old ISP
maintaining an X.500 database;
inserting a "to" account entry into the X.500 database comprising the new address of the recipient; and forwarding e-mail to the new address when it is received at the old ISP.

9. The method of re-routing e-mail of claim 2, further comprising maintaining a DNS table to which the new address comprising a "to" account entry is written; and forwarding e-mail to the new address when the DNS table is accessed.

10. The method of re-routing e-mail of claim 2, further comprising:
writing a "to" account comprising the new address for the recipient to a private alias file;
passing e-mail for other recipients whose addresses are not in the private alias file to e-mail software of the ISP's; and forwarding e-mail for the recipient to the "to" account for the recipient.

11. The method of re-routing e-mail of claim 2, wherein the new address for the recipient is in Internet Protocol version 6 (IPv6) format; and further comprising forwarding e-mail for the recipient to the new address when it is received at the old ISP.

12. The method of re-routing e-mail of claim 2, further comprising:
the re-route server generating a statistical record of the re-route request.

13. The method of re-routing e-mail of claim 12, wherein the generated statistical record includes information regarding the old ISP and the new ISP.

14. The method of re-routing e-mail of claim 12, wherein the generated statistical record includes information indicating customer churn.

15. The method of re-routing e-mail of claim 12, wherein the generated statistical record is added to an aggregated register of from and to data for a plurality of users.

16. The method of re-routing e-mail of claim 2, wherein the old ISP
automatically forwards e-mail directed to an old address at the old ISP to the new address, consistent with Simple Mail Transfer Protocol.

17. A method of re-routing e-mail comprising:
a recipient, that formerly had an old e-mail address at an old ISP, registering a request to re-route the recipient's e-mail with a re-route server;
the old ISP storing e-mail for the recipient;
the re-route server accessing and downloading the e-mail for the recipient stored at the old ISP; and the re-route server forwarding the downloaded e-mail to a new address for the recipient.

18. The method of re-routing e-mail of claim 17, wherein the accessing and downloading occurs on a periodic basis.

19. The method of re-routing e-mail of claim 17, wherein the request to re-route the recipient's e-mail comprises the old address of the recipient at the old ISP
and the new address to which the recipient wants the recipient's e-mail forwarded.

20. A method of re-routing e-mail comprising:
a recipient registering a request to re-route the recipient's e-mail with a re-route server;
the re-route server sending the re-route request to an old ISP;
the old ISP receiving and processing the re-route request;
the old ISP bouncing mail for the recipient to the re-route server when the recipient no longer has an e-mail address at the old ISP;
the re-route server receiving the bounced e-mail for the recipient; and the re-route server forwarding the e-mail to a new address for the recipient.

21. The method of re-routing e-mail of claim 20, wherein the request to re-route the recipient's e-mail comprises an old address of the recipient at the old ISP
and the new address to which the recipient wants the recipient's e-mail forwarded.

22. A method of re-routing e-mail comprising:
a sender of e-mail addressing e-mail to a recipient, the e-mail address comprising a universal re-route symbol in the local part of the e-mail address;
if the recipient is not a subscriber of an old ISP, the old ISP checking if a universal re-route symbol is present in the local part of the e-mail address;
if a universal re-route symbol is present in the local part of the e-mail address, the old ISP forwarding the e-mail to a re-route server;
the re-route server receiving the forwarded e-mail and forwarding the forwarded e-mail to a new address associated with the recipient.

23. The method of re-routing e-mail of claim 22, wherein the re-route server receiving the forwarded e-mail further comprises the re-route server checking if a universal re-route symbol is present in the local part of the e-mail address; and if the recipient is a registered re-route customer, forwarding the e-mail to the new address.

24. A method of re-routing e-mail comprising:

a sender of e-mail addressing e-mail to a recipient, the overall e-mail address comprising an old address of the recipient at an old ISP and a re-route extension to the e-mail address designating a re-route server;
receiving and processing the e-mail at the re-route server;
the re-route server checking to determine if the recipient is a re-route customer;
forwarding the e-mail to a new address associated with the recipient if the recipient is a re-route customer.

25. The method of re-routing e-mail of claim 24, wherein the receiving and processing further comprises the re-route server checking if a re-route extension is present in the overall e-mail address; and ceasing further processing if no re-route extension is present.

26. The method of re-routing e-mail of claim 24, further comprising passing the e-mail through to the old address if the recipient is not a re-route customer.

27. A method of re-routing e-mail comprising:
a sending computer querying a re-route server for an e-mail address of a recipient;
the re-route server determining if an e-mail address for the recipient is available;
if an e-mail address for the recipient is available, the re-route server forwarding e-mail sent by the sending computer to the recipient at the e-mail address.

28. The method of re-routing e-mail of claim 27, wherein the sender computer query comprises a query under the lightweight directory access protocol (LDAP).

29. A method of re-routing e-mail comprising:
a sending computer querying a re-route server for an e-mail address of a recipient;
the re-route server determining if an e-mail address for the recipient is available;
if an e-mail address for the recipient is available, the re-route server providing that address to the sending computer; and the sending computer re-addressing the e-mail to the recipient at the e-mail address.

30. The method of re-routing e-mail of claim 29, wherein the sender computer query comprises a query under the lightweight directory access protocol (LDAP).

31. A method of re-routing e-mail comprising:
an old ISP assigning its mail exchange authority to a re-route server;
the re-route server receiving e-mail addressed to subscribers at the old ISP;
the re-route server comparing the addresses of subscribers to a re-route customer list, the re-route customer list comprising new e-mail addresses for re-route customers;

the re-route server forwarding e-mail addressed to re-route customers to the new e-mail addresses; and the re-route server passing the e-mail through to the old ISP if the subscriber is not a re-route customer.

32. A method for re-routing e-mail comprising:
addressing e-mail using the user portion and the fully qualified domain name portion of e-mail addresses;
creating a mail exchange re-route directory in a re-route server comprising an entry for a recipient's new e-mail address mapped to an old e-mail address of the recipient;
periodically distributing the re-route directory to ISPs for forwarding e-mail from the old e-mail address of the recipient to the new e-mail address of the recipient.

33. A method for re-routing e-mail comprising:
addressing e-mail using both the user portion and the fully qualified domain name portion of e-mail addresses;
creating a mail exchange re-route directory in a re-route server comprising an entry for a recipient's new e-mail address mapped to an old e-mail address of the recipient;
periodically distributing updates to the the re-route directory to ISPs for forwarding e-mail from the old e-mail address of the recipient to the new e-mail address of the recipient.

34. A method of re-routing e-mail comprising:
sending an e-mail message, via a sending computer, to an old address at an old ISP, receiving, at the sending computer, a bounce message from the old ISP
indicating that the old address is not valid, prompting a user, at the sending computer, for a command to re-route the bounced e-mail message, resending the bounced e-mail message, in the event the user issues the command to re-route, this time addressed to a re-route server, the re-route server forwarding the resent e-mail message to the new address for the intended recipient, assuming that the intended recipient is a registered re-route customer.

35. A system for re-routing of e-mail comprising:
a sending computer for sending e-mail to a recipient;
a network connected to the sending computer;

an old ISP, connected to the network, at which the recipient formerly was a subscriber and at which the recipient had an old e-mail address;
a re-route server connected to the network for processing re-route requests and effecting the forwarding of e-mail to the recipient;
a new ISP, connected to the network, at which the recipient has a new e-mail address;
and a recipient computer for receiving e-mail addressed to the recipient at the new e-mail address.

36. The system for re-routing e-mail of claim 35, wherein the re-route server comprises a server memory embodying software instructions adapted to enable the re-route server to perform: receiving an email re-route request from the recipient, and forwarding the re-route request to the old ISP; and wherein the old ISP comprises an old ISP memory embodying software instructions adapted to enable the re-route server to perform: receiving and processing the re-route request.

37. The system for re-routing e-mail of claim 36, wherein the re-route request received by the re-route server from the recipient comprises the new address of the recipient.

38. The system for re-routing e-mail of claim 36, wherein the re-route request forwarded to the old ISP comprise instructions for forwarding the e-mail of the recipient to the new address for the recipient at the new ISP.

39. The system for re-routing e-mail of claim 36, wherein the old ISP further comprises a "FROM" account for the recipient, and wherein the software instructions embodied in the old ISP memory further enable the old ISP to perform receiving and processing the re-route request by:
inserting a ".forward" file comprising a "to" account comprising the new address of the recipient; and forwarding e-mail for the recipient to the new address when it is received at the old ISP.

40. The system for re-routing e-mail of claim 36, wherein the old ISP further comprises a "FROM" account for the recipient, and wherein the software instructions embodied in the old ISP memory further enable the old ISP to perform receiving and processing the re-route request by:

aliasing the FROM account for the recipient with an alias entry comprising the new address for the recipient; and forwarding e-mail for the recipient to the new address when it is received at the old ISP.

41. The system for re-routing e-mail of claim 36, wherein the old ISP further comprises a "FROM" account for the recipient and an X.500 database in which the "FROM"
account is stored, and wherein the software instructions embodied in the old ISP
memory further enable the old ISP to perform receiving and processing the re-route request by:
inserting a "to" account entry into the X.500 database comprising the new address of the recipient; and forwarding e-mail to the new address when it is received at the old ISP.

42. The system for re-routing e-mail of claim 36, further comprising storage, in which a DNS table is stored, the DNS table comprising a "to" account comprising the new address of the recipient; and wherein the software instructions embodied in the old ISP memory further enable the old ISP to perform: forwarding e-mail for the recipient to the new address.

43. The system for re-routing e-mail of claim 36, wherein an SMTP wrapper augments a message transport system of the old ISP; and wherein the software instructions embodied in the old ISP memory further enable the old ISP to perform: creating a private alias file comprising a "to" account comprising the new address for the recipient;
passing e-mail for other recipients whose addresses are not in the private alias file to the message transport system of the old ISP; and forwarding e-mail for the recipient to the "to" account for the recipient.

44. The system for re-routing e-mail of claim 36, wherein the new address comprises an e-mail address in Internet Protocol version 6 (IPv6) format.

45. The system for re-routing e-mail of claim 36, wherein software instructions embodied in the old ISP memory further enable the old ISP to perform: holding e-mail for the recipient for further action by the re-route server.

46. The system for re-routing e-mail of claim 45, wherein the software instructions embodied in the server memory further enable the re-route server to perform:
storing the new address of the recipient;

periodically downloading from the old ISP stored e-mail for the recipient; and forwarding the downloaded e-mail for the recipient to the new address stored in the re-route server.

47. The system for re-routing e-mail of claim 36, wherein the software instructions embodied in the old ISP memory further enable the old ISP to perform: bouncing e-mail that is addressed to a recipient that is no longer a subscriber to the old ISP.

48. The system for re-routing e-mail of claim 47, wherein bouncing e-mail includes bouncing e-mail to both the sending computer and to the re-route server.

49. The system for re-routing e-mail of claim 48, wherein the software instructions embodied in the server memory further enable the re-route server to perform:
checking to determine if the bounced e-mail is for a recipient who is registered with the re-route server; and forwarding the bounced e-mail to the new address of the recipient if the recipient is registered with the re-route server.

50. The system for re-routing e-mail of claim 35, wherein the e-mail sent by the sending computer further comprises a universal re-route symbol in the local part of the e-mail address thereby causing the old ISP to determine if the recipient is a current subscriber of the old ISP;
the old ISP comprising an old ISP memory embodying software instructions adapted to enable the old ISP to perform: forwarding the e-mail to the re-route server if the recipient is not a subscriber of the old ISP;
the re-route server comprising a server memory embodying software instructions adapted to enable the re-route server to perform: detecting the presence of the universal re-route symbol; determining if the recipient is a re-route subscriber; and forwarding the e-mail to the new address if the recipient is a re-route subscriber.

51. The system for re-routing e-mail of claim 35, wherein the e-mail sent by the sending computer comprises the old address of the recipient at the old ISP and a re-route extension designating the re-route server;
the server memory further embodying software instructions adapted to enable the re-route server to perform: determining if the recipient is a re-route customer;
and forwarding the e-mail to the new address if the recipient is a re-route customer.

52. The system for re-routing e-mail of claim 35, wherein the sending computer comprises a sending computer memory embodying software instructions adapted to enable the sending computer to perform: first querying the re-route server to determine if the new address is available for the recipient;
the re-route server comprising a server memory embodying software instructions adapted to enable the re-route server to perform: providing the new address to the sending computer if the new address is available; and wherein the software instructions embodied in the sending computer memory further enable the sending computer to perform: forwarding the e-mail to the new address if the new address is available.

53. The system for re-routing e-mail of claim 52, wherein the sending computer query is under the lightweight directory access protocol (LDAP).

54. The system for re-routing e-mail of claim 35, wherein the sending computer comprises a sending computer memory embodying software instructions adapted to enable the sending computer to perform: first querying the re-route server to determine if the new address is available for the recipient;
the re-route server comprising a server memory embodying software instructions adapted to enable the re-route server to perform: determining if the new address is available; and forwarding the e-mail to the new address if the new address is available.

55. The system for re-routing e-mail of claim 54, wherein the sending computer query is under the lightweight directory access protocol (LDAP).

56. The system for re-routing e-mail of claim 35, wherein the re-route server further comprises Mail Exchange (MX) authority for the old ISP;
the re-route server comprising a server memory embodying software instructions adapted to enable the re-route server to perform: receiving e-mail addressed to subscribers of the old ISP;
comparing the addresses of subscribers to the old ISP to a re-route customer list, the re-route customer list comprising new addresses for re-route customers; and forwarding the e-mail to the new addresses if the e-mail is addressed to subscribers to the old ISP who are also subscribers to the re-route server.

57. The system for re-routing e-mail of claim 56, wherein the software instructions embodied in the server memory further enable the re-route server to perform:
passing the e-mail through to the old ISP if the e-mail is not addressed to a re-route subscriber.

58. The system for re-routing e-mail of claim 35, wherein the re-route server further comprises a mail exchange re-route directory further comprising an entry for the recipient's new e-mail address mapped to the old e-mail address, each entry comprising a user portion and a fully qualified domain name portion;
the re-route server comprising a server memory embodying software instructions adapted to enable the re-route server to perform: distributing the mail exchange directory to the old ISP, thereby allowing the old ISP to forward e-mail to the new address of the recipient.

59. The system for re-routing e-mail of claim 35, wherein the re-route server comprises a server memory embodying software instructions adapted to enable the re-route server to perform: sending a re-route add request message to the old ISP upon receiving a request from the recipient for re-route service.

60. The system for re-routing e-mail of claim 59, wherein the software instructions embodied in the server memory further enables the re-route server to perform:
sending a message to the recipient confirming that the request for re-route service is accepted, in the event that a message is received from the old ISP indicating that the re-route add request message has been accepted.

61. The system for re-routing e-mail of claim 35, wherein the re-route server comprises a server memory embodying software instructions adapted to enable the re-route server to perform: sending a re-route delete request message to the old ISP, in the event that no re-route service extension authorization is indicated by the recipient.

62. The system for re-routing e-mail of claim 61, wherein the software instructions embodied in the server memory further enables the re-route server to perform:
sending a message to the recipient indicating that re-route service is ended, in the event that a message is received from the old ISP indicating that the re-route delete request message has been accepted.

63. The system for re-routing e-mail of claim 35, wherein the re-route server comprises a server memory embodying software instructions adapted to enable the re-route server to perform: sending a re-route edit request message to the old ISP upon receiving a request from the recipient for updated re-route service.

64. The system for re-routing e-mail of claim 63, wherein the software instructions embodied in the server memory further enables the re-route server to perform:
sending a message to the recipient confirming that the request for updated re-route service is accepted, in the event that a message is received from the old ISP indicating that the re-route edit request message has been accepted.