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
> | 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
On Apr 9, 2007, at 5:33 AM, Robert Elz wrote: Uniqueness is what is needed - the hostname issue is that I know of know way to ensure uniqueness without some kind of global registry The best uniqueness property for a message is the message itself. Derive the message-id from a cryptographic hash of the message. E.g.: Message-ID: md5(message)@sha1(message) is pretty much guaranteed to be unique for any period of time where the Message-ID matters. --lyndon ___ 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
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 was going to put it in the ChangeLog and give it a somewhat prominent place in the 1.3 release announcement. 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? Other defaults would be a different matter. > | 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. Is this our problem? So long as we do everything that's reasonable to notify site administrators of the change, it's theirs, just as if this was not an upgrade but a first install of some new software. 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? > 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). 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? > 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. 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. > 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. Ah. I think you've just answered the question I asked above. Looks like you're worried about the uniqueness of hostnames, not the propriety. > 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. I wasn't making that assumption; I spent some time thinking about this before I made the suggestion, but I certainly don't have the experience to identify all possible issues. That's why I wanted to see what everbody else thought, and I've been waiting for responses. 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
Robert Elz wrote: >From:Joel Reicher <[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. I agree with this point -- by now almost the only people who are using nmh will be long-time users, I expect, and it would be rude to break their existing setups like this. I think the best thing we could do would be to document a sort of "best practice" configuration, and perhaps arrange for install-mh to set new users up that way. That's a general point. For the specific message-id case, I'm not convinced that -msgid should be the default anyway. I prefer having the MTA create the message ID; it means you only need to set one program up correctly rather than making sure that every MUA users might use does message ID generation correctly. Since there are reasonable arguments in both directions I'd say that changing the existing default is very hard to justify. -- PMM ___ 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: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
>> 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 Yes, you did. When in fact, what you meant was non-fully qualified addresses. There is very much a difference as not all networks have mail going to each machine on the network; not everyone in your domain necessarily has an entry in your machine's passwd or what have you, but is still on the same mail server. So that's one source of confusion. The other is why this is even such a pressing matter, if you want fully qualified addresses, write fully qualified addresses (or setup aliases for them if you're too lazy to do that). HAND -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Setting Orange, the 17th of Discord, in the YOLD 3173: 1:37 is an excellent time. ___ 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
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
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
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
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
>Perhaps I wasn't clear. If I have Indeed. >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. 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. -- 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
>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 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
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? paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 35.8 degrees) ___ 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
Joel Reicher wrote: >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 certainly think we could do with another release. I had some minor tidyups in mind (fixing compiler warnings mostly) but they can go in or not depending on whether I have time to commit them. I do think we should try to test compiling the RC on as many systems as we can. One of the problems with 1.2 (entirely my fault, alas) was that it didn't build on FreeBSD et al. Unfortunately Sourceforge's compile farm isn't available this time round... Incidentally http://www.nongnu.org/nmh/ claims that 1.2 would be the last release from this codebase. Anybody know why that is there? -- PMM ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
