On 16/04/2022 10.53, Viktor Dukhovni wrote:
> On Fri, Apr 15, 2022 at 04:30:19PM -0600, @lbutlr wrote:
>
>> However, it is *very* common for a BBC email to have a To header with
>> no email address in it at all,
>
> This violates RFC5322 and earlier versions. The "To:" header must
> contain at least one address (or group).
>
> https://datatracker.ietf.org/doc/html/rfc5322#section-3.4
> https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.3
Which says that the word "To", followed by a colon, must be followed by
a list.
Whilst this is correct, the To-header itself, is optional.
However, in the 'not allowed' reaction, there is some room for
ironic amusement. The Robustness principle, ie
"be conservative in what you send, be liberal in what you accept"
is also known as Postel's law. Jon Postel was the editor of the RFCs,
for something like 30-years.
TLDR: some history, which (eventually) confirms the above!
It won't tell you (Victor or others of my 'betters' on this list)
anything, but diving down this 'rabbit-hole', as a break from other
research (courtesy of this list) and because the topic amused me,
tickling at my memory:-
Originally, ie way-back, as far as last century; email was sent over FTP.
RFC524 is more interested in mailbox@host, but talks of "recipient" in
the "short body".
An early attempt to harmonise several differing email ideas was RFC680
which talked about a "header" - but neither the example message nor the
formal syntax included a recipient/To:
As well as the "Message Transmission Protocol" (RFC680) starting the
separation from FTP, talks of distinguishing "human processing and
features for machine processing". It's "required headers" continued by
only including date and sender. It recognised three "Receiver
Specifications", our familiar To, CC, and BCC. However,
misunderstandings and factions followed, and this became known as an
"interim" arrangement.
1977 was a busy year. Ideas such as one user having multiple mail-boxes
and messages being sent to "Address lists" or "Groups" were formally
proposed in RFC724. Two interesting statements appear in one paragraph:
"No mechanism for authentication is provided, since the Network
provides no mechanisms for enforcing mail security. The syntax does
provide for one aspect of "correctness": a distinction is made
between an address which is claimed to be a valid network address and
one which is simply free text, included for the convenience of the
human participants."
Then there is:
"some of the header fields must be included in all messages. In
addition to the fields specified in this document, it is expected
that other fields will gain common use. User-defined header fields
allow systems to extend their functionality while maintaining a
uniform framework." Postel's law in other words!
General Syntax allowed for a message to be all headers or headers +
message-text. I guess if all one wishes to say is "come here, I want to
see you", 'headers' is all that is needed to convey the message!
Headers were split into "required" and "optional", and the only
required-headers were date and "originator".
The "receiver fields" were expanded to include "Fcc:" (for a few months,
that is).
By the end of the year, that "Proposed official standard" was re-drafted
as RFC733 "Standard for the format of ARPA network text messages". The
introduction loses no time getting into our topic:
"A distinction should be made between what the specification REQUIRES
and what it ALLOWS".
"To:" (etc) remain as "optional-field[s]".
Five years later, RFC822 intended to update (the above) and emphasised
the "requires" and "allows", particularly in the context of specific
systems being 'different', but requiring a basic convention towards
interoperability.
The pertinent change was:
fields = dates ; Creation time,
source ; author id & one
1*destination ; address required
*optional-field ; others optional
With "destination" explained as:
destination = "To" ":" 1#address ; Primary
/ "Resent-To" ":" 1#address
/ "cc" ":" 1#address ; Secondary
/ "Resent-cc" ":" 1#address
/ "bcc" ":" #address ; Blind carbon
/ "Resent-bcc" ":" #address
Thus, a To-field is not required, but at least one 'destination' is.
Interestingly, a field need NOT hold meaningful content:
field = field-name ":" [ field-body ] CRLF
My small brain can't cope with the syllogism of having (only) field
'labels' with no content, as acceptable (required) destination-fields -
but perhaps I'm mis-reading (mea culpa).
Rolling forward to this century, and the reading extends beyond fifty
pages! (progress?)
RFC 2822 3.6. Field definitions says "The only required header fields
are the origination date field and the originator address field(s). All
other header fields are syntactically optional.", and that the To: field
can appear a minimum of 0-times (same for Cc: and Bcc:).
Making me wonder if I missed something, even later discussion "3.6.3.
Destination address fields" doesn't indicate that at least one of these
should be meaningful. On the other hand, some older systems would
extract 'header' or 'envelope' meaning from message-contents.
RFC5322 seemed designed to rid the standards of 'cruft' and stream-line
things towards what we know-and-love today. There is discussion about
the need for, or need to omit, Originator fields.
It still talked of "A [header] field body may be composed of printable
US-ASCII characters as well as ... white space characters". Carried
forward was "The only required header fields..." (per above).
That said, (almost) at the end (p53/57) is "Appendix B. Differences
from Earlier Specifications". Which, almost-casually, drops:
19. Empty members of address lists not allowed.*"
but the asterisk indicates that it is an obsoleted feature. (Perhaps I
did mis-read something, somewhere, earlier?)
[Grump, notice that sometimes the term is "address-list" and at others
it is an "address list", which the user of my browser's Find-facility
did not enjoy!]
The-meat-of-the-matter appears as:
3.6.3. Destination Address Fields
The destination fields of a message consist of three possible fields,
each of the same form: the field name, which is either "To", "Cc", or
"Bcc", followed by a comma-separated list of one or more addresses...
to = "To:" address-list CRLF
but (3.4) defines:
address-list = (address *("," address))...
IIRC the surrounding parentheses indicate that the list, consisting of
one or more addresses, is a grouping, cf square-brackets indicating an
option, ie there must be at least one address in an address-list.
Thus, at least one address is (now) required, if a To: destination
header-field exists (same for Cc: and Bcc:). Yet, Postel's law...
--
Regards =dn
