--On 14 February 2010 18:57:28 -0500 Rich Kulawiec <rsk(_at_)gsp(_dot_)org>
wrote:
On Sun, Feb 14, 2010 at 03:04:51PM -0800, Steve Atkins wrote:
You sent the email I'm replying to from an end user system, so there's
an innate paradox in that statement.
Actually, no. My email message is NOT an input to a security
policy mechanism.
---Rsk
ASRG doesn't influence security policies?
Actually, all emails that are scanned by security mechanisms, are inputs to
that mechanism. That's especially true if the mechanism is a learning
mechanism, like a bayesian filter with auto-learning.
So, of course, are all emails to abuse@ or postmaster(_at_)(_dot_) I get surprisingly
few of each.
You're correct, of course, to caution that automatic reporting mechanisms
will be subject to automated poisoning. We should, of course build
mechanisms to defend against such attacks. I'd suggest the following:
1. Reports should be submitted over an authenticated channel. If the
mechanism is SMTP, then it needs to be ESMTPSA, or via a verified feedback
loop supported by DKIM signatures or SPF.
These measures don't make us immune to attack, but they do raise the bar.
2. Reports should be ignored if the subject of the report can't be
verified. That is, if an email isn't on the system AS DELIVERED, you should
not accept a report against that email.
3. An heirarchy of possible actions should be available in response to a
set of reports, for example (a) unsubscribing the reporter from a mailing
list; (b) blocking delivery to the reporter's mailbox; (c) blocking
delivery to an entire mailstore; (d) reporting up the channel; (e)
involving official regulators; (f) calling the police.
4. The action selected should be proportionate to the confidence that one
has in the report. Confidence might be built by aggregating reports, by out
of channel confirmation, or by admin eyeballing the offending message.
Client machines that we administer (on campus) might be given more
weighting than others.
NB: Some actions - (a) and (b) - are already available to black-hats, so
automatic reporting mechanisms are not introducing a new risk. The
mechanism, if well implemented, will make it easier for end users to block
senders. Of course, the mechanism might be easier for black-hats to achieve
those particular ends, but the system could guard against by using
out-of-channel confirmations.
Other actions, (c), (d) and (f) would require different levels of
investigation, but if I can make it easier for end users to report spam,
then I can focus my investigations on incidents that affect more people
rather than incidents that affect the loudest shouters or the people
closest to me in the organisation.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg