RFC821 address functions in Notes – are they working properly?

I have been trying to use the built-in RFC821 address functions in Notes recently but has given up since they do not work correctly in my mind. A RFC821 – or an internet address – is in my mind composed of a local part (the part before the @-sign) and a period separated domain component (the part after the @-sign). A valid RFC821 address must contain both parts. Valid examples could be:

  • jdoe@example.com
  • john.doe@example.com
  • jdoe@sales.example.com

Notes/Domino has functions in @Formula, LotusScript and Java for working with and validating RFC821 addresses and none work as expected (probably because they all use the same C code). For example all functions will accept “jdoe@example” as a valid RFC821 address – an address which is my mind isn’t valid at all. This fact is further aggravated by the fact that I would expect to use the functions to distinguish between Notes addresses and RFC821 addresses. When the functions “work” as they do I cannot do that since jdoe@example could just as well be a Notes shortname followed by a Domino domain.

Below is a test case for LotusScript (non-blank value should indicate a valid RFC821 address).

Dim nn As New NotesName("jdoe@example.com")
Print nn.Addr821
>> jdoe@example.com
Set nn = New NotesName("jdoe@example")
Print nn.Addr821
>> jdoe@example

The help states:

The RFC 821 address is a name followed by an at sign followed by an organization, for example, jbg@acme.us.com. In an RFC 822 address, it is the part enclosed in pointed brackets.
This property returns an empty string if the name does not contain an RFC 821 Internet address.

In my mind this is just plain wrong.

5 thoughts on “RFC821 address functions in Notes – are they working properly?”

  1. I’m not sure what the RFC says, but in an internal environment – jdoe@example could well be a valid address.

    ‘example’ could be a (not fully qualified) hostname rather than a domain, so this would be required to route correctly. Bad practice IMHO, but possible…

    Similiarly, I suppose it’s possible that jdoe could be a user in the ‘example’ TLD – if one existed. Which makes me wonder – is there a postmaster@com ? I suppose theoretically there should be, or are TLD’s subject to different rules?


  2. Well section “3.7 Domains” of RFC 821 (http://www.ietf.org/rfc/rfc0821.txt) says (my emphasis): “Domains are a recently introduced concept in the ARPA Internet mail system. The use of domains changes the address space from a flat global space of simple character string host names to a hierarchically structured rooted tree of global addresses. The host name is replaced by a domain and host designator which is a sequence of domain element strings separated by periods with the understanding that the domain elements are ordered from the most specific to the most general.”.

    Strictly speaking it doesn’t say that a domain must be separated into more than one component. I guess that it is given that if there’s one component then there’s no need for any separation.

    I agree that in an internal case jdoe@example could be possible and resolvable as an MX record but as you say hardly recommended or usable.


  3. This is easy enough to work around. If you’re testing for validity, just add a condition to test for a period somewhere to the right of the @.

    I’m pretty sure that Sec. 3.7 (I just re-read it) *adds* the concept of dot-delimited domains to the older BITNET and bangpath type addresses, but does not replace them. The only “must” in the spec is that you can’t alias the domain, you have to use the “official” one. I think that it’s behaving properly.


  4. It may be working as designed but what’s the point of having methods validate an address that no one in the 21st century would ever use? My point is that there’s no need in having a method that only does some of the work since it means that some corner cases are not covered which is why I discovered the issue. In any case I guess it comes back to the documentation. If it stated how IBM interpreted RFC821 I would have caught the issue before going into production. I know it’s my bad that I didn’t think to test jdoe@example but still…


Comments are closed.