[dmarc-discuss] SA and domains (was Views on passive DMARC checks)

Franck Martin fmartin at linkedin.com
Mon Jul 8 18:03:58 PDT 2013


Resurrecting an old thread.

As DMARC act on direct domain spoofing, I looked at how spamassassin could help on non-direct domain spoofing. I noticed none of the rules in http://spamassassin.apache.org/tests_3_3_x.html verify that domains found in various part of an email are in spamhaus DBL or SURBL.

An oversight or I missed something?

Implementing these rules, I think, would be very useful.

On Jan 10, 2013, at 5:44 PM, Tom Hendrikx <tom at whyscream.net> wrote:

> On 10-01-13 22:55, Franck Martin wrote:
>> What I (we?) don't want is that DMARC affects the reputation of the email
>> as spammers will publish a DMARC record if it lowers their spamassassin
>> score.
> 
> My idea was more along the lines:
> - add some informational rules with near-zero scores that tell the
> recipient about Dmarc policy existance and contents (see: DKIM_SIGNED)
> - add some penalty rules when policy evaluation fails, or alignment fails.
> 
> While it does not improve deliverablity for poor-formatted senders (both
> phish and legit), it would create a direct positive experience for
> recipients: block more phish mail.
> 
>> 
>> Also I think the RFC specifies that aggregate reports are an integral part
>> of DMARC. You can't develop one without the other.
> 
> Noted.
> 
>> 
>> The opendmarc milter/proxy way seems the way to go, spamassassin is
>> installed this way on linux boxes, I don't see why it would not be as easy
>> to install opendmarc.
> 
> I used Spamassassin just as an example, but let's stay on that route.
> - It has already a huge install base, adding a plugin to something that
> already exists is easier than integrating a new piece of software in
> your mailstack.
> - It has lots of ways to integrate other than a milter api.
> - Not everyone runs a milter-capable MTA.
> 
>> 




More information about the dmarc-discuss mailing list