Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
On 9/23/11 12:27 PM, John Leslie wrote:
Douglas Otis<dotis(_at_)mail-abuse(_dot_)org> 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 <john(_at_)jlc(_dot_)net>
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg