Date: Wed, 04 Dec 2013 00:33:20 +0000
From: Ralph Corderoy <ralph(_at_)inputplus(_dot_)co(_dot_)uk>
Message-ID:
<20131204003320(_dot_)99C602DA1D(_at_)orac(_dot_)inputplus(_dot_)co(_dot_)uk>
| Where do the RFCs hint that it is OK to remove the recipients from
| "group: a, b, c;"?
Ken already sent a reply to this question ... sorry I originally missed your
message amongst various junk mail, and didn't see it (because you sent it
directly to me, and the list, the first message to arrive didn't have the
list headers, so my mail filtering didn't put it with other list mail - the
2nd copy was detected as a duplicate, and dropped...)
But I generally agree with his reply.
To reinforce a couple of points though.
First, all the e-mail standards (at least preceding the mail submission
protocol) talk only about the exchange of messages between MTAs, and the
meanings of the various fields in the header - there is (or was) nothing
about how the message was to initially be constructed and then the relevant
protocol parts of it conveyed to the MTA for message delivery.
Most early mail applications did all of the header construction for you,
the application was just told (in one way or another) what were to be the
destination addresses (and perhaps which header field each address should
go in - many just use "To" and nothing else - or did at the time) and
then took the message body, combined that with the constructed header,
and delivered that. I suspect that most still do.
MH took the opposite approach - perhaps for the first time, I'm not sure -
and instead allowed the user to construct the complete message, including
the header, and then extracted the protocol info from the relevant fields.
That is much more flexible for the user, much easier to allow new fields to
be added as need for them arises, etc - but is also much trickier to do
correctly.
For the group address issue, that the group is allowed to have no
addresses when the message is transmitted is clear ...
group = display-name ":" [group-list] ";" [CFWS]
(that's from 5322, but it has always been like that, with different
syntax for the grammar).
But, a group that had no recipients would clearly be a meaningless
concept, the intent is clearly not that there be no recipients, but
that they not be disclosed in the message header. 5322 actually says
so ...
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.
OK, so we know that this is what it all means, then it just comes down to
how the user conveys to the MUA what the destination addresses are, and
what the header should look like when the message is sent.
Remember there is no standard (or if you like, no rules) for this, any
system can do it however it likes.
With MH, extracting information from the header, as constructed by the
user, having a group with no addresses in the user constructed message
would clearly be a useless form ... since the header field is the only
place MH has from which to extract destination addresses, if there are
none present there, the message cannot be sent to anyone.
So, MH users must fill in the addresses in the group in the relevant header
field, then MH extracts them and adds them to the list of recipients.
Now, there's no question, it would be acceptable (in some sense anyway)
for MH to stop there, and simply transmit the message as it was formed.
But then MH users would have no way to do what is expressed as being one
of the uses of the group concept in the text quoted above. On the
other hand, when they do want to convey the list of addresses, there is
a solution ... just don't use the group construct (that the addresses are
related in some way could be indicated by comments inserted into the field.)
So (and here I am guessing, as I am not privy to the design decisions
of MH) the designers opted for the increased functionality of providing
the mechanism to allow sending to recipients without including their
addresses in the header, while sticking to the MH philosophy of the
user constructing the message, and MH interpreting it.
I do agree that it would have perhaps been better had the syntax for
groups (as interpreted my MH) been extended a little, to allow the
user to convey to MH which addresses in the group were to be retained
in the transmitted header, and which were to be removed - but that
wasn't done. It would be harder to add now than it would have been
originally, as now we need to keep compatibility with existing usage,
so we'd need to add a syntax to indicate that an address (or block of
addresses) were to be retained, rather than removed, which is not
as easily to design cleanly -- it would be fairly easy I guess if the
only option provided was all or none, we could add
group = display-name "::" group-list ";" [CFWS]
as input syntax to MH, which would generate
display-name ":" group-list ";"
on transmission, whereas (as now) the syntax
group = display-name ":" group-list ";" [CFWS]
on input would produce
display-name ":" ";"
when the message is transmitted (which is what MH does now).
Note however that I'm not offering to provide the code to implement that,
even less a more general form that would allow some addresses from the
group list to be retained in the header field, and others removed. For
my usage (and I do use groups quite a lot - I have dozens in my MH aliases
file) I'm quite happy with how MH processes the header now, and have
no need for any modifications - that is, I certainly wouldn't object
to an extension that added this functionality, and assuming it was done
properly, I'd probably even consider it a good idea - just not one that
is in sufficient demand to expect anyone (and definitely not me) to work on.
If you want to provide code to fix it (code that doesn't break existing
usage) then please, go ahead.
Lastly, while more documentation seems like always a good thing, we do
need to be a little careful that the MH documentation doesn't just turn
into a copy of 5322 ... after all, what MH is supposed to permit is
anything that the e-mail standards permit (plus more, as it is being used
in an extended role). Documenting the "plus more" is clearly needed,
but I'm not sure it is reasonable to expect the MH doc to cover everything
that the e-mail standards already say (books on the other hand can do so much
more, and/or be more selective) - certainly it is rarely a good idea to
add documentation for some facility, just because some user who didn't
know it existed discovers it, and thinks it's cool, and so should be
documented - doing that leads to a very patchy documentation set, with
some stuff covered in loving detail, and other stuff, just as important,
barely touched "because everyone knows that already" ...
kre
ps: if you wanted to design an MH input syntax that was a little more general,
probably general enough, that allowed the most flexible input, I'd
probably produce something like ...
group = display-name ":" [group-list] [ ":" group-list ] ";"
with the extra rule that at least one of the group-lists exist, and
contain at least one address (no real need to enforce that, but the
group is meaningless without it - meaningless as a user specification of
destination addresses). MH would then produce a 5322 syntax group construct,
containing any addresses that are in the 2nd of the two group lists (if it
is present) and omitting any that were in the first (if it is present).
(No need to special case handling of cases where an address is in both
group-lists, just allow whatever the code does naturally to happen...)
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers