Programmers with network engineering skills
Owen DeLong
owen at delong.com
Mon Mar 12 22:40:29 UTC 2012
I don't believe that is true.
From RFC-821, it is true that:
@ONE, @TWO:JOE at THREE
Is supposed to be valid as a forward path, but, not an address. However, I believe its
use is effectively, if not actually deprecated at this point.
It doesn't really describe address, per se, but, it does define mailbox as follows:
mailbox
A character string (address) which identifies a user to whom mail
is to be sent. Mailbox normally consists of the host and user
specifications. The standard mailbox naming convention is defined
to be "user at domain". Additionally, the "container" in which mail
is stored.
Looking at more recent RFC 5321,
One important change is this:
Only resolvable, fully-qualified domain names (FQDNs) are permitted
when domain names are used in SMTP. In other words, names that can
be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
in Section 5) are permitted, as are CNAME RRs whose targets can be
resolved, in turn, to MX or address RRs. Local nicknames or
unqualified names MUST NOT be used. There are two exceptions to the
rule requiring FQDNs:
o The domain name given in the EHLO command MUST be either a primary
host name (a domain name that resolves to an address RR) or, if
the host has no name, an address literal, as described in
Section 4.1.3 and discussed further in the EHLO discussion of
Section 4.1.4.
Regarding addresses, it says this:
2.3.11. Mailbox and Address
As used in this specification, an "address" is a character string
that identifies a user to whom mail will be sent or a location into
which mail will be deposited. The term "mailbox" refers to that
depository. The two terms are typically used interchangeably unless
the distinction between the location in which mail is placed (the
mailbox) and a reference to it (the address) is important. An
address normally consists of user and domain specifications. The
standard mailbox naming convention is defined to be
"local-part at domain"; contemporary usage permits a much broader set of
applications than simple "user names". Consequently, and due to a
long history of problems when intermediate hosts have attempted to
Klensin Standards Track [Page 15]
RFC 5321 SMTP October 2008
optimize transport by modifying them, the local-part MUST be
interpreted and assigned semantics only by the host specified in the
domain part of the address.
Yes, there are user parts that are technically valid which my regex would reject. There are also some invalid addresses which I don't reject (for example, I won't reject Abc. at example.com).
If you want to get truly pathologically pedantic about it:
http://en.wikipedia.org/wiki/Email_address#Valid_email_addresses
You may have noticed my particular test wouldn't accept foo!bar!ucbvax!user format addresses, either.
It works well enough for my purposes. I did not claim it was perfect.
Owen
On Mar 12, 2012, at 3:01 PM, William Herrin wrote:
> On Mon, Mar 12, 2012 at 5:32 PM, Owen DeLong <owen at delong.com> wrote:
>> Whenever I've built code to check someone's email address on a form, I always just looked for the following:
>>
>> 1. matches ^[^@]+@[A-Za-z0-0\-\.]+[A-Za-z]$
>> 2. The component to the right of the @ sign returns at least one A, AAAA, or MX record.
>
> Hi Owen,
>
> If I'm not mistaken, "B at M4N"@delong.com is a legitimately formatted
> email address which fails part one of your test. Something along the
> lines of @delong.com;bob at some.private.network is also supposed to be
> legit though it's been so long since I looked at it that I may have
> munged the format.
>
> No, I don't allow these in systems I've designed either. Just sayin'.
>
> Regards,
> Bill Herrin
>
>
>
> --
> William D. Herrin ................ herrin at dirtside.com bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
More information about the NANOG
mailing list