Talk:E-mail address
From Wikipedia, the free encyclopedia
[edit] un structured comments
Would be useful if those able to translate a page into a language didn't have to read through the entire Wikipedia site in order to do so, wouldn't it? The language of my choice is not on the left pane list and the word languages is not clickable. Is all of wikipedia of this mindset? (no tilde on this keyboard, sorry, send money for new one!)
Would be nice for someone to find a list of government e-mail-for-all initiatives or more of the cultural stuff, rather than just adding to the technical details.
A note vis-a-vis allowed characters - despite me accidentally adding a period to the excluded characters list, the rest are from the RFC, so should be correct. If you see different it's because the standard is being broken.
-
- I have put these un structured comments inside a sub section . Will the author please explain himself.
Otherwise , these comments may be deleted
Sanjiv swarup (talk) 03:36, 8 June 2008 (UTC)
[edit] The Need for E-mail
I cut this section, then User:IanM restored it. I'm cutting it again because it still has many errors. I don't object to something like this being in the article, but it should be correct.
- Having your own e-mail address is considered an essential part of life in cyberspace and is required for almost everything other than viewing pages. Making online purchases, subscribing to paid content, posting in web logs or Internet forums, participating in Usenet newsgroups and many other tasks will require a valid e-mail address. Despite once being considered part of "geek culture", not having an e-mail address can seriously disadvantage a person. For this reason, many governments in modern countries are undertaking initiatives to give e-mail addresses to public servants and school children.
None of the listed activities require an e-mail address. Most online retailers and some web sites require you to have an e-mail address in order to sign up for their services. But some retailers and most web sites don't. For example, you don't need an e-mail address to edit Wikipedia. So this needs to be rewritten with specifics. How exactly not having an e-mail address disadvantage a person? Which governments are untaking which initiatives? Gdr 10:20, 2004 Jul 9 (UTC)
Maybe "Making online purchases..." should be replaced with "In many cases making online purchases..."? Paul Carpenter 14:59, 23 Apr 2005 (UTC)
Insightful and informative (a few things a geek like me didn't know, also). Keep. --Primetime 20:54, 19 January 2006 (UTC)
Keep. Email addresses are different to Email itself, in that this article discusses the actual address. You can't combine that with email.
[edit] Complexity of email addresses
This article currently doesn't explain the complexity of email addresses, in that they may take many forms, many of which would not be recognized as valid email addresses by the average internet user. As evidenced by the EBNF for email addresss (I may have missed some as I copy-pasted from RFC 2822 the parts I could find that were needed):
address = mailbox / group
mailbox = name-addr / addr-spec
name-addr = [display-name] angle-addr
angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
group = display-name ":" [mailbox-list / CFWS] ";" [CFWS]
display-name = phrase
mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
address-list = (address *("," address)) / obs-addr-list
addr-spec = local-part "@" domain
local-part = dot-atom / quoted-string / obs-local-part
domain = dot-atom / domain-literal / obs-domain
domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS]
dcontent = dtext / quoted-pair
dtext = NO-WS-CTL / ; Non white space controls
%d33-90 / ; The rest of the US-ASCII
%d94-126 ; characters not including "[",
; "]", or "\"
FWS = ([*WSP CRLF] 1*WSP) / ; Folding white space
obs-FWS
ctext = NO-WS-CTL / ; Non white space controls
%d33-39 / ; The rest of the US-ASCII
%d42-91 / ; characters not including "(",
%d93-126 ; ")", or "\"
ccontent = ctext / quoted-pair / comment
comment = "(" *([FWS] ccontent) [FWS] ")"
CFWS = *([FWS] comment) (([FWS] comment) / FWS)
NO-WS-CTL = %d1-8 / ; US-ASCII control characters
%d11 / ; that do not include the
%d12 / ; carriage return, line feed,
%d14-31 / ; and white space characters
%d127
specials = "(" / ")" / ; Special characters used in
"<" / ">" / ; other parts of the syntax
"[" / "]" /
":" / ";" /
"@" / "\" /
"," / "." /
DQUOTE
quoted-pair = ("\" text) / obs-qp
text = %d1-9 / ; Characters excluding CR and LF
%d11 /
%d12 /
%d14-127 /
obs-text
atext = ALPHA / DIGIT / ; Any character except controls,
"!" / "#" / ; SP, and specials.
"$" / "%" / ; Used for atoms
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~"
atom = [CFWS] 1*atext [CFWS]
dot-atom = [CFWS] dot-atom-text [CFWS]
dot-atom-text = 1*atext *("." 1*atext)
qtext = NO-WS-CTL / ; Non white space controls
%d33 / ; The rest of the US-ASCII
%d35-91 / ; characters not including "\"
%d93-126 ; or the quote character
qcontent = qtext / quoted-pair
quoted-string = [CFWS]
DQUOTE *([FWS] qcontent) [FWS] DQUOTE
[CFWS]
[edit] Perl's RFC2822 email regex
And the following regex for validating emails, from Perl's RFC2822 package:
(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t] )+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?: \r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:( ?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0 31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\ ](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+ (?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?: (?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z |(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n) ?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\ r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n) ?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t] )*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])* )(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t] )+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*) *:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+ |\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r \n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?: \r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t ]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031 ]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\]( ?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(? :(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(? :\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(? :(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)? [ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]| \\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<> @,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|" (?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t] )*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\ ".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(? :[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[ \]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000- \031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|( ?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,; :\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([ ^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\" .\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\ ]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\ [\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\ r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\] |\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0 00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\ .|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@, ;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(? :[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])* (?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\". \[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[ ^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\] ]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*( ?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\ ".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:( ?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[ \["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t ])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t ])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(? :\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+| \Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?: [^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\ ]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n) ?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[" ()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n) ?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<> @,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@, ;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t] )*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\ ".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)? (?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\". \[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?: \r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[ "()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t]) *))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]) +|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\ .(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z |(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:( ?:\r\n)?[ \t])*))*)?;\s*)
porges 01:27, 4 April 2006 (UTC)
- Yarr, that be mighty advanced, I appriciate it, however. Thank you 62.20.156.137 19:02, 28 February 2007 (UTC)
[edit] plus signs
Is there a polite way to convince people to allow email addresses with plus signs, as required by the appropriate standards since 1982?
You could threaten to list them on the "plus haters page of shame".
- I recommend this statement:
- I have listed your website at http://mozilla.wikia.com/wiki/User:Me_at_work/plushaters#Plus_haters as it does not conform with accepted Internet email standards AND does not assist in the prevention of spam and address reselling
This section of the article should be updated to explain how plus signs can be used to track down spammers and sellers of email addresses. 147.145.40.44 18:47, 25 January 2007 (UTC)
[edit] Moved comment from main article to talk page
The following was found at the end of the "plus (or minus) addressing" section:
- "The reason why gmail.com and qmail support are different systems, or pro's and cons have yet to be fully explained."
I couldn't figure out who originally added it. It looks more like a (poorly formatted) general comment than anything that belongs in the article, so I've moved it here in case anyone would like to discuss it. Pat 16:51, 26 May 2006 (UTC)
[edit] English Language ??
The Phrase "Through technical misuse of the word" should be removed. It is such a common usage that it could be said to be another meaning of the wordin it's own right.
- "Common usage" isn't the same as "correct usage".
[edit] References
The following is incorrect. The link is not RFC 2822 compliant because the input box only allows for up to 90 characters.
Verify email address: Verify the syntax & format, the domain name, a valid user and actual mailbox. (RFC 2822 compliant online free tool).
Similar to above, the last reference linked, "e-mail address validation: a Regular Expression that validates e-email addresses according to RFC 2822", is incorrect. It attempts to validate email addresses, but does not do so in accordance with RFC 2822. IMO, it's considerably further from RFC 2822 than most other examples I have seen and should be removed entirely. RevEng (James Cooper) 18:41, 17 January 2007 (UTC)
- I restored the link to one that was used earlier. The regular expression listed there still isn't right though, as it rejects various parts where stuff like UTF-8 is allowed. As mentioned about in #Complexity of email addresses, this really is a very nasty problem. Wrs1864 20:59, 17 January 2007 (UTC)
[edit] "User" vs. User
Some email clients—such as Google Mail’s web interface—writes out emails as "Full Name" <user@server.tld>. However this is an outdated method of adding comments to the name part. So the email standard says the address should be written as Full Name <user@server.tld>. Can anyone explain the difference of the two, and elaborate on why many choose to comment out the name using outdated standards? —Preceding unsigned comment added by 84.202.43.102 (talk) 22:38, 10 January 2008 (UTC)
- A number of characters (roughly, anything apart from the usual alphanumerics and common punctuation) must be quoted if they appear in the display-name part of an address. Most notably, RFC 2822 does not include the dot (period / full stop) in that common punctuation - you don't need quotes for J Public <jpublic@domain.tld>, but you do need them for "J. Public" <jpublic@domain.tld>. Because characters that need quoting are very common, especially with an international audience, it's simpler and safer to quote everything. (A legal unquoted display-name never changes if you quote it, but lots of quoted ones become illegal if you take the quotes away.)
- I don't know why you think quoted names are outdated - they're still current as far as I know. Are you perhaps confusing them with the old address@domain.tld (Display Name) form? That's certainly outdated (it might still be legal under RFC 2822's CFWS rules, but don't quote me on that, and it would render the bracketed Display Name meaningless anyway), but I don't know of anything that still uses it...
- -- 210.54.3.3 (talk) 06:19, 29 October 2008 (UTC)
[edit] Limitations and Validation part of the same thing?
I think the section discussing validation should be merged with the limitations section as they both go hand in hand. --Hm2k (talk) 12:06, 6 June 2008 (UTC)
- I think they are different enough topics that they should stay separate. I changed the section name from "limitations" to "detailed definition" to try to make this distinction clearer. Wrs1864 (talk) 17:42, 6 June 2008 (UTC)
- The "limitations" title comes directly from the RFCs themselves. "Restrictions" is be a better term as per RFC 3696. You must bare in mind that the restrictions any kind of email address validation (not to be confused with verification) is based on. --Hm2k (talk) 18:29, 6 June 2008 (UTC)
- Well, I disagree that either "limitations" or "restrictions" are good names for that section. It defines what a valid e-mail address looks like. Yes, technically, any definition is a restriction/limitation, but that is kind of meaningless. RFC 3696 uses "restrictions", but as a complaint about broken validators that cause needless restrictions. I still think that definition the section based on what something is, rather than what it is not, is a better way to go. Wrs1864 (talk) 18:46, 6 June 2008 (UTC)
- Additionally, you will understand that the "restrictions" or "specification" are used for one thing, and one thing only, that is "validation". Which begs the question, is it just a subsection of "validation"? --Hm2k (talk) 11:10, 7 June 2008 (UTC)
- Yes, I think that the word Restrictions is not the right one to use instead it can always be a subsection of Validation and Verification.
Kalivd (talk) 14:46, 7 June 2008 (UTC)
[edit] See also
Also the See Also section has only one link i would like to add a few more See Also links for easy navigation to other e-mail related articles. Kalivd (talk) 14:46, 7 June 2008 (UTC)
-
-
-
- Mr. Kalivd. Please stick to one issue per post Sanjiv swarup (talk) 03:31, 8 June 2008 (UTC)
-
-
-
- Be Bold WP:BOLD and add the links. Just remember to follow WP:SEEALSO. It is always a good idea to have the wikipedia articles inter-linked for easy navigation. Dhshah (talk) 07:05, 8 June 2008 (UTC)
-
- Well thanks for the suggestion, here on i would stick to one issue per post 59.92.138.194 (talk) 15:22, 9 June 2008 (UTC)
-
- Be Bold WP:BOLD and add the links. Just remember to follow WP:SEEALSO. It is always a good idea to have the wikipedia articles inter-linked for easy navigation. Dhshah (talk) 07:05, 8 June 2008 (UTC)
- Clicking the the "e-mail" category is a far more effective way of navigating than listing all marginally related e-mail related articles to the see also link. As the WP:SEEALSO page says, links are better inline. Wrs1864 (talk) 15:52, 9 June 2008 (UTC)
[edit] Difference between Validation and Verification
"Actually trying to send email" is NOT a validation technique, it is a verification technique.
Validation is a check to ensure it is true to the specification (eg: is the number N digits long?). Not to be confused with verification which is a check to ensure it is correct within the intended system (eg: does the number work when phoned?). --Hm2k (talk) 09:27, 14 June 2008 (UTC)
[edit] Corrected Missing Hyphenation in This Article
I corrected the missing hyphenation in the spelling of “e-mail” in this article. A section in it said I was to comment here if I edited it. Why is this necessary and only for that section? Greta Hoostal (talk) 02:21, 18 July 2008 (UTC)
- The request to discuss that section was due to incorrect changes to that section, as discussed above, however this request no longer really applies as no further incorrect edits have been made since. --Hm2k (talk) 17:42, 15 August 2008 (UTC)
[edit] Tone
Can someone explain why we're using contractions and first person in this article? Ten Pound Hammer and his otters • (Broken clamshells • Otter chirps • HELP) 17:33, 17 October 2008 (UTC)
[edit] User validation vs MIME validation
This article confuses validating an email from the point of an user with from the point of "how it must be structured inside the MIME". For example, it is perfectly ok for a mail client to accept [Full Name full.name@domain.dm] as a valid email as long as the email client can interpret the name part (Full Name) from the mailbox part (full.name@domain.dn)]. When the email client creates the corresponding mime it must use the syntax described in the RFCs. Microsoft Outlook does this, for example.
Another example of this is the usage of unicode characters on the name part. There are special mechanisms for encoding those characters in the MIME yet the users of a mail client do not need to know about them, and will only type the characters directly.
"€" <euro@europe.eu>
Any user will say that we are looking at a valid email address yet the corresponding utf-8 byte sequence is not a valid MIME address:
"%d226%d130%d172" <euro@europe.eu>
In a mime a correct ASCII sequence for the previous address may be:
=?windows-1252?Q?=22=80=22?= <euro@europe.eu>
Yet no one will try to explain this to a user. Another important thing to note for developers is that, due to this problem, a regular expression directly taken from the RFCs is not of any practical use, at least in an international point of view. This is because the regular expression will fail to parse any address that contains an unicode character. Such a regular expression may only be useful for parsing addresses directly from the MIME.
Developers of email clients should create a different regular expression to parse user inputed text, extract the relevant parts and convert the parsed address into the RFC format.
I think it is important, from an encyclopedia point of view, to differentiate the two topics.
From an encyclopedic view it suffices to exaplain that an email address is an electronic address used to deliver internet messages to an entity. This address is composed off an optional entity name and an entity mailbox. The mailbox is composed of an user part and an host part. The way this entities are encoded in MIME is irrelevant to the concept. Typically, similarly to physical addresses, this entity is a person and in such situations an email address is composed of of that person's name and a his mailbox.
However, the typical address format accepted by email clients should be documented, but not as if it was the RFC format itself. —Preceding unsigned comment added by João Graça da Nóbrega (talk • contribs) 17:30, 9 January 2009 (UTC)
