Date:Mon, 12 Mar 2012 16:48:26 -0700
From:Lyndon Nerenberg
Message-ID: <045459a5-0de8-4e24-987d-9d49123b5...@orthanc.ca>
| I doubt they'll be used often enough for that to be an impediment.
Very possibly true, but the same applies to using a more normal
looking fi
Date:Mon, 12 Mar 2012 19:32:23 -0400
From:Ken Hornstein
Message-ID: <201203122332.q2cnwnu8001...@hedwig.cmf.nrl.navy.mil>
| I think you've misunderstood me; in this particular instance,
OK.
| Paul's proposal was to generate a Sender: header if there were multipl
Hi,
Lyndon Nerenberg wrote:
> 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:
>
> metahead = "." directive *(SP params)
> directive = LETTER *(LETTER / DIGIT / "-")
> params = ; free-form text to t
On 2012-03-12, at 4:32 PM, Robert Elz wrote:
> Adding stuff like "nmh" in the field name would certainly reduce the
> chances of a clash even further, but at the expense of making them
> less manageable (for humans to deal with.)
I doubt they'll be used often enough for that to be an impediment.
Date:Mon, 12 Mar 2012 16:06:34 -0700
From:Lyndon Nerenberg
Message-ID:
| That sort of statement tends to lead to infamy ...
Not really - there have been invented field names that have given problems,
but none with rational names - sendmail's Apparently-To had all
> | 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.
>
On 2012-03-12, at 2:39 PM, Robert Elz wrote:
> Make the name fairly precise and the chances of someone using the same
> thing (including the IETF) for some different purpose are absurdly
> small.
That sort of statement tends to lead to infamy ...
But I suppose I wouldn't grumble too loudly if w
Date:Mon, 12 Mar 2012 13:57:43 -0400
From:Ken Hornstein
Message-ID: <201203121757.q2chviac031...@hedwig.cmf.nrl.navy.mil>
| 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
|
ken wrote:
> > > 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.: d
> > 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
>What about repl and forw? Will the default `comp' files all insert an
>appropriate From: that respects the mts.conf/localname setting? That's
>all I want and need.
Yes, _all_ default components files now do that, for all programs
that use a components files. Feel free to download the sources
f
Ken Hornstein wrote:
>> >Right now From: has to be set in components, replcomps, replgroupcomps,
>> >etc. I currently rely on From: being set from the GECOS and localname:'
>> >option from mts.conf so I don't have to set From: in all those "comp"
>> >files.
>> >
>> >If you make the above change,
lyndon wrote:
> 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-b
ken wrote:
> >[ i tried to send this before, but something went wrong, and ken's
> >moving so fast these days, i feel compelled to resend asap. :-) ]
>
> You say that like it's a bad thing! :-)
are you kidding!? it's great! now, when someone calls me a luddite
for using such a clunky archai
>[ i tried to send this before, but something went wrong, and ken's
>moving so fast these days, i feel compelled to resend asap. :-) ]
You say that like it's a bad thing! :-)
>- if there are multiple addresses in From:, then require at least
>one of Envelope-From: or Sender:. create
>Right now From: has to be set in components, replcomps, replgroupcomps,
>etc. I currently rely on From: being set from the GECOS and localname:'
>option from mts.conf so I don't have to set From: in all those "comp"
>files.
>
>If you make the above change, will there be an .mh_profile way to set
On 2012-03-12, at 9:26 AM, Earl Hood wrote:
> I thought the "X-" prefix was the standard for designating
> non-standard headers. Therefore, for nmh, something like
> "X-nmh-" could be the prefix to use for any nmh-based
> custom headers.
The IETF consensus is that X-headers are going to die. B
On Mon, Mar 12, 2012 at 11:05 AM, Lyndon Nerenberg wrote:
> 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:
>
> metahead = "." directive *(SP params)
> directive = LETTER *(LETTER / DIGIT / "-")
> para
ken wrote:
> So here's what I came up with:
>
> - Reject drafts that don't have a From: header (this was non-controversial
> as I recall).
> - Allow a Sender: header in the drafts (previously post would reject
> drafts that had one; I assume that's because post had it's own idea
> wha
On 2012-03-12, at 9:05 AM, Lyndon Nerenberg wrote:
> Since these headers will be specific to the backend transport I would suggest
> ignoring ones unknown to the backend, and giving the backend the ability to
> print warnings, or abort the send, if there are problems processing a
> recognized
>> - Reject drafts that don't have a From: header (this was non-controversial
>> as I recall).
Right now From: has to be set in components, replcomps,
replgroupcomps, etc. I currently rely on From: being set from the
GECOS and localname:' option from mts.conf so I don't have to set
From: in all
On 2012-03-11, at 8:39 PM, Ken Hornstein wrote:
> My thinking was that since bounces go to the SMTP envelope-from,
> bounces should go back to the person who wrote the message. In the
> example above, I'd want to know about a bounced email, rather than
> my secretary (I guess I could see other p
On 3/12/2012 9:53 AM, Tethys wrote:
> As such, I'd say if Sender is present, always prefer it over From,
> regardless of how many From addresses there are. This will hold
> true even if you don't have a secretary. If you've specified a
> Sender, I can't imagine why you'd want bounces to go elsewher
[ i tried to send this before, but something went wrong, and ken's
moving so fast these days, i feel compelled to resend asap. :-) ]
ken wrote:
> So here's what I came up with:
>
> - Reject drafts that don't have a From: header (this was non-controversial
> as I recall).
> - Allow a Send
I agree with Tet, and considered saying the same thing
(though less eloquently) last night...
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
>If you're the sort of person that has a secretary send email for you
>(probably less common now than when the RFCs were drafted, but still...)
>then you'd want the bounce to go to the secretary and have them deal
>with it, since you're clearly too busy for such minutiae.
>
>As such, I'd say if Sen
Ken Hornstein writes:
>My thinking was that since bounces go to the SMTP envelope-from,
>bounces should go back to the person who wrote the message. In the
>example above, I'd want to know about a bounced email, rather than
>my secretary
If you're the sort of person that has a secretary send em
I just committed some changes to "post", and I wanted to give people a
heads up and solicit some feedback.
The changes to "post" include the previously-discussed requirement
that a From: header is now required in message drafts. But as always,
there are wrinkles.
The discussion I had with Robert
28 matches
Mail list logo
