> Yes, there is lots of text that said otherwise, but it is in
> error.
>
Then get a time machine and fix it, both STD 10 and RfC 2821.
good idea.
sorry you missed the point of the email-arch document.
> The operative point is:
> "to which error reports should be directed"
> is not required to be the sender
>
It's the same meaning of "sender" as in the many "Secy at Host"
examples of RfC 733.
examples help make something easier to understand, but they are not the
definition. the fact that a secretary might want to receive bounces does not
mean that the bounce address must be the same as the .Sender address.
Besides that, 733's reference to .Sender does not specify a return notification
function, so I do not understand why you are calling on 733 as if it did.
> The only thing that is really interesting about all this is
> that it took us 25 years to discover the error in wording.
>
There's no error, all these "Secy" examples were pretty clear.
What is it about 733 that makes you think those examples refer to the address
to be used for bounce or notification messages?
In any event, rfc733 is obsolete.
If I had to reinvent SMTP based on your old texts I'd come to
the same MAIL FROM sender idea as it is.
yes, well, that's why 25 years of experience is supposed to be helpful.
one is supposed to learn from one's mistakes.
and the mistakes of others. (c.f., Hamming
<http://c2.com/cgi/wiki?ShouldersOfGiants>.)
> One can easily construct other, legitimate scenarios, for
> having it be a different address.
>
Not with different hosts.
can. do. need to. works fine.
in other words, you are wrong.
Different local parts can be okay.
facinating assertion. please cite the source of its specification?
Otherwise you'd need "security considerations" equivalent to
the terabytes of spam, billions of dollars, and ages of time
wasted by the blatant abuse of this obvious security loophole.
isn't it fun, the way holes become 'obvious' only after a couple of decades?
> if it were merely redundant with RFC2822.Sender or
> RFC2822.From, it would have been specified as being required
> to be redundant.
>
SMTP is only one way to transport mail, and Sender: Secy is
only one of the cases, where a Sender: makes sense. Normally
with SMTP a Sender: is in fact redundant, because it should be
the same as the mailbox address in the reverse path.
you are confusing common practise with normative mandate (or, in this case,
stricture.)
in any event, although i happen to think of email as being defined by the
common object, that was not the common view on the Internet, during the periods
of specification.
FTP was all there was. Then SMTP was all there was.
RFC 733/822/2822 were not designed with the intent of being carried over
transfer protocols of any significant semantic difference.
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net