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.
