Talk:Simple Mail Transfer Protocol
![]() | The contents of the Extended SMTP page were merged into Simple Mail Transfer Protocol on 17 September 2020. For the contribution history and old versions of the redirected page, please see its history; for the discussion at that location, see its talk page. |
![]() | The contents of the Mail Transfer Protocol page were merged into Simple Mail Transfer Protocol on 19 March 2021. For the contribution history and old versions of the redirected page, please see its history; for the discussion at that location, see its talk page. |
This is the talk page for discussing improvements to the Simple Mail Transfer Protocol article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives: 1 |
![]() | This ![]() It is of interest to the following WikiProjects: | |||||||||||||
|
|
|
History
[edit]I updated the history to deal with a chronology cit request placed there in 2012. Maybe this has not been dealt with as it was not entirely clear what the request was asking for. However as it was a chronology request I think it likely it was the statement that BSD 4.1c was released "right after" RFC 788. The RFC is dated November 1981 (and already cited in the article). BSD 4.1c was released 1982/1983 which is not "right after" the RFC so I have corrected the sentence and as everything else is cited, I am not sure it needs a citation. If it needs one, it would be the release date of BSD 4.1c. Nevertheless WP:OVERCITE pertains. This is not really controversial enough for a citation now in my opinion, so I boldly removed the chronology cit request after my rewording. If an editor disagrees, I suggest citing the release date of 4.1c BSD would be sufficient to establish chronology. -- Sirfurboy (talk) 19:23, 1 December 2019 (UTC)
Traffic spike in late 2019?
[edit]Can anyone explain this?
A fairly obscure techie article on WP, with no overlap to Hollywood, rappers or the usual traffic drivers, went from small amounts of traffic (a respectable 40,000 / month) to a massive 4 and 12 million in October and November 2019. I've never seen a hundred-fold increase like that, unless someone dies or a new film is announced. Andy Dingley (talk) 17:37, 16 February 2020 (UTC)
- Interesting! But I don't know what has caused it. Even if it was slashdotted the spike should be nothing like that. It is almost as if a botnet was instructed to fetch the page, yet the question is why anyone would bother doing that. I don't see anything malicious having been edited in. -- Sirfurboy🏄 (talk) 23:01, 19 February 2020 (UTC)
Merge Extended SMTP into this article
[edit]I propose to merge Extended SMTP into this article for the reasons described on Talk:Extended SMTP. Since I forgot to add the merge tags to the actual article bodies, I'm posting this here now to follow the proper protocol. The original proposal received only one comment ("Agree"). I'm looking forward to any comments on this matter. Thank you. Anton.bersh (talk) 12:21, 2 August 2020 (UTC)
- @Anton.bersh: Your proposal at Talk:Extended SMTP#Proposal to merge parts of this article into Simple Mail Transfer Protocol "Optional extensions" section and List of mail server software and Comparison of mail servers had unanimous support; you probably had few additional comments because your arguments were sound. Klbrain (talk) 13:38, 2 September 2020 (UTC)
Merger complete. Klbrain (talk) 13:05, 17 September 2020 (UTC)
Merge Mail Transfer Protocol into this article
[edit]I propose merger of Mail Transfer Protocol (MTP) into this article's History section because:
- 1. MTP is not notable by itself. I literally could not find sources to add to that article which would talk about MTP but not SMTP.
- 2. The name MTP existed for at most two years, from 1980 (when it was introduced in RFC 772) through 1981 (RFC 780) until November 1981 (when MTP was effectively renamed into SMTP by RFC 788).
- 3. The name MTP is obsolete, as stated on Mail Transfer Protocol, and therefore will likely not get much third-party coverage in sources that can be used for that article.
If there are no objections, I can carry out the merge myself. Anton.bersh (talk) 17:48, 14 March 2021 (UTC)
Merger complete. If you object to it, feel free to revert. Please comment how you plan to improve that article. Anton.bersh (talk) 18:02, 19 March 2021 (UTC)
I removed "SMTP transport example" section
[edit]I just removed "SMTP transport example" section because I believe it does not fit Wikipedia standards:
- - it had no third-party sources (OR).
- - it would not be helpful for an encyclopedia reader. Only a protocol implementer needs detailed command timeout information (a good programmer would refer to actual IETF standards and not Wikipedia).
- - it appeared as this example was captured from some particular protocol implementation (email client, perhaps) but did not describe which one. This example was not even consistent with RFCs.
If you object to this change, please feel free to revert it. Also, please take a second to comment why you did so and how the section can be improved. Anton.bersh (talk) 18:41, 15 March 2021 (UTC)
- I will try to revert it after writing this comment.
- The easier answer for me is the improvement. I am fine with it as it is. As for why I reverted it:
- - it is a handy source of information for a plain basic, short and simple example for the article. No need to google for such an information. It is here for years. An example that makes the discussion much more concrete, and live. The same role as a picture, diagram and the like, for other articles. It is very helpful for an encyclopedia reader. I still haven't restored it, which is why I am not sure about the timeouts values you mentioned. Where did you see them? A novice programmer might start with such an article, before delving into the actual IETF standards, trying to figure out how they create the current full picture.
- - as for it without a third-party sources: It is a very basic example. Asking for a third-party sources looks to me a highly excessive demand. It could be that I might be able to have such sources. I might also try to capture an actual conversation from a real world SMTP conversation, showing a very similar conversation to the example. Will you approve that as a source? But why bother? Over the years, how many readers claim the example is wrong?
- - It is a very basic example. It was not captured from some particular protocol implementation. In which way it is not consistent with the RFCs?
- 147.161.8.122 (talk) 14:40, 15 April 2021 (UTC)
- After I reverted the change, I have noticed the example mentions Postfix. Which is a particular implementation. A popular open source one, by the way. Most implementations mentions their names at this place. Partially for self promotion. But partially to help resolve problems. It is just like engineers would ask about exact models. Particular models of a product have strengths and weaknesses. However, if that really bother, one can write another real world product name here, write a faked name, or omit the name. But I haven't checked if the RFCs actually permit an omission.
- 147.161.8.122 (talk) 15:02, 15 April 2021 (UTC)
Does BDAT makes the Protocol_overview section not accurate? In any case, shouldn't BDAT gets mentioned?
[edit]Assuming negotiated, can't BDAT, RFC 3030, fully replace DATA? If so, are Simple_Mail_Transfer_Protocol#Protocol_overview, and perhaps other sections of the article, not accurate? In any case, shouldn't BDAT mentioned at least once in the article? 147.161.13.105 (talk) 18:48, 10 June 2021 (UTC)
- ESMTP and specifically BDAT aren't mandatory, so BDAT cannot replace DATA in general. In practice, 8BITMIME is normally used and has likely displaced adoption of BDAT. CHUNKING is in our list though, if relevant it could be expanded. --Zac67 (talk) 07:03, 11 June 2021 (UTC)
Port 465 and 587
[edit]I'm not sure what's incorrect about my edit that was reverted.
As I understand (as explained in Simple Mail Transfer Protocol#Ports), server-server communication always uses port 25, while client-server can use port 25, 465 or 587. (Where for client-server communication, port 465 is preferred since RFC 8314.) So anywhere were port 587 is allowed, port 465 is too.
@Zac67: Please let me know if I've got something wrong. -- Lonaowna (talk) 21:42, 1 March 2022 (UTC)
- Port 465 was intended for the same purpose as port 25, in the MX role ("server-to-server"), just with implicit SSL/TLS. That has been deprecated since.
- Port 587 is dedicated to the MSA role ("client-to-server") and may or may not use explicit SSL/TLS. They may be used as alternatives in certain scenarios (only when MX and MSA are identical) but that's not a given. Of course, you can build your network and your service any which way you want but then again you could use just about any port. --Zac67 (talk) 07:42, 2 March 2022 (UTC)
- C-Class vital articles
- Wikipedia level-5 vital articles
- Wikipedia vital articles in Technology
- C-Class level-5 vital articles
- Wikipedia level-5 vital articles in Technology
- C-Class vital articles in Technology
- C-Class Computing articles
- High-importance Computing articles
- C-Class Computer networking articles
- High-importance Computer networking articles
- C-Class Computer networking articles of High-importance
- All Computer networking articles
- All Computing articles