Jump to content

Talk:Simple Mail Transfer Protocol/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

Commands and Error Codes List

Do we really need the commands and error codes? Wikipedia is not a general knowledgebase. --Xcali 04:18, 14 Jun 2005 (UTC)

It's useful, and not overly long. I say leave it.
Beska 18:17, 15 Jun 2005 (UTC)
I'm for leaving the details in.
~ender 2005-10-24 16:24:MST

Not a general knowledgebase? What is it then?

It's an encyclopedia. Paper Encyclopedias don't include some General Info, neither does the wiki

Wikipedia:What_wikipedia_is_not is a good reference. That being said, I think the command and error codes should definately be kept. They are an important part of SMTP, and the descriptions are useful and interesting. ArrowmanCoder 14:39, 17 August 2005 (UTC)

Alternatives

Aren't alternatives being developed for SMTP? Protocols with more security and are able to handle large attachments more efficiently?--ShaunMacPherson 09:54, 3 October 2005 (UTC)

Yes, there's at least one: Internet Mail 2000.
~ender 2005-10-24 16:23:MST

RFC 4952 contains proposals for UTF8SMTP which supports headers and messages using UTF8 codes. John a s 22:59, 30 August 2007 (UTC)

I disagree about the usefulness of this link: www.windowsnetworking.com/articles_tutorials/Understanding-SMTP-Protocol.html. The article is more useful than the link, and for those who want more information, other listed links are better. Also that link is definitely self-promotional spam, as seen here. Aapo Laitinen 17:16, 21 October 2005 (UTC)

History?

So who wrote the protocol, how did it get implemented, etc, etc... I'd like some of the history, and not just dry technical details (which are good to have)
~ender 2005-10-24 16:23:MST

I've split the WP:LEAD section, the content starts now with "history". I've also added a list of main "developers" (authors of relevant RFCs ). Omniplex 01:55, 25 February 2006 (UTC)

Proposed merge

done. Omniplex 07:36, 4 March 2006 (UTC)

ESMTP SIZE

Shouldn't that go to the ESMTP article? I'd like to keep this for the basics without EHLO, and there's still a lot to say about MX priorities, error codes, etc. Nevertheless I've removed the old (?) {{technical}} template here, IMHO the article isn't too bad. -- Omniplex 20:06, 10 April 2006 (UTC)

I thought this would be "simple"  :)
I've no strong feelings about you moving the example if you wish — in the small picture you're correct. But I suggest that the articles collectively have serious problems of incorrect emphasis, ambiguation, and pedagogy.
The emphasis problem as I read ESMTP, "basics without EHLO" no longer exist in the RFC compliant universe ('Support for the EHLO command in servers was made a "MUST,"...'). HELOs aren't basics because they are tolerated in deprecated fallback only after a client first tries EHLO. If HELOs have some advantage for a beginning user doing manual testing or sending, that belongs in a tips-&-tricks focus.
This SIZE example and failure of Wikipedia to help actually happened to me. I originally looked for a solution here (at "Simple Mail Transfer Protocol"), didn't find it, and researched it. Since the research was inherently difficult, I plugged it in back here where I originally expected to find it.
Why did I expect it here? The ambiguation problem is that "Simple Mail Transfer Protocol" is actually a system and "SMTP" is a deprecated protocol, but these terms are used interchangeably in the field. For example, a large number of servers are named 'smtp.example.com', yet they mostly aren't and should not be SMTP protocol. For this reason I'd vote no to the name change as "SMTP", though I might compromise on "SMTP Protocol (Deprecated)"
There are also the specific pedagogy problems of teaching things in slices that are too small to be immediately helpful (separate SMTP & ESMTP pages), or too simplified to recognize in the field. For latter analogy, Old MacDonald's Farm leaves children clueless about agribusiness.
Seems to me that the pages should be combined and structured more or less like:
_Simple Mail Transfer Protocol / ESMTP / SMTP_" {however Wikified}
  • Disambiguation
  • Introduction {to include the first two paragraphs of current "History"}
  • ESMTP Protocol
- example(s) {focused for intermediate users}
  • SMTP Protocol (Deprecated) {what to do when EHLO fails}
- example(s)
  • SMTP Security and Spamming
  • MX Records {focused for advanced users and admin students}
  • History
- developers
  • Related RFCs
Btw, thanks for checking RFC 1870 for being current, and the link to RfC on how to check.

Milo 08:04, 11 April 2006 (UTC)

Okay, let's see what happens. Officially STD 10 + STD 3 are still the full Internet standards, and 2821 is "only" a proposed standard, but as you said that's not exactly related to the reality outside of the IETF. Merging it all would be a bad idea, some extensions like AUTH (ESMTPA + ESMTPS + ESMTPSA) deserve a separate article, and 2476bis (SUBMIT) got now a number, it's at "draft standard" (better than 2821). SIZE+HELP+PIPELINING are pretty basic, having them here or there is both okay at the moment. If we ever reach a point where the complete "mail architecture" is discussed here we could move the extensions to ESMTP - because then SMTP would be a rather long article. No issue at the moment.
(A recent "rv" let me see this talk page in my watchlist, I missed your old comment, sorry). -- Omniplex 02:08, 11 May 2006 (UTC)

So let me get this straight

So e-mail servers like Rogers Yahoo and Hotmail use SMTP as a base, then transfer the message to your mailbox? 70.25.138.179 20:35, 21 June 2006 (UTC)

Yes. When Hotmail "talks" with Yahoo, sending mails from Hotmail users to Yahoo users, then the protocol of this "talk" is SMTP (or rather ESMTP as explained above and in the article, SMTP with some extensions). -- Omniplex 20:48, 21 June 2006 (UTC)

Alright then. Maybe this should be clarified in the article. What about communication within an e-mail server, would that just be internal, or would that use ESMTP? One more thing, how are HTML messages transferred? Thanks. 70.25.138.179 21:25, 21 June 2006 (UTC)

Internally (e.g. MX to MDA) they either use also (E)SMTP or LMTP (local MTP). I can't tell you more about the latter, some simplifications because it knows where mail has to go to, no need to lookup MX records. For different mail formats see MIME. -- Omniplex 21:48, 21 June 2006 (UTC)

Thanks! I didn't really expect someone to reply so soon on a subject like this! 70.25.138.179 22:03, 21 June 2006 (UTC)

Omniplex is clearly more familiar with the details, but depending on your tech level, I've written a more general explanation in a new section below, that you or others may find useful. Milo 00:51, 22 June 2006 (UTC)

Deep fast dive into internal email serving

...communication within an e-mail server, would that just be internal, or would that use ESMTP? ... how are HTML messages transferred?

Both, I'd say, and HTML is handled the same as other messages.

  • The e-mail server viewed at its input and its output handles messages according the ESMTP (or other) protocol. Internally it communicates using a black box process that is analogous to ESMTP, yet is somewhat different for every brand of program.
  • In general, the email server's black box is a set of interacting executable programs typically coded in C language. C program coding implements memory data spaces known as buffers, for transferring character-coded messages "within an e-mail server", from one buffer to another (loosely called "buffering").
  • For example, when using the classic ASCII character-code, the letter "A" is represented in 8 memory bits (one byte) by a binary "0100-0001", meaning that "1" memory bit cells have a slightly higher voltage electrical charge than do the "0" cells.
  • To communicate internally, the C program repeatedly instructs the computer hardware's CPU to copy the voltage of bits from buffer 1, write those bits to buffer 2, and then delete those bits from buffer 1 to make room for the next group of incoming message bits. This is useful because incoming messages can be sorted for delivery by reading the user@address.tld and writing messages with recognized addresses to buffers 2, 3, and 4, that eventually get written to local mailbox X, neighboring computer Y, and external network Z.
  • The ESMTP protocol is implemented when buffering the formatting between characters, lines, and message blocks, but ESMTP is more-or-less ignored while ASCII-coded bits within the message are buffered.
  • HTML is just another language dialect using ASCII (or now Unicode) character codes. ESMTP protocol doesn't care whether the message's dialect/language is English, Spanish, or HTML -- every message text bit is buffered in the same way. If your desktop email program is too ancient to read HTML, you will see an HTML message with many exposed codes that are hard to read, just as Spanish is hard for an English speaker to read. Milo 00:51, 22 June 2006 (UTC)


Ah, I see. So it just transfers the basic text of the message, and the HTML is interpreted later. Thanks!--70.25.138.179 02:37, 25 June 2006 (UTC)

Happened to google similar text and notice there's a bunch of word for word text at:

http://www.kerberosworld.com/Simp-to-Socc/smtp_server-sntp_server.php

That matches this entry. It's of course possible wikipedia is the authoritative source, but figured I'd mention it here just in case. —Preceding unsigned comment added by 68.226.4.50 (talk • contribs)

That website appears to be one of many sites that simply copies wikipedia articles, adds a lot of ads and hopes to make money off it. Thanks for checking though. Wrs1864 14:26, 12 December 2006 (UTC)
Yeah, I recognize some of the stuff I wrote in there. Is Wikipedia aware of this particular website? Should we put it on a list somewhere of websites violating Wikipedia's license, or whatever is generally done? --Steven Fisher 19:23, 12 December 2006 (UTC)
What in the hell they violate? Wikipedia license is completely commercial friendly. You can take stuff, and sell it. Or put advertisement and show it. Or make money any other way. TestPilot 06:41, 31 December 2006 (UTC)

typo?

"(Unix to Unix CoPy)" -- really "CoPy"?

That isn't really a typo, the abbreviation "UUCP" does stand for "unix to unix copy" and the capitalization is used to show which letters were used. I think this is in violation of the WP:Manual of style. Wrs1864 13:39, 9 January 2007 (UTC)
Well, according to the UUCP article, it stands for Unix to Unix Copy Program. Regardless, it is in violation of WP:Manual of style#Acronyms_and_abbreviations, not to mention standard writing practice, to first use the acronym and then expand in parentheses. Rather, the expanded name should be used first, then abbreviated in parentheses. I've changed it. --66.18.238.241 (talk) 02:07, 27 March 2009 (UTC)

SMTP over SSL

Is it a deliberate omission that there is no mention of SSMTP and port 465? SSMTP is recommended for client to MTA communication whilst MTA to MTA communication remains over regular SMTP. Although TLS/SSL can be used on regular SMTP channels to verify the endpoints using a separate port assists network administrators who can simply reject connections to port 25 to stop spamming from infected machines and help preserve their MTA's good reputation. StevenMcCoy 10:01, 1 February 2007 (UTC)

Obsoleted with the new port 587 submission RFC. StevenMcCoy 14:39, 5 November 2007 (UTC)

And now since 2008 port 465 has also been made obsolete and even used for a new purpose (audio and video broadcast). Somebody needs to update the article adding the following crucial information:

  1. Port 465 is obsolete since 2008.
  2. Port 587 is preferred for secure mail submission (ESMTPS standard).
  3. The STARTTLS command over port 25 enables SSL on the same port, when a second port/587 is not available/desired.
  4. Port 25 may be blocked in a public/secured environment where only SSL mail submission is allowed over port 587.

You get that by following the links:

https://en.wikipedia.org/wiki/SMTPS

...and one of the latest (2013) external links from that article...

http://www.theartfarm.com/knowledgebase.php?action=displayarticle&id=5

Is that okay? Shall I just go ahead and edit that with citations?

Codechief (talk) 09:27, 26 February 2014 (UTC)

Error codes revisited

So, someone apparently thought the error codes were not appropriate for Wikipedia (see previous discussion, above), so the solution was to not mention error codes at all in the article. Great. The article no longer has any mention of the only thing I came here to find. I shall now go back into the page history to find some actually useful information about SMTP...... - dcljr (talk) 04:46, 11 December 2007 (UTC)

I removed this

This needs an attribution. Sounds like original research. I like to saw logs! (talk) 00:23, 16 January 2008 (UTC)

If no number appears after the SIZE keyword, or if the current message limit must be exactly determined, the user can further interact by simulating the ESMTP header of a message with an estimated size.

WHat was the existing system before SMTP ?

I dont know .what was the existing system before SMTP Mail Server ? —Preceding unsigned comment added by 203.153.32.18 (talk) 08:10, 14 March 2008 (UTC)

Significant error

The assertion "the e-mail must be delivered twice to the same SMTP server: once for each recipient listed in the "To" and "Cc" headers" (in connection with the inappropriate "Sample communication" which does exactly that) is completely incorrect, contradicted by section 3.3 "Mail Transactions" in RFC2821 [1] where, in regard to the "RCPT TO" command, it is stated both that "A series of one or more RCPT commands follows giving the receiver information" and that "This step of the procedure (RCPT TO) can be repeated any number of times." Further illustration of this may be found in the section "D.1 A Typical SMTP Transaction Scenario" in the same document, showing several RCPT TO commands followed by one DATA command. The only time that repetition of the DATA portion is actually necessary is in fact when it must be delivered to different SMTP servers, as finally noted in the following sentence of the article: "If the second recipient had been located elsewhere..." 69.18.50.253 (talk) 03:48, 15 April 2008 (UTC)

I don't know if I would call it a "significant error", but you are right, most MTAs would use two RCPT TO commands. I have fixed it, but please be bold and fix things that you know are wrong. It would probably have saved you time. Wrs1864 (talk) 17:57, 15 April 2008 (UTC)

Diagram request

Should be made simpiler for users by creating a diagram. I'll do this, if I get the chance, anybody else: feel free to do one. Message from XENUu, t 21:22, 5 September 2008 (UTC)

Don't understand something in "Sample communications" section

The text says: "If the second recipient had been located elsewhere, the client would QUIT and connect to the appropriate SMTP server after the first message had been queued." What would be "the appropriate SMTP server"? As far as I know, the only one I have access to is the one my ISP provides. Is this other server one that services the person I'm trying to send my email to? If so, how would I or my email client know what it is, given only an email address? I'm confused. I thought the point of SMTP was that I simply send to my SMTP server and it takes care of the rest.Therealdp (talk) 16:55, 15 May 2009 (UTC)

Point well taken. The example descriptions are not explicit enough. The implication is that this is what happens on the originating SMTP server (i.e. the one that an end-user would send the messages to at the ISP). In this case the originating SMTP server acts as the client to the receiving SMTP servers. However, many end-user systems, particularly on UNIX-like systems, can also do this function directly, they don't need an ISP-provided forwarder. The article needs a lot of work. Kbrose (talk) 19:19, 15 May 2009 (UTC)

I took "the client" to be "the email client" that's discussed in the preceding section. It would be better to describe how that interaction works first and then, perhaps, describe how SMTP servers talk to each other (and, for that matter, how they determine "who" they should be talking to).Therealdp (talk) 22:58, 15 May 2009 (UTC)

Well, the word "client" is a role played by a computer or device. In general, any host on the Internet could be an SMTP client, although most would say that there are relatively few SMTP servers... which from the article you will know SMTP servers generally listen on port 25, have a FQDN on the global Internet, and are listed in DNS under an MX record. (They have an A, MX, and PTR record.) But if I set up an SMTP server on a Windows PC in my garage, it would still be a server, and I could make a UNIX server send it mail as a client. Change the article to say what would make it more clear that this term is a role. I like to saw logs! (talk) 00:16, 17 May 2009 (UTC)

After another reading of the example and your comment, I find there is nothing in principle factually wrong with the description in the article, albeit it may be too terse for novices. It's simply a general case of SMTP transaction between two fully capable SMTP agents, which is all that the article promises, based on its title. This should also work fine on any network, unless your ISP (typically cable systems) blocks the standard port (25), in which case you must use another port. You don't have to use your ISPs server. The point of SMTP is not what you describe, instead it's a general mail transport protocol, not just a mail-user-agent (e-mail client appliction) that talks to a server. What you are expecting is a specific scenario of a limited user agent using a smart relay host to handle all of SMTPs intricacies. But in general, a standard email agent obtains the proper SMTP server to send a message to by querying the DNS for the mail exchanger of the domain specified in the email address automatically. But, indeed, your response is quite correct, the problem with the article is that the preceeding section discusses that an outgoing server is required for the email client to work, which is misleading in the context of the article and your suggestion should be honored. The article should be using the term 'SMTP client' and not 'email client' to describe the protocol operation, as 'e-mail client' usually imply the end-user application that most people run on their PCs that need a relay MTA. Kbrose (talk) 01:09, 17 May 2009 (UTC)

I arrived at this article by clicking the SMTP link in http://en.wikipedia.org/wiki/Email. I read that, and the links re. POP and IMAP, and wanted to learn how the sending side works. So I think this article should explain how a user's email client communicates with its SMTP server before discussing the server-server interactions that are its main focus. (Alternatively, the email article could explain the email-client/SMTP-server interaction, but I suspect that would create a "complexity discontinuity" problem.) Thus, the problem I'm flagging is that this article doesn't integrate well with at least one other that links to it.Therealdp (talk) 04:04, 17 May 2009 (UTC)

I'll see what I can do. I started rewriting the protocol overview and that addresses your interest to some degree. The actual protocol for submission is still standard SMTP so the example in principle is representative. The primary differences from the user's point of view are the authentication mechanisms in place for submission in most system today. Kbrose (talk) 05:17, 17 May 2009 (UTC)

The Client is the machine sending the email at this moment. The server is the machine receiving it. In Multi-hop service (e.g. an ISP server which collects from many or all of the ISP's customers and then does the 'real' delivery, the same machine functions first as server (to the customer), and then as client (for the recipient's machine). It's not unusual for an email to go through 4 or more machines before arriving at it's final recipient's server. In such a situation all of the machines other than the first and last will occupy both roles -- first as a server and then as a client to subsequent machine in the chain. Darkonc (talk) 09:13, 19 December 2012 (UTC)

Merge proposal

I'm proposing a merge from Secure Password Authentication as that subject doesn't stand alone. Alternative merge targets could be NLTM and Integrated Windows Authentication. Thoughts? Fences&Windows 20:33, 8 September 2009 (UTC)

The merger is inappropriate here, SPA is a proprietary MS protocol that is not part of SMTP. I have removed the tags. It is appropriate however to mention it in connection with the mechanism (SMTP AUTH, RFC 2554) why which SPA ties into SMTP authentication in MS products. Kbrose (talk) 21:23, 8 September 2009 (UTC)

RFC status?

I see that the list of related RFCs lists RFC 5321 as defining the protocol, and RFC 5322 as defining the message format; however, as I understand, RFCs 5321 and 5322 are still draft standards. The standards currently in effect are still RFC 821 and RFC 822 or RFC 2821 and RFC 2822. 69.251.180.224 (talk) 05:57, 20 January 2010 (UTC)

Most RFCs are drafts, proposed standards or similar. There's no Internet law to enforce them. However, it's considered 'best practice' to comply - if you want your products/nodes to successfully interact with others. See Request_for_Comments#Status. Zac67 (talk) 14:49, 16 July 2010 (UTC)

I propose adding:

CheckTLS tests are free, they've been online six months and seem stable. AUP says site will not use any email addresses entered/tested.

Disclaimer: I wrote the tests for a client, and this site makes them available free to the 'net. Sshoe (talk) 21:56, 15 July 2010 (UTC)

Outgoing Only?

The introduction states that "SMTP is specified for outgoing mail transport and uses TCP port 25". It fails to address the issue of incoming mail. This lack of explanation leaves an obvious hole in the information, and IMHO it should be repaired by a knowledgable individual. Thanks. - KitchM (talk) 20:18, 15 June 2011 (UTC)

Indefinite article

See Wikipedia:Administrators' noticeboard/Incidents#User: 109.77.xx.xx and the indefinite article and Talk:XMPP#Please discuss changes to the indefinite article. Andrewa (talk) 15:15, 24 May 2013 (UTC)

SMTP transport example - Note at bottom appears to be overstating the situation

There is a note at the bottom of the example conversation that happens during an email being sent that states:

(note:The above 2 lines are actually incorrect, the ones that state the server sends a "221 Bye" message and also closes the connection. The client Outlook IMMEDIATELY closes the connection after sending QUIT. I can only assume other clients do so as well. This causes the server to give an error when it tries to give the 221 reply.)

Just because Outlook immediately closes the connection, that does not mean the code output we are seeing here is incorrect. I recreated the listed example as a Telnet session with my own ISP's smtp server. My last three lines looked something like this (changed server names only)

250 2.0.0 KECe1m0034h0NJL01EDcUB mail accepted for delivery

quit

221 2.0.0 server.servername.com bizsmtp closing connection

So, the quit command and the 221 message are completely valid in a real world example. While immediately closing the connection may stop a program from receiving the 221 message, that doesn't mean the communication doesn't happen or that all programs will not see it. — Preceding unsigned comment added by Kendb3 (talk • contribs) 02:44, 31 August 2013 (UTC)

Thanks for pointing this out; Outlook's handling of SMTP is not really relevant here. I've changed the note appropriately and moved it to the bottom of the detailed explanation. Zac67 (talk) 12:31, 31 August 2013 (UTC)

BSMTP

Bsmtp redirects to SMTP, but is not explained at all. Schoppenhauer (talk) 19:31, 25 November 2014 (UTC)

Hello fellow Wikipedians,

I have just added archive links to one external link on Simple Mail Transfer Protocol. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers. —cyberbot IITalk to my owner:Online 15:16, 27 August 2015 (UTC)

RFC 3463 Enhanced Mail System Status Codes

Shouldn't the article discuss the RFC 3463 Enhanced Mail System Status Codes and the RFC 5248 Registry for SMTP Enhanced Mail System Status Codes? Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:28, 26 May 2016 (UTC)

Typo in Optional extensions example?

The 2nd line says bob.example.com and the 3rd line says bob.example.org. Is this a typo or is it looking up the IP address of bob.example.com and then going back and finding the domain name from the IP address and getting bob.example.org? I'm thinking this might happen if both domain names are registered to the same IP address.

Typo

Is:

  • "For retriving messages, client applications usually use either IMAP or POP3."

Should be:

  • "For receiving messages, client applications usually use either IMAP or POP3."

--NoToleranceForIntolerance (talk) 20:36, 28 August 2017 (UTC)

Retrieving is correct – the client is the active party, not the server. --Zac67 (talk) 20:39, 28 August 2017 (UTC)

How Many Agents?

It states, "Often, these two agents are instances of the same software launched with different options on the same machine." But in that same paragraph we see three agents listed. Please clarify. - KitchM (talk) 20:38, 29 June 2018 (UTC)

Process Is Server?

"Each process is an MTA (an SMTP server) in its own right." Really? I thought that a process was a process and a server was a server. Such a statement needs clarification. There had better be some provable context IMHO. - KitchM (talk) 20:42, 29 June 2018 (UTC)

Okay, Just A Bad Section

After posting two confusing bits in the section entitled "Mail processing model", I am seeing more things. Such as the use of the word "boundary" without any definition. I think the whole thing needs a fine-toothed comb. An honest-to-goodness expert needs to look it over. - KitchM (talk) 20:48, 29 June 2018 (UTC)

Archive 1
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Simple_Mail_Transfer_Protocol/Archive_1&oldid=1056943296"