Talk:Extended SMTP

Keywords

I wonder if the different keywords would merit their own articles, or if a short summary in this article would suffice? AUTH already has an article dedicated to it, and there are a few that could do with some additional explanation (STARTTLS for one). Any opinions on this? Milliped 18:49, 8 April 2006 (UTC)

STARTTLS would be nice for ESMTPS, but I'm not sure if it deserves its own article. We have SASL, SMTP AUTH, and TLS for details wrt STARTTLS, anything else about it could go in a new section in this article. But if you're more comfortable with a separate article go, we can merge it later if the outcome shows that that's better. -- Omniplex 19:39, 8 April 2006 (UTC)

If you want to write the complete RFC 2476 (submit) story from SMTP-after-POP over CRAM MD5 ESMTPA up to ESMTPS / ESMTPSA a separate article is of course the way to go, sorry, a lack of caffeine on my side :-) -- Omniplex 19:47, 8 April 2006 (UTC)

I don't believe STARTTLS should be redirected here. Thats plain wrong. STARTTLS can be used with many other protocols and is not tied with SMTP alone —Preceding unsigned comment added by Wk muriithi (talk • contribs) 10:50, 5 January 2008 (UTC)

Looks like I have forgotten how to remove redirection. I wonder if someone can help me remove the above redirect and at least redirect STARTTLS to TLS for the time being. Thanks in advance. gathima (talk) 10:59, 5 January 2008 (UTC)

I for one would like to see each of these commands have their own page. — Preceding unsigned comment added by 75.189.236.125 (talk) 14:36, 6 December 2012 (UTC)

Update: Most of these keywords already have dedicated pages now. Anton.bersh (talk) 07:41, 28 May 2019 (UTC)

HELP is one of the standard SMTP commands, not an ESMTP command, thus it should not appear here. See the current SMTP spec: http://tools.ietf.org/html/rfc5321#section-4.1.1.8 — Preceding unsigned comment added by 75.189.236.125 (talk) 14:16, 6 December 2012 (UTC)

Sample conversation

Anyone willing to write a sample conversation like the ones at POP3 or SMTP? They're especially helpful for those of us troubleshooting mail server access problems. — SheeEttin {T/C} 20:33, 3 July 2006 (UTC)

Update: in the last decade a sample conversation was added.

Anton.bersh (talk) 07:41, 28 May 2019 (UTC)

set and for new

I get confused reading these words.Unfree (talk) 05:00, 3 November 2008 (UTC)

Wikiproject Computing

I have removed the WikiProject tag, as this article is either a redirect or deleted. If you oppose, please restore the tag. Thank you, fahadsadah (talk,contribs) 16:06, 30 March 2009 (UTC)

Update: in the last decade the article was rewritten and Wikiproject Computing tag was restored.

Anton.bersh (talk) 07:41, 28 May 2019 (UTC)

Why not punycode?

Does anyone knows of a reliable source that explains why they are thinking more about additional fields and complicated downgrading negotiations systems and such, instead of just using punycode like on IDNs for UTF8SMTP? --TiagoTiago (talk) 07:15, 26 May 2009 (UTC)

This is a very late answer (10 years after the question was asked), but here it is:

Punycode was specifically designed to work around the fact that DNS accepts only ASCII characters. As such, Punycode is basically a good example of Technical debt because we will be stuck with it for foreseeable future and maintaining it is non-trivial. E.g., there is no easy way to tell if an international domain name is "valid" aside from determining if it is "representable" in Punycode as a valid ASCII domain. Furthermore, domain names (and by extension Punycode-encoded domain names) are case-incensitive, while email name that goes before @ sign is case-sensitive. So you would have to make a different custom version of case-sensitive Pynycode specifically for email names. In contrast, UTF-8 is an actual standard encoding that literally every system understands and can use.

Anton.bersh (talk) 07:41, 28 May 2019 (UTC)

List of supporting servers

I would expect more or less all modern mail servers to be ESMTP compliant, not just the 3 listed. — Preceding unsigned comment added by 24.87.51.64 (talk) 10:41, 27 April 2011 (UTC)

You are right: virtually every mail client uses a few extensions, at least for authentication (to prevent spam and ensure integrity), encryption (to protect confidentiality), and binary MIME type (to transfer binary data efficiently).

Anton.bersh (talk) 07:41, 28 May 2019 (UTC)

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

This page contains two types of information: an incomplete overview of extensions and a few lists of software that supports some extensions. The first kind of information overlaps with the Simple Mail Transfer Protocol "Optional extensions" section. Because of the overlap, we should either move Simple Mail Transfer Protocol "Optional extensions" section here or move content here to that section. Furthermore, the content (of the merged article, whichever it will be) needs to be extended, which will be much easier after the merge. I propose move there (merger of the overview of extensions into the Simple Mail Transfer Protocol "Optional extensions" section). The remaining list of software really belongs to the List of mail server software and Comparison of mail servers.

Rationale for this merge:

1. Officially (since 2001) SMTP is defined by RFC 2821 "Simple Mail Transfer Protocol" which obsoletes both RFC 821 "Simple Mail Transfer Protocol" which introduced the original SMTP and RFC 1869 "SMTP Service Extensions" which introduced notion of Extended SMTP.

2. Virtually all modern servers adhere to the modern naming convention of RFC 2821 and use EHLO and therefore ESMTP became synonymous with SMTP. Most sources online use the modern definition of SMTP and do not mention ESMTP. The ones that do talk about ESMTP are clearly obsolete.

3. That article is much more popular, about 10 times the number of views on average. Therefore it is much more likely to be seen by readers and maintained by other Wikipedia contributors

4. This article did not see much contributions activity in the last few years (likely due to low number of views) so likely will not be updated and maintained unless someone steps up.

5. Most, if not all, extensions already have their own pages and if this article was to this be separate from the SMTP article, it be just a list of short overviews for each. I believe it's better to have such an index in the main SMTP article.

Please comment on this merge: do you agree that it's needed and which way do you think it should go? If there are no comments, I'll follow WP:BOLD and carry out the merge.Anton.bersh (talk) 03:56, 23 May 2019 (UTC)

Agree - your logic is sound. - Snori (talk) 05:20, 23 May 2019 (UTC)

Support the merge, as proposed; merging to SMTP, on the grounds that this is now the more commonly used name, and hence the one most like to be recognised and searched for. Klbrain (talk) 21:02, 7 August 2020 (UTC)

Support – sounds very reasonable, go ahead. --Zac67 (talk) 21:52, 7 August 2020 (UTC)

  Y Merger complete. Klbrain (talk) 13:05, 17 September 2020 (UTC)

Is there a way to archive very old and resolved discussions?

I have answered all the very old discussions to confirm that they are resolved. Is there a way to archive them? Anton.bersh (talk) 07:41, 28 May 2019 (UTC)

In principle Help:Archiving a talk page, but nothing here currently warrants such an action. Incnis Mrsi (talk) 08:16, 28 May 2019 (UTC)