John Leslie wrote:
Alessandro Vesely <vesely(_at_)tana(_dot_)it> wrote:
Let me try and summarize the topics we are concerned about.
* "Assess operator's policy enforcement." IMHO, the primary product
of feedback processing is to tell how cleverly an operator blocks
reported spammers.
It's not that simple, IMHO.
Agreed :-)
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.
Secondly, the botnet problem is endemic. It's nearly impossible to
avoid having some ISP customers (or even enterprise users) let their
computers be infected and become part of a botnet. Blocking outgoing
port 25 helps, but it's very hard to catch botnet spam going through
your "standard" MTA before hundreds have gone out; and some botnet
operators are skilled at staying below your radar.
Thirdly, fixing botnet-infected computers is insanely expensive to
ISPs _and_ enterprises, while botnet re-infection rates are scary.
Botnet spam shouldn't be reported. 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, if
we didn't know the answer: vouching. When whitelisting will work well,
postmasters will be able to lower their spam thresholds without fear
of FPs.
However, an operator could lie, which is why we need the other topics.
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.)
* "Relationship between vouching and reputation services." Vouching
must clearly be based on reputation.
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.
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."
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?
Why should it be a separate service, and what are the relationships
between them and with mail operators?
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?
* "Reliable feedback paths." This includes vetting sources,
assessing operators, and establishing minimal authentication
requirements for exchanging abuse reports.
Vetting spam-report sources is _hard_. Ideally, the reports would
contain enough information, and you'd have access to enough logged
information, to verify that such a message was indeed sent by the
customer of the vouching service.
Yes. We won't catch professional spammers this way. We need to catch
the good guys that occasionally fall into temptation. Numerically, it
is a minimal part of spam, because most spam comes from botnet
operators. Think of it as a sombrero-shaped pitch surface centered on
ham: we want to block the neighborhood just outside the ham boundary,
so that we can whitelist that region.
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. It may or may not be worth
to avoid list washing capabilities by trying to protect the reporter's
address; 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.)
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. Maybe individual users deserve
the right to appeal against a block, _they_ may want to know who
reported what message as spam...
I agree a vouching service may cash a fee from the mail domain they
vouch for. This does not imply corruption, though.
* "Senders' generic profiling." A rather slippery slope, because we
don't want to break anonymity nor privacy.
I don't believe this is a function for vouching services, but
rather a function for reputation services that don't have an
established relationship with the sender.
IMHO the presence of vouching services reduces the need for sender
profiling.
An obvious workaround for a mailbox provider who has to block a user
is to provide an alias. It should be forbidden. However, it is
difficult to track it. Statistical data or sample audits may help to
withdraw vouching for fraudulent operators.
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.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg