Editing Simple Mail Transfer Protocol (section)

=== Modern SMTP ===
In November 1995, {{IETF RFC|1869}} defined Extended Simple Mail Transfer Protocol (ESMTP), which established 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 ({{IETF RFC|2476}}) and [[SMTP Authentication|SMTP-AUTH]] ({{IETF 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 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 [[Mail submission agent|message submission agents]] for [[Email client|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 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 ([[Email spam|spam]]). Work on message submission ({{IETF RFC|2476}}) was originally started because popular mail servers would often rewrite mail in an attempt to fix problems in it, for example, adding 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 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 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 is needed for most non-text data and some text formats). In 2012, the <code>SMTPUTF8</code> extension was created to support [[UTF-8]] text, allowing international content and addresses in non-[[Latin script|Latin]] scripts like [[Cyrillic script|Cyrillic]] or [[Chinese characters|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]].