83521 - Use RFC822 "groups" for Mozilla's "lists" during composition

Status: NEW

(MailNews Core :: Address Book, enhancement)

Description

[Ben Bucksch (:BenB)]

We support "lists" in the Address Book, which group several addresses together
to implement client-side "mailing lists".

The ideal mapping to RFC822 (msg format) is to use "groups":

From RFC2822, Section 3.4.:

group           =       display-name ":" [mailbox-list / CFWS] ";"
                        [CFWS]

[...]
   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. This is done by giving a display name for the group,
   followed by a colon, followed by a comma separated list of any number
   of mailboxes (including zero and one), and ending with a semicolon.
   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 each of those
   recipients.

From RFC822:

group       =  phrase ":" [#mailbox] ";"
[...]
6.2.6.  MULTIPLE MAILBOXES

        An individual may have several mailboxes and wish  to  receive
        mail  at  whatever  mailbox  is  convenient  for the sender to
        access.  This standard does not provide a means of  specifying
        "any member of" a list of mailboxes.

        A set of individuals may wish to receive mail as a single unit
        (i.e.,  a  distribution  list).  The <group> construct permits
        specification of such a list.  Recipient mailboxes are  speci-
        fied  within  the  bracketed  part (":" - ";").  A copy of the
        transmitted message is to be  sent  to  each  mailbox  listed.
        This  standard  does  not  permit  recursive  specification of
        groups within groups.

        While a list must be named, it is not required that  the  con-
        tents  of  the  list be included.  In this case, the <address>
        serves only as an indication of group distribution  and  would
        appear in the form:

                                    name:;

        Some mail  services  may  provide  a  group-list  distribution
        facility,  accepting  a single mailbox reference, expanding it
        to the full distribution list, and relaying the  mail  to  the
        list's  members.   This standard provides no additional syntax
        for indicating such a  service.   Using  the  <group> address
        alternative,  while listing one mailbox in it, can mean either
        that the mailbox reference will be expanded to a list or  that
        there is a group with one member.


So, if a user says "send this mail to this list" (there are sevreal ways to do
that in the Mailnews Composer), we should use the group construct to make the
group explicit to the recipient.

We need to consider the case where a user doesn't want the name of the group to
be shown to recipients. We have the same problem for normal adresses, so we
should use the same solutions (display name vs. nickname or similar).

Comment 1

[Ben Bucksch (:BenB)]

Bug 83516 is about groups in the viewer.

Comment 2

[James Ralston]

I don't really care that much about how Mozilla expands internal mailing lists,
but I *do* care if I can't do this:

    undisclosed-recipients:;

And I can't.  The above is a perfectly valid recipient according to RFC822, yet
Mozilla won't accept it if I enter it into the composer as an address.  That's a
clear failure to comply with RFC822, and is a bug.

This bug should be nominated for mozilla1.0.

Comment 3

[(not reading, please use [e-mail] instead)]

taking all of chuang's bugs.  she doesn't work on mozilla anymore.

Comment 4

[Mike Cowperthwaite]

*** Bug 299908 has been marked as a duplicate of this bug. ***

Comment 5

[Hideo Oshima]

I think Composition as component is more appropriate 
than Address book, isn't it?

Comment 6

[Sean Vickery]

(In reply to comment #5)
> I think Composition as component is more appropriate 
> than Address book, isn't it?

I'm not sure as I don't know the code. Thunderbird might want to support RFC822
groups in its mailing lists, part of its Address Book.

Comment 8

[Gudmund Areskoug]

Shouldn't these bugs

<https://bugzilla.mozilla.org/show_bug.cgi?id=163498>
<https://bugzilla.mozilla.org/show_bug.cgi?id=378531>

belong in one single bug, e. g. "Bcc handling in Address Book", which would
include lists?

A setting for an address to default to Bcc as soon as there are several
addresses included in sending a message might be a nice thing. Presumably, it
might be turned into part of electronic address preferences as in vCard etc.
standards (<http://en.wikipedia.org/wiki/VCard>).

I see Joshua Cranmer is on the go squashing duplicates, perhaps the two mentioned above could be pooled into this one too, or vice versa.

Comment 9

[Mark Banner (:standard8)]

(In reply to comment #8)
> Shouldn't these bugs
> 
> <https://bugzilla.mozilla.org/show_bug.cgi?id=163498>
> <https://bugzilla.mozilla.org/show_bug.cgi?id=378531>
> 
> belong in one single bug, e. g. "Bcc handling in Address Book", which would
> include lists?

No, because BCC isn't quite the same as using RFC822 groups.

Comment 10

[Sean Vickery]

A really good implementation of this would provide at least these functions:

Scenario 1:

Open up a new message window. Type the name of the group in the To: field. The group has been configured in the Address Book to be a "blind" group. Upon sending, TB inserts the header

  To: group-name:;

and puts the actual recipients only in the message's envelope. The message is filed in Sent with the actual recipients in Bcc headers.


Scenario 2:

I want to knock up a quick message to several people about a meeting. I don't want to disclose their email addresses to each other. So I type in 

  meeting-invitees:;

in the To: field. (Meeting-invitees is not an existent group in my address book.)  I enter their actual email addresses in the Bcc field.

TB passes the To: meeting-invitees:; header unprocessed to the MTA.

This gives the recipients an idea why they're receiving the message.



Scenario 2 would be easier to implement so might be a good start.

Comment 11

[Gudmund Areskoug]

How about the ability to in some user-safe way handle the situation when only some addresses in a list/group need to be bcc? File a new bug, or would that be covered here?

Comment 12

[Takanori MATSUURA]

Bug 242693 is now fixed.  So we can use
To: foo: addr1, addr2, ..., addrn;

But it ex extracted as the following when the email is saved or sent:
To: addr1, addr2, ..., addn

Comment 13

[Takanori MATSUURA]

I suppose this bug should be set
Component: "Address Book" -> "Composition"
Depends on: 242693 (already fixed)