Does RFC 5322 allow reply-to header without any actual e-mail address? If so, what is its semantic?

Question

Section 3.6.2 of RFC 5322 defines the reply-to header as:

reply-to        =   "Reply-To:" address-list CRLF

Where address-list is defined at section 3.4. When unfolding the ABNF grammar, I find that address-list can consist of nothing but phrase ":" ";" (phrase being defined at section 3.2.5). So it boils down to you being able to add a reply-to header that does not contains any actual e-mail address.

The RFC states:

When the "Reply-To:" field is present, it indicates the address(es) to which the author of the message suggests that replies be sent.

Even if it is only a suggestion, it seems rather strange that I can suggest to someone to reply to an address I name but don't specify.

Am I missing something here? How should I interpret such a construction?

Answer 1

You seem to have discovered an oversight in the spec. Nice!

If you read the rest of Section 3.4, you find this (emphasis mine):

When it is desirable to treat several mailboxes as a single unit (i.e., in a distribution list), the group construct can be used. The group construct allows the sender to indicate a named group of recipients. This is done by giving a display name for the group, followed by a colon, followed by a comma-separated list of any number of mailboxes (including zero and one), and ending with a semicolon. Because the list of mailboxes can be empty, using the group construct is also a simple way to communicate to recipients that the message was sent to one or more named sets of recipients, without actually providing the individual mailbox address for any of those recipients.

This makes sense in the context of (e.g.) To or CC, but not (e.g.) From or Reply-To. They got this right for "From" by specifying it as a mailbox-list, but they seem to have botched it for Reply-To.

It looks like they should have made Reply-To a mailbox-list instead of an address-list. Might be worth trying to contact the IETF working group to point out the error.

[update]

I have submitted an erratum against RFC 5322 for this issue:

http://www.rfc-editor.org/errata_search.php?eid=2816

Let's see what they do with it.