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.
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.
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.
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...
Douglas Otis wrote:
On 12/11/09 6:41 AM, John Leslie wrote:
I remain convinced that senders need an established relationship
with vouching services and receivers need an established relationship
with reputation services, and that the interaction between these two
types of services is an area for interesting work.
* "Relationship between vouching and reputation services." Vouching
must clearly be based on reputation.
Vouching based _solely_ on reputation is useless, IMHO.
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?
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...
The focus could be more on vetting feedback sources directed to the
postmasters using _blind_ addresses, rather than assessing each
individual message, and have a centralized feedback system that
publishes related metrics and sender's specific information, such as
their volumes, their purported types of messages, and their directly
verifiable sources such as hostnames or DKIM signatures. The direct
information assists in establishing correctly attributed feedback.
This is another item a vouching service might include: number or
percentage of emails received at spamtraps. Doug has a point here:
spam-reporting is _so_ broken that vouching services starting business
today probably would need a network of spamtraps to get useful reports.
But IMHO spamtraps are not a viable long-term measure. It's too
easy to find out where a spamtrap is and ensnare an innocent MTA to
send something to it. (Some spamtraps can trigger on NDNs _required_
by the SMTP RFCs.)
* "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.
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...
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.
* "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.
--
John Leslie <john(_at_)jlc(_dot_)net>
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg