Hi Ken,
To: groupname: a, b, c;
Now the RFCs are a bit vague on what this means. RFC 5322, Section
3.4 says in part:
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.
Ok, fine. I've never seen a MUA actually treat those as a single
unit, and I don't even know what that would mean from a MUA's
perspective.
I think it's purely a presentational hint by the author that
To: cow-orkers: tom, dick, harry; xyzzy
can be so grouped and recipients understand and see those three are
under one umbrella with xyzzy separate. Receiving
To: cow-orkers: ; xyzzy
as nmh here dishes up, is very wrong.
To: undisclosed recipients:;
The author should have explictly written this empty group in this case.
The way nmh deals with this is to handle the second case.
Specifically, if you provide something like this:
To: list: a, b, c;
When post runs the email will be _sent_ to a, b, and c, but the
headers will look like this:
To: list:;
Then nmh is at fault AIUI; there is no concept of hiding the recipients
here, merely a group labelling of them. It stops recipients replying to
them.
- Should we leave the current behavior? It's been this way forever
and I think it's the most useful behavior for dealing with groups, but
I just want to be sure everyone is on the same page. It doesn't seem
to be documented anywhere (but it is mentioned in the MH book).
The current behaviour should be solely achievable by
To: undisclosed-recipients:;
dcc: tom, dick, harry
One of the nice things about MH/nmh is it's tried to follow the RFCs,
e.g. Gmail still doesn't show Resent-* headers last time I looked. I
don't think we should deviate for this trivial case. Is there a clue
why the recipients are being removed in the change history?
Cheers, Ralph.
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers