[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] Changes to post
From: |
Lyndon Nerenberg |
Subject: |
Re: [Nmh-workers] Changes to post |
Date: |
Mon, 12 Mar 2012 09:05:41 -0700 |
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 people NOT wanting to deal
> with that, though). But since it's not obvious what to use when
> there are multiple addresses in From:, Sender: should be the one
> that should be used. But since I could imagine wanting to override
> that, that's why I created Envelope-From:.
The intent for Sender: is that it represent the entity responsible for the
transmission and delivery of the message, and that explicitly includes handling
DSNs, therefore the Sender: address should always be used as the MAIL FROM
address, if it's present.
But even in the presence of Sender:, the Envelope-From: should override Sender:
to allow for the scenario where address@hidden sends a message on behalf of
address@hidden, but wants DSNs directed at address@hidden E.g.:
From: address@hidden
Sender: address@hidden
Envelope-From: address@hidden
This makes it clear that grunt initiated the message on behalf of boss while
allowing grunt to point DSNs at a filter that automatically processes those
DSNs.
Thus the MAIL FROM construction logic would be:
* use envelope-from, if present
* use sender:, if present
* if multiple from: and no sender:, abort
* use from: address
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 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 the end of line
In the new syntax the above example would be written as:
From: address@hidden
Sender: address@hidden
.mail-from address@hidden
Post would strip out all the .foo meta-headers. 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 directive.
--lyndon
- Re: [Nmh-workers] Changes to post, (continued)
- Re: [Nmh-workers] Changes to post, Paul Fox, 2012/03/12
- Re: [Nmh-workers] Changes to post, Ken Hornstein, 2012/03/12
- Re: [Nmh-workers] Changes to post, Paul Fox, 2012/03/12
- Re: [Nmh-workers] Changes to post, Robert Elz, 2012/03/12
- Re: [Nmh-workers] Changes to post, Lyndon Nerenberg, 2012/03/12
- Re: [Nmh-workers] Changes to post, Ken Hornstein, 2012/03/12
- Re: [Nmh-workers] Changes to post, Robert Elz, 2012/03/12
- Re: [Nmh-workers] Changes to post, Robert Elz, 2012/03/12
- Re: [Nmh-workers] Changes to post, Lyndon Nerenberg, 2012/03/12
- Re: [Nmh-workers] Changes to post, Robert Elz, 2012/03/12
Re: [Nmh-workers] Changes to post,
Lyndon Nerenberg <=
Re: [Nmh-workers] Changes to post, Ralph Corderoy, 2012/03/12
Re: [Nmh-workers] Changes to post, Paul Fox, 2012/03/12
Re: [Nmh-workers] Changes to post, layer, 2012/03/12