On Fri, 10 May 2002, Kevin Stone wrote:
> As we all know ARPA is thet university network, funded by the government
> to build an information infrastructure that eventually became the
> internet we have today. But the standards for text messaging within the
> ARPA net have been added to over the years in order to accomodate ever
> expanding requirments.
Yes, and those changes are codified into new RFCs which eventually become
standards. By all means have a look at RFC 2822 which, if passed into use,
will obsolete 822.
> For example I have read that a valid email needn't necessarily require
> anything before the @ symbol. The ARPA RFC specifically states that it
> does. But <[EMAIL PROTECTED]> can be just as valid as <@foo.bar.com> if the the
> domain resolves and the server is setup to parse from a catch all account
> named ''. Is this not true?
Sure, and if a web server is set up to respond to a request like:
SPLEARGH www.boogermax.com/greebles ? 888 *** 3424235667
then web browsers could send it and get something in return, but it
doesn't mean it's a valid HTTP request.
> If this is true then eregi(/^[a-z0-9]+/, $email ) wouldn't necessarily be
> valid. We could then say that eregi(/^[a-z0-9]*/, $email) is pointless
> becuase if nothing has to be there then there isn't any reason to look for
> it. And thus we return to the original assertion that ereg('@', $email) is
> the only way to know that the string is a properly formated email address.
"Properly formatted email address" is a term whose meaning derives from a
prescriptive, rather than descriptive, definition. A properly-formatted
email address is one which has been properly formatted in accordance with
the rules governing mail addressing, and nothing any more arbitrary than
> So why even validate that format beyond the most basic rules (@, length, and
> invalid characters)? The result of which is useless, unless the address is
> sendable, in which case the string format is irrelevant.
Why even look for an @ sign then? I can address a message to 'mnc' and it
will arrive just fine - within my zone of control.
The reason that we use standards is to ensure that hardware and software
from various vendors can communicate with each other without unexpected
results. As soon as you start giving that up, you subdivide the internet
into smaller zones of mutual compatibility. About 99.9% of the time, there
is no constructive reason for doing it. Given the flexibility already
allowed in email addressesing, I certainly don't see this as one of the
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php