| Now the RFCs are a bit vague on what this means.
Not really, the syntax and semantics have always been quite clear.
Well, I guess it's a matter of how it all fits together. What it means
in a message, yeah, there's no real confusion there. Basically, ignore
the group name (as you state below, "it doesn't mean much").
| RFC 5322, Section 3.4 says in part:
| Ok, fine. I've never seen a MUA actually treat those as a single unit,
I'm not sure what you think that means?
Well, I _don't_ know what that means. "Treat as a single unit" - what,
exactly, does that mean? What do I, as a MUA programmer, need to do,
exactly? That's the vague part.
| and I don't even know what that would mean from a MUA's perspective.
OK ... it doesn't mean much, it is just intended to give a way to name a
list of recipients - think of it as the standard equivalent of MH's aliases.
Yeah, that's the weird part, at least to me ... how did the authors of
RFC 822 envision that would be used?
Any single message is treated as a unit, when you consider the message.
The addresses can be anywhere, so clearly it was never intended that the
"unit" be delivered at the same time to all, or anything like that.
Right, but my point was that stuff is not really spelled out anywhere;
that's why I'm asking.
You quoted the same text.
Whoops, my bad. I meant to include:
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 is probably what people are familiar with, e.g.:
| To: undisclosed recipients:;
I've seen it used both ways. That is, with the addresses included in the
header, and without.
I don't doubt you've seen it used both ways, but I have to ask: how
many decades ago did you see a group list that included the addresses
in the header? Of course I can't claim to seen every email ever, but
my impression that you'd see a few of those in the wild ... maybe 10-20
years ago. Nowadays I've solely seen the group functionality used for
blind distribution lists.
| The way nmh deals with this is to handle the second case.
Yes, I use groups a lot. This way they're useful for cases where I
want to send to a bunch of people, but not expose the addresses to the
recipients - but still give them some indication who the set of recipients
are (the group name).
Sure, that's definitely useful, and IMHO the only real functionality gain
to groups in practice.
The part where I'm talking about it being vague is ... well, as far as I
can tell, MUAs aren't required to omit addresses in the group list. In
fact, a VERY brief survey of MUAs makes me think nmh is alone in this
behavior. I don't think this necessarily wrong; it seems like it's
the most useful behavior. But this behavior is (as far as I can tell)
neither endorsed nor prohibited by the RFCs; it's a grey area. But what
gives me pause is I know many of the original people who worked on MH
way back when were ALSO involved in the email standardization process,
so I'm inclined to give the implementation that they actually worked on
as some serious evidence as to what they were thinking.
To give some background: I think people are aware that I'm been working
on RFC-2047 encoding support. To do that properly requires parsing out
address headers. That means understanding how nmh does address parsing,
which led me into the group handling. That made me ask, "Hey, what is
going on here?", which led me to read the RFCs, which left me confused ...
and here we are :-)
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers