spamassassin-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Cole" <sausers-20150...@billmail.scconsult.com>
Subject Re: How to get spam assassin to detect spoofed mails as SPF is clearly useless
Date Sat, 15 Oct 2016 20:35:48 GMT
On 15 Oct 2016, at 14:13, Petr Bena wrote:

> That would obviously work and blocked hackers from spoofing,

No, it would not do so.

It's clear that you didn't bother reading Dianne Skoll's message and 
considering or testing her counter-example.

> but as you said, it would also break some other stuff, like mailing 
> lists for instance,

And also not work for some From spoofing, which is ridiculously easy to 
do.

> so you deemed this solution evil and something what should never be 
> done on any mail server, even if that mail server was used only by 
> people who don't care about mailing lists at all.

I don't think anyone said "evil" but it WILL catch mail other than 
mailing lists and spam. It also won't catch some forms of From header 
spoofing unless you also prohibit some forms of formally allowable From 
headers.

So it might be absolutely acceptable for some systems. Your server, your 
rules. No one can stop you from building such a plugin, recruiting 
others to help you do so and deploy it, and thereby demonstrate how 
useful and how harmful such a tactic is. I do not think you will ever be 
able to get such a plugin included as a part of the Apache SpamAssassin 
project, but that's why OSS is so great: you can create and distribute a 
plugin for SA on your own or even fork the whole project and distribute 
an alternative package. You do not need the blessing of the members of 
this list or of any governance mechanisms of the Apache Software 
Foundation to design and implement a SpamAssassin plugin.

> So is there actually any other solution?

There is not any comprehensive solution to identify From header forgery 
across all or even most domains without substantial false positive 
and/or false negative rates and due to the history of Internet email 
there cannot be such a solution any time soon. However, many sites can 
safely control spoofing of their own domain names in their own inbound 
mail rather easily if they are willing to impose some basic simple 
rules, which will vary from site to site.

One could go the Full Yahoo: publish a p=reject DMARC policy, require 
all users to use an authenticated submission mechanism, sign their mail 
with DKIM, and honor the DMARC policy. They'd still need to filter out 
the pathological cases like Dianne's example, but that is not hard or 
very risky. This will also cause some other sites to refuse some mail 
spoofing those domains and some sites to refuse some valid mail because 
of DKIM's inherent fragility. Oh and yes: forget about mailing lists.

A purely local approach is again to require all users to use an 
authenticated submission mechanism, but then just reject any mail with 
any local domains in the From coming in over a port 25 connection from 
untrusted IP's. Exempt mailing lists as needed. Of course this doesn't 
catch forgeries of non-local domains and doesn't prevent local domains 
from being forged on mail to other sites, but it is a usable approach.


Mime
View raw message