The problem I see here is the number of people who really want to push blacklists and whitelists, as if they were a magic thing to add to their served to catch spam and blame for the failures. Why would you trust list B and W knowing that they can be corrupted? Why letting them know about your contacts? Are you aware that the communications between your server and the remote service can be altered to fool you into accepting a cryptolocker? There are privacy and secutity considerations that are completely ignored here. If you are serious about e-mail, stop looking for magic. It is a waste of human resources. I would rather see an open debate and collaboration on closing the loopholes of the RFC standard while making sure the servers implementations are sound and complete. I speak out of experience, as I catch 98% of spam without any magic.
Sent from ProtonMail Mobile On Sun, Oct 8, 2017 at 4:18 PM, David Jones <djo...@ena.com> wrote: > On 10/08/2017 08:42 AM, Rupert Gallagher wrote: > You are blinded by your > purpose. > > > > On Sun, Oct 8, 2017 at 9:45 AM, Matthias Leisi > wrote: >> > > Am 08.10.2017 um 00:55 schrieb Rupert Gallagher : > > Whitelisting >> > DKIM-signed domains is a bad idea for at least two reasons: >> mass-mailing > services, and spammers who send from real addresses of >> people whose > passwords were easy to guess. This is not whitelisting >> any and all > DKIM-signed domain (that would obviously be foolish). This >> is about > whitelisting DKIM-signed domains with a positive reputation. >> And > „whitelisting" here means, that some points are deducted from the >> > SpamAssassin result. — Matthias No one is forcing anyone to add this to their > SA setup. I personally think it's an excellent idea and have been promoting a > similar concept with a long list of whitelist_auth entries of reputable > domains based on the envelope-from which is mostly aligned with SPF_PASS. The > good far outweighs the bad if you have a well-tuned MTA doing most of the > rejecting of bad senders before the message makes it to SA. Adding some of > this logic to SA can only improve things. Let's say your own bank (i.e. > chase.com) sends you an email about a loan or a credit card which is > legitimate. They DKIM signed it as alertsp.chase.com and the envelope-from > was no-re...@alertsp.chase.com. Now a spammer sends the exact same email body > but used their own DKIM and envelope-from domain. Both emails it hit > SPF_PASS, DKIM_VALID, and DKIM_VALID_AU in SA. How are you going to allow in > the chase.com email and block the other one? You have to use something based > on authorization (SPF) and/or authentication (DKIM) to trust the > alertsp.chase.com domain. whitelist_auth no-re...@alertsp.chase.com I assume > that eventually this DNS query would respond with high trust: # dig > alertsp.chase.com.dwl.dnswl.org It's already listed on a few other Internet > whitelists. Then you can train the spammer's email as spam in your Bayesian > DB or add custom content rules to score this email high and the real > chase.com email will score low. -- David Jones @leisi.net> @leisi.net>
