Barry Shein <bzs(_at_)world(_dot_)std(_dot_)com> wrote:
Most of you don't see this tidal wave of muck banging away on the
shores here like a massive oil spill, so you tend to be focused only
on stuff that actually gets into your boxes which you personally don't
want, you become content-centric.
As time goes by, I'm becoming more convinced that the *only*
solution to the spam problem is whitelists, coupled with explicit
exchange of consent.
The general idea is to NOT change SMTP, but to install IP-layer
filters which block traffic to the SMTP server. Then, a new "consent"
protocol is run prior to any SMTP exchange. The "consent" protocol
gives both parties a fast and low-bandwidth method of agreeing upon
limited terms of use for the SMTP transactions.
The consent data would include things like originating MTA IP,
recipient addresses, sender addresses, message ID's, and number of
messages. The consent information may be negotiated across multiple
packets, to ensure that the exchange is fast, and consumes little
bandwidth.
If the sender fails to abide by the previously agreed-upon consent,
then the recipient can stop accepting the traffic.
This idea requires a new consent protocol, and new consent servers
to implement that protocol. It also requires changes to SMTP server
implementations, so that information which is currently internal can
be exported, and used for consent negotiation. The SMTP server
implementations also need to have consent enforcement added. This
idea does not require changes to SMTP, and I believe that none should
be made.
Administrators do something similar already, with hand-built
whitelists and blacklists. Automating the process would be
beneficial.
There are some advantages and disadvantages to this system. If it's
coupled with open (non-consent based) MTA's on lower priority MX's,
then non-consent email may still be delivered, but will be explicitely
marked as not having mutual consent. This allows better the local
administrator to have more confidence in the utuility of local
filters, as they will have more information with which to make their
decisions.
The main disadvantage to the system is time to design and implement
the protocol. But if we wait until everyone here agrees on a perfect
solution, we'll be here a long time...
Alan DeKok.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg