[Nmh-workers] 1.3 release and Dcc/Bcc behaviour
Hi all, Two things: 1) Some people have commented on the comp.mail.mh newsgroup that Bcc and Dcc headers should not be removed before Fcc is processed, so that the Fcc copy contains them. Since the default components has Fcc: +outbox in it I'm inclined to agree. Does anyone disagree? Perhaps there should be an option to send for this so we can have it both ways, but I honestly don't see what could be desirable about the current behaviour. 2) I think the current CVS code should be released as 1.3. If nobody objects, I will change the version string to 1.3-RC1 and upload a 1.3-RC1 tarball. When all issues are worked out, I'll tag the code in CVS as RELEASE_1_3, change the version string to 1.3, and upload the 1.3 tarball. I have no experience with release engineering so comments, please. Cheers, - Joel ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.3 release and Dcc/Bcc behaviour
Hi Paul, joel wrote: 1) Some people have commented on the comp.mail.mh newsgroup that Bcc and Dcc headers should not be removed before Fcc is processed, so that the Fcc copy contains them. Since the default components has Fcc: +outbox in it I'm inclined to agree. Does anyone disagree? Perhaps there should be an option to send for this so we can have it both ways, but I honestly don't see what could be desirable about the current behaviour. isn't the risk that, if you forward someone a copy from your outbox, that it will contain the bcc headers? Agreed. Besides, I've always found fcc useless. It doesn't expand local user names, e.g. `to: ralph' stays like that instead of becoming `to: [EMAIL PROTECTED]', and there's no message-id which is vital for referring someone back to an earlier email. I dcc myself and file that copy instead. It too doesn't keep track of invisible recipients but then that's good because of the forwarding danger Paul points out. I suppose some meta-data outside of the email file could keep track of such things in son-of-MH. Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.3 release and Dcc/Bcc behaviour
Besides, I've always found fcc useless. It doesn't expand local user names, e.g. `to: ralph' stays like that instead of becoming `to: [EMAIL PROTECTED]', and there's no message-id which is vital for Erm, it's not at all useless, you're misusing it. Fcc is for filing a local copy, it expects a folder name, not email addresses or aliases. -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Prickle-Prickle, the 16th of Discord, in the YOLD 3173: Snoochie Boochie Noochies! ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.3 release and Dcc/Bcc behaviour
Hi Jerrad, Besides, I've always found fcc useless. It doesn't expand local user names, e.g. `to: ralph' stays like that instead of becoming `to: [EMAIL PROTECTED]', and there's no message-id which is vital for Erm, it's not at all useless, you're misusing it. Fcc is for filing a local copy, it expects a folder name, not email addresses or aliases. Perhaps I wasn't clear. If I have to: ralph fcc: +foo subject: test -- end as a draft then folder foo ends up with a version of the email that has no message-id header and the `to' header says to: ralph as opposed to to: [EMAIL PROTECTED] The former isn't very helpful if I ever wish to dist or forw the email on. No message-id is a killer. Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.3 release and Dcc/Bcc behaviour
Hi Jerrad, Perhaps I wasn't clear. If I have Indeed. Actually, I was just being polite. My second message merely repeated the information that was in the first. The former isn't very helpful if I ever wish to dist or forw the email on. No message-id is a killer. Meh, it saves a copy of the draft. (Meh?) OK, so it saves the draft less the empty headers, things like bcc and dcc, and the line of minuses after the headers. And it appends spaces after a header's colon. No alias expansion, and (in theory) no header strippage. This preserves as much information as possible; potentially useful for replicating any problems that one might run into. Is fcc meant to be used for a file copy, or for debug? If a file copy then it's flawed; no message-id, etc. If debug then it's flawed since it mucks around with the draft too much. ~/mail/drafts/,1 preserves as much as possible for debug. dcc-ing myself and filing that gives a file-copy. Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.3 release and Dcc/Bcc behaviour
Ralph Corderoy [EMAIL PROTECTED] wrote on Mar 30, 2007: Agreed. Besides, I've always found fcc useless. It doesn't expand local user names, e.g. `to: ralph' stays like that instead of becoming `to: [EMAIL PROTECTED]', and there's no message-id which is vital for referring someone back to an earlier email. I dcc myself and file that Strange. I see aliases expanded in the fcc: copy. And I see a message-id header. The message-id header results from send: -msgid in my profile. -NWR ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.3 release and Dcc/Bcc behaviour
I didn't read the comp.mail.mh article, so maybe I'm repeating what was said there. But whenever I use dcc:, I always end up saving those lines to a temporary file (or copying them with my mouse), then editing my copy to add that field to it -- so I can find out, later, who I sent the message to. So, for me, having a choice (if not by default) to include the contents of dcc: and bcc: would be a win. As for forwarding those fields accidentally: If you use non-MIME forwarding, you can set up a forw -filter file that doesn't include dcc: or bcc:... and I'd think that would prevent the problem. For forwarding as an attachment, after you've typed mime at the What now? prompt, you can type edit and remove header fields that you don't want to send. I usually do that to remove fields like Received: (and, often, Message-ID: too). It does sound like some people don't want this behavior, though. Adding an option to send like -showblind, or something, might be a good compromise. Jerry ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
