On Aug 16, 2007, at 6:54 AM, <michael.dillon@xxxxxx>
<michael.dillon@xxxxxx> wrote:
Such a document could help frame the discussion and identify
weaknesses that need further work such as the SPF/DKIM bandaids. We
have gotten to the present situation because various people doing
work on the problem have blinders on as that focus on one narrow
area of the problem. We need to describe the totality of the
situation, point out what works fine or has already been fixed, and
suggest a way forward for fixing the problems.
By the way, SPAM is not the problem. The problem is anonymity and
lack of accountability.
This should be stated just a bit differently.
Anonymity of SMTP clients and lack of accountability for SMTP
client's access vetting is a major part of the problem. CSV
extensions would have made a difference and would have laid a
foundation suitable for an IPv6 era.
Instead, SPF places DNS infrastructure in peril without identifying
who administers the SMTP client. This inability to authorize SMTP
clients by name is not an oversight. Path registration would have
been safe using the SMTP client's name instead of expecting DNS to
return _all_ IP addresses of _all_ systems operating on behalf of a
domain. Even with SPF, the receiver can't be sure whether an
authorization is for a bounce address or some purported originator.
To ensure the proprietary purported originator algorithm works,
mailing lists and forwarders must now identify themselves as a
purported originator using this algorithm.
DKIM, although extremely useful for filtering phish, avoids a means
to authorize SMTP clients while insisting replay abuse is not a
concern. Again, this inability to authorize the SMTP client is not
an oversight. After all, SMTP is a store and forward protocol, and
path registration impinges upon freedoms SMTP provides, right? Of
course, no provider wants to be identified to then deal with complaints.
Many providers filter messages prior to hitting a mailbox. When not
accepted, the message might be bounced as a DSN. When not bounced, a
suspect message is easily lost. A sizable portion of spam is a
spoofed bounce which just increases the chances a valid DSNs will be
lost. Here BATV might help, but only when domains are restricted to
specific outbound servers. A sizable portion of the spam is from
large providers. Their mail normally represents a mixture of good
and bad.
Can accountability ever be forced upon 900 pound gorillas, or even an
organization of 900 pound gorillas? No. Accountability will simply
never happen, and gorilla solutions are likely to make the problem
much worse.
SMTP needs to change how delivery integrity is maintained. The
delivery of a message needs to be controlled by the individual, and
made separate from SMTP. SMTP needs to change into offering a
reference for the retrieval of messages. Such a strategy ensures
originating domain spoofing is less likely without burdening the
recipient. Not even a subject line should accompany the link
comprised of a local-part and a double hash of the message and time-
stamp. Publishing could use HTTP/HTTPS and a back-end supported by a
Lustre network FS, for example. A message publishing system could
provide notifications when a message is not fetched after some
interval. DSNs would not be relied upon, nor are DSNs currently that
reliable anyway.
Of course this would not be practical or empowering without also
offering individuals some tools. Initially, the vetting could be
done on behalf of individuals where their email could be pre-fetched
and filtered. However, Individuals will also be able to directly
deal with the link vetting process themselves. Individuals should
have many choices in how their incoming email links are vetted. Of
course, the vetting process would depend upon the reputation of the
publisher.
Any filtering that might happen after the message is fetched is
responsibility of the individual or organization acting on behalf of
the individual. When a message contains malware, the individual or
organization should report this to the authorities, but the bouncing
of these message will have been made obsolete.
-Doug
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf