Re: Domain reputation

From: Alessandro Vesely <>
Date: Fri, 10 Jun 2011 13:13:17 +0200

On 09/Jun/11 22:19, Murray S. Kucherawy wrote:
>>> Perhaps domains that users often choose as targets, and seldom
>>> compare in abuse-reports are good candidates for whitelisting.
> I don't think MTAs should be doing any measuring as they often have
> too narrow a view. Rather, MTAs report data, and query other
> services for allow/deny instructions.

I agree a single server's view is very narrow, but it is easily
available now, and non-secret. I'd consider it a staging post on the
way there.

>> Should that be used for white/blacklisting or more as another
>> spam filtering weight/score?
> I think we'll need layers. Due to the nature of SMTP, IP-level
> filtering (RBLs, firewalls, etc.) are far more effective than
> anything at the SMTP level, so there will be a layer of that before
> any content analysis or DKIM verification. However, all three of
> those need to be present in a site's toolbox. And those tools will
> interchange data to increase each other's accuracy.

To expand on this, let's name the three levels IP, SMTP, and content.
 Roughly, we have:

*IP* may depend on local BLs (e.g. fail2ban, stockade) besides DNSBLs,
*SMTP* checks invalid HELO or MAIL FROM, SPF, local spamtraps, and
*content* based on DKIM signatures, and heuristic fuzzy filters.

Unfortunately, these layers are stacked according to the protocols
rather than the reliability of the corresponding filters. Despite
being potentially able to deliver a reliable reputation value, DKIM
comes quite late in the stack traversal. IP comes early, but IPv6 BLs
are going to be less reliable due to increased use of ranges.

IOW, in order to assuredly whitelist a DKIM signed message, it is not
enough to skip any downstream filters (e.g. Bayesian ones, in some
configurations.) One would also have to pierce upstream filters,
which is a layer violation.

Weight/score is a clean method to run filters independently of
protocol layers. It consumes more resources, though.
Received on Fri Jun 10 2011 - 11:13:27 PST

This archive was generated by hypermail 2.3.0 : Mon Oct 29 2012 - 23:20:18 PST