[Top][All Lists]

[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 

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.


reply via email to

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