Federal Internet Law & Policy
An Educational Project


Navigation Links:
:: Home :: Feedback ::
:: Disclaimer :: Sitemap ::

- Notes
- Internet
- Email
- Proceedings
- - Email Portability Proceeding
- History
- Phishing
- 602P
- Timeline
- Telegraph
- Instant Messaging


Electronic Mail Address

(5) ELECTRONIC MAIL ADDRESS- The term `electronic mail address' means a destination, commonly expressed as a string of characters, consisting of a unique user name or mailbox (commonly referred to as the `local part') and a reference to an Internet domain (commonly referred to as the `domain part'), whether or not displayed, to which an electronic mail message can be sent or delivered.
CAN SPAM Act Sec. 3(5)

Electronic Mail Message

(6) ELECTRONIC MAIL MESSAGE- The term `electronic mail message' means a message sent to a unique electronic mail address.
CAN SPAM Act Sec. 3(6)


  After a user composes a message in an e-mail client program, a program called a mail transfer agent ("MTA") formats 2 that message and sends it to another program that "packetizes" it and sends the packets out to the Internet. Computers on the network then pass the packets from one to another; each computer along the route stores the packets in memory, retrieves the addresses of their final destinations, and then determines where to send them next. At various points the packets are reassembled to form the original e-mail message, copied, and then repacketized for the next leg of the journey. See J. Klensin, RFC 2821: Simple Mail Transfer Protocol (Apr. 2001); Jonathan B. Postel, RFC 821: Simple Mail Transfer Protocol (Aug. 1982), ("RFC 821"). Sometimes messages cannot be transferred immediately and must be saved for later delivery. Even when delivery is immediate, intermediate computers often retain backup copies, which they delete later. This method of transmission is commonly called "store and forward" delivery.
  Once all the packets reach the recipient's mail server, they are reassembled to form the e-mail message. A mail delivery agent ("MDA") accepts the message from the MTA, determines which user should receive the message, and performs the actual delivery
by placing the message in that user's mailbox. One popular MDA is "procmail," which is controlled by short programs or scripts called "recipe files." These recipe files can be used in various ways. For example, a procmail recipe can instruct the MDA to deposit mail addressed to one address into another user's mailbox (e.g., to send mail addressed to "help" to the tech support department), to reject mail from certain addresses, or to make copies of certain messages.
  Once the MDA has deposited a message into the recipient's mailbox, the recipient simply needs to use an e-mail client program to retrieve and read the message. While the journey from sender 3 to recipient may seem rather involved, it usually takes just a few seconds, with each intermediate step taking well under a second. See, e.g., W. Houser et al., RFC 1865: EDI Meets the Internet (Jan. 1996) ("For a modest amount of data with a dedicated connection, a message transmission would occur in a matter of seconds . . . .").

-- United States v. Councilman, ___ F3d ___ slip at 4-5 (1st Cir. Aug 11, 2005) (rehearing en banc)

602P Email Tax Hoax

A hoax that was not terribly serious but nevertheless resulted in a flurry of Congressional action was the infamous 602P hoax. According to a widely circulated email in 1999, Senator Schnell (German for "Fast") had recently introduced the legislative proposal 602P that would impose a 5 cent tax upon every email sent (or assess access charges on modems, aka "The Modem Tax"), with the proceeds going to the US Post Office. It was reported that the March 6 edition of Washingtonian Magazine included an editorial that supported the email tax. Panic spread and Congress was inundated by concerned citizens.

This hoax was an obvious deception. There was no Sen. Schnell. There is no congressional legislation numbering format that includes a "P"; legislation in the House would be H.R. 602 and legislation in the Senate would be S. 602. There was no March 6 edition of Washingtonian; it is a monthly periodical that does not publish issues on specific days. There was no editorial, there was no such legislation, and a Virginia law firm that was the hoax reported was leading the lobbying campaign against the bill did not exist.

Nevertheless, Washingtonian Magazine, the US Post Office, and a multitude of Congressional offices were so inundated by inquiries that they were forced to post responses disclaiming the existence of the legislation - and if it did exist, disclaiming any support for such legislation. In a perfect example of life inside the Beltway, Rep. Upton introduced legislation in response to the non-existence 602P, in order to prohibit the federal government from doing what it had no intention of doing; the measure passed the House.

602P Email Tax Links

Government Activity

  • US Postal Service: Postal Activities and Laws Related to Electronic CommercePDF, GAO-00-188
  • In re Request for declaratory ruling and investigation by Graphnet Systems, Inc., concerning the proposed E-COM service, FCC Docket No. 79-6 (Sept 4, 1979).
  • U.S. Postal Rate Commission, Opinion and Recommended lkbion on Ekxtronic Mail Classification Proposal docket No. MC78-3, Dec. 17, 1979, pp. 278 (with regard to E-COM, "PRC recommended that USPS provide only the printing, enveloping, and hardcopy delivery functions and not the telecommunication function")
  • Guidelines to telecommunications interconnection requirements for message input to the USPS E-COM system , ITS NTIA, April 1981
  • Implications of Electronic Mail and Message Systems for the U.S. Postal Service , Office of Technology Assessment, Congress of the United States, August 1982
    • OTA's analysis suggests that advances in technology and increased competition in the communications marketplace will significantly affect USPS finances, service levels, and labor force requirements over the next two decades. It further suggests that modification or clarification of the USPS role in EMS can, in turn, help determine how effectively USPS accommodates to these changes. Given the difficulty of modifying institutions as large and complex as USPS and the laws and regulations that govern USPS actions, it would seem prudent for Congress and USPS to address these issues aggressively. Changes are taking place so fast in the so-called "communications revolution" that by the time USPS actually experienced significant reductions in conventional mail volume, most opportunities for participation in EMS would have passed and it would be much more difficult to adjust.


  • J. Klensin, IETF RFC 2821, Simple Mail Transfer Protocol (April 2001).
  • J. Postel, IETF RFC 821, Simple Mail Transfer Protocol (August 1982).
  • S. Sluizer, J Postel, NWG RFC 772, Mail Transfer Protocol (Sept 1980)
  • D Crocker, J Vittal, K Pogran, D Henderson, RFC 733, Standard For the Format of ARPA Network Text Messages (Nov. 21, 1977)
  • J Postel, RFC 706, On the Junk Mail Program (1975)
    • In the ARPA Network Host/IMP interface protocol there is no mechanism for the Host to selectively refuse messages. This means that a Host which desires to receive some particular messages must read all messages addressed to it. Such a Host could be sent many messages by a malfunctioning Host. This would constitute a denial of service to the normal users of this Host. Both the local users and the network communication could suffer. The services denied are the processor time consumed in examining the undesired messages and rejecting them, and the loss of network thruput or increased delay due to the unnecessary busyness of the network.
    J White, RFC 524, A Proposed Mail Protocol (June 1973)
  • Michael Kudlick, RFC 469, Network Mail Meeting Summary (Mar. 1973) (agreeing to use the "@" sign proposed by Tomlinson)
  • Abhay Bhushan, RFC 385 Comments on the File Transfer Protocol (adding the command MAIL to FTP)
  • RW Watson, RFC 196, Mail Box Protocol (1971)



  • Douglas Aide, Monopoly Mail: Privatizing the US Postal Service


Web services provided by
:: Home :: About Us :: Contact Us :: Sitemap :: Discussion :: Disclaimer :: Search ::