I don't agree on your opinions about accepting bad email. Accepting RFC-incompliant or spam email for local delivery is no wrong, because then it won't hurt someone else. Eg, if you accept spam to yourself or your own users, who is it gonna hurt on the internet? Its when you are RELAYING RFC-incompliant, or even RFC-compliant email, for unauthorized people, that creates problems.
Also another common problem is that the default configuration (ubuntu .deb) allows SASL authenticated users to relay anywhere from any email. So if someone decides to only accept email from the outside, not relay outgoing email, and still some hacker out there starts a password hacker program (often called dictionary or brute force), which goes through all possible passwords, and then "u=root p=root Access Granted!" and then those details end up in some "list of open SMTP servers" and the servers are quickly ending up on DNSBLs. Personally, I think the default config should be that SASL should be turned off. Or that SASL should only be permitted for local hosts, so the only way to relay is to be in mynetworks AND have a valid account, and that mynetworks default should always be 127.0.0.0/8 and nothing else. Another thing that you need to be aware of, is that certain DNSBLs for Open Relay, does not propely test open-relayness of the server. Some Open Relay tests just try to send a email through the server, and then bail out after RCPT TO, and if the server didnt reject RCPT TO, then server is listed. This causes 3 types of servers to be listed. Those that are configured for global catchall, eg *@*.* is delivered to a local mailbox, certain webmail systems are configured this way, and those that reject unauthorized relay in the DATA stage, and those that DISCARD's unauthorized relay email instead of REJECT'ing them. The proper way to test for relay is that the DNSBL should attempt to relay to a email that the DNSBL is in control of, and then programmatically checking the inbox of that email if the relay goes through. This also allow the DNSBL to list the outgoing server, and not the incoming server, of a misconfigured open relays that uses different inbound and outbound servers. When it comes to spam fighting, I have resorted to DISCARD'ing specific domains. Kills like 90 % of the spam. (REJECTing won't work, spammer instantly just switch to a new domain, but DISCARD works perfectly, the spammer won't notice the mail got rejected). Best regards, Sebastian Nielsen -----Ursprungligt meddelande----- Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] För sb Skickat: den 29 december 2015 13:02 Till: majord...@cloud9.net; postfix users <postfix-users@postfix.org> Ämne: 53% of Postfix servers are black-listed (DNSBL) 90% of global e-mail is SPAM. 91% of targeted attacks start with e-mail. What is Postfix's share of SPAM? -------------------------------- A recent survey of 2.8M SMTP servers shows the following. - 53% of Postfix servers are black-listed (DNSBL) http://www.mailradar.com/mailstat/mta/Postfix.html - 44% of open relays are Postfix servers http://www.mailradar.com/mailstat/open-relay/ - 35% of Postfix servers are hosted in the USA http://www.mailradar.com/mailstat/mta/Postfix.html Who makes Postfix? ------------------ Wietse Venema IBM T.J. Watson Research P.O. Box 704 Yorktown Heights, NY 10598, USA What is Postfix's share of the SMTP server market? -------------------------------------------------- A recent survey of 2.3M SMTP servers shows the following. #1: 53.25% EXIM #2: 32.64% POSTFIX #3: 6.66% SENDMAIL http://www.securityspace.com/s_survey/data/man.201511/mxsurvey.html What is wrong with Postfix? --------------------------- Suppose you are a school/SME/you-name-it, you want a secure server, and you run Postfix. The following is what you get in your inbox. > Date: Thu, 17 Dec 2015 15:6:1 > From: paulnoah@ > Message-ID: <8038f16fe88ca0b6a66649d005c232e9@localhost.localdomain> > Received: from 1-160-101-156.dynamic.hinet.net ([1.160.101.156]:52001 > helo=uwtir.com) by seth.lunarpages.com with esmtpsa [...] > Received: from localhost (localhost.localdomain [127.0.0.1]) by > zimbra.baycix.de (Postfix) with ESMTP id E7078416A85 [...] > Received: from [127.0.0.1] by omp1062.mail.bf1.yahoo.com with NNFMP; 25 Dec 2015 23:24:21 -0000 > Received: from uhosp.example.com ([37.230.116.83]) > Received: [...] >... > Message-ID: [...] <----------- > Delivered-To: [...] > Received: [...] > Received: [...] [anonymised] > To: <y...@your-domain.com> >... > Reply-To: <y...@your-domain.com> There are more examples, and the all reduce to Postfix accepting incoming e-mail whose origin and envelope are not RFC compliant. In fact, the task of writing PCRE parsers and policies is delegated to the user, that is you, as part of your own configuration (access, helo_access, header_checks, etc). Writing such parsers and policies is highly rewarding: my servers reject 95% of SPAM by rejecting non-RFC-compliant e-mails, without any DNSxL or anti-spam add-on. The task required months of full-time labour. The same task cannot be brought to completion, however. The postfix-users forum would be a good place where to discuss Postfix's problems in detail. However, the same forum is rather focused on self-celebration than active collaboration, where attempts to address SPAM as a problem are scornfully dismissed. Given the above statistics, this is no longer surprising. Postfix is easy on the spammers and hard on the honest. unsubscribe postfix-users
smime.p7s
Description: S/MIME Cryptographic Signature
