Re: [Asrg] Opt-Out ideas/suggestions?

[John Leslie <[e-mail]>]

Douglas Otis <[e-mail]> wrote:
> On 9/23/11 12:27 PM, John Leslie wrote:
>> Douglas Otis<[e-mail]>  wrote:
>>
>>> Keeping an opt-out list secret can't work.
>> 
>> Of course it can, if sufficiently distributed...
> 
> Consider what happened with Blue Security.

   I assume you refer to the DDoS on Blue Security's Blue Frog list.
Being a centrally-maintained list, DDoS is possible. For distributed
opt-out service at MDAs, individual lists they might query _are_
subject to DDoS, but DDoS on the MDAs themselves isn't practical.

> Although lists were private, when applied, content became obvious.

   Yes, content of such centrally-maintained lists will become obvious.

> Not offering DSN will require some method to resolve delivery issues.

   Strictly, yes; but that method can filter through individual MDA
customers -- who for the most part will be quite happy to deep-six
anything spam-like (as happens today).

   MDA-maintainers have no reason to accept such complaints from the
mass-mailers absent a contract in place.

>>> A) What would be the penalty for those that did not know of an opt-out
>>>    and yet received an opt-in?
>> Howzzat? I can't imagine any appropriate penalty beyond the opt-in.
> 
> What you seem to be describing are mail filtering rules.

   I certainly wouldn't limit it to that.

> However, random junk easily side steps such rules. This brings us back
> to opt-in with perhaps review of junk folders for strays.

   That depends on how you define "opt-in"...

   Technically, it's possible to gather opt-in confirmations and
whitelist the particular List-ID and MTA (though not trivial).

   If the service in question _participates_ in the opt-in, it could
provide additional "secrets" to check on incoming email.

   Personally, I doubt it's worth the trouble for a researcher to try
to duplicate all the details of how ISPs do filtering today -- instead
one needs to invent rules of what "opt-out" _means_. For a start, an
opt-out request from a customer probably _doesn't_ mean you hunt down
an unsubscribe process for any senders except those with contractual
arrangements (possibly through a clearing service).

   Another point: "botnet" email likely deserves to be quietly discarded.

> Again where we are today.

   A lot of it _is_ pretty similar -- but there's the opportunity to
better match the actual desires of different customers.

>>> B) What would be the penalty for those that send to the opt-out simply
>>>    because they were listed?
>> I don't understand that question either...
> 
> This was based on the assumption no opt-out, or spam trap for that 
> matter, can be kept secret.

   Hopefully we can agree _some_ opt-out listings can be kept secret.

>>> C) How would case A or B be determined?
>> Ditto.
> 
> This will not reduce the amount of abuse, nor alter any of the burdens 
> on the receiver.

   I didn't claim it would.

> Cryptographic authentication of the sending MTA, not the message, would 
> offer a more effective opt-out scheme when acceptance is predicated on 
> authentication of the entity responsible for authenticating actual 
> senders and asserting intended recipients.

   I quite agree!

> This can be done by confirming either the MSA or the MHA acting on
> behalf of the MSA. A simple SMTP token exchanged to validate
> possession of the private half of a DANE certificate would be a good
> starting point.  Perhaps just the use of TLS with these certificates.

   I'd recommend researchers try that...

>>> D) Who would accept penalty notifications?
>> I don't believe I mentioned any...
> 
> Because you think op-out lists can be kept secret.  Never returning 
> delivery status but not delivering may have a few down sides.

   Yes, but that's an issue between customer and MDA-maintainers.

>>>E) What would be used to determine accountability?
>> 
>> The question of accountability only arises if there is a contract
>> between the mass-mailer and the MDA-maintainer -- in which case it
>> is a contract issue.
> 
> There is no real benefit when the same amount of "accepted" mail is 
> still exchanged.

   I'm not sure -- that's a question for research.

>> While it may well make sense to use source-IP to verify that a
>> particular email is covered by contract, that too feels like a contract
>> issue.
> 
> Neither regex rules nor IP addresses alone will block abuse.  When it 
> doesn't, what identifier is to be held accountable?

   IMHO, absent a contract, "accountability" is a wasted effort.

>>> With many messages originating from compromised systems, any enforcement
>>> would be analogous to a notification that a system or network has been
>>> compromised.  Which organization would manage the announcement of the
>>> blackhole lists?  But we are already doing just that in various fashions.
>> 
>> Actually, no. Enforcement could be limited to the MDA in question.
> 
> You are expecting to accept all unwanted email? We tried that, but this 
> becomes a type of email black-hole sucking in ever increasing amounts.  
> You'll need more servers and storage for this scheme that will grow and 
> grow.

   My experience doesn't support quite that much pessimism.

   However, there are a number of tricks, the simplest being simply
simulating the high packet-loss of a vastly overloaded MDA. I doubt,
however, that that issue will arise during the research phase.

>> At first blush, it seems reasonable to use results to feed the
>> algorithms of blacklist maintainers, but that goes beyond the research
>> I was suggesting...
> 
> And another place where acceptance information is leaked.

   Agreed!

--
John Leslie <[e-mail]>