Alessandro Vesely <vesely(_at_)tana(_dot_)it> wrote:
John Leslie wrote:
Alessandro Vesely <vesely(_at_)tana(_dot_)it> wrote:
Firstly, "reporting" of spammers is badly broken. If the only thing
you do is react to spam reports, your reputation is likely to be damaged
before the first report arrives.
This can be fixed by pushing, perhaps. Reporting huge quantities of
spam may eventually move abuse-box operators.
I have no objection to you trying that...
But I'd like to have a vouching service warn me _before_ I receive
any "abuse@" emails.
Secondly, the botnet problem is endemic...
Botnet spam shouldn't be reported...
I don't agree. If one of my users is botted, I'd like to know it.
(Obviously, there are lazy operators who'd rather not know.)
It shouldn't be accepted in the first place, which would have brought
us back to the question of how does one tell a zombie's disposable
mail domain from a regular one,
I don't want _my_ MTA blacklisted because one of my users is botted:
I want to _seriously_ ration the damage he can do until he fixes it.
if we didn't know the answer: vouching.
But how does the receiving MTA know what vouching service to check?
And how does it know whether the vouching service is useful?
When whitelisting will work well, postmasters will be able to lower
their spam thresholds without fear of FPs.
Agreed.
I don't think we _can_ enumerate all the components of reputation
that matter. Certainly, tendency to mis-state policies and enforcement
matters a lot...
I've tried and depict it in
http://wiki.asrg.sp.am/wiki/Abuse_Reporting
The reputation tracker appears there in all its invisibility ;-)
(There is also a tentative summary of the previous thread.)
A worthy exercise! I hope it gets updated as the discussion continues.
Vouching based _solely_ on reputation is useless, IMHO.
Add the lapse of time that the mail domain has existed for, whether
its whois information is complete, and similar "easy" data.
Be my guest... it still doesn't seem useful enough to me...
Vouching should be based on more immediate knowledge: are there
policies in place that satisfy the vouching service? What is the record
of enforcement of those policies? What measure do you have of "normal"
traffic for the sender you're vouching for?
The policy that keeps jumping in my mind is "I'll ban you from sending
for N minutes times the number of abuse reports I get about you."
A useful policy, easily implemented... but what qualifies as an
"abuse report" sufficient to enforce this? (The majority of reports I
receive concern spam that never touched my network, for example.)
I don't know about "normal" traffic. Perhaps, there could be an ARF
field counting how many messages from a given IP a server got since
the previous abuse report?
Potentially useful... but you need the sender to agree to release
this information to your vouching service...
Vouching should be a separate service so that the relationship with
the (sending) customer isn't compromised. Different vouching services
should be able to vouch for different characteristics: percentage or
volume of emails considered abusive, responsiveness, etc...
But how is that different from a reputation tracker?
Reputation trackers lack the sender-supplied information we have
discussed above.
At first blush, that would seem sufficient to qualify the message
as spam, and your customer should agree to stop sending such messages
to that recipient. But of course you won't _get_ enough information
to say _what_ message and _what_ recipient without an established
trust level between reporter and vouching service...
When someone reports a message as spam, there are no concerns about
confidentiality of the message's content.
We need reports from folks who can't be bothered to agree or disagree
with that.
It may or may not be worth to avoid list washing capabilities by trying
to protect the reporter's address;
This is why I want to have spam reports go to a reputation service
which can satisfy (different) customen their privacy isn't compromised.
(I don't know what it will take to satisfy everyone...)
in such respect, it may have no sense to forward a report to both the
sender _and_ its connection provider (steps 2 and 3 in the picture
linked above.)
AFAICT, most spam-receivers figure it makes no sense to report to
_either_ of these. :^(
There's a delicate balance here, where a vouching service needs to
first satisfy its customer (the sender) and secondly assure the
reporter that it can be trusted with enough information to be useful.
IMHO, a voucher who determines that spammers are not being blocked
should just withdraw vouching for the relevant mail domain --not doing
so would degrade its own reputation.
Agreed. There's a grey area in how long after a spam report is
forwarded before withdrawing vouching -- or how many spam reports before
withdrawing. This is why I envision a "vouching" report to say "incident
in progress," encouraging receivers to give a temporary error.
Maybe individual users deserve the right to appeal against a block,
_they_ may want to know who reported what message as spam...
This is what we need to get away from: appeals are just _too_
expensive.
I agree a vouching service may cash a fee from the mail domain they
vouch for. This does not imply corruption, though.
There are actual expenses involved in vouching. A fee is needed to
cover these in most cases.
...
Providers who don't even know who their users are, are unable to block
them effectively. They are 2big2block, so vouching for them is useless
anyway.
No provider is _always_ 2big2block! Some customers will want to avoid
blocking _some_ sending MTAs. That's a tussle for receiving providers
to work out with their customers. (And of course, nothing prevents a
reputation service from whitelisting "all" 2big2block senders...)
--
John Leslie <john(_at_)jlc(_dot_)net>
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg