Re: Adding text to subject when calling group
On 09.06.21 12:15, steve wrote: > Hello, > > Nobody for this one? > > I found that I could modify the subject with a folder-hook but that's > only half of the solution since it doesn't take care of the group alias > part. > > Any help would be highly appreciated. I'd try a message-hook with pattern: %C GROUP │messages either to: or cc: to any member of GROUP Have a look at "Table 4.4. Pattern modifiers" under the heading "3.1. Pattern Modifier" in the manual. (On key F1 in mutt.) I'd need a quick read of section "6. Using Hooks", for the header edit, asit's a while since I last wrote one. IIRC, send-hooks & message-hooks are triggered prior to composing a message, so if you have "set edit_headers=yes", then your modified header ought to show in the edit session. (Not tried.) Erik
Re: Adding text to subject when calling group
Hello, Nobody for this one? I found that I could modify the subject with a folder-hook but that's only half of the solution since it doesn't take care of the group alias part. Any help would be highly appreciated. Steve Le 02-06-2021, à 08:54:50 +0200, steve a écrit : Hi, In the alias file, I defined several users and with them defined a group 'groupX'. When creating a new message with 'm' and calling 'groupX', I would like to add a fixed text to the subject line (only when the alias 'groupX' is called'). How could I do that? I failed to find that particular usecase on the Net. Thanks Steve
Adding text to subject when calling group
Hi, In the alias file, I defined several users and with them defined a group 'groupX'. When creating a new message with 'm' and calling 'groupX', I would like to add a fixed text to the subject line (only when the alias 'groupX' is called'). How could I do that? I failed to find that particular usecase on the Net. Thanks Steve
Re: group and alias
On 01Mar2021 09:45, Kevin J. McCarthy wrote: >On Mon, Mar 01, 2021 at 01:32:47AM -0500, Jon LaBadie wrote: >>And where/how do you use the group rather than the alias? > >Groups are used in patterns. See the modifiers starting with '%' in ><http://www.mutt.org/doc/manual/#patterns>. For example, the "%f htmlers" in the last line below: # alternative-order criteria message-hook . 'unalternative_order *; alternative_order text/plain text/html' # Apple Mail embeds attachments in the HTML part instead of outside # the multipart/mixed message-hook '~h "X-Mailer: Apple Mail" ~X 1-' 'unalternative_order *; alternative_order text/html multipart/mixed text/plain' # senders who can't seem to master multipart/mixed, and send empty # or useless text/plain sections # or just badly badly formatted plain text, such as live.com etc message-hook '%f htmlers | ~f @no-re...@cc.yahoo-inc.com | ~f @outlook.com | ~f live.com | ~f @facebookmail.com' 'unalternative_order *; alternative_order text/html text/plain' Cheers, Cameron Simpson
Re: group and alias
On Mon, Mar 01, 2021 at 01:32:47AM -0500, Jon LaBadie wrote: And where/how do you use the group rather than the alias? Groups are used in patterns. See the modifiers starting with '%' in <http://www.mutt.org/doc/manual/#patterns>. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: group and alias
On Mon, Mar 01, 2021 at 01:19:10PM +1100, Cameron Simpson wrote: On 28Feb2021 19:00, Jon LaBadie wrote: Trying to use the "group" facility. Expected I could do something like: group -group ABC -addr -addr -addr And then email 3 people with $ mutt ABC I am able to accomplish this with an alias: alias ABC , , Is this not an application for which "group" was intended? Aliases probably predate groups, I'd expect. They can contain only addresses (including other aliases). Groups can include regexps for matching, so they're arguably more a PATTERN thing than an alias is. And I presume that recognising that often aliases and groups server the same purpose, alias has a -group options which also adds the addresses to a named group. I maintain my alias using a small otuside db, and autogenerate them. They all have the form: alias -group group_name alias_name \ address, \ ... etc ... where in fact group_name and alias_name are the same name. And where/how do you use the group rather than the alias? Jon -- Jon H. LaBadie j...@labadie.us 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: group and alias
On 28Feb2021 19:00, Jon LaBadie wrote: >Trying to use the "group" facility. Expected I could >do something like: > group -group ABC -addr -addr -addr > >And then email 3 people with > > $ mutt ABC > >I am able to accomplish this with an alias: > > alias ABC , , > >Is this not an application for which "group" was intended? Aliases probably predate groups, I'd expect. They can contain only addresses (including other aliases). Groups can include regexps for matching, so they're arguably more a PATTERN thing than an alias is. And I presume that recognising that often aliases and groups server the same purpose, alias has a -group options which also adds the addresses to a named group. I maintain my alias using a small otuside db, and autogenerate them. They all have the form: alias -group group_name alias_name \ address, \ ... etc ... where in fact group_name and alias_name are the same name. Cheers, Cameron Simpson
group and alias
Trying to use the "group" facility. Expected I could do something like: group -group ABC -addr -addr -addr And then email 3 people with $ mutt ABC I am able to accomplish this with an alias: alias ABC , , Is this not an application for which "group" was intended? Jon -- Jon H. LaBadie j...@labadie.us 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: Differences and interactions between subscribe, lists, group, alternates and alias.
On Mon, Feb 15, 2021 at 06:04:03PM -0600, boB Stepp wrote: > On 21/02/16 12:28AM, Øyvind A. Holm wrote: > > On 2021-02-16 00:17:22, Øyvind A. Holm wrote: > > > On 2021-02-15 16:01:06, boB Stepp wrote: > > > > > On Monday, 15 February at 21:53, boB Stepp wrote: > > > > > > And from reading the Mutt manual I have encountered the > > > > > > alternates option, but now I am not sure what it is useful for > > > > > > and how to most effectively use it. > > > > > > > > And "alternates" is still a mystery... > > > > > > It is used if you have any alternate or old email addresses. > > > `alternates` makes it possible for Mutt to mark messages in the index > > > with "F" (from one of your addresses), "+" or "T" (to one of your > > > addresses), etc. For example, > > > > > >alternates job_em...@example.net > > >alternates old_em...@example.com > > >alternates another_...@example.org > > > > > > Now Mutt knows that all these addresses belong to you. > > > > A small correction (even though the above example will work). The > > parameter after `alternates` is a regexp, so a more correct way to write > > them would be > > > >alternates ^job_email@example\.net$ > >alternates ^old_email@example\.com$ > >alternates ^another_old@example\.org$ > > > > to avoid false positives with for example "yet_another_...@example.org". > > So is this mostly to provide labeling information in the index? I suppose it > might be usable for some sort of filtering purposes... > > -- > Wishing you only the best, > > boB Stepp Alternates is also relevant for the reverse_name setting: reverse_name Type: boolean Default: no It may sometimes arrive that you receive mail to a certain machine, move the messages to another machine, and reply to some the messages from there. If this variable is set, the default From: line of the reply messages is built using the address where you received the messages you are replying to if that address matches your “alternates”. If the variable is unset, or the address that would be used doesn't match your “alternates”, the From: line will use your address on the current machine. Also see the “alternates” command. Very handy when you have hundreds of email addresses. cheers, raf
Re: Differences and interactions between subscribe, lists, group, alternates and alias.
On 2021-02-15 18:04:03, boB Stepp wrote:
> On 21/02/16 00:28, Øyvind A. Holm wrote:
> > On 2021-02-16 00:17:22, Øyvind A. Holm wrote:
> > > On 2021-02-15 16:01:06, boB Stepp wrote:
> > > > And "alternates" is still a mystery...
> > >
> > > It is used if you have any alternate or old email addresses.
> > > `alternates` makes it possible for Mutt to mark messages in the
> > > index with "F" (from one of your addresses), "+" or "T" (to one of
> > > your addresses), etc. For example,
> > >
> > >alternates job_em...@example.net
> > >alternates old_em...@example.com
> > >alternates another_...@example.org
> > >
> > > Now Mutt knows that all these addresses belong to you.
> >
> > A small correction (even though the above example will work). The
> > parameter after `alternates` is a regexp, so a more correct way to
> > write them would be
> >
> >alternates ^job_email@example\.net$
> >alternates ^old_email@example\.com$
> >alternates ^another_old@example\.org$
> >
> > to avoid false positives with for example
> > "yet_another_...@example.org".
>
> So is this mostly to provide labeling information in the index? I
> suppose it might be usable for some sort of filtering purposes...
Yes, it also works with limiting ("l") and search ("/") in the index.
For example,
~P|~p
will search for or limit the view to all mails to/from you. It also
makes reply a bit more intelligent. For example, when I replied to the
first mail I sent it didn't address it to me, but either you ("r") or
the list ("L").
Regards,
Øyvind
geo:60.38,5.33;u=500
OpenPGP fingerprint: A006 05D6 E676 B319 55E2 E77E FB0C BEE8 94A5 06E5
21039562-6feb-11eb-9c1a-5582e081d110
Re: Differences and interactions between subscribe, lists, group, alternates and alias.
On 21/02/16 12:28AM, Øyvind A. Holm wrote: On 2021-02-16 00:17:22, Øyvind A. Holm wrote: On 2021-02-15 16:01:06, boB Stepp wrote: > > On Monday, 15 February at 21:53, boB Stepp wrote: > > > And from reading the Mutt manual I have encountered the > > > alternates option, but now I am not sure what it is useful for > > > and how to most effectively use it. > > And "alternates" is still a mystery... It is used if you have any alternate or old email addresses. `alternates` makes it possible for Mutt to mark messages in the index with "F" (from one of your addresses), "+" or "T" (to one of your addresses), etc. For example, alternates job_em...@example.net alternates old_em...@example.com alternates another_...@example.org Now Mutt knows that all these addresses belong to you. A small correction (even though the above example will work). The parameter after `alternates` is a regexp, so a more correct way to write them would be alternates ^job_email@example\.net$ alternates ^old_email@example\.com$ alternates ^another_old@example\.org$ to avoid false positives with for example "yet_another_...@example.org". So is this mostly to provide labeling information in the index? I suppose it might be usable for some sort of filtering purposes... -- Wishing you only the best, boB Stepp
Re: Differences and interactions between subscribe, lists, group, alternates and alias.
On 2021-02-16 00:17:22, Øyvind A. Holm wrote: > On 2021-02-15 16:01:06, boB Stepp wrote: > > > On Monday, 15 February at 21:53, boB Stepp wrote: > > > > And from reading the Mutt manual I have encountered the > > > > alternates option, but now I am not sure what it is useful for > > > > and how to most effectively use it. > > > > And "alternates" is still a mystery... > > It is used if you have any alternate or old email addresses. > `alternates` makes it possible for Mutt to mark messages in the index > with "F" (from one of your addresses), "+" or "T" (to one of your > addresses), etc. For example, > >alternates job_em...@example.net >alternates old_em...@example.com >alternates another_...@example.org > > Now Mutt knows that all these addresses belong to you. A small correction (even though the above example will work). The parameter after `alternates` is a regexp, so a more correct way to write them would be alternates ^job_email@example\.net$ alternates ^old_email@example\.com$ alternates ^another_old@example\.org$ to avoid false positives with for example "yet_another_...@example.org". Regards, Øyvind geo:60.38,5.33;u=500 OpenPGP fingerprint: A006 05D6 E676 B319 55E2 E77E FB0C BEE8 94A5 06E5 b12c0f9a-6fe4-11eb-8623-5582e081d110
Re: Differences and interactions between subscribe, lists, group, alternates and alias.
On 2021-02-15 16:01:06, boB Stepp wrote: > > On Monday, 15 February at 21:53, boB Stepp wrote: > > > And from reading the Mutt manual I have encountered the alternates > > > option, but now I am not sure what it is useful for and how to > > > most effectively use it. > > And "alternates" is still a mystery... It is used if you have any alternate or old email addresses. `alternates` makes it possible for Mutt to mark messages in the index with "F" (from one of your addresses), "+" or "T" (to one of your addresses), etc. For example, alternates job_em...@example.net alternates old_em...@example.com alternates another_...@example.org Now Mutt knows that all these addresses belong to you. HTH, Øyvind geo:60.38,5.33;u=500 OpenPGP fingerprint: A006 05D6 E676 B319 55E2 E77E FB0C BEE8 94A5 06E5 ea237272-6fe2-11eb-8f99-5582e081d110
Re: Differences and interactions between subscribe, lists, group, alternates and alias.
On 21/02/15 10:33PM, Wim wrote: On Monday, 15 February at 21:53, boB Stepp wrote: ...BTW, typing "Mu" into the "To:" field and then hitting does *not* fill in the email address; instead, it brings up a browser view where I have to hit before the address is inserted. Is there a way, when there are no conflicting "Mu" entries, to just *immediately* have hitting insert the address? If you change your alias line to: alias Mu Mutt-Users typing Mu and will work, not . Ah! I was misunderstanding the function of in expanding things. I haven't done it yet, but what I would like to do is have different groups that I can type a shortcut and have all the email addresses inserted. For instance, I would like to have a group "Kids" which when typed would auto-expand into my kids' email addresses. Also, I would like to be able to type in abbreviations like "Jess" and have that expand to my daughter's email address. How would I go about doing this without having a browser view come up with numbered entries? I think what you want is this. Given the kids' email addresses: alias Joe Josephine Murphy alias Moe Moe Murphy you can alias them as: alias fam Joe Moe and typing fam and will auto-expand. Yep, this works. Thanks! So what is the purpose of "group"? How can it help me? And from reading the Mutt manual I have encountered the alternates option, but now I am not sure what it is useful for and how to most effectively use it. And "alternates" is still a mystery... -- Wishing you only the best, boB Stepp
Re: Differences and interactions between subscribe, lists, group, alternates and alias.
Hi boB, On Monday, 15 February at 21:53, boB Stepp wrote: > The current ongoing thread about lists and subscribe have led to my email. I > don't think I am understanding the differences and interactions to these > different Mutt configuration possibilities. > > From the other thread if I am understanding correctly for those mailing lists > that I am subscribed to and actively participating in in real life, it is to > my benefit to set these up with > setting subscribe for each such list. For these lists there is no point in my > using the lists configuration option. If I a just following a list, then > using lists configuration option is probably more appropriate. > > As to the group option I was under the impression that I could give a nice > shortcut name and assign a list of email addresses to it and then use it as an > alias. But that does not appear to be the case. For instance I had forgotten > to explicitly subscribe to Mutt-Users, so today added to my muttrc: > > subscribe -group Mutt-Users mutt-users@mutt.org > I've got a simple 'subscribe mutt-users' in my muttrc. It works. Subscribing to a list allow replying to that list with 'L'. > and had the expectation that since I used "-group", I could type "Mu" and hit > in the "To:" field and get the Mutt-Users address inserted. I was sadly > mistaken! I had to explicitly add > > alias Mutt-Users > > to my aliases file before that would occur. So I am not seeing how to use > "group". Can someone explain please? BTW, typing "Mu" into the "To:" field > and then hitting does *not* fill in the email address; instead, it > brings up a browser view where I have to hit before the address is > inserted. Is there a way, when there are no conflicting "Mu" entries, to just > *immediately* have hitting insert the address? > If you change your alias line to: alias Mu Mutt-Users typing Mu and will work, not . > I haven't done it yet, but what I would like to do is have different groups > that I can type a shortcut and have all the email addresses inserted. For > instance, I would like to have a group "Kids" which when typed would > auto-expand into my kids' email addresses. Also, I would like to be able to > type in abbreviations like "Jess" and have that expand to my daughter's email > address. How would I go about doing this without having a browser view come > up with numbered entries? I think what you want is this. Given the kids' email addresses: alias Joe Josephine Murphy alias Moe Moe Murphy you can alias them as: alias fam Joe Moe and typing fam and will auto-expand. > > And from reading the Mutt manual I have encountered the alternates option, but > now I am not sure what it is useful for and how to most effectively use it. > > I think that sums up most of my current head scratching. > > -- > Wishing you only the best, > > boB Stepp -- |\ _,,,---,,_ ZZZzz /,`.-'`'-. ;-;;,_ |,4- ) )-,_. ,\ ( `'-' '---''(_/--' `-'\_)
Differences and interactions between subscribe, lists, group, alternates and alias.
The current ongoing thread about lists and subscribe have led to my email. I don't think I am understanding the differences and interactions to these different Mutt configuration possibilities. From the other thread if I am understanding correctly for those mailing lists that I am subscribed to and actively participating in in real life, it is to my benefit to set these up with setting subscribe for each such list. For these lists there is no point in my using the lists configuration option. If I a just following a list, then using lists configuration option is probably more appropriate. As to the group option I was under the impression that I could give a nice shortcut name and assign a list of email addresses to it and then use it as an alias. But that does not appear to be the case. For instance I had forgotten to explicitly subscribe to Mutt-Users, so today added to my muttrc: subscribe -group Mutt-Users mutt-users@mutt.org and had the expectation that since I used "-group", I could type "Mu" and hit in the "To:" field and get the Mutt-Users address inserted. I was sadly mistaken! I had to explicitly add alias Mutt-Users to my aliases file before that would occur. So I am not seeing how to use "group". Can someone explain please? BTW, typing "Mu" into the "To:" field and then hitting does *not* fill in the email address; instead, it brings up a browser view where I have to hit before the address is inserted. Is there a way, when there are no conflicting "Mu" entries, to just *immediately* have hitting insert the address? I haven't done it yet, but what I would like to do is have different groups that I can type a shortcut and have all the email addresses inserted. For instance, I would like to have a group "Kids" which when typed would auto-expand into my kids' email addresses. Also, I would like to be able to type in abbreviations like "Jess" and have that expand to my daughter's email address. How would I go about doing this without having a browser view come up with numbered entries? And from reading the Mutt manual I have encountered the alternates option, but now I am not sure what it is useful for and how to most effectively use it. I think that sums up most of my current head scratching. -- Wishing you only the best, boB Stepp
Re: group-reply (ctrl-g) only replies To: but not Cc: ?
On Mon, 21 Jan 2019 17:55:42 -0600 wrote: > I' m not sure if this is supposed to be default behavior, but when I > attempt to group reply to an email, only those addresses previously > listed as To: are included in the response, and not those Cc'ed. Is > this a bug, something I may be suppressing, or something to enable? I > have not been able to find an answer anywhere online. > > Mutt -v > 8.1.1 20180712 (Red Hat 8.1.1-5) > > Thanks! > Please ignore this stupid mutt newbie question that took me hours to figure out... Just realized that it's working as expected, but wasn't asking about cc's.
group-reply (ctrl-g) only replies To: but not Cc: ?
I' m not sure if this is supposed to be default behavior, but when I attempt to group reply to an email, only those addresses previously listed as To: are included in the response, and not those Cc'ed. Is this a bug, something I may be suppressing, or something to enable? I have not been able to find an answer anywhere online. Mutt -v 8.1.1 20180712 (Red Hat 8.1.1-5) Thanks!
Re: [Mutt] Re: Group reply To-vs-Cc recipients
On Fri, Dec 14, 2018 at 03:20:57PM +0100, Mihai Lazarescu wrote: > On Thursday, December 13, 2018 at 17:56:51 -0600, Derek Martin wrote: > > >The majority of the community said nothing at all, which > >suggests (as I suggested) that most people don't actually give > >a $#@! about this, as well they shouldn't. I'll note that in > >response to Kevin's query, two people (Ariis and Christiansen) > >said preserving the To: line was sensible, and three people > >(Zimmerman, Yardley, and myself) said it seems pointless. > >There were no other opinions provided. > > For some posters here I probably don't fit in the "people" category, > since I made clear that both behaviours make very much sense and the > user, not MUA, should decide which and where to use. No, sorry, this was simply oversight on my part. > First reason, by design mutt has little appeal where the To:/Cc: > distinction is likely to matter, i.e., organizations with layered > structures. That's because such structures: I think this idea is a mistake. I use Mutt in just such a corporate environment and it does not hinder me in any way. And FWIW, for the nearly 15 years I've worked here, absolutely no one has come begging me to change the way I address my messages. It's largely pointless to care about this since users WILL NOT follow it uniformly, and once the convention is broken on your thread, it's permanently broken, since the overwhelming majority of users simply won't care enough to even notice. Besides, if you're in the camp that says that USUALLY the respondent is the primary recipient, but SOMETIMES it isn't, what do you want Mutt to do here? Ask you every time? That seems tedious and cumbersome. The fact is, at the time the RFC was published, nearly all clients behaved like Mutt does today (including Netscape Mail--Thunderbird didn't exist yet). Outlook was--as usual--the largest exception, but Outlook has always done things wrong. [Curiously, Exchange web client currently does work like Mutt.] I can't say for sure why the author decided to buck the trend and go soft on this, but I can guess: He worked for Qualcomm (they're named on the RFC), who published Eudora. Probably they thought it should be done the other way--most likely to be compatible with Outlook--but had to acknowledge that everyone else in the world did it the way Mutt does when they wrote the RFC. Eudora died in 2006, and Qualcomm turned its focus to a client based on Thunderbird. Then, assuming my theory is correct, it's not a big surprise that Thunderbird eventually adopted this approach. Most likely the Eudora developers would have moved to the Thunderbird team after Eudora's final demise, and brought with them their various ideas and prejudices. RFCs are not always free of corporate agenda, and the late 90's and early 2000's were a time when that was especially rampant, though Microsoft was the usual culprit. > Second reason, mutt project seems to be very conservative. Hence, if > something is not proven to be clearly broken (the code or the > reasoning behind it), then it is very unlikely to "outweigh the > risks" of most potential changes. This is not nearly as true as it used to be. Kevin, and Brendan before him, have done (I think) a good job at balancing progress vs. change risk. He may still make a change here, and he's well within his right to do so. As a final note, the bug poster has actually agreed with me and requested the bug be closed. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpBBsfeJgkrS.pgp Description: PGP signature
Re: [Mutt] Re: Group reply To-vs-Cc recipients
On Thu, Dec 13, 2018 at 05:56:51PM -0600, Derek Martin wrote: The majority of the community said nothing at all, which suggests (as I suggested) that most people don't actually give a $#@! about this, as well they shouldn't. I'm pretty happy with the turnout. I've re-read the discussion and arguments, and I appreciate everyone's time to voice their opinion. In the end, I still believe both modes have merit depending upon the situation. The default most certainly won't change, but I do plan on adding a new function. But FWIW Kevin isn't the only one with his sleeves rolled up--there are other maintainers, and beyond that there are other contributors, myself included, albeit infrequently. Vincent is the only other semi-active team member. Patches have been ticking up since the move to gitlab, but let's be honest, if I stepped away things would grind to a halt. I don't do this full time, so development moves at the pace I can sustain, which is somewhat slow. Other maintainers to share the load would be a good thing for the project. For those who share the culture and goals of Mutt, please consider that a "help wanted" sign. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Group reply To-vs-Cc recipients
On 2018-12-13 17:56, Derek Martin wrote: > The majority of the community said nothing at all, which suggests (as > I suggested) that most people don't actually give a $#@! about this, > as well they shouldn't. I'll note that in response to Kevin's query, > two people (Ariis and Christiansen) said preserving the To: line was > sensible, and three people (Zimmerman, Yardley, and myself) said it > seems pointless. There were no other opinions provided. My original one line message may have allowed different interpretations, so here I clarify: Derek's interpretation is correct, i.e. I see no need to change mutt's current behavior. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
Re: [Mutt] Re: Group reply To-vs-Cc recipients
On 2018-12-13, Derek Martin wrote: > On Wed, Dec 12, 2018 at 01:18:04PM +1100, Erik Christiansen wrote: > >> Then the thoughts of the majority of the community bear >> consideration, especially when based on reason. > > The majority of the community said nothing at all, which suggests (as > I suggested) that most people don't actually give a $#@! about this, > as well they shouldn't. Depending on the definitions of "community" and "most people", there's also the problem that an undefined number of mutt users might not be reading this list at all. > I'll note that in response to Kevin's query, > two people (Ariis and Christiansen) said preserving the To: line was > sensible, and three people (Zimmerman, Yardley, and myself) said it > seems pointless. There were no other opinions provided. Whatever ends up being done, I'd advise against *changing* the default behaviour, either keep just the current behaviour or add an alternative, but keep it disabled by default. But I'm just a user. -- Nuno Silva
Re: [Mutt] Group reply To-vs-Cc recipients
On Tuesday, December 11, 2018 at 17:48:14 -0600, Derek Martin wrote: On Tue, Dec 11, 2018 at 09:08:16PM +0100, Mihai T. Lazarescu wrote: > >If a reply is sent to a message that has destination fields, it > >is often desirable to send a copy of the reply to all of the > >recipients of the message, in addition to the author. When > >such a reply is formed, addresses in the "To:" and "Cc:" fields > >of the original message MAY appear in the "Cc:" field of the > >reply, since these are normally secondary recipients of the > >reply. OK, so the author JUST TOLD YOU that 1. Cc: is for secondary recipients, Which is what I always agreed to. and 2. on a reply, the other recipients in the To: and Cc: fields are secondary recipients. "Normally" does not mean "always". It follows logically that therefore, you SHOULD (in both the English sense and the RFC sense) put the other recipients in the Cc: line. This is basic logic. Not in RFC 2822 (or RFC 5322, see below) authors' logic. Even though the RFC authors consider "normally" (not always) the other recipients as secondary, even in that case they merely concede (as in "MAY", truly optional in RFC lingo) the MUA the derogation from the implicit keep-them-where-they-were rule. As I said, mutt provides an RFC derogation as the only available option. I also said that this is perfectly acceptable from a project that is free as in beer and as in change-it-yourself. But it's not because it's logic to behave this way. But given the author's reasoning, the choice of "MAY" is again logically inconsistent. By choosing "MAY" it's not *technically* a recommendation, but in name only, since it just told you that exactly that is how the fields are meant to be used. Basically, "MAY" here is an unfortunate mistake--But the RFC contains more words than just "MAY" or "SHOULD", and you mustn't pay attention only to that, ignoring everything else it says. The context matters, and the rest of the context is clearly a recommendation for that behavior. See that these so-easily-dismissed "mistakes" have been preserved in later incarnations of the RFC 2822, e.g., RFC 5322 https://tools.ietf.org/html/rfc5322#page-23 Best, Mihai
Re: [Mutt] Re: Group reply To-vs-Cc recipients
On Thursday, December 13, 2018 at 17:56:51 -0600, Derek Martin wrote: The majority of the community said nothing at all, which suggests (as I suggested) that most people don't actually give a $#@! about this, as well they shouldn't. I'll note that in response to Kevin's query, two people (Ariis and Christiansen) said preserving the To: line was sensible, and three people (Zimmerman, Yardley, and myself) said it seems pointless. There were no other opinions provided. For some posters here I probably don't fit in the "people" category, since I made clear that both behaviours make very much sense and the user, not MUA, should decide which and where to use. That being said, it's obvious that a +1 does not change meaningfully any stats or decisions. Even more, considering mutt design objectives and project evolution, IMO this whole discussion was and is pointless after the first few fact-finding messages, for two major reasons. First reason, by design mutt has little appeal where the To:/Cc: distinction is likely to matter, i.e., organizations with layered structures. That's because such structures: 1. tend to have a non-mutt IT-supported (or even -enforced) MUA; 2. tend to exchange messages with HTML formatting and/or embedded images, for which mutt, by definition, does not excel. Instead, where the organizational layers are blurred or absent, people tend to discard also the distinctions To:/Cc: and even prevalently use unadorned text too communicate. Second reason, mutt project seems to be very conservative. Hence, if something is not proven to be clearly broken (the code or the reasoning behind it), then it is very unlikely to "outweigh the risks" of most potential changes. That reminds me of TeX: http://www.tug.org/tetex/html/texfaq/faq_1.html#QU13 which I very much appreciate, too (the program, not decision). Unlike TeX, mutt has much limited extension support, but is forked with lots of additions. For those interested, the original To:/Cc: distribution can be semi-automatically preserved: copy-paste the To:/Cc: fields of the incoming message from viewer in place of the whole Cc: field and its list in the editor (I assume edit_headers=yes). The resulting two To: fields are automatically merged when quitting the editor. Cheers, Mihai
Re: [Mutt] Re: Group reply To-vs-Cc recipients
On Wed, Dec 12, 2018 at 01:18:04PM +1100, Erik Christiansen wrote: > On 11.12.18 17:52, Derek Martin wrote: > > On Tue, Dec 11, 2018 at 10:37:02PM +, Nuno Silva wrote: > > > > Yes, I did not think I needed to say this explicity, but it also > > > > explains why: Because that usage is the one that corresponds to the > > > > stated purpose of those fields. As such it is the obvious, and should > > > > be preferred, way to use them on replies. Using the fields the way > > > > they are intended to be used, to me, adheres to the principle of least > > > > surprise. > > > > > > Can't what is the least surprising to you be more surprising to somebody > > > else? > > > > In general? Of course. But not in this particular context, no. The > > RFC is the spec, and being logically consistent with the spec is the > > only "least surprising" that matters. > > May I humbly suggest that what matters most is what Kevin thinks, as > he's the one with his sleeves rolled up. You may suggest whatever you like, humbly or not. But FWIW Kevin isn't the only one with his sleeves rolled up--there are other maintainers, and beyond that there are other contributors, myself included, albeit infrequently. But the position I'm advocating requires no sleeves to be rolled up--no action whatsoever, so I'm not sure that's relevant. Though, as the primary maintainer, as I've already said, Kevin certainly may do whatever he chooses. My role here, as someone who's been around for a very long time, usually is to remind people both that certain choices were made intentionally and with good reason, and to weigh potential changes and their inherent risks against the actual benefit they will provide. I'm doing both of those things in this thread. As you hint, the decision ultimately is Kevin's, and I'm perfectly happy with that. > Then the thoughts of the majority of the community bear > consideration, especially when based on reason. The majority of the community said nothing at all, which suggests (as I suggested) that most people don't actually give a $#@! about this, as well they shouldn't. I'll note that in response to Kevin's query, two people (Ariis and Christiansen) said preserving the To: line was sensible, and three people (Zimmerman, Yardley, and myself) said it seems pointless. There were no other opinions provided. > Last and least come a sole opinion based on taking an RFC as > evidence, then rewriting it when it fails to support an entrenched > inflexible view. Fortunately no such thing happened. No one rewrote the RFC and it explicitly supports the entrenched view, even if half-heartedly in deference to existing mailers that do it differently. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpVikiyEKWXp.pgp Description: PGP signature
Re: [Mutt] Re: Group reply To-vs-Cc recipients
On Tue, Dec 11, 2018 at 06:41:17PM -0800, Kevin J. McCarthy wrote: > On Tue, Dec 11, 2018 at 06:23:11PM -0600, Derek Martin wrote: > >On Tue, Dec 11, 2018 at 09:51:08AM -0800, Kevin J. McCarthy wrote: > >>But the "reason" supplied by the RFC, which I snipped to emphasize, > >>is a bit weak. > > > >I'm not sure why you think that. You, just now, responded to > >something I said. > > I responded to your message, but I replied to mutt-users. That's > the reason for the function, because the primary > recipient was and continues to be the mailing list. You used Mutt's list-reply feature, which still most mailers don't have. As for the list being the primary recipient, a demonstration to the contrary: Imagine you're standing in a group of people, and someone says something to the group. If you respond to what that person says, do you face that person? I promise you, unless you're neuro-atypical, you most likely do, because it is that person you are primarily addressing; and since it is, it is natural to address them directly. even if it is a group conversation. It's no different if you're participating in a mailing list, except that instead of face-to-face, the conversation is electronic, and your circle of friends doesn't have a Cc: line. The whole reason to have a mailing list: One person asks a question or posts some info, responses are specifically for them, but may be of interest to others. They (the list members) are being kept in the loop. It's automatic Cc:. It's a clever hack to prevent you from having to manually manage the recipient list each time you want to message a group of people which may (or may not) be interested in what you're messaging about. Mutt evolved functionality to deal with this, and a small handful of other mailers copied it. A clever hack on top of a clever hack. Even now, most major mailers don't give you that option--you'd need to use group reply, which would still put the sender to whom you're replying in the To: line, and put the list address in the Cc: line. > If you convert the mailing list concept to a group of "To" > recipients instead, the same logic can apply. A sends an email to > B,C,D as a group conversation, "Where should we have lunch today". > B may respond to A's email, but her desire is to reply equally to > all the other primary (to) recipients. Her group-reply ought to put > A,C,D in the To field. This continues the indication that it's a > group conversation whose primary recipients still include C and D. I think you have that backward--it's the mailing list that has been converted from the traditional method of addressing recipients, as an exceptional case. But sans any list-reply function, replies instantly revert to traditional addressing on all mailers, including those which preserve the To: line. > I believe this pattern of conversation is more common now-a-days, > and that it deserves support in the MUA. It was no less common in the early days of e-mail, and I would imagine it was actually a higher percentage of messages that were used this way, since Internet mail was mostly used by the folks who were creating the Internet, to discuss how to create the Internet... This is not new. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpNBkBsybyHA.pgp Description: PGP signature
Re: [Mutt] Re: [Mutt] Re: Group reply To-vs-Cc recipients
On Tuesday, December 11, 2018 at 18:23:11 -0600, Derek Martin wrote: On Tue, Dec 11, 2018 at 09:51:08AM -0800, Kevin J. McCarthy wrote: > On Mon, Dec 10, 2018 at 05:29:01PM -0600, Derek Martin wrote: > > [...]since these are normally secondary recipients of the reply. > > > >It recomments Mutt's current behavior, for precisely the reasons I > >gave in support of it. > > Okay, that's a good argument for keeping the default behavior as-is. > > But the "reason" supplied by the RFC, which I snipped to emphasize, > is a bit weak. I'm not sure why you think that. You, just now, responded to something I said. Without the thing I said you have no purpose in replying to the message. Therefore principally, inherently, it is me that you are responding to... no one else said the thing you're responding to, only me. I am the only principle recipient of your message. Everyone else who is a recipient, inherently, you are just keeping in the loop, because they may be interested in your follow-up to my message. That's exactly the stated purpose of the Cc: line. That is a fact, and it's a fact your mailer can easily deal with. Both behaviours are useful, for distinct use cases. An example: 1. Incoming: manager-to-team members, with team members in To: + some recipients from aux services in Cc:. Replies from team members very likely should have only the manager in To: and the rest in Cc:. 2. Incoming: manager-to-managers all at same level and all in To: + some aux recipients in Cc: (e.g., secretaries) Replies from other managers should preserve the incoming To:/Cc: distribution. Technically, To: and Cc: deliver the message the same way. So the RFC could have discarded Cc: altogether. However, Cc: is there exactly because of the carbon-copy era distinction between primary and secondary recipients, which matters in some use cases. If and when the Cc:/To: distinction matters and how the recipients should be distributed between these fields is only environment- and user-specific. The RFC or other static rules cannot determine it universally. That's why the RFC and other MUAs allow both behaviours. Mihai
Re: [Mutt] Re: Group reply To-vs-Cc recipients
On Tue, Dec 11, 2018 at 06:41:17PM -0800, Kevin J. McCarthy wrote: > If you convert the mailing list concept to a group of "To" recipients > instead, the same logic can apply. A sends an email to B,C,D as a group > conversation, "Where should we have lunch today". B may respond to A's > email, but her desire is to reply equally to all the other primary (to) > recipients. Her group-reply ought to put A,C,D in the To field. This > continues the indication that it's a group conversation whose primary > recipients still include C and D. > > I believe this pattern of conversation is more common now-a-days, and that > it deserves support in the MUA. I _think_ I understand what's being asked / suggested here. To me, it seems mostly cosmetic (and adjustable if you're willing to move them around in your editor). I guess I kind of have to agree with the folks who think that this doesn't really need to be configurable, and in fact, making it configurable might cause more confusion than it solves? w
Re: [Mutt] Re: Group reply To-vs-Cc recipients
On Tue, Dec 11, 2018 at 06:23:11PM -0600, Derek Martin wrote: On Tue, Dec 11, 2018 at 09:51:08AM -0800, Kevin J. McCarthy wrote: But the "reason" supplied by the RFC, which I snipped to emphasize, is a bit weak. I'm not sure why you think that. You, just now, responded to something I said. I responded to your message, but I replied to mutt-users. That's the reason for the function, because the primary recipient was and continues to be the mailing list. If you convert the mailing list concept to a group of "To" recipients instead, the same logic can apply. A sends an email to B,C,D as a group conversation, "Where should we have lunch today". B may respond to A's email, but her desire is to reply equally to all the other primary (to) recipients. Her group-reply ought to put A,C,D in the To field. This continues the indication that it's a group conversation whose primary recipients still include C and D. I believe this pattern of conversation is more common now-a-days, and that it deserves support in the MUA. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [Mutt] Re: Group reply To-vs-Cc recipients
On 11.12.18 17:52, Derek Martin wrote: > On Tue, Dec 11, 2018 at 10:37:02PM +, Nuno Silva wrote: > > > Yes, I did not think I needed to say this explicity, but it also > > > explains why: Because that usage is the one that corresponds to the > > > stated purpose of those fields. As such it is the obvious, and should > > > be preferred, way to use them on replies. Using the fields the way > > > they are intended to be used, to me, adheres to the principle of least > > > surprise. > > > > Can't what is the least surprising to you be more surprising to somebody > > else? > > In general? Of course. But not in this particular context, no. The > RFC is the spec, and being logically consistent with the spec is the > only "least surprising" that matters. May I humbly suggest that what matters most is what Kevin thinks, as he's the one with his sleeves rolled up. Then the thoughts of the majority of the community bear consideration, especially when based on reason. Last and least come a sole opinion based on taking an RFC as evidence, then rewriting it when it fails to support an entrenched inflexible view. But full points for doggedness. ;-) Erik
Re: [Mutt] Re: Group reply To-vs-Cc recipients
On Tue, Dec 11, 2018 at 09:51:08AM -0800, Kevin J. McCarthy wrote: > On Mon, Dec 10, 2018 at 05:29:01PM -0600, Derek Martin wrote: > > [...]since these are normally secondary recipients of the reply. > > > >It recomments Mutt's current behavior, for precisely the reasons I > >gave in support of it. > > Okay, that's a good argument for keeping the default behavior as-is. > > But the "reason" supplied by the RFC, which I snipped to emphasize, > is a bit weak. I'm not sure why you think that. You, just now, responded to something I said. Without the thing I said you have no purpose in replying to the message. Therefore principally, inherently, it is me that you are responding to... no one else said the thing you're responding to, only me. I am the only principle recipient of your message. Everyone else who is a recipient, inherently, you are just keeping in the loop, because they may be interested in your follow-up to my message. That's exactly the stated purpose of the Cc: line. That is a fact, and it's a fact your mailer can easily deal with. You can concoct all sorts of other reasons to put additional people on the To: line. But they have nothing to do with who the principle recipient of the message is, and as such they have nothing to do with the defined purpose of the To: line. [It should be noted that at this point I'm arguing purely for the sake of the argument itself, for the satisfaction of principle and logic, and no other reason. I object to adding any code to Mutt to allow for this purely on the basis of pragmatism: I mostly think people who care about this are being silly and it's not worth even a line of code--but if you really want to add it, you should go right ahead and do that. But if you want to argue what is RIGHT, I'll assure you that my positions are nearly always very well researched and thought out, and I'll defend them--without malice--to the death. Right up until someone actually proves me wrong. =8^)] -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpboYfeuOAAI.pgp Description: PGP signature
Re: [Mutt] Re: Group reply To-vs-Cc recipients
On Tue, Dec 11, 2018 at 10:37:02PM +, Nuno Silva wrote: > > Yes, I did not think I needed to say this explicity, but it also > > explains why: Because that usage is the one that corresponds to the > > stated purpose of those fields. As such it is the obvious, and should > > be preferred, way to use them on replies. Using the fields the way > > they are intended to be used, to me, adheres to the principle of least > > surprise. > > Can't what is the least surprising to you be more surprising to somebody > else? In general? Of course. But not in this particular context, no. The RFC is the spec, and being logically consistent with the spec is the only "least surprising" that matters. [There is of course the case where the spec is logically inconsistent with itself. That's another matter.] -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpgaNZ8kt94D.pgp Description: PGP signature
Re: [Mutt] Re: Group reply To-vs-Cc recipients
On Tue, Dec 11, 2018 at 09:08:16PM +0100, Mihai T. Lazarescu wrote: > > It recomments Mutt's current behavior > > I disagree on "recommends". Actually "may", as modal verb, is used to > express *possibility* or used to ask or give *permission* (or is used > to make a *suggestion* or suggest a *possibility* in a polite way): > https://dictionary.cambridge.org/us/dictionary/english/may Yes, I'm well aware of what the word "may" means, both in English and in RFCs. I've been doing this a very long time. The choice of "MAY" is essentially wrong... [Don't worry, I'll get to it...] > Either way, in the RFC it expresses an option, an acceptable alternate > behavior to the (implicit, because it's obvious) behavior Obvious in the sense that it is the only possible alternative to a group reply... Removing the other recipients would be the other alternative but then it wouldn't be a group reply. It is a recommendation in that it points out the reason to do this is that it matches the stated purpose of the To: and Cc: fields, which it just explained 4 paragraphs ago. Consider: > >When a message is a reply to another message, the mailboxes of the > >authors of the original message (the mailboxes in the "From:" > >field) or mailboxes specified in the "Reply-To:" field (if it > >exists) MAY appear in the "To:" field of the reply since these > >would normally be the primary recipients of the reply. Would you agree that no one disagrees with this? Where else would you put them? Nothing else makes sense here. So why is this "MAY" rather than "SHOULD" or "MUST?" The choice of "MAY" here is, sadly, logically inconsistent. And while it is technically possible for a message to have more than one author, in general there is only ever one From: address and on replies it is always placed on the To: line by every mailer ever. Likewise: > >If a reply is sent to a message that has destination fields, it > >is often desirable to send a copy of the reply to all of the > >recipients of the message, in addition to the author. When > >such a reply is formed, addresses in the "To:" and "Cc:" fields > >of the original message MAY appear in the "Cc:" field of the > >reply, since these are normally secondary recipients of the > >reply. OK, so the author JUST TOLD YOU that 1. Cc: is for secondary recipients, and 2. on a reply, the other recipients in the To: and Cc: fields are secondary recipients. It follows logically that therefore, you SHOULD (in both the English sense and the RFC sense) put the other recipients in the Cc: line. This is basic logic. So again, why is this "MAY" and not "SHOULD" or "MUST?" Mostly, I think, because it's known that some other mailers don't follow this, and the RFC author didn't want to effectively retroactively declare them to be out of spec. But given the author's reasoning, the choice of "MAY" is again logically inconsistent. By choosing "MAY" it's not *technically* a recommendation, but in name only, since it just told you that exactly that is how the fields are meant to be used. Basically, "MAY" here is an unfortunate mistake--But the RFC contains more words than just "MAY" or "SHOULD", and you mustn't pay attention only to that, ignoring everything else it says. The context matters, and the rest of the context is clearly a recommendation for that behavior. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgp3MhkPhz80U.pgp Description: PGP signature
Re: [Mutt] Re: Group reply To-vs-Cc recipients
On 2018-12-11, Derek Martin wrote: > On Tue, Dec 11, 2018 at 08:39:31PM +1100, Erik Christiansen wrote: >> On 10.12.18 17:29, Derek Martin wrote: >> >When a message is a reply to another message, the mailboxes of the >> >authors of the original message (the mailboxes in the "From:" >> >field) or mailboxes specified in the "Reply-To:" field (if it >> >exists) MAY appear in the "To:" field of the reply since these >> >would normally be the primary recipients of the reply. If a reply >> >is sent to a message that has destination fields, it is often >> >desirable to send a copy of the reply to all of the recipients of >> >the message, in addition to the author. When such a reply is >> >formed, addresses in the "To:" and "Cc:" fields of the original >> >message MAY appear in the "Cc:" field of the reply, since these are >> >normally secondary recipients of the reply. >> > >> > It recomments Mutt's current behavior, for precisely the reasons I >> > gave in support of it. The person who opened the ticket stated that >> > the expected behavior is for the recipients in the To: field to be >> > preserved, but the RFC clearly states otherwise. >> >> It clearly states that it "MAY" be otherwise. > > Yes, I did not think I needed to say this explicity, but it also > explains why: Because that usage is the one that corresponds to the > stated purpose of those fields. As such it is the obvious, and should > be preferred, way to use them on replies. Using the fields the way > they are intended to be used, to me, adheres to the principle of least > surprise. Can't what is the least surprising to you be more surprising to somebody else? > It certainly has (clearly) always matched my personal > expectation such that I've never given it a second thought. But I > still say it mostly doesn't, and shouldn't, matter in practical use. > > [I'd obviously prefer the RFC should say "SHOULD" instead of "MAY" but > you get what you get when someone else does it for you.] -- Nuno Silva
Re: [Mutt] Re: Group reply To-vs-Cc recipients
On Tuesday, December 11, 2018 at 21:08:16 +0100, Mihai Lazarescu wrote: On Tue, Dec 11, 2018 at 12:29 AM Derek Martin wrote: > > On Wed, Dec 05, 2018 at 05:31:28PM +1100, Erik Christiansen wrote: > > Thread comment: It's OK to be unaware of the usefulness of RFC features, > > but it does seem odd to pretend that they're not useful just because > > it's only others who need them. > > I'm not entirely sure what you mean by this, but for the sake of > clarity about RFC features, here's what RFC 2822 says on the matter > (3.6.3, paragraph 6): > >When a message is a reply to another message, the mailboxes of the >authors of the original message (the mailboxes in the "From:" >field) or mailboxes specified in the "Reply-To:" field (if it >exists) MAY appear in the "To:" field of the reply since these >would normally be the primary recipients of the reply. If a reply >is sent to a message that has destination fields, it is often >desirable to send a copy of the reply to all of the recipients of >the message, in addition to the author. When such a reply is >formed, addresses in the "To:" and "Cc:" fields of the original >message MAY appear in the "Cc:" field of the reply, since these are >normally secondary recipients of the reply. > > It recomments Mutt's current behavior I disagree on "recommends". Actually "may", as modal verb, is used to express *possibility* or used to ask or give *permission* (or is used to make a *suggestion* or suggest a *possibility* in a polite way): https://dictionary.cambridge.org/us/dictionary/english/may Either way, in the RFC it expresses an option, an acceptable alternate behavior to the (implicit, because it's obvious) behavior, which is to preserve the distinction between Cc: and To:. Distinction which, BTW, the same RFC states beyond doubt (see the relevant quote in my previous message in thread). Seems like I'm talking to myself, :-) but I just learned that RFC 2119 (thanks Francesco for the pointer) https://www.ietf.org/rfc/rfc2119.txt explains "Key words for use in RFCs to Indicate Requirement Levels". Specifically, RFC 2119 says the following about "MAY": «5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item.» So mutt implements as default and mandatory a "truly optional" alternate behavior allowed by RFC 2822. And for sure the said behavior is not the "recommended" one, as implied in this thread. Mihai
Re: [Mutt] Re: Group reply To-vs-Cc recipients
On Tue, Dec 11, 2018 at 12:29 AM Derek Martin wrote: > > On Wed, Dec 05, 2018 at 05:31:28PM +1100, Erik Christiansen wrote: > > Thread comment: It's OK to be unaware of the usefulness of RFC features, > > but it does seem odd to pretend that they're not useful just because > > it's only others who need them. > > I'm not entirely sure what you mean by this, but for the sake of > clarity about RFC features, here's what RFC 2822 says on the matter > (3.6.3, paragraph 6): > >When a message is a reply to another message, the mailboxes of the >authors of the original message (the mailboxes in the "From:" >field) or mailboxes specified in the "Reply-To:" field (if it >exists) MAY appear in the "To:" field of the reply since these >would normally be the primary recipients of the reply. If a reply >is sent to a message that has destination fields, it is often >desirable to send a copy of the reply to all of the recipients of >the message, in addition to the author. When such a reply is >formed, addresses in the "To:" and "Cc:" fields of the original >message MAY appear in the "Cc:" field of the reply, since these are >normally secondary recipients of the reply. > > It recomments Mutt's current behavior I disagree on "recommends". Actually "may", as modal verb, is used to express *possibility* or used to ask or give *permission* (or is used to make a *suggestion* or suggest a *possibility* in a polite way): https://dictionary.cambridge.org/us/dictionary/english/may Either way, in the RFC it expresses an option, an acceptable alternate behavior to the (implicit, because it's obvious) behavior, which is to preserve the distinction between Cc: and To:. Distinction which, BTW, the same RFC states beyond doubt (see the relevant quote in my previous message in thread). So, that "MAY" above just allows the MUA to *optionally* blur the original assignment of recipients between To: and Cc:. Not to enforce a reassignment instead of the normal behaviour. Beyond this, the fact that someone *should* change mutt is a completely different discussion. mutt is free as in "beer" and as in "chage it yourself", and I completely respect that. Mihai P.S. FWIW, Thunderbird changed to preserve original assignment some 5-6 years ago.
Re: [Mutt] Re: Group reply To-vs-Cc recipients
On Mon, Dec 10, 2018 at 05:29:01PM -0600, Derek Martin wrote: I'm not entirely sure what you mean by this, but for the sake of clarity about RFC features, here's what RFC 2822 says on the matter (3.6.3, paragraph 6): [...]since these are normally secondary recipients of the reply. It recomments Mutt's current behavior, for precisely the reasons I gave in support of it. Okay, that's a good argument for keeping the default behavior as-is. But the "reason" supplied by the RFC, which I snipped to emphasize, is a bit weak. Certainly there are situations where the other "To" recipients might be secondary recipients of the reply. However, there are also situations where they should be primary recipients of the reply. In fact thinking over my own personal usage, preserving To recipients would be _my_ more common preference. This is something I would like to have control over, not be subject to an RFC's thought on the situation. Still, Mutt is such a beast to configure as it is, with so many configuration options, by default I lean heavily against adding more options unless it can be shown that there's significant benefit. I'm also not a big fan of adding configuration variables for trivial things. Perhaps in this case a new function is merited. People could rebind 'g' if desired, or bind to a new key to have the choice when replying (e.g. 'G'). Just to get a good bikeshedding going, are there any suggestions? What about ? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [Mutt] Re: Group reply To-vs-Cc recipients
On Tue, Dec 11, 2018 at 08:39:31PM +1100, Erik Christiansen wrote: > On 10.12.18 17:29, Derek Martin wrote: > >When a message is a reply to another message, the mailboxes of the > >authors of the original message (the mailboxes in the "From:" > >field) or mailboxes specified in the "Reply-To:" field (if it > >exists) MAY appear in the "To:" field of the reply since these > >would normally be the primary recipients of the reply. If a reply > >is sent to a message that has destination fields, it is often > >desirable to send a copy of the reply to all of the recipients of > >the message, in addition to the author. When such a reply is > >formed, addresses in the "To:" and "Cc:" fields of the original > >message MAY appear in the "Cc:" field of the reply, since these are > >normally secondary recipients of the reply. > > > > It recomments Mutt's current behavior, for precisely the reasons I > > gave in support of it. The person who opened the ticket stated that > > the expected behavior is for the recipients in the To: field to be > > preserved, but the RFC clearly states otherwise. > > It clearly states that it "MAY" be otherwise. Yes, I did not think I needed to say this explicity, but it also explains why: Because that usage is the one that corresponds to the stated purpose of those fields. As such it is the obvious, and should be preferred, way to use them on replies. Using the fields the way they are intended to be used, to me, adheres to the principle of least surprise. It certainly has (clearly) always matched my personal expectation such that I've never given it a second thought. But I still say it mostly doesn't, and shouldn't, matter in practical use. [I'd obviously prefer the RFC should say "SHOULD" instead of "MAY" but you get what you get when someone else does it for you.] -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpuPUtqXdzcR.pgp Description: PGP signature
Re: [Mutt] Re: Group reply To-vs-Cc recipients
On 10.12.18 17:29, Derek Martin wrote: > On Wed, Dec 05, 2018 at 05:31:28PM +1100, Erik Christiansen wrote: > > Thread comment: It's OK to be unaware of the usefulness of RFC features, > > but it does seem odd to pretend that they're not useful just because > > it's only others who need them. > > I'm not entirely sure what you mean by this, but for the sake of > clarity about RFC features, here's what RFC 2822 says on the matter > (3.6.3, paragraph 6): > >When a message is a reply to another message, the mailboxes of the >authors of the original message (the mailboxes in the "From:" >field) or mailboxes specified in the "Reply-To:" field (if it >exists) MAY appear in the "To:" field of the reply since these >would normally be the primary recipients of the reply. If a reply >is sent to a message that has destination fields, it is often >desirable to send a copy of the reply to all of the recipients of >the message, in addition to the author. When such a reply is >formed, addresses in the "To:" and "Cc:" fields of the original >message MAY appear in the "Cc:" field of the reply, since these are >normally secondary recipients of the reply. > > It recomments Mutt's current behavior, for precisely the reasons I > gave in support of it. The person who opened the ticket stated that > the expected behavior is for the recipients in the To: field to be > preserved, but the RFC clearly states otherwise. It clearly states that it "MAY" be otherwise. There will doubtless be use cases where that is fully acceptable, and cases where it can be tolerated. It does, though, seem a pity to arbitrarily munge the user's recipient preferences, rather than preserve them. It does seem to violate POLA. Erik
Re: [Mutt] Re: Group reply To-vs-Cc recipients
On Wed, Dec 05, 2018 at 05:31:28PM +1100, Erik Christiansen wrote: > Thread comment: It's OK to be unaware of the usefulness of RFC features, > but it does seem odd to pretend that they're not useful just because > it's only others who need them. I'm not entirely sure what you mean by this, but for the sake of clarity about RFC features, here's what RFC 2822 says on the matter (3.6.3, paragraph 6): When a message is a reply to another message, the mailboxes of the authors of the original message (the mailboxes in the "From:" field) or mailboxes specified in the "Reply-To:" field (if it exists) MAY appear in the "To:" field of the reply since these would normally be the primary recipients of the reply. If a reply is sent to a message that has destination fields, it is often desirable to send a copy of the reply to all of the recipients of the message, in addition to the author. When such a reply is formed, addresses in the "To:" and "Cc:" fields of the original message MAY appear in the "Cc:" field of the reply, since these are normally secondary recipients of the reply. It recomments Mutt's current behavior, for precisely the reasons I gave in support of it. The person who opened the ticket stated that the expected behavior is for the recipients in the To: field to be preserved, but the RFC clearly states otherwise. Also FWIW, I've been a member of the Mutt community since about 1996, and this is the first time I remember anyone ever bringing it up. If it's happened before, it certainly has never been a hot issue. 22 years of virtually no one complaining does not exactly scream that it needs attention... Given that, I think the benefit of making this configurable is not worth the risk of introducing a new bug that comes with every change and with every increase in code complexity. That said, in this case I imagine the required change is probably small enough and simple enough that it's not a very interesting consideration either way. Still, Mutt is such a beast to configure as it is, with so many configuration options, by default I lean heavily against adding more options unless it can be shown that there's significant benefit. I think the available information suggest that there is not. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpD1td1r4lq8.pgp Description: PGP signature
Re: [Mutt] Re: Group reply To-vs-Cc recipients
On 05.12.18 00:44, Mihai Lazarescu wrote: > On Thu, Nov 29, 2018 at 04:12:08PM -0800, Kevin J. McCarthy wrote: > > > On Thu, Nov 29, 2018 at 03:41:12PM -0800, Ian Zimmerman wrote: > > > > > I am curious to know in what context "someone" felt it would > > > make a difference. > > > > The ticket number is 98, but I thought mutt-users would be a better > > place to have a discussion. > > > > I can't speak for the reporter, but my understanding was the desire > > to preserve the distinction between primary recipients, towards whom > > the conversation is directly relevant, and others who may be just > > being kept in the loop. > > That's the meaning of To:/Cc: fields according to RFC5322 > https://tools.ietf.org/html/rfc5322#section-3.6.3 > >«The "To:" field contains the address(es) of the primaryrecipient(s) > of the message.» > >«The "Cc:" field (where the "Cc" means "Carbon Copy" inthe sense of > making a copy on a typewriter using carbonpaper) contains the addresses > of others who are to receivethe message, though the content of the > message may not bedirected at them.» Yes, the separate fields replicate paper based systems with a long history of established use. Any lack of awareness of the clear distinction between the fields merely reveals a lack of experience of situations in which it is important, such as in many a corporate culture. Where the recipients are all in-house but from differing departments or teams, then leaders will be in the To: list, and significant lieutenants (and departments passively involved) in the Cc: list. The latter to review the content, but reply may need to be from a leader to be acceptable. I have been involved in cross-corporate exchanges (in between physical meetings) where corporate relationships, contractual implications, and domain of responsibility are important considerations. And being on the Cc: list implied a responsibility to read and consult - not reply unilaterally. Thread comment: It's OK to be unaware of the usefulness of RFC features, but it does seem odd to pretend that they're not useful just because it's only others who need them. Erik
Re: [Mutt] Re: Group reply To-vs-Cc recipients
On Thu, Nov 29, 2018 at 04:12:08PM -0800, Kevin J. McCarthy wrote: On Thu, Nov 29, 2018 at 03:41:12PM -0800, Ian Zimmerman wrote: > I am curious to know in what context "someone" felt it would > make a difference. The ticket number is 98, but I thought mutt-users would be a better place to have a discussion. I can't speak for the reporter, but my understanding was the desire to preserve the distinction between primary recipients, towards whom the conversation is directly relevant, and others who may be just being kept in the loop. That's the meaning of To:/Cc: fields according to RFC5322 https://tools.ietf.org/html/rfc5322#section-3.6.3 «The "To:" field contains the address(es) of the primary recipient(s) of the message.» «The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of making a copy on a typewriter using carbon paper) contains the addresses of others who are to receive the message, though the content of the message may not be directed at them.» A distinction makes sense, otherwise Cc: would be an exact duplication of To:, hence redundant. The same RFC requires that all original recipients should be included in reply (so at least Cc-ed). But given the RFC distinctive meaning for the original To:/Cc:, it make sense to preserve it in reply-to-all. Or dump the Cc: field altogether and always list recipients in To:. :-) Mihai
Re: Group reply To-vs-Cc recipients
On Thu, Nov 29, 2018 at 04:12:08PM -0800, Kevin J. McCarthy wrote: > On Thu, Nov 29, 2018 at 03:41:12PM -0800, Ian Zimmerman wrote: > >I am curious to know in what context "someone" felt it would make > >a difference. > > The ticket number is 98, but I thought mutt-users would be a better > place to have a discussion. > > I can't speak for the reporter, but my understanding was the desire > to preserve the distinction between primary recipients, towards whom > the conversation is directly relevant, and others who may be just > being kept in the loop. A reply is inherently a response to something someone else said, and as such that person is the only specific recipient, and all other recipients are receiving a carbon copy. I believe Mutt's current behavior is correct in the spirit of how these fields are meant to be used. That said, FWIW, I almost never even look at the mail envelope, unless I'm writing a "sensitive" response, so that I can make a decision as to whether or not the recipient list needs to be pruned. I mostly think the notion that "If I'm only on the CC list I can ignore this" is idiotic... Like most people, anything superfluous that I can ignore, I certainly will; so putting me on the CC list, if that is your intent, is a waste of your time. But I think recipients should generally know whether they can or should ignore a thread from its context and their relationship to the issue. Rely on the message envelope to decide that for you at your own peril. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpDM4jiEhciv.pgp Description: PGP signature
Re: Group reply To-vs-Cc recipients
On 30.11.18 01:34, Francesco Ariis wrote: > On Thu, Nov 29, 2018 at 03:41:12PM -0800, Ian Zimmerman wrote: > > I am curious to know in what context "someone" felt it would make a > > difference. > > I suspect work related setting. Cc: is indeed "being kept in the loop" > while To: is "addressed specifically". > > I have never noticed mutt behaviour, but the above seems a sensible > behaviour. +1 Spontaneous increase of entropy isn't usually user-friendly. If I hadn't retired ten years ago, it'd make more of a difference here, but letting the CC list know they can leave the message on the back burner is fractionally as important as signalling the TO recipients that they can't. Erik
Re: Group reply To-vs-Cc recipients
On Thu, Nov 29, 2018 at 03:41:12PM -0800, Ian Zimmerman wrote: > I am curious to know in what context "someone" felt it would make a > difference. I suspect work related setting. Cc: is indeed "being kept in the loop" while To: is "addressed specifically". I have never noticed mutt behaviour, but the above seems a sensible behaviour.
Re: Group reply To-vs-Cc recipients
On Thu, Nov 29, 2018 at 03:41:12PM -0800, Ian Zimmerman wrote: I am curious to know in what context "someone" felt it would make a difference. The ticket number is 98, but I thought mutt-users would be a better place to have a discussion. I can't speak for the reporter, but my understanding was the desire to preserve the distinction between primary recipients, towards whom the conversation is directly relevant, and others who may be just being kept in the loop. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Group reply To-vs-Cc recipients
On 2018-11-29 13:26, Kevin J. McCarthy wrote: > Someone opened a ticket asking about Mutt's group reply behavior. > > By default (i.e. ignoring Mail-Followup-To, $reply_self, $reply_to, > etc.), the To recipients are added to the Cc list of the reply. The > ticket reporter thought it made more sense for To recipients to remain > in the To list of the reply. Apparently, Thunderbird does this, but > not sure about other clients. > > Have no fear, I have no intention of changing default behavior. But > I'm curious about opinions on this list. Is this "established proper" > behavior, or is this something reasonable to have an option for? I am curious to know in what context "someone" felt it would make a difference. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
Group reply To-vs-Cc recipients
Someone opened a ticket asking about Mutt's group reply behavior. By default (i.e. ignoring Mail-Followup-To, $reply_self, $reply_to, etc.), the To recipients are added to the Cc list of the reply. The ticket reporter thought it made more sense for To recipients to remain in the To list of the reply. Apparently, Thunderbird does this, but not sure about other clients. Have no fear, I have no intention of changing default behavior. But I'm curious about opinions on this list. Is this "established proper" behavior, or is this something reasonable to have an option for? Thank you! -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
group-reply Bcc
Hi I have asked this some time ago [1] but I may have not been specific enough. I'll give it another shot. I have write_bcc=yes set and therefore a copy of a sent mail will have the Bcc header set and filled with recipients. I'd like to to that mail and wonder how to make the reply mail get the Bcc header filled. doesn't do that. Is there any setting that I may have overlooked in the manual? If not, I should be able to write a macro which extracts the Bcc from the mail when replying. I'm thinking along the lines of and "formail -x Bcc" for extracting the header and my_hdr for setting it, but I have kind of a hard time coming up with a working macro, so if someone has some clever hints, that'll be great. Thanks! best, Steve [1] https://marc.info/?l=mutt-users&m=144239490327363&w=2
Re: what is the command of group-reply
On Fri, May 05, 2017 at 09:13:36PM -0700, Will Yardley wrote: > On Sat, May 06, 2017 at 07:49:49PM +0800, Yubin Ruan wrote: > > > > Can anyone tell me what is the command of group-reply? > > Whenever replying a email with multiple `Cc' and recipents, I usually want > > to > > reply to all of them. This can be achieved by "Reply-to-all" in some mail > > clients. In Mutt, that is a single `g' in the pager. > > > > But as I have binded 'g' to another command, I have to bind the group-reply > > command to another key. How can I achieve that? > > You can bind it to whatever key you want if you're not going to use the > default binding. > > In hindsight, I wish I had rebound less stuff and just learned to use > Mutt's bindings when I first started. But as someone who had used Pine > for a while, I bound 'g' to cycle between mailboxes, and I use 'R' for > group reply. You could use capital G or whatever other binding is > convenient for you. > > e.g., > bind pager R group-reply > bind index R group-reply group-reply is exactly what I want. Thanks! Regards, Yubin
Re: what is the command of group-reply
On Sat, May 06, 2017 at 07:49:49PM +0800, Yubin Ruan wrote: > > Can anyone tell me what is the command of group-reply? > Whenever replying a email with multiple `Cc' and recipents, I usually want to > reply to all of them. This can be achieved by "Reply-to-all" in some mail > clients. In Mutt, that is a single `g' in the pager. > > But as I have binded 'g' to another command, I have to bind the group-reply > command to another key. How can I achieve that? You can bind it to whatever key you want if you're not going to use the default binding. In hindsight, I wish I had rebound less stuff and just learned to use Mutt's bindings when I first started. But as someone who had used Pine for a while, I bound 'g' to cycle between mailboxes, and I use 'R' for group reply. You could use capital G or whatever other binding is convenient for you. e.g., bind pager R group-reply bind index R group-reply w
what is the command of group-reply
Hi, Can anyone tell me what is the command of group-reply? Whenever replying a email with multiple `Cc' and recipents, I usually want to reply to all of them. This can be achieved by "Reply-to-all" in some mail clients. In Mutt, that is a single `g' in the pager. But as I have binded 'g' to another command, I have to bind the group-reply command to another key. How can I achieve that? Thanks, Yubin
Re: group reply [SOLVED] now alternates
On 27-09-2016, at 14h 45'42", Jon LaBadie wrote about "Re: group reply [SOLVED] now alternates" > On Tue, Sep 27, 2016 at 02:20:14PM +0200, Ionel Mugurel Ciobîcă wrote: > > > > Another shot in the dark: Is there a chance that the original author > > is one of your alternates and you set up metoo variable to no? > > > Pay the man!!! That's it. > My alternates definition is a regex that matched the author. I am glad I could help. > A couple of queries about alternates. > > I simply have: > > alternates ".*@labadie\.us" ".*@jgcomp\.org" ".*@jgcomp\.com" > > I can definitely make it more specific, but with many aliases > I may need a long list. Is a large alternates list common? Mine is fairly long... > > The .muttrc comments show this as "set alternates=" but my > form obviously works. Do both forms work? Is there a difference? I also have it as "alternates address1 address2 etc.", so yes both form works. This one may be the older version and the one with set is the newer version :-) In my case the list is more specific. I even protect the dot with a backslash not to match something else, so an address as u...@domain.net is listed in my alternates as ^user@domain\.net$. This is to avoid other addresses to match, such as new-u...@domain.net, etc. But you can also use unalternates as Nathan said. > Can multiple "alternates" lines appear in .muttrc? I would guess that the last one will be honored. Ionel
Re: group reply [SOLVED] now alternates
On Tue, Sep 27, 2016 at 14:45:42 -0400, Jon LaBadie wrote: > My alternates definition is a regex that matched the author. > > A couple of queries about alternates. > > I simply have: > > alternates ".*@labadie\.us" ".*@jgcomp\.org" ".*@jgcomp\.com" > > I can definitely make it more specific, but with many aliases > I may need a long list. Is a large alternates list common? If the list of exceptions-to-the-rule is short, you can use "unalternates" to list specific patterns that shouldn't be treated as an alternate, while continuing to use the broad wildcard pattern on the alternates line to match everything else Nathan
Re: group reply [SOLVED] now alternates
On Tue, Sep 27, 2016 at 02:20:14PM +0200, Ionel Mugurel Ciobîcă wrote: > On 26-09-2016, at 17h 20'26", Jon LaBadie wrote about "Re: group reply" > > Did a reply to everyone in the "To:" header but the > > original author in the "From:" header was not included. > > > > Another shot in the dark: Is there a chance that the original author > is one of your alternates and you set up metoo variable to no? > Pay the man!!! That's it. My alternates definition is a regex that matched the author. A couple of queries about alternates. I simply have: alternates ".*@labadie\.us" ".*@jgcomp\.org" ".*@jgcomp\.com" I can definitely make it more specific, but with many aliases I may need a long list. Is a large alternates list common? The .muttrc comments show this as "set alternates=" but my form obviously works. Do both forms work? Is there a difference? Can multiple "alternates" lines appear in .muttrc? Why am I asking something that I can easily try? Jon -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: group reply
On 26-09-2016, at 17h 20'26", Jon LaBadie wrote about "Re: group reply" > Did a reply to everyone in the "To:" header but the > original author in the "From:" header was not included. > Another shot in the dark: Is there a chance that the original author is one of your alternates and you set up metoo variable to no? Kind regards, Ionel
Re: group reply
On Mon, Sep 26, 2016 at 05:30:47PM -0400, Nathan Stratton Treadway wrote: > On Mon, Sep 26, 2016 at 14:38:00 -0400, Jon LaBadie wrote: > > On Mon, Sep 26, 2016 at 02:02:24PM -0400, Guy Gold wrote: > > > A shot in the dark..(and eventhough you inspected the headers_ :) > > > > > > Nothing odd set into the "reply to:" header on the original > > > message ? > > > > None present in original message. > > Mail-Followup-To: header? > Not that one either. Here is the entire header section minus the Received: lines, the msg id shortened, and email addresses slightly munged. From gu...@jgcomp.com Sun Sep 25 12:35:02 2016 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on cyber.jgcomp.com X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=4.0 tests=BAYES_20,DOS_OUTLOOK_TO_MX, FSL_HELO_NON_FQDN_1,HTML_MESSAGE,MIMEOLE_DIRECT_TO_MX autolearn=no autolearn_force=no version=3.4.1 X-Original-To: j...@jgcomp.com Delivered-To: j...@jgcomp.com X-Virus-Scanned: amavisd-new at jgcomp.com Return-Receipt-To: "Gundula U. LaBadie, PhD" From: "Gundula" To: "'George'" <...@comcast.net>, "'Gertrude'" <...@gmail.com>, "'Christy'" <...@gmail.com>, "'Erika'" <...@yahoo.com>, "'Zeb'" <...@gmail.com>, "'Mike'" <...@gmail.com> Cc: "'Jon LaBadie'" Subject: Reston Home Tour - October 15 Date: Sun, 25 Sep 2016 12:31:04 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_NextPart_000_040F_01D21728.AEAB2C70" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AdIXSjV3gYlyf9HKTWG9qvIIVg5MZw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Status: RO X-Status: A Content-Length: 4694 Lines: 120 I noted the strange use of both single and double quotes in the To: header but not the From: header. Neither eliminating the single quotes or adding them to the From: line had any effect. One other note, this message had both text and html versions of the message. But that should not affect mutt's handling of replies should it? Jon -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: group reply
On Mon, Sep 26, 2016 at 14:38:00 -0400, Jon LaBadie wrote: > On Mon, Sep 26, 2016 at 02:02:24PM -0400, Guy Gold wrote: > > A shot in the dark..(and eventhough you inspected the headers_ :) > > > > Nothing odd set into the "reply to:" header on the original > > message ? > > None present in original message. Mail-Followup-To: header? Nathan
Re: group reply
On Mon, Sep 26, 2016 at 10:21:11PM +0200, Jostein Berntsen wrote: > On 26.09.16,14:38, Jon LaBadie wrote: > > On Mon, Sep 26, 2016 at 02:02:24PM -0400, Guy Gold wrote: > > > A shot in the dark..(and eventhough you inspected the headers_ :) > > > > > > Nothing odd set into the "reply to:" header on the original > > > message ? > > > > None present in original message. > > > > What happens if you do "R" instead? > > Jostein > I presume you meant "r" rather than "R" (recall postponed msg). Well I wasn't expecting that. "r" acted just like "g". Did a reply to everyone in the "To:" header but the original author in the "From:" header was not included. Why do you ask? Jon > > > > > > On Sun,Sep 25 07:35:PM, Jon LaBadie wrote: > > > > I don't recall this happening before. I replied to > > > > a message using 'g' and the message author was not > > > > included in the list of recipients of my reply. > > > > > > > > I did not notice the omission until the author > > > > mentioned she did not get my reply. But I went > > > > back to the original message and typed 'g' and > > > > she is not in the recipient list. > > > > > > > > Another oddity, I had trouble finding the original > > > > message to run the test. Turns out saving that > > > > message saved it to the first recipients file > > > > rather than the authors file. > > > > > > > > I don't see anything strange in the headers, but ... > > > > > > > > Any clue what might cause this? > > > > > > > > Jon > > > > -- > > > > Jon H. LaBadie j...@jgcomp.com > > > > 11226 South Shore Rd. (703) 787-0688 (H) > > > > Reston, VA 20190 (703) 935-6720 (C) > > > > > > > > > > -- > > > Guy Gold > > > Cambridge, Massachusetts > > > > > End of included message <<< > > > > -- > > Jon H. LaBadie j...@jgcomp.com > > 11226 South Shore Rd. (703) 787-0688 (H) > > Reston, VA 20190 (703) 935-6720 (C) > > >>> End of included message <<< -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: group reply
On 26.09.16,14:38, Jon LaBadie wrote: On Mon, Sep 26, 2016 at 02:02:24PM -0400, Guy Gold wrote: A shot in the dark..(and eventhough you inspected the headers_ :) Nothing odd set into the "reply to:" header on the original message ? None present in original message. What happens if you do "R" instead? Jostein jl On Sun,Sep 25 07:35:PM, Jon LaBadie wrote: > I don't recall this happening before. I replied to > a message using 'g' and the message author was not > included in the list of recipients of my reply. > > I did not notice the omission until the author > mentioned she did not get my reply. But I went > back to the original message and typed 'g' and > she is not in the recipient list. > > Another oddity, I had trouble finding the original > message to run the test. Turns out saving that > message saved it to the first recipients file > rather than the authors file. > > I don't see anything strange in the headers, but ... > > Any clue what might cause this? > > Jon > -- > Jon H. LaBadie j...@jgcomp.com > 11226 South Shore Rd. (703) 787-0688 (H) > Reston, VA 20190 (703) 935-6720 (C) > -- Guy Gold Cambridge, Massachusetts End of included message <<< -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: group reply
On Mon, Sep 26, 2016 at 02:02:24PM -0400, Guy Gold wrote: > A shot in the dark..(and eventhough you inspected the headers_ :) > > Nothing odd set into the "reply to:" header on the original > message ? None present in original message. jl > > On Sun,Sep 25 07:35:PM, Jon LaBadie wrote: > > I don't recall this happening before. I replied to > > a message using 'g' and the message author was not > > included in the list of recipients of my reply. > > > > I did not notice the omission until the author > > mentioned she did not get my reply. But I went > > back to the original message and typed 'g' and > > she is not in the recipient list. > > > > Another oddity, I had trouble finding the original > > message to run the test. Turns out saving that > > message saved it to the first recipients file > > rather than the authors file. > > > > I don't see anything strange in the headers, but ... > > > > Any clue what might cause this? > > > > Jon > > -- > > Jon H. LaBadie j...@jgcomp.com > > 11226 South Shore Rd. (703) 787-0688 (H) > > Reston, VA 20190 (703) 935-6720 (C) > > > > -- > Guy Gold > Cambridge, Massachusetts >>> End of included message <<< -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: group reply
A shot in the dark..(and eventhough you inspected the headers_ :) Nothing odd set into the "reply to:" header on the original message ? On Sun,Sep 25 07:35:PM, Jon LaBadie wrote: > I don't recall this happening before. I replied to > a message using 'g' and the message author was not > included in the list of recipients of my reply. > > I did not notice the omission until the author > mentioned she did not get my reply. But I went > back to the original message and typed 'g' and > she is not in the recipient list. > > Another oddity, I had trouble finding the original > message to run the test. Turns out saving that > message saved it to the first recipients file > rather than the authors file. > > I don't see anything strange in the headers, but ... > > Any clue what might cause this? > > Jon > -- > Jon H. LaBadie j...@jgcomp.com > 11226 South Shore Rd. (703) 787-0688 (H) > Reston, VA 20190 (703) 935-6720 (C) > -- Guy Gold Cambridge, Massachusetts
group reply
I don't recall this happening before. I replied to a message using 'g' and the message author was not included in the list of recipients of my reply. I did not notice the omission until the author mentioned she did not get my reply. But I went back to the original message and typed 'g' and she is not in the recipient list. Another oddity, I had trouble finding the original message to run the test. Turns out saving that message saved it to the first recipients file rather than the authors file. I don't see anything strange in the headers, but ... Any clue what might cause this? Jon -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: Send mail to an 'address group'
El Tuesday, 13 de September del 2016 a les 23:30, Erik Christiansen va
escriure:
On 13.09.16 12:08, mimosinnet wrote:
When the members of the group CoordsM change, I have to change the
alias.
Is there a way I can use the definition of the "Address Groups"
(http://www.mutt.org/doc/manual/#addrgroup) to be able to define an
alias (http://www.mutt.org/doc/manual/#alias).
I've not tried to make the group and group_alias names the same, to
ease
the task of e.g. an awk script synthesising the group's alias from the
"alias -group" lines. Leaving it as is, I figure one would need a
linking comment line, e.g.:
# group_alias CoordsMaster CoordsM
placed _before_ the first alias line using either name.
Then a script something like:
Waw! Erik! Thanks a lot!
I have been playing with your idea and written a script in perl6:
https://github.com/mimosinnet/Actius/blob/master/Aliases_groups.pl6
This script:
- Creates the same alias that has been defined by the -group option
- It can be used with multiple definitions of -group
Cheers!
---
(P.S.: I am sorry I have hijack the thread ಥ_ಥ )
#!/bin/bash
gawk '
$2 ~ /group_alias/ { alias_groups[$4] = $3 ; group_aliases[$3] = $4 }
$1 ~ /alias/ && $2 ~ /-group/ {
if ($3 in alias_groups)
{ i = alias_groups[$3]
alias_lists[i] = alias_lists[i] ", " $4
}
}
$1 ~ /alias/ && $2 !~ /-group/ {
if ($2 in group_aliases) printf("%s %s %s\n",$1,$2,substr(alias_lists[$2],3))
else print
next
}
{ print } # Print all lines not rewritten.
' ~/.muttrc > /tmp/muttrc
does the trick for me. To use:
$ muttalgrp # Or whatever it should be called.
$ diff ~/.muttrc /tmp/muttrc # Check shows one line updated, here.
$ mv /tmp/muttrc ~/.muttrc # You could back-up the old one first.
Caveats:
1) This was quickly cobbled together to see what it'd take to do the job.
It has only been lightly tested.
2) It catches the required alias lines, and those without -group, but
not present in group_aliases, but there might be some .muttrc idiom
which isn't covered.
3) It ought to work for multiple groups in the .muttrc, but it's only been
tested on one.
4) It doesn't suit my use-case, where not every member of the group
is allowed to be in the group alias, as the group included in
replies
is a subset of the receipt group. That could perhaps be fiddled with
either multiple groups or group aliases.
--
Mimosinnet
Linux User: #463211
41:25:16N (41.421110) 2:11:28E (2.188333)
Re: Send mail to an 'address group'
On 13.09.16 12:08, mimosinnet wrote:
> When the members of the group CoordsM change, I have to change the
> alias.
>
> Is there a way I can use the definition of the "Address Groups"
> (http://www.mutt.org/doc/manual/#addrgroup) to be able to define an
> alias (http://www.mutt.org/doc/manual/#alias).
Defining group membership the other way, using the "group" command,
would offer the opportunity to do that, _if_ mutt had a -group_alias
option on the group command, for adding the needed group alias.
But it doesn't, and you'd still be editing in two places, anyway.
I've not tried to make the group and group_alias names the same, to ease
the task of e.g. an awk script synthesising the group's alias from the
"alias -group" lines. Leaving it as is, I figure one would need a
linking comment line, e.g.:
# group_alias CoordsMaster CoordsM
placed _before_ the first alias line using either name.
Then a script something like:
#!/bin/bash
gawk '
$2 ~ /group_alias/ { alias_groups[$4] = $3 ; group_aliases[$3] = $4 }
$1 ~ /alias/ && $2 ~ /-group/ {
if ($3 in alias_groups)
{ i = alias_groups[$3]
alias_lists[i] = alias_lists[i] ", " $4
}
}
$1 ~ /alias/ && $2 !~ /-group/ {
if ($2 in group_aliases) printf("%s %s %s\n",$1,$2,substr(alias_lists[$2],3))
else print
next
}
{ print } # Print all lines not rewritten.
' ~/.muttrc > /tmp/muttrc
does the trick for me. To use:
$ muttalgrp # Or whatever it should be called.
$ diff ~/.muttrc /tmp/muttrc # Check shows one line updated, here.
$ mv /tmp/muttrc ~/.muttrc # You could back-up the old one first.
Caveats:
1) This was quickly cobbled together to see what it'd take to do the job.
It has only been lightly tested.
2) It catches the required alias lines, and those without -group, but
not present in group_aliases, but there might be some .muttrc idiom
which isn't covered.
3) It ought to work for multiple groups in the .muttrc, but it's only been
tested on one.
4) It doesn't suit my use-case, where not every member of the group
is allowed to be in the group alias, as the group included in replies
is a subset of the receipt group. That could perhaps be fiddled with
either multiple groups or group aliases.
Send mail to an 'address group'
I have an alias file with: alias -group CoordsM alias1 Name Surname alias -group CoordsM alias2 Name Surname alias -group CoordsM alias3 Name Surname alias -group CoordsM alias4 Name Surname alias -group CoordsM alias5 Name Surname To send an email to the address group CoordsM, I have to create an alias: alias CoordsMaster alias1,alias2,alias3,alias4,alias5 When the members of the group CoordsM change, I have to change the alias. Is there a way I can use the definition of the "Address Groups" (http://www.mutt.org/doc/manual/#addrgroup) to be able to define an alias (http://www.mutt.org/doc/manual/#alias). Thanks! -- Mimosinnet Linux User: #463211 41:25:16N (41.421110) 2:11:28E (2.188333)
Re: group mailings with blind cc - RTM
On 16.04.16 14:59, Jon LaBadie wrote: > > Next step was to set up a send-hook on the tfccc email addr. > > This would setup "my_hdr Bcc:" to be the list of recipients, > > or later perhaps a mutt group alias for the list. I've done > > similar settings before, but not for the Bcc: header. > > > > This step doesn't work. Either nothing gets added or the > > list gets added to the To: header. ... > So it appears you can't change the recipients from within a send-hook. Nor with a reply-hook or message-hook, AFAICT. > I compose in vi, so I'll just append a group alias to the Bcc line. > I was simply trying to automate that step. A file, e.g. drafts/tfccc, could be a template, including a long Bcc, a default Subject, default body, and any action points open from the last session. (OK, getting carried away here, but I've found that useful for meetings.) With edit_headers set, a ":r drafts/tfccc"in vi/vim will place the whole box and dice more cleanly if invoked in a macro which deletes the default headers first. The greatest risk with that much automation is forgetting to update the meeting date. Another option is an autocommand which defines a key mapping which inserts the Bcc:, but only when editing a mutt tmpfile. (Lets you use the key in other ways outside mutt edits.) Erik
Re: group mailings with blind cc - RTM
On Fri, Apr 15, 2016 at 02:40:27PM -0400, Jon LaBadie wrote: > I'm trying to set up a way to send periodic notices > to a list of people with the restriction that the > recipients email addresses not be generally visible, > thus they would be listed in the Bcc: header. > > My approach is to create an email alias "tf...@jgcomp.com" > and a mutt alias "tfc" to be "Tuesday Fun Club - Community > Center" . This works fine. > > Next step was to set up a send-hook on the tfccc email addr. > This would setup "my_hdr Bcc:" to be the list of recipients, > or later perhaps a mutt group alias for the list. I've done > similar settings before, but not for the Bcc: header. > > This step doesn't work. Either nothing gets added or the > list gets added to the To: header. > > I'm not sure if the approach is bad or something about my > syntax. Any guidance would be appreciated? Well it doesn't solve the problem, but reading the fine manual explains why my approach doesn't work. From section 19: 19. Change Settings Based Upon Message Recipients ... Note ... Also note that my_hdr commands which modify recipient headers, or the message's subject, don't have any effect on the current message when executed from a send-hook. 20. Change Settings Before Formatting a Message So it appears you can't change the recipients from within a send-hook. I compose in vi, so I'll just append a group alias to the Bcc line. I was simply trying to automate that step. Thanks, jl -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: group mailings with blind cc
On Sat, Apr 16, 2016 at 09:30:14AM +1000, Brian Salter-Duke wrote: > On Fri, Apr 15, 2016 at 04:13:47PM -0400, Jon LaBadie wrote: > > On Fri, Apr 15, 2016 at 09:48:26PM +0200, Alarig Le Lay wrote: > > > On Fri Apr 15 14:40:27 2016, Jon LaBadie wrote: > > > > I'm trying to set up a way to send periodic notices > > > > to a list of people with the restriction that the > > > > recipients email addresses not be generally visible, > > > > thus they would be listed in the Bcc: header. > > > > > > Why do you don’t set up a mailing list? That’s their aim. > > Not enough traffic. I wouldn't expect more than > > 1 or 2 messages a year. Like meet times change > > in the summer, revert in fall. > How large is the list. If it is not too large, just make a group alias > in your alias file and send the message putting that alias in the Bcc line. > I do that for about 30 or 40 people. What I've done sometimes is to just write the message in a text file, and put the recipients in another text file, then use mutt (or mailx) to send one at a time; this way the recipient's address only is in the To: line. w
Re: group mailings with blind cc
On Fri, Apr 15, 2016 at 04:13:47PM -0400, Jon LaBadie wrote: > On Fri, Apr 15, 2016 at 09:48:26PM +0200, Alarig Le Lay wrote: > > On Fri Apr 15 14:40:27 2016, Jon LaBadie wrote: > > > I'm trying to set up a way to send periodic notices > > > to a list of people with the restriction that the > > > recipients email addresses not be generally visible, > > > thus they would be listed in the Bcc: header. > > > > [snip] > > > > Hi, > > > > Why do you don’t set up a mailing list? That’s their aim. > > If you do so, you don’t have to care about Bcc header, just send a mail > > to tf...@jgcomp.com. > > > > Not enough traffic. I wouldn't expect more than > 1 or 2 messages a year. Like meet times change > in the summer, revert in fall. > > jl > -- > Jon H. LaBadie j...@jgcomp.com > 11226 South Shore Rd. (703) 787-0688 (H) > Reston, VA 20190 (703) 935-6720 (C) How large is the list. If it is not too large, just make a group alias in your alias file and send the message putting that alias in the Bcc line. I do that for about 30 or 40 people. Brian. -- I really didn't foresee the Internet. But then, neither did the computer industry. Not that that tells us very much, of course - the computer industry didn't even foresee that the century was going to end. -- Douglas Adams Brian Salter-Duke (Brian Duke) Email: brian.james.duke(AT)gmail(DOT)com
Re: group mailings with blind cc
On Fri, Apr 15, 2016 at 09:48:26PM +0200, Alarig Le Lay wrote: > On Fri Apr 15 14:40:27 2016, Jon LaBadie wrote: > > I'm trying to set up a way to send periodic notices > > to a list of people with the restriction that the > > recipients email addresses not be generally visible, > > thus they would be listed in the Bcc: header. > > [snip] > > Hi, > > Why do you don’t set up a mailing list? That’s their aim. > If you do so, you don’t have to care about Bcc header, just send a mail > to tf...@jgcomp.com. > Not enough traffic. I wouldn't expect more than 1 or 2 messages a year. Like meet times change in the summer, revert in fall. jl -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: group mailings with blind cc
On Fri Apr 15 14:40:27 2016, Jon LaBadie wrote: > I'm trying to set up a way to send periodic notices > to a list of people with the restriction that the > recipients email addresses not be generally visible, > thus they would be listed in the Bcc: header. > > My approach is to create an email alias "tf...@jgcomp.com" > and a mutt alias "tfc" to be "Tuesday Fun Club - Community > Center" . This works fine. > > Next step was to set up a send-hook on the tfccc email addr. > This would setup "my_hdr Bcc:" to be the list of recipients, > or later perhaps a mutt group alias for the list. I've done > similar settings before, but not for the Bcc: header. > > This step doesn't work. Either nothing gets added or the > list gets added to the To: header. > > I'm not sure if the approach is bad or something about my > syntax. Any guidance would be appreciated? Hi, Why do you don’t set up a mailing list? That’s their aim. If you do so, you don’t have to care about Bcc header, just send a mail to tf...@jgcomp.com. -- alarig signature.asc Description: Digital signature
group mailings with blind cc
I'm trying to set up a way to send periodic notices to a list of people with the restriction that the recipients email addresses not be generally visible, thus they would be listed in the Bcc: header. My approach is to create an email alias "tf...@jgcomp.com" and a mutt alias "tfc" to be "Tuesday Fun Club - Community Center" . This works fine. Next step was to set up a send-hook on the tfccc email addr. This would setup "my_hdr Bcc:" to be the list of recipients, or later perhaps a mutt group alias for the list. I've done similar settings before, but not for the Bcc: header. This step doesn't work. Either nothing gets added or the list gets added to the To: header. I'm not sure if the approach is bad or something about my syntax. Any guidance would be appreciated? -- Jon H. LaBadie mut...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: List reply + group reply combined
On Thu, Feb 04, 2016 at 11:22:53PM +1100, Erik Christiansen wrote: > On 04.02.16 12:13, Dominik Vogt wrote: > > On Thu, Feb 04, 2016 at 09:51:54PM +1100, Erik Christiansen wrote: > > > OK, as is, "To:" becomes the sender of the post to which we're replying, > > > i.e. the person to whom we actually are replying, and "CC:" is the list > > > and all the other recipients of the prior post, i.e. the CC recipients. > > > The effect of that is the same as your proposed aesthetic variant, AIUI. > > > > For one this is not just aesthetic, because putting a recipient in > > "CC:" tells him or her "you might be interested in this" while > > "To:" means "I'm talking specifically to you". I make this > > distinction frequently and may often not read a message thoroughly > > if I'm only in "CC:". > > That is precisely why it is correct for the prior poster, i.e. the only > person to whom we _are_ directly replying, to be alone on "To:", as > currently occurs. When using list-reply the prior poster is not the main recipient, and that's what we're talking about. You start a discussion on a mailing list with every subscriber or reader "implicitly" cc'ed. Staying with the example of gcc-patches: Many people (including me) don't subscribe the list but check it manually for topics interesting to them, so usually the "courtesy copy" is the only message they usually get. Still, replies should go to the list with "courtesy copies" in CC. This model is not well supported by mutt, i.e. you have to hand edit the recipient list (which I do all the time) or live with the main recipient (the list) in CC and/or other people who may not even have written a single message in "To:". > As you have defined it, and I am tempted to concur, it is the proposed > variant which would be incorrect, if anything is. Your model of reading gcc-patches may be different and well supported by mutt. "list-reply-keep-others-in-cc", not for a group reply with special handling for list addresses. > Still, if desperate, you could: > > set edit_headers=yes > > and shuffle recipients about while composing the reply. If that doesn't > suit, then ISTR that a post-edit filter could be written and > automatically run on exit from the editor, e.g. a few lines of awk. > (If not automatically, then it can definitely be run manually once back > in the compose menu.) I'll try that if there's no easier way built into mutt. Ciao Dominik ^_^ ^_^ -- Dominik Vogt IBM Germany
Re: List reply + group reply combined
On 05.02.16 08:54, Michelle Konzack wrote: > On 2016-02-04 11:34:49 Ben Boeckel hacked into the keyboard: > > On Thu, Feb 04, 2016 at 23:22:53 +1100, Erik Christiansen wrote: > > > The group of list members who are listed CC recipients who "might be > > > interested in this", receive individual "courtesy copies" in addition to > > > the list copy, which is often more than they want, as it is.¹ > > > > Mailman has an option to not send you the list copy if you're on the CC > > list. > > Which break "Reply-to-List" because your > "Cc:" has not the List-Header anymore... That need not happen, if mutt is adequately configured. When my procmail rules faithfully mimic the above, by sending the list copy (it almost always is the second to arrive) to "duplicates", the CC serves just as well for Reply-to-List. Mutt does not require a List-Header for Reply-to-List to function. All that is necessary for mutt to pick up the list in the CC header is that the list address appear in one of .muttrc's "subscribe" lines. Kinda handy, that. :-) Erik
Re: List reply + group reply combined
On 2016-02-04 11:34:49 Ben Boeckel hacked into the keyboard: > On Thu, Feb 04, 2016 at 23:22:53 +1100, Erik Christiansen wrote: > > The group of list members who are listed CC recipients who "might be > > interested in this", receive individual "courtesy copies" in addition to > > the list copy, which is often more than they want, as it is.¹ > > Mailman has an option to not send you the list copy if you're on the CC > list. Which break "Reply-to-List" because your "Cc:" has not the List-Header anymore... -- Michelle KonzackITSystems GNU/Linux Developer 0033-6-61925193
Re: List reply + group reply combined
On Thu, Feb 04, 2016 at 23:22:53 +1100, Erik Christiansen wrote: > The group of list members who are listed CC recipients who "might be > interested in this", receive individual "courtesy copies" in addition to > the list copy, which is often more than they want, as it is.¹ Mailman has an option to not send you the list copy if you're on the CC list. --Ben
Re: List reply + group reply combined
On 04.02.16 12:13, Dominik Vogt wrote: > On Thu, Feb 04, 2016 at 09:51:54PM +1100, Erik Christiansen wrote: > > OK, as is, "To:" becomes the sender of the post to which we're replying, > > i.e. the person to whom we actually are replying, and "CC:" is the list > > and all the other recipients of the prior post, i.e. the CC recipients. > > The effect of that is the same as your proposed aesthetic variant, AIUI. > > For one this is not just aesthetic, because putting a recipient in > "CC:" tells him or her "you might be interested in this" while > "To:" means "I'm talking specifically to you". I make this > distinction frequently and may often not read a message thoroughly > if I'm only in "CC:". That is precisely why it is correct for the prior poster, i.e. the only person to whom we _are_ directly replying, to be alone on "To:", as currently occurs. We are not specifically replying to every list member, so it is correct for them to be on "CC:", in the form of the list address. The group of list members who are listed CC recipients who "might be interested in this", receive individual "courtesy copies" in addition to the list copy, which is often more than they want, as it is.¹ As you have defined it, and I am tempted to concur, it is the proposed variant which would be incorrect, if anything is. ¹ Because the damned "courtesy copy" arrives first, I'm forced to use procmail to divert that to the list mailbox. Then the list copy is dumped to "duplicates", so I'm spared the nuisance of needless repetition wasting my time. Now the reply can be read in the context of the thread - very handy if there is a follow-up with a subject of "FIXED: ...". Still, if desperate, you could: set edit_headers=yes and shuffle recipients about while composing the reply. If that doesn't suit, then ISTR that a post-edit filter could be written and automatically run on exit from the editor, e.g. a few lines of awk. (If not automatically, then it can definitely be run manually once back in the compose menu.) Erik
Re: List reply + group reply combined
On Thu, Feb 04, 2016 at 09:51:54PM +1100, Erik Christiansen wrote: > On 04.02.16 11:24, Dominik Vogt wrote: > > On some mailing lists you're expected to keep people on CC, for > > example the gcc lists. So I need kind of a combination of a list > > reply and a group reply, i.e. put the list address in "To:" and > > add all other addresses that would be included in a group reply to > > "CC:". > > > > Or put in another way: In a group reply, if there is at least one > > mailing list in the recipient list, put all of them in the "To:" > > header and stick all non-list-recipients into the "CC:" header. > > OK, as is, "To:" becomes the sender of the post to which we're replying, > i.e. the person to whom we actually are replying, and "CC:" is the list > and all the other recipients of the prior post, i.e. the CC recipients. > The effect of that is the same as your proposed aesthetic variant, AIUI. For one this is not just aesthetic, because putting a recipient in "CC:" tells him or her "you might be interested in this" while "To:" means "I'm talking specifically to you". I make this distinction frequently and may often not read a message thoroughly if I'm only in "CC:". And then what you describe does only work this way in some cases. Consider a message that I have sent to a list and cc'ed a colleague: From: ME To: LIST CC: COLLEAGUE Using group reply to my own message generates From: ME To: LIST, COLLEAGUE > On gcc-patches, for example, posts use every variant of the above, and > even have several recipients on "To:", and others on "CC:". But the most > common is the native behaviour of mutt, I observe. I.e. the list is more > often on "CC:". Well, "most common" is not a synonym for "correct". ;-) Ciao Dominik ^_^ ^_^ -- Dominik Vogt IBM Germany
Re: List reply + group reply combined
On 04.02.16 11:24, Dominik Vogt wrote: > On some mailing lists you're expected to keep people on CC, for > example the gcc lists. So I need kind of a combination of a list > reply and a group reply, i.e. put the list address in "To:" and > add all other addresses that would be included in a group reply to > "CC:". > > Or put in another way: In a group reply, if there is at least one > mailing list in the recipient list, put all of them in the "To:" > header and stick all non-list-recipients into the "CC:" header. OK, as is, "To:" becomes the sender of the post to which we're replying, i.e. the person to whom we actually are replying, and "CC:" is the list and all the other recipients of the prior post, i.e. the CC recipients. The effect of that is the same as your proposed aesthetic variant, AIUI. On gcc-patches, for example, posts use every variant of the above, and even have several recipients on "To:", and others on "CC:". But the most common is the native behaviour of mutt, I observe. I.e. the list is more often on "CC:". Erik
List reply + group reply combined
On some mailing lists you're expected to keep people on CC, for example the gcc lists. So I need kind of a combination of a list reply and a group reply, i.e. put the list address in "To:" and add all other addresses that would be included in a group reply to "CC:". Or put in another way: In a group reply, if there is at least one mailing list in the recipient list, put all of them in the "To:" header and stick all non-list-recipients into the "CC:" header. Ciao Dominik ^_^ ^_^ -- Dominik Vogt IBM Germany
Handling of ";" in To: with group nameing
Hi, RFC2822 defines a possibility to put group names in To/Cc etc ... Format is described in RFC2828 Section 3.4 Addesss Specification " 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. " Request Tracker AKA RT uses this for communicating an empty group which looks like this and a BCC + Reply-To:: To: undisclosed-recipients:; Which is perfectly valid. The Problem is that when i press reply-group i get the Reply-To: address in the To and the ";" in CC. IMHO this is mishandling of addresses in mutt. I am using 1.5.24 Flo -- Florian Lohoff f...@zz.de We need to self-defend - GnuPG/PGP enable your email today! signature.asc Description: Digital signature
Re: Change to group reply from compose map?
I concur that from within Vim there is not much sense to do it. But why not from compose map? Should have access to same information as pager map. Kind regards, Xu On Mon, Nov 23, 2015 at 8:13 PM, Stephen wrote: > I tend to just exit Vim, and then hit the right key (in fact, had to > do it right now :P). Never felt it's delayed me enough to see if > there's an alternative approach, although I'd think at that point > there's not (in relation to Mutt) as you're in an external editor with > no direct tie to mutt, other than passing off the file at the > completion of your composition. > > -Stephen > > On Thu, 19 Nov 2015, Xu Wang wrote: > >> I often press 'r', write my message, and then realize on compose map >> that I should have done 'g' for group reply. Is there a way to switch >> on compose map (other than doing manually editing)? >> >> Kind regards, >> >> Xu
Re: Change to group reply from compose map?
I tend to just exit Vim, and then hit the right key (in fact, had to do it right now :P). Never felt it's delayed me enough to see if there's an alternative approach, although I'd think at that point there's not (in relation to Mutt) as you're in an external editor with no direct tie to mutt, other than passing off the file at the completion of your composition. -Stephen On Thu, 19 Nov 2015, Xu Wang wrote: > I often press 'r', write my message, and then realize on compose map > that I should have done 'g' for group reply. Is there a way to switch > on compose map (other than doing manually editing)? > > Kind regards, > > Xu
Change to group reply from compose map?
I often press 'r', write my message, and then realize on compose map that I should have done 'g' for group reply. Is there a way to switch on compose map (other than doing manually editing)? Kind regards, Xu
Re: Default send subject for group
On Sun, Oct 18, 2015 at 02:59:38PM +0200, Francesco Ariis wrote: > On Sun, Oct 18, 2015 at 02:49:27PM +0200, Teon Banek wrote: > > Hello everyone, > > > > Is it possible to have a default subject prefix when sending a mail to a > > group? For example, I have a group of people and I'd like to > > automatically fill in the subject with '[Group]' when sending mail to > > all members of the group. Basically, what I want is subject prefix > > functionality of gmail. > > > > As far as I can tell (and is mentioned in manual), modifying subject > > header through `my_hdr` variable isn't supported in `send-hook`. > > > > Also, what are the differences between having an alias with multiple > > people and creating a group? > > Would using a macro be a viable choice? It would, since I don't have many groups nor any macros at the moment. I would prefer a solution akin to a hook, though. -- Teon Banek
Re: Default send subject for group
On Sun, Oct 18, 2015 at 02:49:27PM +0200, Teon Banek wrote: > Hello everyone, > > Is it possible to have a default subject prefix when sending a mail to a > group? For example, I have a group of people and I'd like to > automatically fill in the subject with '[Group]' when sending mail to > all members of the group. Basically, what I want is subject prefix > functionality of gmail. > > As far as I can tell (and is mentioned in manual), modifying subject > header through `my_hdr` variable isn't supported in `send-hook`. > > Also, what are the differences between having an alias with multiple > people and creating a group? Would using a macro be a viable choice?
Default send subject for group
Hello everyone, Is it possible to have a default subject prefix when sending a mail to a group? For example, I have a group of people and I'd like to automatically fill in the subject with '[Group]' when sending mail to all members of the group. Basically, what I want is subject prefix functionality of gmail. As far as I can tell (and is mentioned in manual), modifying subject header through `my_hdr` variable isn't supported in `send-hook`. Also, what are the differences between having an alias with multiple people and creating a group? Thanks! -- Teon Banek
Re: how to limit/filter on a fixed set of adresses (group)
On Mon, Oct 12, 2015 at 04:51:23PM +0200, Gregor Zattler wrote: > I would wish to limit/search etc. emails which are addressed to a > group of 6 email addresses. But %C matches if one of the > addresses in the emails header matches one of the groups email > addresses. This does not check if all addresses match nor if > there are addresses which are not part of the group. > > The limit/search should not be triggered if only one or some of > the addresses match but all of them and none else. Is this > doable? if so, how? You can require all to match by using the search pattern: ~C us...@example.com ~C us...@example.net ~C foo@domain.invalid However, I can't think of a way within Mutt to limit to only those N addresses and no others (though you could exclude explicit addresses with '!~C bar@...'). You'd probably have to either limit further by hand, or write a script to do this. w
how to limit/filter on a fixed set of adresses (group)
Dear mutt users, I would wish to limit/search etc. emails which are addressed to a group of 6 email addresses. But %C matches if one of the addresses in the emails header matches one of the groups email addresses. This does not check if all addresses match nor if there are addresses which are not part of the group. The limit/search should not be triggered if only one or some of the addresses match but all of them and none else. Is this doable? if so, how? If it's not doable, is it possible to match: - if only addresses from the group match (none else)? - if all addresses of the group match (and perhaps additional others)? Thanks, Gregor -- -... --- .-. . -.. ..--.. ...-.-
Re: format=flowed (was: If List Reply Fails, Fall Back to Group Reply or Reply)
On Mon, Sep 07, 2015 at 12:31:58AM -0400, Grady Martin wrote: > On 2015年09月07日 13時39分, Cameron Simpson wrote: > >Hmm. I was going to complain about your reflow_* > >settings (even though the defaults are to reflow > >at 78 columns), but I see that they are not > >properly obeyed for me either. Grady's message > >wraps at my terminal width, even though I have > >just set reflow_wrap to 40 as a test. > > The reflow_wrap setting does not seem to affect messages for me, either, > despite reflow_text being set. This could be a problem, as the ideal display > width of lines is a matter of personal opinion, and people's opinions differ. > Personally, I do not like wasted screen space and have set reflow_wrap to 0. > The problem is that Patrick, for example, would probably like a reflow_wrap > value of 80 and yet setting it to 80 does nothing. > > In the spirit of experimentation... > > On 2015年09月07日 13時39分, Cameron Simpson wrote: > >Hmm. I was going to complain about your reflow_* settings (even though the > >defaults are to reflow at 78 columns), but I see that they are not properly > >obeyed for me either. Grady's message wraps at my terminal width, even > >though I have just set reflow_wrap to 40 as a test. > I certainly know which is easier to read. If it's hard to read most people don't bother, and if you are looking for help then that can be very problematic. Of course, it's the OP's choice how they format their mail. -- "If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing." --- Malcolm X
Re: format=flowed (was: If List Reply Fails, Fall Back to Group Reply or Reply)
On 07Sep2015 00:31, Grady Martin wrote: On 2015年09月07日 13時39分, Cameron Simpson wrote: Hmm. I was going to complain about your reflow_* settings (even though the defaults are to reflow at 78 columns), but I see that they are not properly obeyed for me either. Grady's message wraps at my terminal width, even though I have just set reflow_wrap to 40 as a test. The reflow_wrap setting does not seem to affect messages for me, either, despite reflow_text being set. This could be a problem, as the ideal display width of lines is a matter of personal opinion, and people's opinions differ. Personally, I do not like wasted screen space and have set reflow_wrap to 0. The problem is that Patrick, for example, would probably like a reflow_wrap value of 80 and yet setting it to 80 does nothing. I've just been rereading RFC3676, which specifies the format=flowed format. It has these juicy statements in section 4.1: If the line ends in a space, the line is flowed. Otherwise it is fixed. and: A series of one or more flowed lines followed by one fixed line is considered a paragraph, and MAY be flowed (wrapped and unwrapped) as appropriate on display and in the construction of new messages (see Section 4.5). The salient difference between my messages (which reflow to the reflow_wrap value) and yours (which do not, and are simply folded at the display width) is that your messages have every paragraph as a single line. By the above definitions, that is a fixed line which should not be reflowed. What you need to do is edit in a mode that produces flowed paragraphs. I'm using a slightly annoying vim setting that does most of this, and compose messages with "set editor=vim-flowed", where vim-flowed is this: https://bitbucket.org/cameron_simpson/css/src/tip/bin/vim-flowed The upshot is that my paragraphs _are_ multiline, with trailing spaces. And thus get reflowed. Yours are "fixed", and mutt (correctly) tries to not reflow them. (As you might wish it to with code snippets or CSV file lines etc.) Cheers, Cameron Simpson
Re: format=flowed (was: If List Reply Fails, Fall Back to Group Reply or Reply)
* Grady Martin [09-07-15 21:38]: > On 2015年09月07日 07時59分, Patrick Shanahan wrote: > >When so doubt or question exists, there is always that ancient document, > >man pages. > > > >re: wrap > > set wrap=78 > > set smart_wrap > > set reflow_wrap > > > >Nothing weird except habit :) > > Very true. I had neglected to set wrap. With these settings, though, > how would one even notice a format=flowed message? (This line, for > example, wraps at or before 78 characters, correct?) Correct, wraps at 78 or terminal width if less but only for format=flowed. But why would you care to "notice" a post was format=flowed? If you really care, you can examine the headers. ps: your posts still do not observe <78 chars. Please set wrap -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri http://wahoo.no-ip.orgPhoto Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535@ http://linuxcounter.net
Re: format=flowed (was: If List Reply Fails, Fall Back to Group Reply or Reply)
On 2015年09月07日 07時59分, Patrick Shanahan wrote: When so doubt or question exists, there is always that ancient document, man pages. re: wrap set wrap=78 set smart_wrap set reflow_wrap Nothing weird except habit :) Very true. I had neglected to set wrap. With these settings, though, how would one even notice a format=flowed message? (This line, for example, wraps at or before 78 characters, correct?)
Re: format=flowed (was: If List Reply Fails, Fall Back to Group Reply or Reply)
* Cameron Simpson [09-06-15 23:51]: > On 06Sep2015 22:54, Patrick Shanahan wrote: [...] > >Most certainly, longer lines than 80 chars. > > Hmm. I was going to complain about your reflow_* settings (even though the > defaults are to reflow at 78 columns), but I see that they are not properly > obeyed for me either. Grady's message wraps at my terminal width, even > though I have just set reflow_wrap to 40 as a test. > > More interestingly, my reply to you _does_ honour my reflow settings when > displayed. > > This is just weird. > > More testing needed... When so doubt or question exists, there is always that ancient document, man pages. re: wrap set wrap=78 set smart_wrap set reflow_wrap Nothing weird except habit :) -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri http://wahoo.no-ip.orgPhoto Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535@ http://linuxcounter.net
Re: If List Reply Fails, Fall Back to Group Reply or Reply
On 07Sep2015 00:41, Grady Martin wrote: On 2015年09月06日 21時38分, Patrick Shanahan wrote: line wrapping would really be nice. Read the fine manual about "lists" and "subscribe" in muttrc Here is what the manual says: Mutt has a few nice features for handling mailing lists. In order to take advantage of them, you must specify which addresses belong to mailing lists, and which mailing lists you are subscribed to. Laziness is a virtue. Do you think it would be possible to abbreviate the trouble of having to specify regexes or addresses for every mailing list? As is, I use for lists, and that fine works--but it would be nice to have one, intelligent reply command. I use myself. For everthing: lists, direct email, etc. Of course one must review the To/CC this way, but it works well for me. I've practically forgotten that the "r" and "l" keys exist... I confess I have never understood the mindset around making "lists" and "subscribe" separate notions. Could someone outline the use case for this to me please? Cheers, Cameron Simpson
Re: If List Reply Fails, Fall Back to Group Reply or Reply
On 2015年09月06日 21時38分, Patrick Shanahan wrote: line wrapping would really be nice. Read the fine manual about "lists" and "subscribe" in muttrc Here is what the manual says: Mutt has a few nice features for handling mailing lists. In order to take advantage of them, you must specify which addresses belong to mailing lists, and which mailing lists you are subscribed to. Laziness is a virtue. Do you think it would be possible to abbreviate the trouble of having to specify regexes or addresses for every mailing list? As is, I use for lists, and that fine works--but it would be nice to have one, intelligent reply command.
Re: format=flowed (was: If List Reply Fails, Fall Back to Group Reply or Reply)
On 2015年09月07日 13時39分, Cameron Simpson wrote: Hmm. I was going to complain about your reflow_* settings (even though the defaults are to reflow at 78 columns), but I see that they are not properly obeyed for me either. Grady's message wraps at my terminal width, even though I have just set reflow_wrap to 40 as a test. The reflow_wrap setting does not seem to affect messages for me, either, despite reflow_text being set. This could be a problem, as the ideal display width of lines is a matter of personal opinion, and people's opinions differ. Personally, I do not like wasted screen space and have set reflow_wrap to 0. The problem is that Patrick, for example, would probably like a reflow_wrap value of 80 and yet setting it to 80 does nothing. In the spirit of experimentation... On 2015年09月07日 13時39分, Cameron Simpson wrote: Hmm. I was going to complain about your reflow_* settings (even though the defaults are to reflow at 78 columns), but I see that they are not properly obeyed for me either. Grady's message wraps at my terminal width, even though I have just set reflow_wrap to 40 as a test. Mutt 1.5.24 (2015-08-30)
Re: format=flowed (was: If List Reply Fails, Fall Back to Group Reply or Reply)
On 2015-09-07 13:39 +1000, Cameron Simpson wrote: > Hmm. I was going to complain about your reflow_* settings (even > though the defaults are to reflow at 78 columns), but I see that they > are not properly obeyed for me either. Grady's message wraps at my > terminal width, even though I have just set reflow_wrap to 40 as a > test. > > More interestingly, my reply to you _does_ honour my reflow settings > when displayed. Encoding. It is not obeyed for QP parts, in my experience. -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.
Re: format=flowed (was: If List Reply Fails, Fall Back to Group Reply or Reply)
On 06Sep2015 22:54, Patrick Shanahan wrote: * Cameron Simpson [09-06-15 22:41]: On 06Sep2015 21:38, Patrick Shanahan wrote: >* Grady Martin [09-06-15 21:32]: >>Hello, fellow puppies. The mutt mailing list is magical. Executing a >>regular results in a prompt that confirms the recipient (list or >>sender). [...] > >line wrapping would really be nice. His message was format=flowed, and the lines wrapped nicely on my mutt display here. Is there something specific wrong? Most certainly, longer lines than 80 chars. Hmm. I was going to complain about your reflow_* settings (even though the defaults are to reflow at 78 columns), but I see that they are not properly obeyed for me either. Grady's message wraps at my terminal width, even though I have just set reflow_wrap to 40 as a test. More interestingly, my reply to you _does_ honour my reflow settings when displayed. This is just weird. More testing needed... Cheers, Cameron Simpson
