Re: [Nmh-workers] Changes to post

[Robert Elz]

    Date:        Mon, 12 Mar 2012 13:57:43 -0400
    From:        Ken Hornstein <address@hidden>
    Message-ID:  <address@hidden>

  | There is one wrinkle: Right now Envelope-From: can be blank; if you
  | do that, then you will get a MAIL FROM:<>, which is useful if you
  | don't want any bounces at all.  Sounds like the logic should be if
  | you have multiple From: addresses then Envelope-From: cannot be
  | blank.

There's no reason for that, there's no requirement that the smtp
sender (envelope) address be anything in particular, without regard
to what's in the From: field, nor whether or not there's a Sender field.

It might be worth making sure it is only ever blank by deliberate
action however, rather than just because some other function couldn't
produce any data.

  | Actually, now that I think about it I might have written the
  | code that Sender can be blank, so I should fix that :-)

Yes...

I also see no problem with using regular field names (that could be
legal) for internal purposes, and doing so certainly makes things more
regular for everyone.   The only thing to watch for is to avoid using
field names that are too generic (Envelope-From is not going to be a
problem) and that reasonably could be used for almost any purpose.
Make the name fairly precise and the chances of someone using the same
thing (including the IETF) for some different purpose are absurdly
small.   (And of course forget the X nonsense.)

One final comment - much of what is being discussed (about what is
required, rather than mechanism I mean) is based upon the assumption
that nmh is using SMTP for message submission - we wouldn't need to
be worried about envelopes, or Sender headers, if we were using sendmail
type delivery (for example).  But resurrecting that discussion isn't
what I intended, rather perhaps to consider what would be required using
the new mail submission protocol, which I suspect is supported by just
about all rational MTAs these days.   With proper use of that (sometime in
the future perhaps) many of the problems that we're having difficulty
handling should just go away - eg: as typically used these days, we
cannot expect nmh to be able to work out a valid mailbox address for
anyone - so we're more or less requiring the users to set it.   On the
other hand, an MTA receiving a message through a properly authenticated
submission session should have no problem with this at all.

kre