Dave Crocker wrote:
get a time machine and fix it, both STD 10 and RfC 2821.
good idea.
That makes four, you, me (I want to watch this), Bruce,
and I've also invited Keith Moore.
sorry you missed the point of the email-arch document.
Not sure what you're talking about. One point is apparently
to get a new terminology for discussions. The completely
new terms like "mediator" are fine. But where it tries to
redefine MAIL FROM as "errors-to" IBTD, that's far too late,
it would be the last nail in SMTP's coffin.
[Secy at host]
examples help make something easier to understand, but they
are not the definition.
You've written this text before I knew what a modem is or how
to punch a card, so I'm forced to guess: You had some kind of
mail at this time, and a format like the later 822 format. It
had From, Sender, and Reply-To fields among others.
I've only vague ideas how you transported these mails, UUCP,
FTP, and what else, but no SMTP. Somebody wanted a KISS
solution, read your text, and invented SMTP. To, CC, and BCC
were simple, each recipient got a RCPT TO. Now he needed ONE
responsible sender (of course, for the error messages).
He didn't know that MicroSoft patented Sender-ID and IsNot,
therefore he came to conclusion that Reply-To IsNot what he
wants for error messages, that could be anywhere. And it's
only an optional field.
Therefore he took From: and invented MAIl FROM. Reading your
text more carefully he found, that From: isn't always exactly
what he wants, but if it's not, then there's always a Sender:
Therefore he wrote "sender MAIL FROM", and all were happy
because they had SMTP. Please correct this imagiation where
necessary.
Now more than 22 years later you just can't say that all the
"sender / mail from / originator / return path / reverse path"
were incorrect terms, and what the author really wanted to say
was "errors-to". That we can't ask him anymore is only one of
many reasons why it's far too late to undo it in mail-arch.
BTW, looking in your 822 references I find not only 733 and
821 as expected, but also "graph theory". You knew what you
were doing, a term like the "reverse path" was no nonsense.
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.
I've never read 733 before Bruce mentioned it in conjunction
with his from-optional-draft. Its "sender" is apparently
the same concept of "sender" as in 821. And 733 says:
| the critical function served by the "Sender" field is the
| identification of the agent responsible for sending mail
Looking for "responsible" you found the same idea in 2822
in your parallel reply to Chris here.
What is it about 733 that makes you think those examples
refer to the address to be used for bounce or notification
messages?
Responsibility, in 733 you say "Sender SHOULD be a human"
(in slightly different words). A human can fix bugs, maybe,
a program can't. But I only saw this now.
In any event, rfc733 is obsolete.
Yes, but for me it's interesting to reconstruct the history
of SMTP, especially if the author of the message format says
that we all got it wrong for 22 years (reduce this to about
12 years in my case).
one is supposed to learn from one's mistakes.
The mistake was RfC 1123 5.3.6 (a) after the elimination of
source routes in the reverse path: "the rest of the envelope
and the message body are left unchanged". Of course they
couldn't know how MAil FROM would be abused 15 years later.
[1223 5.2.1]
| The envelope addresses may be derived from information in
| the message header, supplied by the user interface
[...]
| The SMTP envelope cannot in general be re-derived from the
| header at a later stage in message delivery, so the envelope
| is transmitted separately from the message itself using the
| MAIL and RCPT commands of SMTP.
"Derived" doesn't sound like an independent "errors-to", but
admittedly "may be" also doesn't sound like "must be".
[MAIL FROM not Sender]
Not with different hosts.
can. do. need to. works fine.
in other words, you are wrong.
Yes, I was wrong. A mailing list with its own bounce address
is fine, it does not necessarily have to do strange things
with a completely different 2822 Sender address set by the
poster. Sympa adds an Errors-To in this case.
The MAIL FROM still reflects the "responsible sender", that
is the mailing list, and the Sender field could be the old
"original sender". Maybe the former is your term "mediating
source". Whatever it is, that's a very sound case (not for
Sender-ID, but for SMTP and SPF).
It would be an invalid case (for Sender-ID, SPF, and RfC 1123
5.3.6b but unfortunately not 5.3.6a) if the mailing-list keeps
the old MAIL FROM.
Different local parts can be okay.
facinating assertion. please cite the source of its
specification?
Cases like BATV or SRS.
isn't it fun, the way holes become 'obvious' only after a
couple of decades?
If what they say in 1123 is true it was a trap. The reverse
path concept didn't work as planned, source routes were more
or less unnecessary, so they just made sure to get rid of it,
quoting 822, but not caring about forged MAIL FROM addresses.
And 251-forwarding was a nice feature, so they left it as is
keeping the old MAIL FROM (5.3.6a). Ready, praying that the
disaster won't come. But it came, that's where we are. Maybe
SPF can fix it, but it's based on the old _literal_ meaning of
MAIL FROM / return path.
Bye, Frank