ietf-asrg
[Top] [All Lists]

Re: 5b. Opt-Out - Re: [Asrg] ASRG work items

2003-03-25 02:20:16
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