Misplaced Pages

#163836

97-463: At one time, the designers of X.400 were expecting it to be the predominant form of email, but this role has been taken by the SMTP -based Internet e-mail . Despite this, it has been widely used within organizations and was a core part of Microsoft Exchange Server until 2006; variants continue to be important in military and aviation contexts. Design issues of protocols for computer mail were explored in

194-514: A DNS name). This server will deliver outgoing messages on behalf of the user. Server administrators need to impose some control on which clients can use the server. This enables them to deal with abuse, for example spam . Two solutions have been in common use: Under this system, an ISP 's SMTP server will not allow access by users who are outside the ISP's network. More precisely, the server may only allow access to users with an IP address provided by

291-505: A Transmission Control Protocol (TCP) connection. An SMTP session consists of commands originated by an SMTP client (the initiating agent , sender, or transmitter) and corresponding responses from the SMTP server (the listening agent, or receiver) so that the session is opened, and session parameters are exchanged. A session may include zero or more SMTP transactions. An SMTP transaction consists of three command/reply sequences: Besides

388-447: A mail user agent (MUA), or a relay server's mail transfer agent (MTA), that is an SMTP server acting as an SMTP client, in the relevant session, in order to relay mail. Fully capable SMTP servers maintain queues of messages for retrying message transmissions that resulted in transient failures. A MUA knows the outgoing mail SMTP server from its configuration. A relay server typically determines which server to connect to by looking up

485-444: A 1993 draft of ITU-T Recommendation F.401, which looked like: 1984 had two forms for address formats: In the 1988 X.400 Recommendations, four forms of addressing were delineated. The 1984 Form 1, Variant 1 format was renamed as the mnemonic O/R address and the 1984 Form 1, Variant 3 and Form 2 format were combined and renamed the terminal O/R address. New forms introduced were the numeric O/R form (a variation of Form 1, Variant 2) and

582-477: A bit more complex to decode by software on usual processors because it will require additional contextual bit-shifting and masking and not direct byte addressing (but the same remark would be true with modern processors and memory/storage units whose minimum addressable unit is larger than 1 octet). However modern processors and signal processors include hardware support for fast internal decoding of bit streams with automatic handling of computing units that are crossing

679-447: A command is acknowledged by the server with a result code and response message (e.g., 250 Ok ). The transmission of the body of the mail message is initiated with a DATA command after which it is transmitted verbatim line by line and is terminated with an end-of-data sequence. This sequence consists of a new-line ( <CR><LF> ), a single full stop ( . ), followed by another new-line ( <CR><LF> ). Since

776-483: A derivative of SMTP designed for this purpose. Once delivered to the local mail server, the mail is stored for batch retrieval by authenticated mail clients (MUAs). Mail is retrieved by end-user applications, called email clients, using Internet Message Access Protocol (IMAP), a protocol that both facilitates access to mail and manages stored mail, or the Post Office Protocol (POP) which typically uses

873-406: A domain name to an unqualified address. This behavior is helpful when the message being fixed is an initial submission, but dangerous and harmful when the message originated elsewhere and is being relayed. Cleanly separating mail into submission and relay was seen as a way to permit and encourage rewriting submissions while prohibiting rewriting relay. As spam became more prevalent, it was also seen as

970-524: A fixed maximum message size no larger than 14,680,064 octets (8-bit bytes). ASN.1 Abstract Syntax Notation One ( ASN.1 ) is a standard interface description language (IDL) for defining data structures that can be serialized and deserialized in a cross-platform way. It is broadly used in telecommunications and computer networking , and especially in cryptography . Protocol developers define data structures in ASN.1 modules, which are generally

1067-523: A general structure for all existing and future extensions which aimed to add-in the features missing from the original SMTP. ESMTP defines consistent and manageable means by which ESMTP clients and servers can be identified and servers can indicate supported extensions. Message submission ( RFC   2476 ) and SMTP-AUTH ( RFC   2554 ) were introduced in 1998 and 1999, both describing new trends in email delivery. Originally, SMTP servers were typically internal to an organization, receiving mail for

SECTION 10

#1732791609164

1164-723: A mail server for relaying, and typically submit outgoing email to the mail server on port 587 or 465 per RFC   8314 . For retrieving messages, IMAP (which replaced the older POP3 ) is standard, but proprietary servers also often implement proprietary protocols, e.g., Exchange ActiveSync . SMTP's origins began in 1980, building on concepts implemented on the ARPANET since 1971. It has been updated, modified and extended multiple times. The protocol version in common use today has extensible structure with various extensions for authentication , encryption , binary data transfer, and internationalized email addresses . SMTP servers commonly use

1261-404: A message body can contain a line with just a period as part of the text, the client sends two periods every time a line starts with a period; correspondingly, the server replaces every sequence of two periods at the beginning of a line with a single one. Such escaping method is called dot-stuffing . The server's positive reply to the end-of-data, as exemplified, implies that the server has taken

1358-459: A module can specify an integer field that must be in the range 0 to 100. The length of a sequence of values (an array) can also be specified, either as a fixed length or a range of permitted lengths. Constraints can also be specified as logical combinations of sets of basic constraints. Values used as constraints can either be literals used in the PDU specification, or ASN.1 values specified elsewhere in

1455-549: A number of predefined encoding rules. If none of the existing encoding rules are suitable, the Encoding Control Notation (ECN) provides a way for a user to define his or her own customized encoding rules. Privacy-Enhanced Mail (PEM) encoding is entirely unrelated to ASN.1 and its codecs, but encoded ASN.1 data, which is often binary, is often PEM-encoded so that it can be transmitted as textual data, e.g. over SMTP relays, or through copy/paste buffers. This

1552-713: A remote host to start processing of the mail queue on a server so it may receive messages destined to it by sending a corresponding command. The original TURN command was deemed insecure and was extended in RFC   1985 with the ETRN command which operates more securely using an authentication method based on Domain Name System information. An email client needs to know the IP address of its initial SMTP server and this has to be given as part of its configuration (usually given as

1649-433: A remote server on demand, SMTP has a feature to initiate mail queue processing on a remote server (see Remote Message Queue Starting below). POP and IMAP are unsuitable protocols for relaying mail by intermittently-connected machines; they are designed to operate after final delivery, when information critical to the correct operation of mail relay (the "mail envelope") has been removed. Remote Message Queue Starting enables

1746-518: A schema, making them easy to use. They are also both cross-platform standards that are broadly popular for communications protocols, particularly when combined with a JSON schema or XML schema . Some ASN.1 tools are able to translate between ASN.1 and XML schema (XSD). The translation is standardised by the ITU. This makes it possible for a protocol to be defined in ASN.1, and also automatically in XSD. Thus it

1843-494: A section of a broader standards document written in the ASN.1 language. The advantage is that the ASN.1 description of the data encoding is independent of a particular computer or programming language. Because ASN.1 is both human-readable and machine-readable , an ASN.1 compiler can compile modules into libraries of code, codecs , that decode or encode the data structures. Some ASN.1 compilers can produce code to encode or decode several encodings, e.g. packed, BER or XML . ASN.1

1940-536: A single and readily usable open-source implementation, and is published as a specification to be implemented by third-party vendors. However, ASN.1, defined in 1984, predates them by many years. It also includes a wider variety of basic data types, some of which are obsolete, and has more options for extensibility. A single ASN.1 message can include data from multiple modules defined in multiple standards, even standards defined years apart. ASN.1 also includes built-in support for constraints on values and sizes. For instance,

2037-460: A single machine, or split among multiple machines; mail agent processes on one machine can share files, but if processing is on multiple machines, they transfer messages between each other using SMTP, where each machine is configured to use the next machine as a smart host . Each process is an MTA (an SMTP server) in its own right. The boundary MTA uses DNS to look up the MX (mail exchanger) record for

SECTION 20

#1732791609164

2134-417: A single public directory. For instance, each Administration Management Domain (service provider) could optionally upload their directory to a shared X.500 server, and then allow this database to be searched by the X.400 User Agents during email creation, thereby avoiding needing to know anything about the address other than the recipient's name and some sort of organizational name like a company. Unfortunately,

2231-406: A standard for Military Messaging based on X.400. One of the core issues X.400 attempted to address was the failure of an email to be properly delivered when the address was not specified correctly. At the time, addressing formats varied from platform to platform, so it was difficult for users to know how to properly type them in. Any error caused the delivery to fail outright. This was in contrast to

2328-502: A user is mobile, and may use different ISPs to connect to the internet, this kind of usage restriction is onerous, and altering the configured outbound email SMTP server address is impractical. It is highly desirable to be able to use email client configuration information that does not need to change. Modern SMTP servers typically require authentication of clients by credentials before allowing access, rather than restricting access by location as described earlier. This more flexible system

2425-587: A way to provide authorization for mail being sent out from an organization, as well as traceability. This separation of relay and submission quickly became a foundation for modern email security practices. As this protocol started out purely ASCII text-based, it did not deal well with binary files, or characters in many non-English languages. Standards such as Multipurpose Internet Mail Extensions ( MIME ) were developed to encode binary files for transfer through SMTP. Mail transfer agents (MTAs) developed after Sendmail also tended to be implemented 8-bit clean , so that

2522-909: A wide range of communication tasks. For example, the P1 protocol is used explicitly for communication among MTAs , P3 between the user agent and an MTA, and P7 between the user agent and message store. In the 1994 version, P7 was enhanced to provide folders in the message store, allow storage of submitted messages, and provide many automatic actions such as auto-foldering and correlation of replies, delivery reports and receipt notifications with submitted messages. X.400 message content standards are defined for communication between user agents. These are modelled as conceptual protocols that treat P1 and P3/P7 as providing an underlying reliable transport of message contents. The message content standard for interpersonal messaging, IPM, defined in ITU-T Rec. X.420 | ISO/IEC 10021-7

2619-481: Is a type–length–value encoding, so the sequence above can be interpreted, with reference to the standard SEQUENCE, INTEGER, and IA5String types, as follows: Alternatively, it is possible to encode the same ASN.1 data structure with XML Encoding Rules (XER) to achieve greater human readability "over the wire". It would then appear as the following 108 octets, (space count includes the spaces used for indentation): Alternatively, if Packed Encoding Rules are employed,

2716-640: Is a joint standard of the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) in ITU-T Study Group 17 and International Organization for Standardization / International Electrotechnical Commission (ISO/IEC), originally defined in 1984 as part of CCITT X.409 :1984. In 1988, ASN.1 moved to its own standard, X.208 , due to wide applicability. The substantially revised 1995 version

2813-468: Is an example ASN.1 module defining the messages (data structures) of a fictitious Foo Protocol: This could be a specification published by creators of Foo Protocol. Conversation flows, transaction interchanges, and states are not defined in ASN.1, but are left to other notations and textual description of the protocol. Assuming a message that complies with the Foo Protocol and that will be sent to

2910-502: Is available). The client notifies the receiver of the originating email address of the message in a MAIL FROM command. This is also the return or bounce address in case the message cannot be delivered. In this example the email message is sent to two mailboxes on the same SMTP server: one for each recipient listed in the To: and Cc: header fields. The corresponding SMTP command is RCPT TO . Each successful reception and execution of

3007-517: Is believed by many to be one factor in the lack of success of X.400. An X.400 address is technically referred to as an Originator/Recipient (OR) address. It has two purposes: An X.400 address consists of several elements, including: The standards themselves originally did not specify how these email addresses should be written (for instance on a business card) or even whether the field identifiers should be upper or lower case, or what character sets were allowed. RFC 1685 specified one encoding, based on

X.400 - Misplaced Pages Continue

3104-511: Is covered by the X.680 series. The latest revision of the X.680 series of recommendations is the 6.0 Edition, published in 2021. ASN.1 is a data type declaration notation. It does not define how to manipulate a variable of such a type. Manipulation of variables is defined in other languages such as SDL (Specification and Description Language) for executable modeling or TTCN-3 (Testing and Test Control Notation) for conformance testing. Both these languages natively support ASN.1 declarations. It

3201-785: Is defined in ITU-T Recs. F.440 and X.440. Exchange Server 2007 does not use the MTA object, and the X.400 connector (which must use the MTA) is gone in Exchange Server 2007. There are no longer any X.400 default proxy e-mail addresses in Exchange Server 2007. Important features of X.400 include structured addressing, ASN.1 binary code enabling multimedia content (predating and more efficient than MIME ), and integrated security capabilities. As X.400 inter-domain relay services were assumed by ITU to be run by PTTs , X.400 incorporated fields for

3298-760: Is friendly to mobile users and allows them to have a fixed choice of configured outbound SMTP server. SMTP Authentication , often abbreviated SMTP AUTH, is an extension of the SMTP in order to log in using an authentication mechanism. Communication between mail servers generally uses the standard TCP port 25 designated for SMTP. Mail clients however generally don't use this, instead using specific "submission" ports. Mail services generally accept email submission from clients on one of: Port 2525 and others may be used by some individual providers, but have never been officially supported. Many Internet service providers now block all outgoing port 25 traffic from their customers. Mainly as an anti-spam measure, but also to cure for

3395-466: Is needed for most non-text data and some text formats). In 2012, the SMTPUTF8 extension was created to support UTF-8 text, allowing international content and addresses in non- Latin scripts like Cyrillic or Chinese . Many people contributed to the core SMTP specifications, among them Jon Postel , Eric Allman , Dave Crocker, Ned Freed , Randall Gellens, John Klensin , and Keith Moore . Email

3492-428: Is not used to define type–length–value encodings. Many programming languages define language-specific serialization formats. For instance, Python's "pickle" module and Ruby's "Marshal" module. These formats are generally language specific. They also don't require a schema, which makes them easier to use in ad hoc storage scenarios, but inappropriate for communications protocols. JSON and XML similarly do not require

3589-457: Is possible to import an ASN.1 module and declare a variable of any of the ASN.1 types declared in the module. ASN.1 is used to define a large number of protocols. Its most extensive uses continue to be telecommunications, cryptography, and biometrics. ASN.1 is closely associated with a set of encoding rules that specify how to represent a data structure as a series of bytes. The standard ASN.1 encoding rules include: ASN.1 recommendations provide

3686-472: Is referred to as Interpersonal Messaging (IPM); electronically structured business documents (e.g., invoices, purchase orders, dispatch advice, etc.) exchanged among trading partners’ computers fall under the EDI protocols. Message handling is a distributed information processing task that integrates two related subtasks: message transfer and message storage. The ITU-T Recommendations define specific protocols for

3783-417: Is submitted by a mail client ( mail user agent , MUA) to a mail server ( mail submission agent , MSA) using SMTP on TCP port 587. Most mailbox providers still allow submission on traditional port 25. The MSA delivers the mail to its mail transfer agent (MTA). Often, these two agents are instances of the same software launched with different options on the same machine. Local processing can be done either on

3880-668: Is that connecting to an MSA requires SMTP Authentication . SMTP is a delivery protocol only. In normal use, mail is "pushed" to a destination mail server (or next-hop mail server) as it arrives. Mail is routed based on the destination server, not the individual user(s) to which it is addressed. Other protocols, such as the Post Office Protocol (POP) and the Internet Message Access Protocol (IMAP) are specifically designed for use by individual users retrieving messages and managing mailboxes . To permit an intermittently-connected mail server to pull messages from

3977-492: Is visually similar to Augmented Backus-Naur form (ABNF), which is used to define many Internet protocols like HTTP and SMTP . However, in practice they are quite different: ASN.1 defines a data structure, which can be encoded in various ways (e.g. JSON, XML, binary). ABNF, on the other hand, defines the encoding ("syntax") at the same time it defines the data structure ("semantics"). ABNF tends to be used more frequently for defining textual, human-readable protocols, and generally

X.400 - Misplaced Pages Continue

4074-435: The MX (Mail eXchange) DNS resource record for each recipient's domain name . If no MX record is found, a conformant relaying server (not all are) instead looks up the A record . Relay servers can also be configured to use a smart host . A relay server initiates a TCP connection to the server on the " well-known port " for SMTP: port 25, or for connecting to an MSA, port 587. The main difference between an MTA and an MSA

4171-588: The Transmission Control Protocol on port number 25 (between servers) and 587 (for submission from authenticated clients), both with or without encryption. Various forms of one-to-one electronic messaging were used in the 1960s. Users communicated using systems developed for specific mainframe computers . As more computers were interconnected, especially in the U.S. Government's ARPANET , standards were developed to permit exchange of messages between different operating systems. Mail on

4268-418: The "real" postal service, where even partial addresses would be routed to a dead letter office where they will attempt to deliver it even if some of the information is missing or wrong. To solve this problem, the X.400 address scheme included several redundant fields that could be used to help deliver the message. For instance, there were separate fields for first and last name, as well as initials. The server

4365-782: The ARPANET traces its roots to 1971: the Mail Box Protocol, which was not implemented, but is discussed in RFC   196 ; and the SNDMSG program, which Ray Tomlinson of BBN adapted that year to send messages across two computers on the ARPANET. A further proposal for a Mail Protocol was made in RFC 524 in June 1973, which was not implemented. The use of the File Transfer Protocol (FTP) for "network mail" on

4462-796: The ARPANET was proposed in RFC 469 in March 1973. Through RFC 561, RFC 680, RFC 724, and finally RFC 733 in November 1977, a standardized framework for "electronic mail" using FTP mail servers on was developed. SMTP grew out of these standards developed during the 1970s. Ray Tomlinson discussed network mail among the International Network Working Group in INWG Protocol note 2 , written in September 1974. INWG discussed protocols for electronic mail in 1979, which

4559-464: The ISP, which is equivalent to requiring that they are connected to the Internet using that same ISP. A mobile user may often be on a network other than that of their normal ISP, and will then find that sending email fails because the configured SMTP server choice is no longer accessible. This system has several variations. For example, an organisation's SMTP server may only provide service to users on

4656-624: The X.400-series recommendations specify OSI standard protocols for exchanging and addressing electronic messages. The companion F.400-series of recommendations define Message Handling Services built on Message Handling Systems (MHS), as well as access to and from the MHS for public services. In the late 1990s, the ITU-T consolidated recommendations F.400 and X.400 and published the ITU-T F.400/X.400 (06/1999) recommendation "Message handling system and service overview". The X.400-series recommendations define

4753-521: The X.500 protocol proved to be every bit as complex and unwieldy as X.400, and this led to the creation of the Lightweight Directory Access Protocol , or LDAP, that standardized a simple subset of the X.500 protocols suitable for use by end-user software searching for addresses. LDAP is widely used in directory services like Microsoft's Active Directory . Additionally, the goal of providing a universal address database

4850-523: The alternate "just send eight" strategy could be used to transmit arbitrary text data (in any 8-bit ASCII-like character encoding) via SMTP. Mojibake was still a problem due to differing character set mappings between vendors, although the email addresses themselves still allowed only ASCII . 8-bit-clean MTAs today tend to support the 8BITMIME extension, permitting some binary files to be transmitted almost as easily as plain text (limits on line length and permitted octet values still apply, so that MIME encoding

4947-490: The answers array between 1 and 10 elements. The anArray field is a fixed length 100 element array of integers that must be in the range 0 to 1000. The '...' extensibility marker means that the FooHistory message specification may have additional fields in future versions of the specification; systems compliant with one version should be able to receive and transmit transactions from a later version, though able to process only

SECTION 50

#1732791609164

5044-431: The automated transfer of messages between X.400 and other PTT services, such as Telex , facsimile and physical postal mail. ISO later added open routing standards (ITU-T Rec. X.412 | ISO/IEC 10021-10 and ITU-T Rec. X.404 | ISO/IEC 10021-11), but the initial misconception that X.400 required PTT relay services, coupled with PTT volume-based charges for these, were factors that inhibited the widespread uptake of X.400. From

5141-522: The body of the message itself. STD 10 and RFC   5321 define SMTP (the envelope), while STD 11 and RFC   5322 define the message (header and body), formally referred to as the Internet Message Format . SMTP is a connection-oriented , text-based protocol in which a mail sender communicates with a mail receiver by issuing command strings and supplying necessary data over a reliable ordered data stream channel, typically

5238-410: The boundaries of addressable storage units (this is needed for efficient processing in data codecs for compression/decompression or with some encryption/decryption algorithms). If alignment on octet boundaries was required, an aligned PER encoder would produce: (in this case, each octet is padded individually with null bits on their unused most significant bits). Most of the tools supporting ASN.1 do

5335-530: The corporate SMTP server.) This issue, a consequence of the rapid expansion and popularity of the World Wide Web , meant that SMTP had to include specific rules and methods for relaying mail and authenticating users to prevent abuses such as relaying of unsolicited email ( spam ). Work on message submission ( RFC   2476 ) was originally started because popular mail servers would often rewrite mail in an attempt to fix problems in it, for example, adding

5432-467: The current destination(s) had been queued. The information that the client sends in the HELO and MAIL FROM commands are added (not seen in example code) as additional header fields to the message by the receiving server. It adds a Received and Return-Path header field, respectively. Some clients are implemented to close the connection after the message is accepted ( 250 Ok: queued as 12345 ), so

5529-509: The early 1980s. The first X.400 Recommendations were published in 1984 ( Red Book ), and a substantially revised version was published in 1988 ( Blue Book ). New features were added in 1992 ( White Book ) and subsequent updates. Although X.400 was originally designed to run over the OSI transport service , an adaptation to allow operation over TCP/IP , RFC 1006, has become the most popular way to run X.400. Developed in cooperation with ISO / IEC ,

5626-408: The encoded PER are padded with null bits in the 6 least significant bits of the last byte c0 : these extra bits may not be transmitted or used for encoding something else if this sequence is inserted as a part of a longer unaligned PER sequence. This means that unaligned PER data is essentially an ordered stream of bits, and not an ordered stream of bytes like with aligned PER, and that it will be

5723-415: The encoder knows that encoding an IA5String byte value requires only 7 bits. However the length bytes are still encoded here, even for the first integer tag 01 (but a PER packer could also omit it if it knows that the allowed value range fits on 8 bits, and it could even compact the single value byte 05 with less than 8 bits, if it knows that allowed values can only fit in a smaller range). The last 6 bits in

5820-448: The exchange.) After the message sender (SMTP client) establishes a reliable communications channel to the message receiver (SMTP server), the session is opened with a greeting by the server, usually containing its fully qualified domain name (FQDN), in this case smtp.example.com . The client initiates its dialog by responding with a HELO command identifying itself in the command's parameter with its FQDN (or an address literal if none

5917-488: The fields specified in the earlier version. Good ASN.1 compilers will generate (in C, C++, Java, etc.) source code that will automatically check that transactions fall within these constraints. Transactions that violate the constraints should not be accepted from, or presented to, the application. Constraint management in this layer significantly simplifies protocol specification because the applications will be protected from constraint violations, reducing risk and cost. To send

SECTION 60

#1732791609164

6014-472: The following 122 bits (16 octets amount to 128 bits, but here only 122 bits carry information and the last 6 bits are merely padding) will be produced: In this format, type tags for the required elements are not encoded, so it cannot be parsed without knowing the expected schemas used to encode. Additionally, the bytes for the value of the IA5String are packed using 7-bit units instead of 8-bit units, because

6111-492: The following: A list of tools supporting ASN.1 can be found on the ITU-T Tool web page . ASN.1 is similar in purpose and use to Google Protocol Buffers and Apache Thrift , which are also interface description languages for cross-platform data serialization. Like those languages, it has a schema (in ASN.1, called a "module"), and a set of encodings, typically type–length–value encodings. Unlike them, ASN.1 does not provide

6208-440: The generated serialization / deserialization routines, raising errors or exceptions if out-of-bounds data is encountered. It is complex to implement all aspects of ASN.1 constraints in an ASN.1 compiler. Not all tools support the full range of possible constraints expressions. XML schema and JSON schema both support similar constraints concepts. Tool support for constraints varies. Microsoft's xsd.exe compiler ignores them. ASN.1

6305-452: The higher cost they have when leaving it open, perhaps by charging more from the few customers that require it open. A typical example of sending a message via SMTP to two mailboxes ( alice and theboss ) located in the same mail domain ( example.com ) is reproduced in the following session exchange. (In this example, the conversation parts are prefixed with S: and C: , for server and client , respectively; these labels are not part of

6402-511: The incoming message, it hands it to a mail delivery agent (MDA) for local delivery. An MDA saves messages in the relevant mailbox format. As with sending, this reception can be done using one or multiple computers, but in the diagram above the MDA is depicted as one box near the mail exchanger box. An MDA may deliver messages directly to storage, or forward them over a network using SMTP or other protocol such as Local Mail Transfer Protocol (LMTP),

6499-441: The initial release " equally happy to dispatch messages via Messaging API (MAPI), X.400, or Simple Mail Transfer Protocol (SMTP) ". In practice however, most of these were poorly produced, and seldom put into operation. In North America, many large defense contractors and universities had also already committed to the Internet and TCP/IP standards, including SMTP for email. There, X.400 is still used in some applications, such as

6596-484: The intermediate reply for DATA, each server's reply can be either positive (2xx reply codes) or negative. Negative replies can be permanent (5xx codes) or transient (4xx codes). A reject is a permanent failure and the client should send a bounce message to the server it received it from. A drop is a positive response followed by message discard rather than delivery. The initiating host, the SMTP client, can be either an end-user's email client , functionally identified as

6693-511: The last two lines may actually be omitted. This causes an error on the server when trying to send the 221 Bye reply. Clients learn a server's supported options by using the EHLO greeting, as exemplified below, instead of the original HELO . Clients fall back to HELO only if the server does not support EHLO greeting. Modern clients may use the ESMTP extension keyword SIZE to query

6790-560: The late 1980s, many major countries committed to the OSI stack, via GOSIP - Government Open Systems Interconnection Profiles . In the United States this was in the form of the 1990 NIST "Federal Information Processing Standard" (FIPS #146). In turn, major computer vendors committed to producing OSI-compliant products, including X.400. Microsoft's Exchange Server was developed in this time period, and internally based on X.400/X.500 - with

6887-400: The message reached the service provider, indicated by the "Administration Management Domain" (ADMD) portion of the address, the system would likely know of the user in question. As this service provider was likely national in scope, simply providing the right country code could be enough information to route the message properly. However, this model fails when the email services are provided by

6984-496: The message that they will try to deliver. The probability that a communication failure occurs exactly at this step is directly proportional to the amount of filtering that the server performs on the message body, most often for anti-spam purposes. The limiting timeout is specified to be 10 minutes. The QUIT command ends the session. If the email has other recipients located elsewhere, the client would QUIT and connect to an appropriate SMTP server for subsequent recipients after

7081-657: The military, intelligence services and aviation, mainly because the X.400 protocol supports encryption , and its functions for integrity and security were developed and deployed much earlier than their SMTP counterparts ( S/MIME , PGP and SMTP-TLS). For similar reasons, it is sometimes used for transmission of EDI messages between applications. In Europe, South America, and Asia, X.400 is quite widely implemented, especially for EDI services. X.400 has been extended for use in military applications - see Military Message Handling System - and aviation - see Aeronautical Message Handling System . Furthermore, NATO uses STANAG 4406 as

7178-459: The most popular operating system on the Internet, Sendmail became the most common MTA (mail transfer agent). The original SMTP protocol supported only unauthenticated unencrypted 7-bit ASCII text communications, susceptible to trivial man-in-the-middle attack , spoofing , and spamming , and requiring any binary data to be encoded to readable text before transmission. Due to absence of a proper authentication mechanism, by design every SMTP server

7275-522: The myQuestion message through the network, the message is serialized (encoded) as a series of bytes using one of the encoding rules . The Foo protocol specification should explicitly name one set of encoding rules to use, so that users of the Foo protocol know which one they should use and expect. Below is the data structure shown above as myQuestion encoded in DER format (all numbers are in hexadecimal): DER

7372-537: The need for developers to hand code protocol constants in their implementation's source code. This significantly aids protocol development; the protocol's constants can be altered in the ASN.1 schema and all implementations are updated simply by recompiling, promoting a rapid and low risk development cycle. If the ASN.1 tools properly implement constraints checking in the generated source code, this acts to automatically validate protocol data during program operation. Generally ASN.1 tools will include constraints checking into

7469-443: The network all the time. Both used a store and forward mechanism and are examples of push technology . Though Usenet's newsgroups were still propagated with UUCP between servers, UUCP as a mail transport has virtually disappeared along with the " bang paths " it used as message routing headers. Sendmail , released with 4.1cBSD in 1983, was one of the first mail transfer agents to implement SMTP. Over time, as BSD Unix became

7566-403: The organization from the outside , and relaying messages from the organization to the outside . But as time went on, SMTP servers (mail transfer agents), in practice, were expanding their roles to become message submission agents for mail user agents , some of which were now relaying mail from the outside of an organization. (e.g. a company executive wishes to send email while on a trip using

7663-434: The postal O/R address. The first large-scale use was conducted in the U.S. under a military communication contract in 1992 to 1997. The confusion caused by the X.400 addressing format led to the creation of the X.500 standard for directory services . The idea was to create a hierarchical and standardized email address directory with replication and distribution functionality that allowed multiple organizations to produce

7760-410: The receiving party, this particular message ( protocol data unit (PDU)) is: ASN.1 supports constraints on values and sizes, and extensibility. The above specification can be changed to This change constrains trackingNumbers to have a value between 0 and 199 inclusive, and questionNumbers to have a value between 10 and 20 inclusive. The size of the questions array can be between 0 and 10 elements, with

7857-422: The recipient's domain (the part of the email address on the right of @ ). The MX record contains the name of the target MTA. Based on the target host and other factors, the sending MTA selects a recipient server and connects to it to complete the mail exchange. Message transfer can occur in a single connection between two MTAs, or in a series of hops through intermediary systems. A receiving SMTP server may be

7954-436: The responsibility of delivering the message. A message can be doubled if there is a communication failure at this time, e.g. due to a power outage: Until the sender has received that 250 Ok reply, it must assume the message was not delivered. On the other hand, after the receiver has decided to accept the message, it must assume the message has been delivered to it. Thus, during this time span, both agents have active copies of

8051-444: The same network, enforcing this by firewalling to block access by users on the wider Internet. Or the server may perform range checks on the client's IP address. These methods were typically used by corporations and institutions such as universities which provided an SMTP server for outbound mail only for use internally within the organisation. However, most of these bodies now use client authentication methods, as described below. Where

8148-456: The schema file. Some ASN.1 tools will make these ASN.1 values available to programmers in the generated source code. Used as constants for the protocol being defined, developers can use these in the protocol's logic implementation. Thus all the PDUs and protocol constants can be defined in the schema, and all implementations of the protocol in any supported language draw upon those values. This avoids

8245-470: The server for the maximum message size that will be accepted. Older clients and servers may try to transfer excessively sized messages that will be rejected after consuming network resources, including connect time to network links that is paid by the minute. Users can manually determine in advance the maximum size accepted by ESMTP servers. The client replaces the HELO command with the EHLO command. Thus smtp2.example.com declares that it can accept

8342-786: The technical aspects of the MHS: ITU-T Rec. X.402 | ( ISO / IEC 10021-2) defines the overall system architecture of an MHS, ITU-T Rec. X.411 | ( ISO / IEC 10021-4) defines the Message Transfer Service (MTS) and its functional component the Message Transfer Agent (MTA) , and ITU-T Rec. X.413 | ( ISO / IEC 10021-5) defines the Message Store. All ITU-T recommendations provide specific terms for descriptions of system entities and procedures. For example, messages (email) exchanged among people

8439-429: The traditional mbox mail file format or a proprietary system such as Microsoft Exchange/Outlook or Lotus Notes / Domino . Webmail clients may use either method, but the retrieval protocol is often not a formal standard. SMTP defines message transport , not the message content . Thus, it defines the mail envelope and its parameters, such as the envelope sender , but not the header (except trace information ) nor

8536-418: The ultimate destination, an intermediate "relay" (that is, it stores and forwards the message) or a "gateway" (that is, it may forward the message using some protocol other than SMTP). Per RFC   5321 section 2.1, each hop is a formal handoff of responsibility for the message, whereby the receiving server must either deliver the message or properly report the failure to do so. Once the final hop accepts

8633-403: The user's company or organization, or when the service provider is not known. In this case, there is no national-scale database of users and an improper organization name is enough to cause it to fail. This is the dominant model today, where companies use an internal server, or even more commonly, use a provider like Microsoft 365, or Gmail , which is invisible outside the organization, and even to

8730-514: The users. In this model, the ADMD is unknown or the same as the organization itself. This multi-part addressing system also led to the format being complex; users were not sure which fields were important and tended to provide all that they could. This made trivial things, like printing the address on a business card or typing it into the email client more difficult than simpler systems like those found in SMTP. The unwieldiness of this addressing format

8827-415: Was an open mail relay . The Internet Mail Consortium (IMC) reported that 55% of mail servers were open relays in 1998, but less than 1% in 2002. Because of spam concerns most email providers blocklist open relays, making original SMTP essentially impractical for general use on the Internet. In November 1995, RFC   1869 defined Extended Simple Mail Transfer Protocol (ESMTP), which established

8924-484: Was developed around the same time as Usenet , a one-to-many communication network with some similarities. SMTP became widely used in the early 1980s. At the time, it was a complement to the Unix to Unix Copy Program (UUCP), which was better suited for handling email transfers between machines that were intermittently connected. SMTP, on the other hand, works best when both the sending and receiving machines are connected to

9021-419: Was fundamentally flawed by the time it was proposed. In the era of national telecommunications companies like British Telecom or France Télécom , people's names and phone numbers were considered public information and already collected into such directories in the form of the phone book . Extending this to email addresses seemed obvious. However, this was simply not the case in the 1980s; at that time, email

9118-447: Was identified with multiple fields, including a company or organization name, as well as the country. The idea was that an address with a misspelt name of the company, for instance, would still contain enough information, the person's name and country, for the message to be properly routed. At the time, it was believed that email would be provided by large service providers, often the national telephone companies. This meant that as long as

9215-519: Was named P2 in the Red Book. The extended version of IPM in the Blue Book was given content-type 22 (for P2 version 2) and is often referred to informally as P22, although that term is not used in the standards. The message content standard for EDI is defined in ITU-T Rec. F.435 | ISO/IEC 10021-8 and ITU-T Rec. X.435 | ISO/IEC 10021-9, and informally referred to as P35. A voice messaging content type

9312-691: Was often associated with business or government users, and those organizations treated their member addresses as valuable, or even confidential. There was no incentive for the organizations to share this data with the public. As RFC2693 put it, "imagine the CIA adding its directory of agents to a world-wide X.500 pool". SMTP The Simple Mail Transfer Protocol ( SMTP ) is an Internet standard communication protocol for electronic mail transmission. Mail servers and other message transfer agents use SMTP to send and receive mail messages. User-level email clients typically use SMTP only for sending messages to

9409-812: Was referenced by Jon Postel in his early work on Internet email. Postel first proposed an Internet Message Protocol in 1979 as part of the Internet Experiment Note (IEN) series. In 1980, Postel and Suzanne Sluizer published RFC   772 which proposed the Mail Transfer Protocol as a replacement for the use of the FTP for mail. RFC   780 of May 1981 removed all references to FTP and allocated port 57 for TCP and UDP , an allocation that has since been removed by IANA . In November 1981, Postel published RFC   788 "Simple Mail Transfer Protocol". The SMTP standard

#163836