[Top] [All Lists]

Re: revised Email Architecture draft

2005-01-29 12:47:03

On Thu January 27 2005 17:03, Frank Ellermann wrote:
Whatever an "originator" is, it's not an arbitrary "bounces to".

the language that says what to actually DO with this string is
clear and straightforward:  it is a notifications address.

Sure, but as "originator" I can't specify whatever I like, it's an
address for error reports.  Some error between the origin and the
recipient as specified in (one of) the original RCPT TO.  Even if
I'd prefer to get my error messages somewhere else, the problem is
not between "somewhere else" and RCPT TO, it's between MAIL FROM
and RCPT TO.

If I'd think that ICANN should solve my mail problems, then I'm
still _not_ free to say "bounces to ICANN".  That's a feature,
you can't replace the "originator" by an arbitrary "bounces to".

The guiding principle is (or at least should be) that the transport
return mailbox (SMTP MAIL FROM or equivalent) should point to
a means of contacting a person who can do something, or who at
least might be presumed to care about, transport problems.  Of
course if the SMTP extension for DSN support (or an equivalent
for non-SMTP transport) is available, that provides more flexibility
in specifying delivery status notifications.  But DSNs hadn't been
invented when RFC 821 was published.

we can see that the intention of this field matches exactly what
the architecture document says it is for.

No, I don't see it, it makes no sense for me.  In very strange
cases it might be interesting that I send RCPT TO:<you> with a
forged MAIL FROM:<user(_at_)dcrocker>. maybe because we try to find an
obscure bug with your new address.  But normally that's not okay,
if the "originator" was me then it wasn't a user(_at_)dcrocker(_dot_)

I think you're getting hung up on old terminology in 821 that
happens not to match the intended original use (prior to DSNs)
for delivery trouble notifications.