What we are trying to accomplish

In the jabber session, Dave Crocker suggested we are aimless:

resnick:  I argued that we should do "all of them", i.e. design a
          mechanism that can handle HELO, MAIL FROM, and 2822.
dcrocker: "let's do everything" is only slightly worse than "let's do
          multiple". either way, it says that we do not really know
          what we are trying to accomplish or why.
jlcjohn:  I disagree -- we have very good reasons for each.
dcrocker: oh? I think I'm missing a clear statement of those "good
          reasons", in a fashion that lets us see incremental,
          long-term benefit. I say long-term because this level of
          standards work cannot ever do anything that is "interim".
jlcjohn:  happy to discuss in detail on list...

   Looks like I get to start this discussion...

   First of all, we're in a context where we're clarifying our charter:
none of these comments should be taken to mean what comes first.

   Dave would like us to lay out what we're trying to accomplish: I'd
like to see that too; but I don't believe there's any reason to worry
about reaching consensus on that yet. It will become an important
question as we set about designing what should go into our first RFC.

   My disagreement (during the jabber session) with Dave was whether
such a choice would "say" we don't know what we are trying to
accomplish.

   My point was that we have very good reasons to want to design
DNS records relating to HELO authorization, equally good reasons to
want DNS records relating to RFC2821-MAIL-FROM, and good, though
different, reasons to want RFC2822 authorization info. They don't
need to be the same reason.

   First of all, with HELO we want to establish a chain of trust for
debugging purposes, and for allowing bounce messages to find their
way to the originator of a message if the message is rejected later
in the chain. With additional (out of our scope) reputation services,
HELO authorization could enable a number of features, _some_ of which
we can imagine today.

   Next, with RFC2821-MAIL-FROM we want to have a useful bounce address,
so that failure information can _automatically_ pass to a person able
to do something about it.

   Third, with the RFC2822 headers, we want _some_ domains to be able
to signal to recipients whether the email they receive is consistent
with the practices of that domain for sending email. Not every domain
will want this service, but it can be a big win for those that want it.

   Thus, three different things we're trying to accomplish, for three
different "good reasons".

   Q.E.D.

--
John Leslie <john(_at_)jlc(_dot_)net>