eServices - Acceptable email format

Started by wuzafuzz, August 31, 2011, 06:44:37 PM

0 Members and 1 Guest are viewing this topic.

wuzafuzz

I just went into eServices to update email addresses and discovered that it no longer accepts a ".us" domain.  eServices insists it's not a valid email address.  My .us  address worked great for years, but now...poof.

Has anyone else experienced this?
"You can't stop the signal, Mal."

Woodsy

I have no problem with it...  After all, FLWG's official email system is a .us domain, so that would cause some problems... 

a2capt

Make sure you have no trailing or leading spaces. The input mechanism is picky. If you pasted the address in, you may have grabbed something extra..

wuzafuzz

Still no joy.  No leading or trailing spaces.  Typed manually or pasted.  The system just won't take it. 

After that I tried the eServices help desk, but it insists on using my User ID instead of my CAP ID.  The lost passwork link wants my email address, which is what I can't enter!  >:( Time for a phone call. 
"You can't stop the signal, Mal."

JC004

I just tried to duplicate this.

I enter e-mail addresses with .us and it says they aren't valid.  I enter e-mail addresses with .com and they're fine.

wacapgh

Input mask problem? Probably breaks with the 4+ letter TLD's as well - .aero, .museum, .mobi

a2capt

I had a problem with .gov one afternoon, too. Thats when I found a space in the thing, that somehow kept getting added by autofill even after I explicitly typed slowly. I had to actually type .gv and then add the 'o' and hurry up on the return key.

Thrashed

It wouldn't take my .net. I tried a few times. It finally accepted my email with no Caps- all lower case.!?

Save the triangle thingy

Eclipse

Quote from: Thrash on September 02, 2011, 11:54:28 PM
It wouldn't take my .net. I tried a few times. It finally accepted my email with no Caps- all lower case.!?

well...emails aren't supposed to have any caps, so...

"That Others May Zoom"

SarDragon

Over the years, I have noticed a difference between Windows and *-ix servers. One is case insensitive, the other is. I used to handle a couple of web sites, on both OSs, and found that entering URLs might or might not depend on using the proper case. Apparently email is the same way. I've just always used lower case.
Dave Bowles
Maj, CAP
AT1, USN Retired
50 Year Member
Mitchell Award (unnumbered)
C/WO, CAP, Ret

Thrashed

Quote from: Eclipse on September 03, 2011, 01:23:37 AM
Quote from: Thrash on September 02, 2011, 11:54:28 PM
It wouldn't take my .net. I tried a few times. It finally accepted my email with no Caps- all lower case.!?

well...emails aren't supposed to have any caps, so...

Says who? I've always used them until CAP.

Save the triangle thingy

a2capt

If the domain is hosted on a case insensitive file system, then the case of the URL entry does not matter.
Those tend to be anything with a Microsoft OS hosting it. But I'm not going to say always. NTFS does support a case sensitive environment. But not from Microsoft.

Classic Mac operating systems are case insensitive. But Mac OS X (HFS+) is actually a case sensitive environment due to it's BSD roots. However, from the GUI it's not possible to enter both 'A' and 'a' and have it be different with respect of the file system. From the shell, that is a different story. The Mac OS X shell takes a hybrid approach. You can't create a file called A and one called a in the same location as you will get an error. But shell commands will not run,  directories can not be navigated, etc - of the file names are not entered exactly as presented. IE: cd System/Library/Extensions is not the same as cd system/library/extensions.

...and of course, this carries over to web sites. Because servers are typically hosted on *nix based, Mac OS X or Microsoft operating systems.

The domain is case INSENSITIVE. Google.Com, google.com, GooGLE.COM, GOOGLE.cOM are all the same thing.

However, the local part of the URL, that what is is past the TLD (Top Level Domain, .com, .net, .us, .su, .gs, etc.) absolutely could be case sensitive and it's best to stick to lower case. However, if you come across a URL containing upper case you should relay that exactly as it's given to you, after you verify that it does work. If you get a 404, then try replacing characters with all lower case.  It might just work, because someone else thought "it would look nicer".

I realize that 'local' means, to be near you, as opposed to far. But in networking context, local is what is local to that server. http://www.remote.com/local.html - the part after the domain is local *to the server*. The local part of any of these things is where the case sensitivity must be recognized/supported.

http://www.google.com/Mail will NOT work, but http://www.google.com/mail will work.
It could work, if Google were using a case insensitive file system, had a parser on the server level, or simply had two different instances of the directory, one being an alias. Imagine what a pain that would be if servers were setup with all that extra crud in the directories.  Yuck.

With email, the same goes, almost. The domain portion of the email address is case insensitive, because as mentioned previously, domains are case insensitive. However, the local part is.  my email address is LoCaL@remote.com -

Suffice to say that MOST email systems, unlike http servers do parse email addresses, thus ignoring the case of the LoCaL portion, so that local@remote.com, LoCal@remote.com, are both the same thing.

That is not to say that all do, and most certainly, if they don't, they are actually not doing anything wrong according to the RFC. That means that MickeyMouse@disney.com is actually NOT the same as mickeymouse@disney.com - Can you imagine the pure *mess* that would cause?

The RFC that covers this is available at http://www.faqs.org/rfcs/rfc2821.html and in a nutshell, explains for technical reasons why it needs to be case sensitive, but in closing actively discourages it. "However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged."

When developers take it on themselves to enforce this at the entry level, that is nice except in cases of poor user interface design where it just rejects it and does not tell you why.

Suffice to say, if you work with email addresses in all lower case, you probably stand a pretty darn good chance at having great success with email.

With domains, you do find a lot of CamelCase simply for presentation matters. I think it looks better, but I realize it can lead to the gateway of confusion simply by encouraging addition similar behavior.

www.GoCivilAirPatrol.com looks more pleasing than www.gocivilairpatrol.com and is easier to convey visually.

http://gocivilairpatrol.com/How_to_Join/ looks nicer, and in this case, does actually work, because either the server is parsing it, or it using Microsoft products on the back end. But the default is really http://gocivilairpatrol.com/how_to_join/

Lastly, in closing: 'www' is generally not required. When configured properly, it's not needed. There are instances where it does not work, because the DNS or server configuration is set up explicitly that it be there. That said, I don't type http:// or www in web browsers, ever. You do not need to do that every time. Simply entering captalk.net is enough. The browser will figure it out.  When providing a link via electronic means it usually is nessessary to supply the http:// so that it is recognized where applicable, as a hotlink, where such function is supported.

Sorry for the rambling, but there's the how - and why, things act like they do.

SarDragon

Dave Bowles
Maj, CAP
AT1, USN Retired
50 Year Member
Mitchell Award (unnumbered)
C/WO, CAP, Ret

Eclipse

Quote from: Thrash on September 03, 2011, 04:49:51 PM
Quote from: Eclipse on September 03, 2011, 01:23:37 AM
Quote from: Thrash on September 02, 2011, 11:54:28 PM
It wouldn't take my .net. I tried a few times. It finally accepted my email with no Caps- all lower case.!?

well...emails aren't supposed to have any caps, so...

Says who? I've always used them until CAP.

pEoPLe wHo UsE cAps iN EmAiL addresses don't understand how the internet works.

"That Others May Zoom"

wuzafuzz

Someone from the help desk contacted me on Thursday to confirm which address I wanted to use in which position (primary or secondary).  I answered right away but haven't heard from them since.  Hopefully there is a simple change on their side and we'll be back in action with .us domains soon.
"You can't stop the signal, Mal."

a2capt

Quote from: Eclipse on September 03, 2011, 09:03:18 PMpEoPLe wHo UsE cAps iN EmAiL addresses don't understand how the internet works.
Hence why I explained it above. Where it *might* work, but just because it does, doesn't mean it should. The RFC says it should, but encourages it not to matter.

IOW, it should get through either way, but it *may* not .. if it doesn't. Change it to lower case and never do ThAt StuFF again, especially before opening a ticket on it. ;)