On 9/23/11 4:30 PM, John Leslie wrote:
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.
What has been described seems like adding inbound filters at the receiver.
The only benefit that could be gained would be to share the list either
directly or via delivery status with bulk senders. Blue Security has
shown sharing will not work. Unfortunately, not returning negative
delivery status continues the erosion of email's integrity. Accepting
all mail irrespective of delivery leads to its own type of DoS.
Are you suggesting that the sharing be done via delivery status?
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.
If you are suggesting use of receiver side filters, how does that
differ from what we have today?
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.
It would be dangerous to use this as a basis for reputation when senders
do not receive notification, where recipients may use filters to replace
unsubscribe after subscribing. That is the case A/B question not
understood.
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.
Receivers conditionally sharing email lists of their customers with
various bulk senders would not seem to be a good practice.
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.
I think most would desire their email addresses kept private as much as
possible. A response that says in effect, "localpart@domain doesn't
want your email", also says this is a valid email-address in active use.
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.
Secrecy offers no benefit beyond that of a spam filter.
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.
What specifically do you see this offering over a spam filter. Is this
advocating a standard method for providers to implement mail filters?
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.
How would you ensure an opt-out is effective and that there is some benefit in
adopting the practice?
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.
The technique of dropping packets also leads to more aggressive retries
as bulk senders attempt to empty their queues. At some point a
negative response is needed, but this will also leak information.
Otherwise, this will require an increased number of servers.
The recipient desires can be more effectively enforced when the outbound
MTA can be authenticated, and not just authorized. That way any abuse
can be stopped at the source where there would be real benefit and fewer
servers required.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg