Re: Syntax check a string as a valid email address

Yeah, if you go by RFC 822, almost anything with an @ symbol in it is a "valid" e-mail address. Though, RFC 822 is outdated, and RFC 2822 is somewhat better in this respect.

The regular expressions that I've used do not allow all possibilities in the RFCs, however... they're based more on what people commonly use for e-mails. In other words, there may be a handful of e-mail addresses that are technically "valid", but are rejected. This sort of thing is very unusual, but possible. It's better to reject the handful of addresses using a very strange syntax than it is to allow just about anything, since the typo mistakes are far more common than the "weird" addresses.

But, getting this exactly right can be tricky. The reason I recommend using a regular expression is that there are expressions out there that are widely used all over the internet that you can easily incorporate in your RPG program. Since these have been well-tested, they are usually a pretty good solution.

If you make up your own checking routine using things like %SCAN, %SUBST, %CHECK, etc, you may be able to make something that works well, but it's hard (when done that way) to get something as widely used and tested as the ones you can get with a regular expression.

That's my 2 cents, anyway.


On 10/15/2014 1:19 PM, John Yeung wrote:

On Wed, Oct 15, 2014 at 11:52 AM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

On 10/14/2014 7:46 PM, John Yeung wrote:

I guess it might depend on precisely what you
want to accept as "valid syntax" of an e-mail address, but for basic
"eyeball" tests, %SCAN goes a long way. Maybe throw in %CHECK if
you're so inclined.

Valid is not in the eye of the beholder and not even in the eye of
RFC822. Valid is in the eye of the issuer. Well, one definition of
'valid' anyway.

Right. The definition of "valid" you've just described isn't the
definition I meant.

The point of the language that I used was to capture *your* use case
of trying to catch typos, which I'm sure is the OP's use case as well.
Because that's what almost all of us (in the IT trenches) are doing
when we have these checks. And it's almost all we *can* do, since
there isn't any completely reliable programmatic way to tell whether a
given e-mail address actually exists and is deliverable.

So the kind of checking we want to do *is* up to us, the beholder.
For some of us, it will probably be a net win if we reject non-ASCII
characters (just to take one example). For others of us, that may be
a horrible piece of logic to use.

John Y.