[Top][All Lists]

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

Re: [Nmh-workers] masquerade settings & spost

From: Robert Elz
Subject: Re: [Nmh-workers] masquerade settings & spost
Date: Thu, 09 Feb 2012 10:50:10 +0700

    Date:        Tue, 07 Feb 2012 09:36:10 -0500
    From:        Ken Hornstein <address@hidden>
    Message-ID:  <address@hidden>

  | - Code simplification.  That's what removing support for turning off
  |   draft_from is about

For what it is worth, in case it was not obvious, I do not have draft_from
(or anything) defined in my mts.conf masquerade setting.

I know I have, in this day and age, a somewhat unusual environment, in that
I control everything that relates to my mail system (MUA, MTA, DNS,...) and
I make sure it all operates correctly. With that, essentially all of the
MH defaults are correct.

In general, I think that MH options (in the "how to process mail" sense
anyway, as opposed to "make this compile on system X") are all set so that
on a properly configured system, they don't need to be touched.  They
exist because it was known that there are many improperly configured systems,
that MH installers don't often get to fix, and yet MH needs to work anyway.

If you're planning on changing the default for an option, I think you
really need to make sure that you're keeping things so MH operates properly
(in all senses).   And that includes keeping the header values all semantically
correct as intended by the mail standards.

  | - Reasonable defaults.  The discussion that has been hashed out over the
  |   last month on this has resulted in the following consensus view:
  |   - All drafts have to have a From: line in them; if they don't, post will
  |     reject them.
  |   - The default components files will have From: lines in them.
  |   - There will be a configurable hierarchy as to where the default From:
  |     information will come from (see the mailing list archives).  This here
  |     is the part that is requiring the majority of new code.

I don't object to any of that, I can't imagine a (private) components
file without a From: field in it, and I think I see an advantage to
always creating one, even when using the default components files,
so the user can see what is going to be generated, rather than only finding
out when the recipient of the e-mail wonders why it came from that
unusual address.

On the other hand, I personally don't think any of this is important enough to
spend a lot of cycles on, this isn't an area where nmh is really deficient.

  | But ... based on what you're saying, nothing I'm proposing is going to
  | change how you use nmh.  Well, except that post probably isn't going
  | to generate a Sender: header anymore

You can't do that and remain compliant to the RFCs, it was that that I
was trying to point out in my first message (the one with the two addresses
in the From: header, which has been legal internet e-mail since forever).

When there's only one address in the From: (most of the time) then according
to the syntax, Sender: is optional, but to be semantically correct, Sender
needs to be there when the From: header does not represent the person
actually sending the e-mail (none of this has anything to do with forgery,
that's only if the sender isn't authorised to send as the address used, and
is irrelevant here).  For this, we need (well, already have) a list of
addresses that represent me, if the From: header is something different
than me, a Sender header ought to be inserted.   The envelope from (which
can be different from both From: and Sender) needs to always be set to a
value that will get e-mail bounces back to me (the person actually running
send).  Note: I'd actually prefer the determination of "me" for Sender
generation purposes to be different to the one used by %(mymbox) as I
actually prefer to keep Sender for many of my identities, even though
that are "me" (stuff like postmaster, and hostmaster, and list-request).
On the other hand, when I send from my academic address (the @coe.psu.ac.th)
I used in the example with two addresses, I don't need a Sender added
(and obviously not for my long term "normal" address as used in this message.)
That is "don't need" as opposed to "don't want", if one is generated, then
so be it, it s harmless.   Similarly, for my other identities, for which
I would prefer to make sure a Sender header is present, if it isn't, then
that would not be a disaster.   But when I send mail for my wife, and use
use her e-mail address in the From: header, which I do occasionally, then I
certainly do want/require a Sender header.   And so does rfc5322:

        The "From:" field specifies the author(s) of the message,
   that is, the mailbox(es) of the person(s) or system(s) responsible
   for the writing of the message.  The "Sender:" field specifies the
   mailbox of the agent responsible for the actual transmission of the

The semantic intent of that (as well as the syntactic requirement that
there must be a sender if the from field has more than one address, which
comes a little earlier in the RFC) really needs to be maintained for MH to
retain its status as one of the best mail systems around.

  | But assuming you have draft_from turned on,

As above, I don't.

  | you probably haven't been generating a Sender header anyway.

So, probably, I have...

  | Well, people have made what I consider reasonable arguments in terms of
  | use cases for IMAP support in nmh.  Of course when nmh has IMAP support
  | (I'm an optimist!) it shouldn't affect you in any way.

Initially, most probably not.  I guess I'm a little afraid that it is likely
to become the most common use mode, leading to both people failing to
appreciate the advantages of being able to use all the unix tools, on
all e-mail, all the time (even when not connected to the network, like in
a plane - though that restriction seems to gradually being lifted, at
a cost...) and to eventually, the worth of features being judged by whether
or not they work wit e-mail on an imap server instead of locally (we've already
seen some of that with annotate).


reply via email to

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