Great info Ben--The listserv software is not the most recent version, and we are looking into what it would take to update. I'll have to dig to see what this version and the latest one supports for literal non-ASCII.
The original address was something like: imnotfindinganÿ[email protected] and it displays in the listserv software as both that (on one screen) and as "imnotfindingan [email protected] on both another screen and in the message headers when it tries to send. Sounds a bit like your description of using equals, question marks, etc, when it doesn't understand what to do. -Bonnie -----Original Message----- From: Ben Scott [mailto:[email protected]] Sent: Wednesday, January 28, 2009 2:47 PM To: MS-Exchange Admin Issues Subject: Re: Is this a valid character to use for e-mail? On Wed, Jan 28, 2009 at 2:04 PM, Miller Bonnie L. <[email protected]> wrote: > Is this: > Ÿ > A valid character to use in the left-hand portion of an e-mail address? Maybe. RFC-822 (1982), the original Internet email standard, says ASCII only. RFC-2822 (2001), the update to RFC-822, reinforces this. ASCII only. RFC-2047 (1996), part of MIME, provides a method for encoding non-ASCII characters into ASCII-only in headers. So non-ASCII characters like that can be encoded into several ASCII characters. Such characters should work in any mail system, because they're just plain old ASCII. Software which isn't aware of RFC-2047 will display gobbledygook fully of question-mark (?) and equal-sign (=) characters, but should be okay. Software which is aware of RFC-2047 should decode and give you the original funny character. There are a series of IETF documents which deal with extensions to permit native encoding and transport of non-ASCII characters in headers. They're still in the "Experimental" or "Draft" stage. I'm not familiar with them, but I believe they include a mechanism for MTAs to downgrade the payload to ASCII-only, so as to not screw-up systems which are unaware of these newer protocols. Google "email address internationalization" (EAI) if you want to read about this. > We have some third-party listserv software that is choking on this and I'm > trying to figure > out if it's valid. You'll note a common theme in the above is backwards compatibility. The IETF goes to great lengths to make sure newer systems can gracefully degrade to be compatible with old ones. If that listserv does not report itself as capable of accepting literal non-ASCII characters, then it should not be receiving any, and thus your funny character should not matter. So either (1) the listserv is reporting capabilities it does not actually support, or (2) something else is handing off non-ASCII data when it should not. A lot of mail software doesn't check input very well, and will allow you to do things like enter non-ASCII characters, and then attempt to pass them around without doing all the proper protocol first. So that could be an issue -- when the protocol violation hits something that does check input, the message gets bounced. I have no idea where Exchange/Outlook fall into this mess. Given the experimental nature of EAI, I would avoid using it for important email addresses at this time. It's too likely to cause trouble. -- Ben ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja ~ ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja ~
