nmh-workers
[Top] [All Lists]

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

2007-04-08 21:05:41
    Date:        Sat, 31 Mar 2007 20:02:55 +1000
    From:        Joel Reicher <joel@panacea.null.org>
    Message-ID:  <6593.1175335375@succubus.panacea.null.org>

  | 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

<Prev in Thread] Current Thread [Next in Thread>