Folks,
do we really care where the message was sent from, as opposed to who
sent it?
My current thinking is I don't want to tightly couple the message
direclty to a person, even in an ephemeral way. I would rather note
sites, especially those that have multiple users.
So, rather than even having a home user site create a "who sent it
identifier", I would prefer the ISP submission server create a "message
passed through my server identifier",
We need to distinguish between having a mechanism with semantics about the
MTA, versus one with semantics about the author of the message. Which
underlying semantic do we really care about and why?
I believe the semantic we care about, for MTAs, is that they are part of
well-behaved networks, not that they are "authorized" by the author, or that
they in turn vouch directly for the author. In other words, is the hosting
ISP running a coherent, controlled MTA environment? If the answer is yes, we
are not certain that other MTA sources from that ISP are rogue, but we are
certain they are not vouched for, by the ISP.
I believe the biggest semantic we want to see is "this author is
well-behaved". Anything about the MTA is indirect. It might be useful, but
it's not core. A step in that direction is to authenticate the author or to
provide an assurance that they can be located.
Schemes that involve MTA registration for/by the author (SPF, LMAP, RMX, ...)
confuse these two semantics and they create very Procrustean usage and
administration scenarios. For an operation with users that send from outside
the ISP, they create problematic usage patterns.
In contrast, schemes that focus on the author directly are more flexible. It
is quite straightforward for an ISP to operate that scheme on behalf of the
author, in those environments that permit it. This means that direct
author-focused schemes permit a number of operational styles, one of which is
equivalent to the MTA registrations such as SPF, LMAP and RMX. This includes
having the ISP mask the actual author, while retaining accountability for
them.
d/
--
Dave Crocker <dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <http://brandenburg.com>