Hallam-Baker, Phillip <pbaker(_at_)verisign(_dot_)com> wrote:
Nobody seems to be commenting on the semantics side of things.
A lot of us aren't commenting on anything. ;^)
I'd _like_ to comment on semantics, but it's hard to get a good start.
Everything is so fragmented, and semantic issues are almost always bogged
down in syntax -- which I frankly don't understand well enough to discuss
authoritatively.
To make it worse, most folks who _do_ comment either confuse the
semantics of the various "identities" or appear to believe there _is_
no difference.
Sorry folks, they _aren't_ the same.
To quote a little-known authority (myself):
"
" 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.
"
" 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.
"
" 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.
This leads to three different semantics, two of which I already
posted a first cut at:
"
" Authorizing the HELO means that the domain (or ISP operating the
" network) directly controls the particular MTA, and claims to respond
" to reports of errors or misuse.
"
" Authorizing the RFC2821-MAIL-FROM means that the operators of the
" domain have taken reasonable precautions to ensure that this email
" address -- when used in RFC2821-MAIL-FROM by the particular MTA --
" accurately represents the proper bounce address; and that they claim
" to respond to reports of its misuse.
and I'll now try for a first cut at the third:
Authorizing various RFC2822 headers means that persons responsible
for managing the domain wish to publish policies relating to the use
of those headers, and make an effort to enforce those policies for
emails using their domain in that header whenever such email is
processed by an MTA under their control. They list (up to) four sets
of IP addresses pertaining to
- MTAs which are known to enforce those policies
- MTAs believed to support those policies but not known to enforce them
- MTAs not known to support the policies (the default)
- MTAs believed to violate those policies
and will accept reports of violations of these policies.
I don't know to what extent others agree with these statements, but
it would be really helpful if we could agree on the issues they cover
before getting any more bogged down in the syntax of how a set of IP
addresses will be expressed.
This is a problem since it is probably the only area where the group
can actually make a mistake that will not correct itself.
I'm not quite that optimistic, but basically I agree.
(Phillip goes on to ask a bunch of good questions, which I prefer
to defer answering until the flame-war over what I posted above is
underway. ;^)
--
John Leslie <john(_at_)jlc(_dot_)net>