In keeping with Paul Judge's request that we focus the conversation
according to the charter, let's consider the "source
tracking component" mentioned in that charter.
By itself, such a component is NOT a solution to spam, but it ENABLES
many different solutions to spam, from "consent-based e-mail," various
white/blacklist schemes, and more. (For the record, I like
Templeton's whitelist-or-slowmail scheme quite a bit. But again, such
a scheme depends on a source tracking component.)
In fact, many messages to this list have focused on source
tracking. However, these messages have dived into particular
mechanisms -- there hasn't been any discussion of requirements for
such mechanisms. The goal of this message is to kick off such a
requirements discussion. In particular, I'd like to raise the
question: What exactly should be tracked?
First some assumptions and definitions:
* Internet e-mail. I'm assuming the context of today's Internet
e-mail, which means SMTP as the MTA protocol and e-mail addresses
that are associated with "domains" in the DNS sense of the term.
* Envelope sender [address]: the e-mail address supplied via the SMTP
"MAIL FROM:" to identify the sender.
* Message sender [address]: the e-mail address supplied in the From:
header of the message. Of course, there might not be one of these
if either there is no such header or if it's malformed.
* Sender's ISP: this is a term used in the ASRG charter, but I'd like
to eliminate it from our vocabulary. I think the following terms
provide more precise meanings for what was intended here.
* Envelope domain: the domain part of the envelope sender.
* Message domain: the domain part of the message sender.
* MTA chain: all MTA's handling the message.
A source-tracking component, then, could track some or more of the
following principals:
* the envelope and/or message sender,
* the envelope and/or message domain, and/or
* the entire MTA chain and/or components thereof.
(Are there others worth considering?)
As a critique of the source-tracing proposals I've seen so far (three,
I think), all were unclear as to what they were ultimately tracing.
Any proposal for source tracking should be clearly on this point.
But again, before debating the merits of specific proposals, it seems
like we could have a more productive discussion debating the merits of
tracking one or more of the above principals.
Here are a few opinions:
* Message vs. envelope sender.
I think the focus should be on message sender and/or domain, not the
envelope sender/domain. At first glance, the envelope sender/domain
appears to have practical advantages over the message sender/domain,
but at closer inspection I think these disappear (anyone disagree?).
On the flip side, the message domain/sender is what the USER sees (and
is what most filtering software uses), so it seems like this is what
should be subjected to tracing. (This seems contrary to the schemes
I've seen posted so far, which seem to focus on the envelope sender
and/or domain.)
* Tracing senders.
Tracing senders amounts to authenticated e-mail. PGP and S/MIME do
this (kind of), I don't see why a new mechanism needs to be invented.
But any scheme for authenticated e-mail faces a fundamental scalability
problem makes adoption slow (as we've witnessed over the last ten
years). In fact, it may not ever become wide spread. Thus, I don't
think we should assume wide spread adoption of sender authentication
as the answer to the "source tracing" problem.
* Tracing message domain versus MTA chain.
The interesting question in my mind is this: should the requirement be
for domain tracing, or MTA-chain tracing.
Let me argue for the domain:
* Again, the domain is what the USER sees (user, in this case, is the
recipient of a message), what the user can easily put into a filter
and/or lodge a complaint about.
* The domain is what's more easily associated (via DNS records) to a
legal entity.
* We want domains to take responsibility for their behavior. More and
more small companies use an ISPs MTA rather than their own. We want
to see these small companies take responsibility for their mailing
habits; domain tracing encourages this.
Perhaps this need not be an either-or choice; perhaps we can get both
with a single mechanism. That's fine, but I'd say that domain tracing
is the "mst have", with MTA-chain tracing as a "nice-to-have" extra.
* Cryptographic vs. DNS-mapping authentication
Another dimension of the design space is the use of cryptographic
signatures versus DNS-mappings to authenticate domains and/or MTAs.
Rather than debate this issue in the context of specific proposals, it
may be worthwhile debating it at a more abstract level.
I personally favor cryptographic approaches:
* DNS-mapping depends on the integrity of both DNS and IP-addressing.
I worry in particular about the integrity of the latter.
* DNS-mapping approaches do not provide a record of verifiable record
of authentication. Basically, in these schemes, when a message
arrives from an MTA marked as "authentic", you have to take that
MTAs word for it, you have no hope of verifying what it (or upstream
MTAs) did to ensure authenticity. Of course, configuration bugs
(versus maliciousness) causes me concern w.r.t. this assumption.
Further, the basis of all authenticity judgments in these schemes
is based on DNS-records which change at a tremendous rate (again,
suggesting that there isn't much to verify here).
* Advocates of DNS-mapping approaches (appear to) claim that this
approach requires less change to existing infrastructure than do
cryptographic approaches. I question this claim. The DNS-mapping
schemes I've seen all involve adding new records to a domain's DNS
record-set. Of course, DNS can be used to distribute keys as well
as addresses, so it seems like a cryptographic scheme could be built
with exactly the same amount of change required by a DNS-mapping
scheme (viz., the addition of DNS records).
--
Again, source tracing of any kind is not a solution to spam per se,
but is an important, infrastructural enabler of many possible
solutions. I haven't proposed a specific mechanism in this posting,
but I've tried to (a) establish a common vocabulary with which we can
compare competing proposals and (b) have suggested that cryptographic
authentication of the message domain is "the right" requirement to
evaluate proposals against.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg