Re: [Nmh-workers] Changes to post

[Ken Hornstein]

> > But there is another issue that we need to address.  Envelope-From:
> > is a valid message header.  It's remotely conceivable that someone
> > might have a need to use it for another purpose.  And there are other
> > SMTP parameters that it might be useful to set, e.g.: deliver-by.
> > I don't like the idea of co-opting yet more headers out of the 822
> > namespace for this.
>
>is there any technical reason that the proposed Envelope-From: header
>functionality simply be named "Return-path:"? since i assume MH
>will remove this header (whatever we call it) from the draft before
>submitting to SMTP, i wouldn't think there's a conflict.

Yes, actually, there is.

Think about the case when you're dist'ing a message with a Return-Path
header.  There's no way to distinguish between the existing Return-Path
header and the one you would possibly add (there is already a Resent-Sender
header that post knows how to deal with).  I'm assuming we don't want
a Resent-Return-Path header.

>(other SMTP directives could still be done with syntax something like
>that proposed by lyndon.)

To reply to Lyndon's message ...

>But there is another issue that we need to address.  Envelope-From:
>is a valid message header.  It's remotely conceivable that someone
>might have a need to use it for another purpose.  And there are
>other SMTP parameters that it might be useful to set, e.g.: deliver-by.
>I don't like the idea of co-opting yet more headers out of the 822
>namespace for this.

I understand where you're coming from, but let me offer two counter
points.  First off, we already do this with a few other headers today.
The big examples are Fcc: and Dcc:.  I don't feel using Envelope-From
is necessarily worse than these headers, since there is already precedence
using these with post.  In fairness, just because bad decisions were
made in the past doesn't mean we should continue to make bad decisions
now.  But ...

>I would prefer to build these non-822 directives using a syntax
>that can't be confused with a valid 822 header. I suggest the format:

My second counter-point boils down to the albatross around our collective
necks: m_getfld().  post uses it to process the draft message, and it expects
RFC-822 headers.  I don't know what m_getfld() will do if it gets
the syntax Lyndon proposed, but I for one am NOT interested in changing
m_getfld() to deal wth it.  In addition, the code in post is all centered
around dealing with RFC-822 headers and processing them.  Adding a new
syntax would involve a lot of extra code that I'm personally not interested
in writing now.  Maybe in the future, once we've replaced m_getfld(),
yeah, we could look at it.  And if someone else wants to do it, even
for 1.5, then I'll gladly step aside and let them tackle it.

--Ken