Re: default components file
Glenn Burkhardt [EMAIL PROTECTED] wrote: I'd like to change the default components file to include a folder copy: To: cc: Fcc: +sent-mail Subject: Obviously it won't be a clear majority, but perhaps there will be some consensus. I think a Fcc out of the box is entirely appropriate for new users. The Dcc usage that Earl suggests is a little more advanced, and is typically used with procmail which is even more advanced (although it is absolutely necessary these days). And remember that Dcc is still undocumented and thus shouldn't be added to the default files. I've been using Fcc: +out for years. Inevitably, I get a I lost your mail, please resend at least once a month, and I often remind myself what I said. Perhaps Earl hasn't quite hit the magic-40 senility barrier yet ;-). While I use +out, I think +outbox is more MH-like than +sent-mail and would vote for +outbox for the default and may well edit my own components file accordingly now that I'm thinking of it. -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: pick argument order
Date:Mon, 30 Jun 2003 15:39:55 -0400 From:Glenn Burkhardt [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | Should this be changed, I have a patch to change it (somewhere, if I can find it, which I made before I discovered that this insanity was actually documented (n)mh behaviour...) | or will it break existing front ends to nmh? It is hard to see anything relying upon this (that is, deliberately including an option then overriding it with a seemingly unrelated option, that just makes no sense). | My reading of the exmh code is that it will not; it adds -list to the end | whenever 'pick' is used. It does now. Earlier versions of exmh had the -list option early, before the -seq option, where it did no good at all. Fixing (changing) nmh would have the benefit of fixing the pick interface for anyone still using an old version of exmh. kre
Re: default components file
The addition of 'Fcc: +outbox' does seem an appropriate and consistent default for new users that can easily be adjusted by seasoned veterans. +1. On Tue, Jul 01, 2003 at 12:17:29AM -0700, Bill Wohler wrote: Glenn Burkhardt [EMAIL PROTECTED] wrote: I'd like to change the default components file to include a folder copy: To: cc: Fcc: +sent-mail Subject: Obviously it won't be a clear majority, but perhaps there will be some consensus. I think a Fcc out of the box is entirely appropriate for new users. The Dcc usage that Earl suggests is a little more advanced, and is typically used with procmail which is even more advanced (although it is absolutely necessary these days). And remember that Dcc is still undocumented and thus shouldn't be added to the default files. I've been using Fcc: +out for years. Inevitably, I get a I lost your mail, please resend at least once a month, and I often remind myself what I said. Perhaps Earl hasn't quite hit the magic-40 senility barrier yet ;-). While I use +out, I think +outbox is more MH-like than +sent-mail and would vote for +outbox for the default and may well edit my own components file accordingly now that I'm thinking of it. -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: default components file
On Tue, 1 Jul 2003 09:01:47 -0400 Tom Julien [EMAIL PROTECTED] wrote: The addition of 'Fcc: +outbox' does seem an appropriate and consistent default for new users that can easily be adjusted by seasoned veterans. +1. Ooops, forgot to send my answer to the list instead of Tom: Agreed. +1 As for what folder name is used, its not something I care a lot about: +1 OutBox # Can you tell this is what I use? +0.5 outbox 0sent_mail 0Sent_Mail 0sentmail 0SentMail -- J C Lawrence -(*)Satan, oscillate my metallic sonatas. [EMAIL PROTECTED] He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
Re: default components file
Bill Wohler wrote: I think a Fcc out of the box is entirely appropriate for new users. The Dcc usage that Earl suggests is a little more advanced, and is typically used with procmail which is even more advanced (although it is absolutely necessary these days). And remember that Dcc is still undocumented and thus shouldn't be added to the default files. I think that this is the main point. Most mail users (in my experience) want to have a copy of mail that's been sent, for a variety of reasons. For a new user, trying to figure out simple things like this can be daunting, and they might not even realize that they are possible. In any case, when the user doesn't want the feature, figuring out how to delete FCC: +outbox will be easier than figuring out how to add it correctly.
pick question
Sorry to interrupt the good work thats going on with a user question,
but I can't seem to figure this one out. How do I use pick to get
messages that are in one sequence but not another, ie:
sequence a is a subset of sequence b.
I want to get the messages that are not in sequence a, something like:
pick b -and -not a
but that doens't work.
Any ideas?
Thanks,
Scott
PS: for what its worth, I'd be in favor of adding a +outbox or
similar to the default components file. I use +sent-mail, probably
because I came from pine, but I could switch. I also use the
following cron entry to keep it in order:
4 3 * * * find /home/slipcon/Mail/sent-mail -mtime +30 -exec rm {} \;
Re: Why not document dcc:?
Comments? Votes? Seems reasonable to me. --Ken
Re: pick question
Scott Lipcon wrote: Sorry to interrupt the good work thats going on with a user question, but I can't seem to figure this one out. How do I use pick to get messages that are in one sequence but not another, ie: sequence a is a subset of sequence b. I want to get the messages that are not in sequence a, something like: pick b -and -not a but that doens't work. I'm not on a system with MH right now, so I can't play around to check it... but I think you want to use sequence-negation. See the online MH book at http://www.ics.uci.edu/~mh/book/mh/morseq.htm#PreSeq . Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Re: Why not document dcc:?
Date:Tue, 01 Jul 2003 07:47:32 -0700 From:Jerry Peek [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | Comments? Votes? Yes, dcc has been around long enough that it isn't about to vanish next week... (and 2822 managed to avoid stealing that field name for some other purpose, which was really the big risk - now I think we're pretty safe to assume there won't be another update for a long time). And yes, Dcc and dcc had better be treated the same, all field names are supposed to be case independent (and I have no doubts that nmh (and MH before it) does this correctly). But I would include a sentence or two about the risks of using dcc when really sending a bcc (as opposed to a cc to myself). Perhaps something like Note that the users listed in the dcc field receive no explicit indication that others who received the message are not aware that a copy was sent to them. This can cause blind recipients to inadvertently reply to all of the sighted recipients of the original message, revealing that they received a blind copy. On the other hand, a normal reply to a message sent via a bcc field will generate a reply only to the sender of the original message, it takes extra effort in most mailers to reply to the included message, and so would usually only be done deliberately, rather than by accident. Or perhaps an abbreviated version of that... kre
Re: pick question
Date:Tue, 01 Jul 2003 07:58:39 -0700 From:Jerry Peek [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | I'm not on a system with MH right now, so I can't play around to check | it... but I think you want to use sequence-negation. No, that doesn't work for the purpose intended. That is, sequence-negation works just fine, but just produces a list of messages. So, assuming sequence-negation: ^ then pick [whatever] a ^b scans all of the messages that are either in sequence a, or are not in sequence b. Not the messages that are both in sequence a and not in sequence b. There's no way (I've ever been aware of) in (n)mh to remove a message from the arg list once you have caused it to be included there. kre
Re: Why not document dcc:?
Robert Elz wrote: ... I would include a sentence or two about the risks of using dcc when really sending a bcc (as opposed to a cc to myself). Perhaps something like Note that the users listed in the dcc field receive no explicit indication that others who received the message are not aware that a copy was sent to them. This can cause blind recipients to inadvertently reply to all of the sighted recipients of the original message, revealing that they received a blind copy. On the other hand, a normal reply to a message sent via a bcc field will generate a reply only to the sender of the original message, it takes extra effort in most mailers to reply to the included message, and so would usually only be done deliberately, rather than by accident. Or perhaps an abbreviated version of that... Hmmm... we wouldn't want to actually *explain* anything in a manpage, would we? ;-) Seriously, that extra info looks good to me. We might be able to do without the last sentence, though; I think people will figure it out pretty quickly. Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Re: Why not document dcc:?
Ralph Corderoy [EMAIL PROTECTED] wrote: Perhaps mention it in the fcc description as an alternative. I found fcc useless for my purposes; it's really handy to have the real message-id, etc. Have mh set the message-id send: -msgid in your .mh_profile -NWR
Re: default components file
On July 1, 2003 at 00:17, Bill Wohler wrote: I think a Fcc out of the box is entirely appropriate for new users. The Dcc usage that Earl suggests is a little more advanced, and is typically used with procmail which is even more advanced (although it is absolutely necessary these days). And remember that Dcc is still undocumented and thus shouldn't be added to the default files. I never recommended that dcc should be in any default files. I just explained why I choose to use it over fcc. I've been using Fcc: +out for years. Inevitably, I get a I lost your mail, please resend at least once a month, and I often remind myself what I said. Perhaps Earl hasn't quite hit the magic-40 senility barrier yet ;-). While I use +out, I think +outbox is more MH-like than +sent-mail and would vote for +outbox for the default and may well edit my own components file accordingly now that I'm thinking of it. After some thought, and reading the responses, I no longer have objections to it. As for the name, it should be outbox (with a lowercase 'o') since it complements the default name of inbox used when incorporating new mail. The only potential confusion for new users about Fcc: +outbox is that when they see it the first time when composing a message, they may be confused on exactly what that means. Other MUAs do the copying of sent mail behind the scenes. There is no explicit indication during message composition that a copy of the message will be filed when sent (it is a general setting of the MUA). If you want to truly mirror the behavior of other MUAs, the filing into the outbox would be done by send(1). For example, a .mh_profile would have: send: -fcc +outbox When nmh if first initialized for a user, this could be a default .mh_profile setting. Either way, being a more advanced user, I do not care, but I think it worth pointing out some behavioral issues with a default Fcc: in components and how it compares with other MUAs. --ewh
Re: Why not document dcc:?
On July 1, 2003 at 07:47, Jerry Peek wrote: A lot of us use the dcc: header field. It acts like bcc: does on most other MUAs. Is there any reason not to add a paragraph about it to the send(1) manpage? My Linux box is down right now, so I can't check this out, but here's a new paragraph. (I guess Dcc: works as well as dcc:, which is what I use... but I'm not sure.) I'll include the existing Bcc: paragraph -- which, I think, the dcc info should follow: - snip -- If a Bcc: field is encountered, its addresses will be used for delivery, and the Bcc: field will be removed from the message sent to sighted recipients. The blind recipients will receive an entirely new message with a minimal set of headers. Included in the body of the message will be a copy of the message sent to the sighted recipients. If a Dcc: field is encountered, its addresses will be used for delivery, and the Dcc: field will be removed from the message. The blind recipients will receive the same message sent to the sighted recipients. - snip -- Comments? Votes? +1 Including the additional note about the dangers of using dcc. Personally, I use dcc when copying myself and bcc when copying someone else. I personally dislike the bcc behavior of other MUAs since they provide no indication to the receipient that they have received a blind-carbon copy. I think the bcc behavior of MH/nmh is what all MUAs should do. Related comment: It may be worth considering making bcc MIME aware. I.e. Have an option that for Bcc addresses, the mail message is wrapped in a message/rfc822 media-type. This will be useful for bcc messages that are mime encoded. If I remember correctly, if you bcc a mime message, the bcc wrapping screws up the mime encoding. --ewh
Re: Why not document dcc:?
Earl Hood [EMAIL PROTECTED] wrote: Including the additional note about the dangers of using dcc. Personally, I use dcc when copying myself and bcc when copying someone else. I personally dislike the bcc behavior of other MUAs since they provide no indication to the receipient that they have received a blind-carbon copy. I think the bcc behavior of MH/nmh is what all MUAs should do. Earl and I are in total agreement here. I can't think of any reasons why we shouldn't document dcc. It works well with building whitelists with procmail, for example. -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: default components file
On 1 July 2003 at 13:51, Bill Wohler [EMAIL PROTECTED] wrote:
Note that in replcomps, the Fcc only appears if you specify repl -fcc
+outbox. But then it does appear in the header.
...
Here's another idea that I sent to Glenn in a private message.
I'm not saying that it's better than any of Bill's suggestions;
it's just another idea. BTW, I tested it now (my Linux box is
back up) and it seems to work:
On Mon, 30 Jun 2003 10:19:58 -0700, Jerry Peek [EMAIL PROTECTED] wrote:
Glenn Burkhardt wrote:
Ok. replcomps already includes the line %{fcc}Fcc: %{fcc}\n%, so
I'll check the others if there's agreement for the change.
But, by default, that doesn't make an Fcc: copy, I think -- unless the
user puts something like -fcc +sent-mail on the command line. (I'm not
on Unix now so I can't check; sorry.) You could add that switch to the
default MH profile file, but I'm not sure people would like that?
Another possibility (though it might mean changing the explanation of
replcomps in the mh-format man page you just committed...) is to change
replcomps to have something like
Fcc: %{fcc}%{fcc}%|+sent-mail%
which (if I got the syntax right, which I can't check...) would output
any -fcc switch argument, else +sent-mail. Since the Fcc: would be
output regardless, I don't think the \n should be embedded in the string.
Jerry
Re: default components file
Ok, I've committed changes to components, forwcomps, distcomps, replcomps, replgroupcomps, based on the discussion. Only repl.man needed to be changed; the other man pages dynamically pull in the current default template file when the man page is built by 'make'.
