Ok, I'm going to add "Modification of email address to show opt-out
choice" as #4 in my list. And to a degree this system is already widely
used when somebody adds "#listname" as part of email address, they show
choice to be opt-in to specific mail list but not others and afterwards
they filter based on this choice.
Regarding #1 (distributed hash list of email address). I'd like somebody
who has exact proposal on this issue speak up and explain this in detail,
especially cipher algorithms used, why its safe, etc. (did Verisign
had some paper, anybody wants to point me?). Then whoever is in
opposition and think this will not work, should explain problems and
technical issues in proposal.
Also regarding #3 where there maybe a problem that all mail servers (even
backups mxs) would need to answer if user is opted out or not, the
solution to this is to build separate opt-out choice report protocol
and have separarte SRV record for it. To be honest this is actually my
preferable choice, I thought to make it a part of "filtering configuration"
database as public information available from such database where as
actual filters to be used would be private information. But I consider
this approach to be subpart of #3 and in the future iteration of choices
for opt-out will list it as subsection.
Also should I mention as separate topic for opt-out an enforcement of
opt-out choices? These can include laws in support of opt-out, distributed
black lists of those companies that did not honor opt-out, etc.
On Mon, 24 Mar 2003, Brad Templeton wrote:
On Mon, Mar 24, 2003 at 03:22:29PM -0800, william(_at_)elan(_dot_)net wrote:
I'll take opt-out. I had notes on that and identified 3 automated out-out
paths (sorted by type of distribution/access to such lists):
1. Distributed lists which use some type of encryption to allow validation
of particular address but not see enter list. Please comment here on all
types of encryption methods that are available.
2. Opt-out server. Here a special service/server (maybe more then one) is
located somewhere. Anybody wishing to check of address is opt-out or not
can connect to that server (with proper authentication if necessary) and
check validity of particular email address.
3. Opt-out system as part of each mail server. Here new command is added
to mail server which allows to check if email is opted out or not.
Separate lists are run by every isp/every email server and are particular
only to email addresses handled by mail server. Its assumed that before or
during email connection command would be issues to verify opt-out
preferences before delivering email.
Any other distribution means I missed?
Unfortunately, distributed lists of hashes of e-mails don't work for secrecy.
Spammers have lists of millions of email addresses. They can just compare
the hashes against them and turn the list of hashes into a list of real
addresses. At least for those on the lists. Which is most of us. If you
get spam, you're on these lists. If you don't get spam, you don't have
much reason to get on the opt-out list.
In fact, anything that will "clean" a list of opted-out people is a way to,
using the 50 million email address spammer's database, get almost all the
list of people who opted out.
Now the question is, do you need secrecy of the names? It certainly would
be nice, since you should ideally not have to declare your address in public
in order to get your privacy! But there is no great solution here.
In fact, the only solution I have come up with requires us to all get new
E-mail addresses. This would be a pattern, such as a reserved word lower
level domain part. Thus william(_at_)ns(_dot_)elan(_dot_)net (with "ns" in
it) would be
an address declared to have opted out.
That's not very exciting but I am open to other solutions for an opt out list.
The other reason it's necessary is that email addresses are not unique.
Many people own whole domains and get all mail to
*(_at_)domain(_dot_)com(_dot_) All
sendmail users get all mail to username+*(_at_)domain(_dot_)com(_dot_) All
qmail users
get all mail to username-*(_at_)domain(_dot_)com(_dot_) There are many other
examples.
Also, user%domain(_dot_)com(_at_)otherdomain(_dot_)com is a valid e-mail for
you if otherdomain
relays. There are an infinite number of variations.
That leaves us with option 3, which can deal with that. Problem is (legit)
relaying. This requires every MX server to know the policy of every user it
MXs for.
I think it sucks, but a reserved word domain is the only solution I have been
able to come up with. Thus plus is that while we all have to get new emails
if you want such a system, it's pretty easy to guess the new address from the
old one.
However, in the end, opt-out and opt-in laws are pretty demonstrably
fruitless.
We have 25 laws already, and leaving aside their highly debatable
constitutionality, that they are entirely ineffective does not seem subject
to debate any more.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg