Re: [Nmh-workers] 1.3 release and Dcc/Bcc behaviour
| Perhaps you are making a point about the way nmh generates message-ids? | Should the algorithm be smarter than it is for us to change the | default with a clear conscience? No, that's not it, the algorithm is fine (look at my message-id header, you'll see nothing there different from what nmh would generate, as that's what I use...).That is, I have no objection at all to the -msgid option as it now is, only to applying it on hosts that aren't correctly configured to use it. You might be right that it should be the site admin (site admin, these days, on someone's random home PC??) who should fix this, and know how to fix this, but I just don't see that happening - rather what I see is lots of other mail admins telling people they don't like MH users, because of the stupid message-ids they generate. I find this point persuasive; we certainly don't want mail admins telling users not to use nmh. Nevertheless, I don't agree that the nmh algorithm is fine. On the contrary, I think most of what you've said constitutes an argument in favour of designing a better algorithm so that -msgid *can* become the default. Moreover, I expect that the developers of other MUAs have already considered and solved this problem, and perhaps solved it well, especially considering the number of MUAs that also double as newsreaders. Consequently, when I find the time, I'm going to do a survey of what's been done and said amongst other developers. I don't want this to hold up the 1.3 release though, so I'm not going to commit the changes I made for -msgid to be the default. Instead I'm submitting a task on the Savannah task tracker and I'll work on it for some post-1.3 release. I've just finished going through all the patches and bugs on Savannah, and have closed/applied all those (bar one) I think are very trivial. The rest can wait until after 1.3. If there's anything that belongs in CVS or the bug tracker before 1.3, put it there soon! 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
Date:Tue, 10 Apr 2007 18:04:11 +1000 From:Joel Reicher [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | Nevertheless, I don't agree that the nmh algorithm is fine. On the | contrary, I think most of what you've said constitutes an argument in | favour of designing a better algorithm so that -msgid *can* become the | default. Yes, that would also be OK. | If there's anything that belongs in CVS or the bug tracker before 1.3, put | it there soon! If you're considering making -msgid the default in some later version, 1.3 would be a good time to announce that, and allow people who'd prefer to keep MTA generated message-ids to add send: -nomsgid to their profiles. kre ___ 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
Date:Mon, 09 Apr 2007 13:38:15 +1000 From:Joel Reicher [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | I was going to put it in the ChangeLog and give it a somewhat | prominent place in the 1.3 release announcement. I'm not sure I can convince myself that most people read those, and of the ones who do, how many would understand what it means. | I've been trying to think of what might break as a result of changing | this default, but can't come up with anything. That's one of the reasons | I'm not shy of making the change. Can you think of anything? non-unique message IDs is what I expect to happen. Or perhaps more accurately, message IDs whose uniqueness isn't something that we have any particular reason to expect. | Perhaps you are making a point about the way nmh generates message-ids? | Should the algorithm be smarter than it is for us to change the | default with a clear conscience? No, that's not it, the algorithm is fine (look at my message-id header, you'll see nothing there different from what nmh would generate, as that's what I use...).That is, I have no objection at all to the -msgid option as it now is, only to applying it on hosts that aren't correctly configured to use it. You might be right that it should be the site admin (site admin, these days, on someone's random home PC??) who should fix this, and know how to fix this, but I just don't see that happening - rather what I see is lots of other mail admins telling people they don't like MH users, because of the stupid message-ids they generate. | I'm not sure I follow. From what I can see in RFC2822, the only requirement | for the message-id is that it be globally unique. Using a proper | hostname is a recommended way of generating such a message-id, but not | required. Are you worried about the uniqueness of improper hostnames, | or are you saying the hostnames should be proper regardless? You answered this yourself (correctly) already, so I'll just confirm it. Uniqueness is what is needed - the hostname issue is that I know of know way to ensure uniqueness without some kind of global registry - something unique that we can start from. For message-IDs, that (and certainly with the MH algorithm) is the DNS and the hostname. I guess we could switch to use IEEE identifiers (these days almost every host that's going to be running MH will have one). Statistically likely unique message-ids (ones that we expect to be unique just because they're big and random) are OK - provided we do the analysis over all messages, over all time - which is a very very huge number of messages, all of which should have unique message-ids. | I'm not really sold on the whole better for the MTA to do it idea because | message-ids are for messages, not email. Usenet posts have message-ids | too. Messages and their IDs are a transport-independent idea, as far as | I understand it. Yes, I'm not disputing that it is better that way, in fact, I use MH generated message IDs (I explicitly said MH rather than nmh, because I've been doing it that way since long before nmh existed). I certainly wouldn't want the option to vanish. I just don't believe that it is a good idea to make it the default without providing some kind of mechanism to actually make sure that it works for everyone (more or less out of the box works, without any special config, assuming only normal host config.) I know that message-id generation has been kind of ignored - everyone just does what they want, and it all just kind of works (they tend to be pretty long, which means clashes are really fairly improbable, no matter how they're generated, as long as there's anything variable - I know of one system that deliberately sent the same message-id in every message, but that was more of a statement about 822, and I think can be ignored). We (on unix type systems) generally assume that if we include the time, (in any representation we like) and the process id to guard against multiple generations at the same time (to whatever resolution we're using, usually 1 second), and the local hostname (to guard against the same algorithm on a different host) then we're pretty safe. But that's not really good enough - something may be using 2007040912 as its time representation, and another host, seconds since some epoch (117612 perhaps - standard unix timestamp for the same (UTC) time). However, the system using the seconds since will eventually reach the value 2007040912, and if at that time (way off into the future) a message-id happens to be generated from a process with the same process id as the one which generated the 2007040912 message-id (using it as MMDDhhmmss), and it just happens to be running on a host that (at that future time) has the same hostname as the host (now) which uses epoch offsets, then we have a potential duplicate, as nothing we were using to ensure uniqueness is now unique. We
Re: [Nmh-workers] 1.3 release and Dcc/Bcc behaviour
Date:Sat, 31 Mar 2007 20:02:55 +1000 From:Joel Reicher [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | I get the feeling this might be catching many people, and my preference | would be to put -msgid in the defaults for send. I might too (see below for possibly why not), if MH were just being released now - but this kind of change to default options is a really annoying thing to have happen. Lots of people (including me) may have send: -msgid in their MH_PROFILE files, but I'd expect that almost no-one is going to have send: -nomsgid there, as that has been (for is it really 30 years?) the default. Changes like that are hard to make, without upsetting lots of people, and almost impossible to make without giving people lots of advance warning so they can prepare, rather than simply getting different (and perhaps broken) behaviour when upgrading to the next version. | I think it makes | more sense for the software constructing the message to construct the | message-id, anyway. I do too, provided you can do it correctly, but my guess is that if you do this, you start seeing nmh mail containing many more bogus message-ids than it currently does. To generate a message-id we need the correct hostname within which the local part of the message id is unique. You'd think that should be the hostname of the local host, which should be easu to obtain... Of course, these days, lots of hosts don't have proper hostnames, and nothing on the system is likely to do much better than pc1 or something, which is not nearly good enough for correct generation of a message-id - and if we go to the lengths that (some) MTAs go to to validate that name (making sure that the local IP address translates into the correct name in the DNS) then you're just as likely to also get utter gibberish (perhaps a valid name, but quite likely not one that can properly be used for correct - semantically, not syntactically - message-id generation). The way things are now, by default, the message id is deferred for generation by the local MTA (quite likely not running on the user's PC), and MH just works out of the box with no special configuration needed. People (like me) who want to change that, need to make sure that the hostname used is correct (either in the system, or in mts.conf) so that the generated message-id fulfills the properties required of it. I don't think this change ought to be made without really careful consideration of the effects it will have - and certainly it shouldn't be thrown in a week (or whatever) before the next release on the assumption that it's a trivial change that cannot possibly break anything. kre ___ 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 see a message-id header. The message-id header results from send: -msgid in my profile. I get the feeling this might be catching many people, and my preference would be to put -msgid in the defaults for send. I think it makes more sense for the software constructing the message to construct the message-id, anyway. If there are no objections, I'll make the change. 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 Neil, 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. So do I. I said local user names. ralph isn't an alias, it's a user in /etc/passwd. forwarding on an fcc copy leaves it as a plain user name which isn't correct in the context of an external recipient. And I see a message-id header. The message-id header results from send: -msgid in my profile. Ah, I don't have that. As Joel goes on to point out, the default is -nomsgid. Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
[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
