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.

Reply via email to