Perl-Sensitive Sunglasses | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
You made it clear already you reserve the right to pick and choose which parts of the RFC to support. That's your right within your own internal systems. It's also fair, when properly documented, for software you release. So I certainly wouldn't blame you for also picking and choosing which RFCs are relevant or which parts of those additional RFCs to support. However, just in case you're interested, I thought I'd give you this heads up.
From RFC 1101: For these reasons, we assume that the syntax of network names will be the same as the expanded syntax for host names permitted in [HR]. The new syntax expands the set of names to allow leading digits, so long as the resulting representations do not conflict with IP addresses in decimal octet form. For example, 3Com.COM and 3M.COM are now legal, although 26.0.0.73.COM is not. See [HR] for details. From RFC 1123 (STD 3): 2.1 Host Names and Numbers From RFC 2181 : Note however, that the various applications that make use of DNS data can have restrictions imposed on what particular values are acceptable in their environment. For example, that any binary label can have an MX record does not imply that any binary name can be used as the host part of an e-mail address. Clients of the DNS can impose whatever restrictions are appropriate to their circumstances on the values they use as keys for DNS lookup requests, and on the values returned by the DNS. If the client has such restrictions, it is solely responsible for validating the data from the DNS to ensure that it conforms before it makes any use of that data. Here some confusion creeps in, in RFC 2181 some leniency about support for "any binary label" needing to be served properly by DNS but not necessarily being allowed as a hostname in client application like, for example, SMTP. Then RFC 2822 specifies RFC 1035 instead of RFC 1123 as the authoritative DNS RFC. Yet RFC 2822 also states that a domain name for either a hostname or a mail exchanger (MX) name is in the terms of STD 3 (RFCs 1122 and 1123), STD 4 (which is reserved for routing topics and respresnts RFC 1812 for IPv4 routing), and STD 14 (which is historical). RFC 2822 defers to RFC 2821 for further information about domain names. RFC 2821 claims to clarify some of RFC 1123 for purposes of SMTP email and states that domain names for SMTP are limited to letters, digits, and hyphen and MUST NOT contain anything else (and specifically not underscore). It makes no mention of whether or not digits may lead or be the entirety of a label as mentioned in RFC 1123. It lists RFC 1035 in examples and suggests being conservative in DNS naming, but does not actually specify a SHOULD or MUST in relation to preferring RFC 1132 (which along with RFC 1122 is part of the Internet standard STD 3) or RFC 1035. It has been not just common practice, then, but some attempt to actually use the standards that allows domain parts other than the top-level domains to start with digits. Like I said before, your company's own decisions are another thing entirely so long as they are internal or clearly documented. You wouldn't be in violation of the RFCs if you were to allow domain name parts to start with digits, though, unless you allow four sections of all-digits in a row or allow top-level domains to start with a digit. In reply to Re: Practical e-mail address validation
by mr_mischief
|
|