spf-discuss
[Top] [All Lists]

Re: Re: Email Forwarder's Protocol ( EFP )

2005-02-28 15:00:29
On Mon, Feb 28, 2005 at 01:35:44PM -0800, Dave Crocker wrote:
  It does not change envelope information.  Therefore, if
  "rfc2821.rcptto" changes, a new message was created.

I should note that there is some controversy to this assertion.  I think most 
people would not expect to call this a new message.

I understand.

In the discussion, we were asked to take definitions from your
document; so I did.  I think this list's members are well aware
of this controversy and I think people know my standpoint is not
necessarily that of the rest of this group.  In any case I am not
going to specify this in each and every message I write.

My reason for claiming that it IS is that the .forward mechanism really 
should take responsibility for originating the message.  Any handling that 
occur after that cannot be viewed as the responsibility of the content 
originator or the original rfc2822.sender.

And I agree.  But even if the task is done somewhere else (not in
.forward or similar technique on the user level) I still feel that
the statement is true.  After all, this different method would be
an implementation variant, not architecture difference.

  The issue I addressed was the supposed SPF forwarder problem.
  There is no such problem.  Once a message is no longer directed
  to the original RFC2821.RcptTo, the message was delivered.

Unfortunately, that's not quite true.

What isn't? You just agreed that if the rfc2821.rcptto changes, a
new message was created.  Do you mean to say that this does not
necessarily means delivery?

Whether it changes the rfc2821.mailfrom apparently is not all that 
straightforward, with the obvious determining question being "where should 
bounces and other notifications go?"

Indeed it does.  I know there is some controversy on this.  My
standpoint is that I am not responsible for sending the message
from "forwarder" via "other forwarder 1 .. n" to it's final
destination (if it arrives at all).


  When the "Source" is faked to be the original rfc2821.mailfrom,

MailFrom does not specify Source.

Sure. "Source", not Source.  The forwarder pretends that the original
responsible person or other kind of entity, in other words the return
address as set by the original Source, has not changed.  It may have
been better not to try and use shorthand.  Sorry.

Alex