[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] 1.3 release and Dcc/Bcc behaviour

From: Joel Reicher
Subject: Re: [Nmh-workers] 1.3 release and Dcc/Bcc behaviour
Date: Mon, 09 Apr 2007 13:38:15 +1000

>     Date:        Sat, 31 Mar 2007 20:02:55 +1000
>     From:        Joel Reicher <address@hidden>
>     Message-ID:  <address@hidden>
>   | 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.


        - Joel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]