On 12/10/15 5:19 PM, Viktor Dukhovni wrote:
On Thu, Dec 10, 2015 at 01:10:52PM +0100, sb wrote:
We must find a way to reject telnet-like cloud-based e-mails.
A little knowledge is a dangerous thing. You've convinced yourself
that you thoroughly understand more than you do, and have become
noticeably dogmatic about it. You've received the best advice this
list has to offer, the rest is up to you. Good luck.
Expertise is demonstrated by being didactic while solving problems. This
is different than
telling others that they are not the expert while brooming the problems
under the carpet.
For the record, the best practice is to use the Spamhaus PBL both
in postscreen and in smtpd. Possibly with additional weighted RBLs
in postscreena and perhaps also DNSWL or similar to reduce FPs.
It won't be perfect, but don't let the perfect be the enemy of the good.
For the record,
Postfix accepts e-mail sent by spam botnets using telnet-like applications.
Postfix does not cover your back in case of attack.
Postfix "experts" refer to DNSxL as the relevant "best practice".
Do not trust the advice of self-appointed experts, especially when their
advice does not work.
You can filter most of the spam (95%) without any DNSxL, as I did.
Any third party DNSBL will not help you with the remaining spam, and you
know it.
Trust the following instead, because it works, and you can rely on it.
Use DNSSEC from static IPs, and make sure its is well configured.
Use SPF, DKIM, DMARC and DANE on top of your DNSSEC.
Use PF to reject all packets from known botnets, spammers, and advertisers.
Use PF and its local dynamic black-lists to save yourself from an attack;
the servers will keep running, only your bandwidth will be affected.
Run a "proper" e-mail server, that is, one that sends and receives.
Reject connections from all dynamic IPs (use fqrdns.pcre).
Finish by rejecting e-mail based on header and content patterns
(use header_checks and body_checks).
I have all of the above, and it works.
I thought I could filter away the remaining spam by rejecting connections
from hosts without MX record, being the case of spam bots. This would
work only-if all "proper" e-mail servers would publish their MX on each
one of their sending IPs. As this is not the case, I will use the
following,
and see if it solves the problem:
Allow e-mail clients to automatically verify your own e-mail addresses,
and reject e-mail from unverified senders (use reject_unverified_sender).
Some servers do not like sender verification, possibly because they
believe you are spamming them, if your volume is consistent. I think
it is possible to solve this problem by caching the result of validations.
We shall see...
---
