Bruce Lilly wrote:
Christopher Yorke wrote:
The confusion on my
part arises when I consult the obs-mbox-list production:
obs-mbox-list = 1*([mailbox] [CFWS] "," [CFWS]) [mailbox]
Again, if my reading of RFC 2234 is correct, this means that
obs-mbox-list
must consist of at least one comma, but that's it. It doesn't seem to
require any addresses at all.
The obs- syntax in 2822 is intended to allow parsing of old messages,
while the regular (non-obs-) syntax is for generation of new messages.
Yes, I understood that. However, I failed to consider RFC 724 in my
definition of old messages, only RFC 822.
If you go back to RFC 724, you'll see that a From header field body
could in fact be completely empty:
<any-from-field> ::= "From" ":" <address-list>
...
<address-list> ::= <null>
| <address-item>
| <address-item> "," <address-list>
In order to be able to handle old messages, a parser should be able
to handle lists with empty elements. The degenerate case, as you
point out, has no mailboxes at all. A robust parser would not fail
even on an empty field body, such as was legal under RFC 724 (i.e. not
even a comma).
If my understanding of this production is correct, the "From" field could
contain no addresses, one address, one address followed by a comma, address
comma address, and so on. At the very least, obs-mbox-list doesn't seem to
allow an empty field body since everything is optional *except* for the
comma.
Of course, generating an RFC 2822-compliant From header field requires
at least one mailbox, and no null list elements (including at the
start or end of the list).
At least I understand this.