Re: Logging DNSBL rejections
On 7/1/2014 2:21 PM, Narcis Garcia wrote: > if I run mail command or swaks, they both make Postfix to send with SMTP > from 127.0.0.1 or public IP. Never 127.0.0.2 > > Can I tell Postfix to make 1 mail sending from 127.0.0.2 ? > If so, I suppose the SMTP service listening at TCP/25 will receive the > local communication from 127.0.0.2 (?) You've completely lost your way, you're confused. DNSBL tests are on inbound connections. Here you're talking about sending mail outbound. I think Wietse's answer confused you. Why are you averse to using the standard tools that everyone uses to test DNSBL queries, mainly 'host' and 'dig'? This is all that's needed to confirm your IP DNSBL queries are working, assuming you execute them with the same user permissions as Postfix. Cheers, Stan > El 01/07/14 19:58, Wietse Venema ha escrit: >> Narcis Garcia: >>> Is there any website or service in internet to send a mail test from a >>> blacklisted IP? >> >> Yes. telnet to 127.0.0.2 port 25. >> >> Wietse >
Re: Logging DNSBL rejections
On 7/1/2014 11:18 AM, Wietse Venema wrote: > Narcis Garcia: >> How can I check in some manner that some of these parameters is working? >> >> reject_rbl_client >> reject_rhsbl_reverse_client >> reject_rhsbl_helo >> reject_rhsbl_sender > > How can WE check that you have configured them properly? > > It is possible to configure these so that they will never fire. Very true. For example, if you are using your ISP's resolvers to query a Spamhaus DNSBL the query may be rejected due to terms of usage violation. Temporary DNS problems will also cause query failures. You need to test your queries to your DNSBLs. Each one should have instructions on their website telling you how. Here are the Spamhaus instructions: http://www.spamhaus.org/faq/section/DNSBL%20Usage#366 Cheers, Stan
Re: Postfix and Generic rDNS
On 6/27/2014 3:53 AM, Klaipedaville on Google wrote: ... > Now my postfix always warns me due to this generic rDNS of my ISP. > > Postfix says, "hostname verification errors in FCrDNS: > Does not resolve to address > 123.45.67.8123-45-67-8.my.isp.com You should only see these warnings for mismatched hosts that connect to your Postfix SMTPD server. Do you have a NAT router in front of the Postfix server? Do your logs show all inbound connections coming from only one IP, your public IP address? Do you get this warning for every connection? If so you might try setting http://www.postfix.org/postconf.5.html#proxy_interfaces If all connections are from that one IP, get a different NAT router that doesn't rewrite the source address. Cheers, Stan
Re: How to block offering SASL auth to clients based on RBL
On 6/10/2014 3:39 PM, Wietse Venema wrote: > Kai Krakow: >> BTW: In this context, what's the best approach to put mailboxes on a >> separate machine? Let the LDA drop mails into NFS mounts, or let postfix >> transport the mails via transport_map into a machine which hosts the LDA >> (dovecot in our case)? > > I recommend Dovecot via LMTP, but NFS would work, too, assuming one > file per message. I can't say which approach would handle the most > load. Dovecot's LMTP and LDA both perform index updates during delivery to the mailbox. They also enable Sieve. Dovecot's speedy performance is due in large part to its indexes. If you use the Postfix LDA to drop mail directly into maildir files, Dovecot will need to stat the new files to update its indexes, before responding to a LIST command. On a busy server this can be expensive, and responsiveness at the MUA may be sluggish. Thus I concur with Wietse. Use LMTP for performance, and to enable Sieve scripting. Cheers, Stan
Re: CIDR Whitelist ?
On 6/10/2014 1:24 AM, Michael Tokarev wrote: > 10.06.2014 05:02, Stan Hoeppner wrote: ... >> Yes. And if you have other separate smtpd_foo_restrictions sections you >> should move those restriction parameters under >> smtpd_recipient_restrictions as well. This will give you precise >> control over whitelisting and blacklisting order. > > I'm sorry to say that, but this is wrong. All smtpd_*_restrictions give > precise control over all the restrictions and their order, if you move "will give you precise control". Note "you", meaning the user, not Postfix. Having all restrictions in one place makes it easier, as in eyeballs on screen, to see what's going on. > it all to one stage it becomes clumsier. Also, moving stuff which should > be run at connect or hello time to recipient time is kinda wrong. Postfix performs delayed evaluation of restrictions by default so this is irrelevant. Evaluation order for the most part doesn't change, only the logical order in main.cf. > Such a suggestion - to move everything to recipient_restriction - can be > given to a novice postfix user (or by novice postfix user), who does not > understand smtp protocol stages and this smtpd_*_restrictions mechanics, > both of which are kinda trivial. Hammer or nail gun Michael? Everyone understands how the hammer works, but given the choice goes for the nail gun. It's faster, more precise, and saves your thumbs. :) Cheers, Stan
Re: CIDR Whitelist ?
On 6/9/2014 7:12 PM, Ronald F. Guilmette wrote: > I really should have figured this out ages ago, but... > > Quite simply, there exits a small number of organizations that > run afoul of my various smtpd_recipient_restrictions and/or my > smtpd_helo_restrictions, but from which I need to be able to > receive mail anyway. (A small number of companies get snagged > on reject_unknown_helo_hostname due to having botched the HELO > strings on their outbound mail servers, and also, in the case of > Microsoft, they seem to have managed to get numerous of their > IPs listed on Spamcop.) > > So anyway, I just now added the following to my pre-existing > list of smtpd_recipient_restrictions: > > check_client_access cidr:/usr/local/etc/postfix/blacklists/cidr-whitelist > > where my cidr-whitelist file currently contains just: > > # Microsoft > 65.52.0.0/14 OK > > Of course, I placed this new check_client_access clause above all of > the other/pre-existing clauses in my smtpd_recipient_restrictions. > > I just want to ask if I have done the proper thing here, because I've > never done this before. > > My hope is that I haven't inadvertantly opened up a relaying hole or > anything awful like that. > > One other question... > > Currently, I have the following: > > smtpd_helo_restrictions = > permit_mynetworks > reject_non_fqdn_helo_hostname > reject_invalid_helo_hostname > reject_unknown_helo_hostname > > In order to make sure that my new CIDR whitelist will allow in even > mail from goofed-up sites that have botched their HELO strings, should > I be moving the three reject_*helo_hostname clauses shown above down > into my smtpd_recipient_restrictions... you know... to a position > that comes *after* my new check_client_access clause? Yes. And if you have other separate smtpd_foo_restrictions sections you should move those restriction parameters under smtpd_recipient_restrictions as well. This will give you precise control over whitelisting and blacklisting order. Cheers, Stan
Re: lost connection with ]server] while receiving the initial server greeting
Scratch my previous suggestion as it was obviously not the correct solution. Read on. On 5/4/2014 9:01 AM, post...@nisny.com wrote: > On , wie...@porcupine.org wrote: >> post...@nisny.com: >>> There were several attempts from postfix to connect to 6 different mx >>> servers to deliver one email. They all have the same result so I'm only >>> including the dump of the first here: >> >> We see SYN, SYN|ACK, ACK, and a bunch of retransmissions. >> >> SYN: Initial client window 1400 (scale 6), options [mss >> 1460,nop,wscale >> 6,sackOK,TS] >> >> SYN|ACK: Initial server window 33304 (scale 1), options >> [nop,nop,TS,mss >> 1460,nop,wscale 1,nop,nop,sackOK]. >> >> Then we see SYN|ACK retransmitted, ACK retransmitted, etc., until >> the server sends a RESET. The TCP handshake never completes. And >> someone may already have posted the solution. >> >> For the telnet connection we have a successful handhake. >> >> SYN: Initial client window 65535 (scale 6), same TCP options as >> >> SMTP client. SYN|ACK: Same initial server window and TCP options >> as STMP server. >> >> The only difference I see is the initial 1400 client TCP window >> size. >> >> As someone already suggested in one of the first follow-ups: >> >> "Would you mind trying to remove "tcp_windowsize = 1400" from >> you configuration (do not forget to issue a "postfix reload" >> afterwards!)?" >> >> Wietse > > Wietse, > > Thank you for your patience with me. I tried way too long trying to > resolve this on my own. > > I totally forgot that was in main.cf (from months ago trying to resolve > a separate issue and missed it in postconf -n output. (the issue in > question is a networking problem at the provider and the main reason for > the move). > > The funny thing is that directive is on the old server as well, which > had no problems connecting to akamai, Are both the old and new server in the new provider's network at this point. It would be informative to compare SMTP session capture of both systems when "tcp_windowsize = 1400" is configured. I.e. test the old system and compare to the capture you already have for the new system. At this point you know what Postfix setting caused the problem on the new server, but you don't know why it caused a problem, you don't know the root cause. Knowing that root cause may be very useful in the future. > At any rate, removing the directive and a reload, postqueue -f resolved > the issue completely. Cheers, Stan
Re: lost connection with ]server] while receiving the initial server greeting
On 5/4/2014 3:02 AM, Stan Hoeppner wrote: ... > 1. Create relay transports for the problem domains and limit > concurrency to those domains, until your sender reputation with Akamai > has increased to the point they allow parallel deliveries. > > 2. Contact the Akamai hostmaster and inquire as to what that threshold > is, and when you may expect to surpass it. ... I forgot the simplest solution: Give the new server the IP address and forward/reverse DNS name of the old Postfix server, same HELO hostname, etc. That should fix this instantly, assuming this problem did not exist before. Your use of the term "old" implies you decommissioned the old box, which makes this the optimal solution. Cheers, Stan
Re: lost connection with ]server] while receiving the initial server greeting
On 5/3/2014 9:48 PM, post...@nisny.com wrote: ... > I am clueless as to why telnet would receive a correct response but > Postfix not. > > I know see this is not necessarily a Postfix issue but not sure what the > next step would be, so if anyone can offer guidance it would be > appreciated. The answer to your problem is in your first post: > We had some initial problems with some private blacklists and the new IP but > those were resolved. However, I had a curious problem sending mail to > icloud.com addresses... The problem is exclusive, as far as we know, to this Akamai hosted MX farm. Wietse is obviously correct. Your telnet sessions work because they are a single connection. When you allow Postfix to deliver, it is making parallel connections to the farm because sufficient mail is queued for domains at that MX farm. You have two options to resolve this: 1. Create relay transports for the problem domains and limit concurrency to those domains, until your sender reputation with Akamai has increased to the point they allow parallel deliveries. 2. Contact the Akamai hostmaster and inquire as to what that threshold is, and when you may expect to surpass it. This problem is not new. The list archives are littered with threads dealing with ISPs who limit concurrency or delivery rate of "fresh" IP addresses. Those threads also contain instructions on how to do what I describe above to limit Postfix concurrency. Cheers, Stan
Re: lost connection with ]server] while receiving the initial server greeting
On 5/3/2014 7:54 AM, post...@nisny.com wrote: > On , wie...@porcupine.org wrote: ... >>> relay=mx4.icloud.com.akadns.net[17.172.34.67]:25, delay=177, >>> delays=0.3/0.01/177/0, dsn=4.4.2, status=deferred (lost >>> connection with mx4.icloud.com.akadns.net[17.172.34.67] while receiving >>> the initial server greeting) 17.172.34.67 >> 0.3 = No congestion within the Postfix queue. >> 0.01 = TCP completes immediately. >> 177 = Postfix waits for the 220 greeting until the connection is >> dropped. >> >> I suggest that you take Postfix out of the loop, and diagnose this >> further with plain old telnet. >> >> Wietse > > Wietse, thank you for your efforts. Telnet isn't telling me anything new: > > Trying 17.172.34.70... > Connected to st11p00mm-mx006.me.com. > Escape character is '^]'. > 220 st11p00mm-smtpin012.mac.com -- Server ESMTP (Oracle Communications > Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) 17.172.34.70 > As you can see, I'm getting an immediate 220 from them which postfix > apparently is not getting. I can, of course, continue the telnet > session and send a complete email which is received by the recipient. Note that you are manually telnet testing against a different host than the one logged by Postfix with the greet timeout. Also note there are 12 MX hosts in the me.com/mac.com inbound farm. Depending on the nature of the problem, you may only see it with 17.172.34.67, and the other 11 may be fine. You need to perform proper and thorough testing in order to determine if this problem exists with only one of the 11 farm hosts, or more than one, and if it is transient or ongoing. > ;; QUESTION SECTION: > ;mac.com. IN MX > > ;; ANSWER SECTION: > mac.com.3600IN MX 10 mx4.mac.com.akadns.net. > mac.com.3600IN MX 10 mx3.mac.com.akadns.net. > mac.com.3600IN MX 10 mx1.mac.com.akadns.net. > mac.com.3600IN MX 10 mx5.mac.com.akadns.net. > mac.com.3600IN MX 10 mx2.mac.com.akadns.net. > mac.com.3600IN MX 10 mx6.mac.com.akadns.net. > > ;; ADDITIONAL SECTION: > mx3.mac.com.akadns.net. 300 IN A 17.172.34.65 > mx5.mac.com.akadns.net. 300 IN A 17.172.34.69 > mx2.mac.com.akadns.net. 300 IN A 17.172.34.12 > mx4.mac.com.akadns.net. 300 IN A 17.172.34.67 > mx2.mac.com.akadns.net. 300 IN A 17.172.34.11 > mx4.mac.com.akadns.net. 300 IN A 17.172.34.66 > mx6.mac.com.akadns.net. 300 IN A 17.172.34.71 > mx1.mac.com.akadns.net. 300 IN A 17.172.34.9 > mx1.mac.com.akadns.net. 300 IN A 17.172.34.10 > mx3.mac.com.akadns.net. 300 IN A 17.172.34.64 > mx5.mac.com.akadns.net. 300 IN A 17.172.34.68 > mx6.mac.com.akadns.net. 300 IN A 17.172.34.70 > ;; QUESTION SECTION: > ;me.com.IN MX > > ;; ANSWER SECTION: > me.com. 3600IN MX 10 mx4.me.com.akadns.net. > me.com. 3600IN MX 10 mx5.me.com.akadns.net. > me.com. 3600IN MX 10 mx3.me.com.akadns.net. > me.com. 3600IN MX 10 mx6.me.com.akadns.net. > me.com. 3600IN MX 10 mx1.me.com.akadns.net. > me.com. 3600IN MX 10 mx2.me.com.akadns.net. > > ;; ADDITIONAL SECTION: > mx1.me.com.akadns.net. 300 IN A 17.172.34.9 > mx6.me.com.akadns.net. 300 IN A 17.172.34.70 > mx4.me.com.akadns.net. 300 IN A 17.172.34.66 > mx2.me.com.akadns.net. 300 IN A 17.172.34.12 > mx5.me.com.akadns.net. 300 IN A 17.172.34.69 > mx4.me.com.akadns.net. 300 IN A 17.172.34.67 > mx3.me.com.akadns.net. 300 IN A 17.172.34.65 > mx6.me.com.akadns.net. 300 IN A 17.172.34.71 > mx1.me.com.akadns.net. 300 IN A 17.172.34.10 > mx5.me.com.akadns.net. 300 IN A 17.172.34.68 > mx2.me.com.akadns.net. 300 IN A 17.172.34.11 > mx3.me.com.akadns.net. 300 IN A 17.172.34.64 Cheers, Stan
Re: Understanding postscreen timeouts
On 5/2/2014 6:07 AM, Wietse Venema wrote: > Stan Hoeppner: >>> swl.spamhaus.org*-4 >>> list.dnswl.org=127.[0..255].[0..255].0*-2 >>> list.dnswl.org=127.[0..255].[0..255].1*-3 >>> list.dnswl.org=127.[0..255].[0..255].[2..255]*-4 >> >> Consolidate these last 3 to something like: >> list.dnswl.org=127.0.[2..14].[2..3]*-4 > > These three will result in one list.dnswl.org query, just like the > consolidated one. There is no performance difference. Correct. The reason for consolidating these is not to reduce queries. > However, there is a correctness difference. The consolidated form > has the same weight 4 for all results, while the original form > has different weights. The consolidated form gives no score to a 4th octet value of [0..1], but gives -4 to [2..3]. This is the key difference. Alex' form and weights are not correct. And that is why I posted the link to the return codes. The second 'octet' is always zero, not a range. The 3rd octet has a range of 2-15, and the 4th octet a range of 0-3. Specifying a range of 0-255 or 2-255 to cover "the future" may have the opposite effect, resulting in potential disaster, depending on how/if/when dnswl changes things. Such wildcards should not be used. A value of 15 in the 3rd octet means the sender is an Email Marketing Provider. Most people would never whitelist such senders. Alex currently does. Most people would give no preference to a 4th octet score of 0 which means "no trust". Alex is giving -2. And he is giving -3 to a 4th octet score of 1, "low trust". The recommended scale is -0.1, -1.0, -10, -100, and this is how SpamAssassin handles dnswl scoring. Using a 4 point scale instead of 100, a 4th octet value of 0 or 1 should be given NO whitelisting preference at all, which is what my consolidated example does. Cheers, Stan
Re: Understanding postscreen timeouts
On 5/1/2014 8:15 PM, Alex wrote: ... > These are both corporate 10mbs dedicated links and I don't think latency > and/or bandwidth is a problem. The problem, if network related, will be UDP packet loss somewhere in the end-to-end path, not b/w or latency on the CPE link into the provider's net. > It actually appears swl.spamhaus.org is the main problem. It doesn't even > resolve when I try to do it manually. >From here: $ host 2.0.0.127.swl.spamhaus.org 2.0.0.127.swl.spamhaus.org has address 127.0.2.2 What response do you receive? Due to your query volume you require paid service for Spamhaus Zen. The same terms apply to all Spamhaus services. Your IPs may have been blacklisted from DWL due to high query volume. Contact Spamhaus. If your contract entitles you to all Spamhaus lists, the fix may be as simple as changing the SWL hostname and adding your key. > This was a recommendation I used from > this list some time ago. Has something changed? See above. > postscreen_dnsbl_sites = mykey.zen.dq.spamhaus.net*3 > b.barracudacentral.org*2 > bl.spameatingmonkey.net*2 > bl.spamcop.net > dnsbl.sorbs.net > psbl.surriel.com > bl.mailspike.net With these 7 dnsbls you will have extreme overlap of listed IPs. The last 5 will gain you little to nothing and simply add latency to your mail transactions, which is something you do not want in a high volume environment. I'd recommend you use Zen and BRBL, remove the rest, and rely on SWL and dnswl for FP mitigation during SMTP. You also run SpamAssassin on all of these hosts, so there's no need to pile on dnsbl queries at SMTP connect. > swl.spamhaus.org*-4 > list.dnswl.org=127.[0..255].[0..255].0*-2 > list.dnswl.org=127.[0..255].[0..255].1*-3 > list.dnswl.org=127.[0..255].[0..255].[2..255]*-4 Consolidate these last 3 to something like: list.dnswl.org=127.0.[2..14].[2..3]*-4 To understand why, read "Return Codes" at: http://dnswl.org/tech > I'm also curious what resolvers people are using for their mail servers? > bind? Looking at my query graphs, it appears to be about 30 queries/sec on > average for each host, just as a local caching server. That's ~2.6M queries/day/host. Eliminating the 5 unnecessary dnsbl queries will lower this considerably. If you're not happy with bind, check out: http://doc.powerdns.com/html/built-in-recursor.html If you have more than a handful of hosts doing 2.5M queries/day, you should seriously consider building a couple of resolvers homed in different networks and having the MX hosts query the pair. This will cut down considerably on the query load you're placing on your dns[b|w]l servers, as resolver cache will be much more effective. Cheers, Stan
Re: email addresses with forwarding receive duplicate emails sent by postfix
On 4/28/2014 10:17 PM, Andy Yen wrote: > Hi, sorry, it appears I forgot to add the logs. They are included below. > This is called with PHPMailer just once, but postfix show it is being > sent 3 times for some reason > > This is the output from /var/log/maillog > > Apr 28 21:50:27 mail postfix/smtp[13404]: 8F8E3142500B4: > to=, > relay=mail.somedomain.com[216.70.96.226]:25, delay=1.2, > delays=0.05/0/0.98/0.2, dsn=2.0.0, status=sent (250 ok 1398736227 qp 7475) > Apr 28 22:06:47 mail postfix/smtp[15276]: 2D7D3142500D1: > to=, > relay=mail.somedomain.com[216.70.96.226]:25, delay=0.75, > delays=0.05/0/0.5/0.2, dsn=2.0.0, status=sent (250 ok 1398737207 qp 7660) > Apr 28 22:15:00 mail postfix/smtp[16179]: A56FD142500D8: > to=, > relay=mail.somedomain.com[216.70.96.226]:25, delay=0.57, > delays=0.06/0.01/0.3/0.2, dsn=2.0.0, status=sent (250 ok 1398737700 qp > 7767) This simply demonstrates what you already know--3 messages queued, 3 delivered. You need to locate the smtpd log entries showing the injection point of each of the 3 message IDs, and any alias expansions. You mentioned this only occurs with users who have "email forwarding enabled on their email addresses". Describe precisely how you are performing such forwarding. This is probably the root of the problem. > And just for good measure, here is the header of one of the duplicate > emails: The header won't tell us anything about injection. ... > On 4/28/2014 10:49 PM, Viktor Dukhovni wrote: >> On Mon, Apr 28, 2014 at 10:37:41PM -0400, Andy Yen wrote: >> >>> Is there a setting I can change to fix this? >> Change the setting that enables you to ask questions that non-psychics >> can answer: >> >> http://www.postfix.org/DEBUG_README.html#mail Per the instructions, paste the output of "postconf -n" into your message. This allows us to spot Postfix configuration errors. >> When mail delivered multiple times that will be recorded in your >> logs. You need to identify all log entries pertaining to some >> sample messages that were delivered more than once. >> >> Avoid virtual alias expansion on both sides of a content filter, >> as that can generate a second copy of a forwarding address. >> >> Watch for deliveries that time-out at end of data, Postfix logs >> make a fuss about these: >> >> sending end of data -- message may be sent more >> than once Cheers, Stan
Re: v4bl.org anyone knows this ?
On 4/14/2014 4:01 AM, li...@rhsoft.net wrote: > > Am 14.04.2014 05:20, schrieb Stan Hoeppner: >> Clearly I was responding specifically to 'what is hard about making them >> match', which is why I snipped the rest. If one controls PTR it's easy >> to make all 3 match. When one does not control PTR it is 'hard', in >> fact impossible, to make them all match. >> >> Our friend from Vienna seemed focused on incompetency of admins, while I >> was pointing out that 'incompetency' of some ISPs is a larger problem, >> as in the latter case there is often no option to set the PTR, whether >> one reads the docs or not > > don't get me wrong but that's the same weak excuse as > "i do not spam my customers do" so why blacklist me > > in fact a sane PTR is a prerequisite for relieable mailservices > and if you are at planning a public MTA normally you make sure > the matching PTR and other things before send the first message > > if you are at checking the prerequisites and realize you can't > get a PTR as needed you can't setup the mailserver on that ISP > or need to rent a relay-server - that's part of organize things > and at the end competence of a sysadmin In a perfect world yes, this is how it should work. But we live in an imperfect world, one in which even competent sysadmins are forced to setup outbound MTAs on IPs with generic rDNS, because there are no alternatives. What you fail to understand is that in many parts of the world outside your sphere of knowledge/experience, people's options are limited or non existent, whether services not offered by the provider, lack of competition, budget, administrative or policy constraints, etc, etc. A couple of years ago I started receiving bot spam from multiple IPs in a Southern California Verizon FIOS subnet. I did a little research into the block, polled the rDNS for the /16, and decided it was all residential. I added a regex to match the generic rDNS pattern to fqrdns.pcre and copied it to the upload dir. Within 12 hours I received an angry email from a user whose Postfix MX had blocked mail from his father who worked at a K-12 school. Correspondence with the administrator revealed that Verizon did not offer custom rDNS for FIOS IP addresses. When I asked why he didn't relay through their servers he explained that their fee for "business SMTP relay" was ridiculous given he had no direct delivery problems of any magnitude. I myself have my SOHO SMTP outbound on an IP with generic rDNS, for the same reason as the OP above. In my case the provider is CentruyLink. While I could use their relays I choose not to for the same reason I run a mail server in my home office in the first place: full control of my email. Co-locating a box is not an option for me as the nearest facility is over an hour away. I could rent a VPS, but many VPS provider's IP space is widely blocked due to snowshoe spammer infestations. But why should I spend money on that when I have no delivery issues relating to generic rDNS, and my outbound IP has a Trustworthiness score of HIGH at dnswl.org? You can call myself, the sysop at the SoCal school, and tens of thousands of other OPs doing the same thing, incompetent all you like. Whether RFCs state A/PTR/HELO *MUST* match, or whether *you* say they must match does not make it so, because a large portion of the world isn't paying attention to either of you, and the mail gets delivered. Cheers, Stan
Re: v4bl.org anyone knows this ?
On 4/13/2014 8:38 AM, Robert Schetterer wrote: > Am 13.04.2014 10:34, schrieb Stan Hoeppner: >> On 4/12/2014 3:03 PM, li...@rhsoft.net wrote: >> >>> but on the other what is that hard to have HELO/PTR/A matching? >> >> This has been asked and answered multiple times on this list. The short >> answer is that customers of some ISPs do not have control of rDNS. For >> a more thorough discussion of this topic please see the list archives. >> >> Cheers, >> >> Stan >> > > Hi Stan it was not about ptr matching A Record , it was about matching > helo to ptr/A, i.e. A/ptr = mail.example.com but helo = smtp.example.com > and it was about ,this was classified by some hosting provider ( using > v4bl.org RBL helo mismatch results ) , as a customer "ban warning" which > is simply nonsense, but for sure it is best to have all parameters > matching ( dont kown why this is/was/cannot be done in this case ) Clearly I was responding specifically to 'what is hard about making them match', which is why I snipped the rest. If one controls PTR it's easy to make all 3 match. When one does not control PTR it is 'hard', in fact impossible, to make them all match. Our friend from Vienna seemed focused on incompetency of admins, while I was pointing out that 'incompetency' of some ISPs is a larger problem, as in the latter case there is often no option to set the PTR, whether one reads the docs or not. Cheers, Stan
Re: v4bl.org anyone knows this ?
On 4/12/2014 3:03 PM, li...@rhsoft.net wrote: > but on the other what is that hard to have HELO/PTR/A matching? This has been asked and answered multiple times on this list. The short answer is that customers of some ISPs do not have control of rDNS. For a more thorough discussion of this topic please see the list archives. Cheers, Stan
Re: Is anyone else having name service errors with barracudacentral.org?
On 3/26/2014 10:46 AM, Viktor Dukhovni wrote: > On Wed, Mar 26, 2014 at 08:57:54AM -0500, deoren wrote: > >> On March 21st I noticed these entries in my mail log and I'm not able to >> pinpoint the source of the trouble: >> >> warning: x.x.x.x.b.barracudacentral.org: RBL lookup error: Host or domain >> name not found. Name service error for name=x.x.x.x.b.barracudacentral.org >> type=A: Host not found, try again > > Your nameserver logs from that time may shed more light on the reason, > but RBLs are sometimes unavailable due to DDoS, and routing problems can > happen due to bad BGP data, ... that was then and this is now. The > fact that it works now just means that the transient problem is gone. > >> Is there anything obvious I can check? > > log entries from your recursive resolver on whichever machine it > resides on (ideally local to the MTA host). Note these are common with BRBL. I got a few the very day I added it to my Postfix config years ago. I show the following recent resolution errors for BRBL, the last three trimmed to save space: Mar 25 15:25:31 greer postfix/smtpd[12892]: warning: 58.0.53.80.b.barracudacentral.org: RBL lookup error: Host or domain name not found. Name service error for name=58.0.53.80.b.barracudacentral.org type=A: Host not found, try again Mar 21 08:05:25 greer postfix/smtpd[28711]: warning: 70.233.116.74.b.barracudacentral.org: RBL lookup error: Host or domain Mar 21 11:07:38 greer postfix/smtpd[29257]: warning: 70.233.116.74.b.barracudacentral.org: RBL lookup error: Host or domain Mar 6 05:19:00 greer postfix/smtpd[26724]: warning: 173.197.89.23.b.barracudacentral.org: RBL lookup error: Host or domain I use powerdns recursor locally on my MX. It is designed for, targeted at, extremely high volume query loads, e.g. ISP environments, thus logging such failures would be useless due to the sheer volume. Think web pages containing multiple broken/dead links, then multiply times millions of page loads per day. Cheers, Stan
Re: Enemieslist, was License question
On 3/4/2014 7:03 AM, Alessandro Vesely wrote:
> On Mon 03/Mar/2014 14:50:07 +0100 Stan Hoeppner wrote:
>> On 2/28/2014 5:16 AM, Alessandro Vesely wrote:
>>> On Thu 27/Feb/2014 15:00:31 +0100 Wietse Venema wrote:
>>>>
>>>> - Write a tool that TRANSFORMS fqrdns.pcre.txt so that it can be
>>>> used by a different mail system. That would immediately make
>>>> fqrdns.pcre.txt useful for a lot more people.
>>>
>>> Hmm... the common ground is looking up RBLs. A quite daunting target.
>>
>> Maybe not. It's already been done, 5+ years ago:
>>
>> http://www.corpit.ru/pipermail/rbldnsd/2009q3/001036.html
>>
>> AFAICT the patch was never accepted into vanilla rbldnsd. However,
>> Enemies List still uses it to this day on their commercial rbldnsd
>> mirrors. The EL implementation does extensive classification and is
>> probably more complex than the generic regex implementation I'd guess
>> you'd be considering. Simply reading the rbldnsd patch linked in the
>> list archive post above may give you a big head start.
>>
>> More information available at:
>> http://enemieslist.com/
>
> Thank you Stan. That patched rbldnsd seems to be easier to
> implement, as it would be enough to transform the data, as Wietse
> said. The old package (.ru link above) contains 59 patterns that may
> correspond to some of the 1523 REJECT patterns in your file[1]. For
> example, they have:
>
>
> BRComAjato_01:[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\.user\.ajato\.com\.br:127.0.0.3:cable
>
> instead of
>
> /^([12]?[0-9]{1,2}\.){4}user\.ajato\.com\.br$/ REJECT Generic -
> Please relay via ISP (ajato.com.br)
>
> Besides a longer invocation path, rbldnsd doesn't seem to handle
> conditionals. So the tradeoff is between ease of implementation and
> efficiency (as usual.)
>
> EL talk of "32K rDNS naming conventions" for their licensed dataset.
It's over 100K now.
> Did you try it?
I've never used it. The last Steven and I spoke about it the Postfix
interface wasn't sufficiently baked. That was a couple of years ago.
>> I don't know if Steven wrote the rbldnsd patch or not but he's the EL
>> lead and project creator. I might be able to get you in touch with him
>> if you hit any serious roadblocks, should you decide to embark on this.
>
> Steven has a more recent open source package[2] written for Sendmail
> in m4, which I didn't dare to look at. I'm writing to EL's
> evaluation address to learn more. (They also market some other
> intriguing mail features.)
TTBOMK the open source packages, Sendmail and qpsmtpd anyway, are the
client code which takes action based on the data returned by the rbldnsd
server. AFAIK the experimental Postfix and Exim versions use a flat
file instead of a DNS query to the rbldnsd server. Steven can tell you
more.
> [1] http://www.hardwarefreak.com/fqrdns.pcre.txt
> [2] https://github.com/schampeo/EnemieslistM4
--
Stan
Re: License question
On 2/28/2014 5:16 AM, Alessandro Vesely wrote: > On Thu 27/Feb/2014 15:00:31 +0100 Wietse Venema wrote: ... >> Besides USING Postfix source code, there are other options: >> >> - Write a tool that TRANSFORMS fqrdns.pcre.txt so that it can be >> used by a different mail system. That would immediately make >> fqrdns.pcre.txt useful for a lot more people. > > Hmm... the common ground is looking up RBLs. A quite daunting target. Maybe not. It's already been done, 5+ years ago: http://www.corpit.ru/pipermail/rbldnsd/2009q3/001036.html AFAICT the patch was never accepted into vanilla rbldnsd. However, Enemies List still uses it to this day on their commercial rbldnsd mirrors. The EL implementation does extensive classification and is probably more complex than the generic regex implementation I'd guess you'd be considering. Simply reading the rbldnsd patch linked in the list archive post above may give you a big head start. More information available at: http://enemieslist.com/ I don't know if Steven wrote the rbldnsd patch or not but he's the EL lead and project creator. I might be able to get you in touch with him if you hit any serious roadblocks, should you decide to embark on this. -- Stan
Re: need help with regexp in header_checks
On 11/14/2013 12:41 AM, Viktor Dukhovni wrote: > On Thu, Nov 14, 2013 at 12:32:45AM -0600, Stan Hoeppner wrote: > >> In recent years CPUs have become so blindingly fast it makes no >> difference. Any excess cycles burned by a non anchored regex were idle >> cycles anyway. There are good arguments for anchoring expressions, but >> saving CPU cycles is simply no longer one of them, not for years now. > > Mere excuse for sloppiness. I find that offensive Viktor. There is a huge difference between arguing a point of fact and arguing a position. Above is an example of the former, and is a correct statement. > Always anchor, then when possible > discard leading "^.*" and trailing ".*$". Yes, for people who have the time and dedication to "do it right", such as ourselves. Others can take shortcuts and get the job done, just as PHP/Perl/Java/etc heretics don't use C. It seemed to me in this case to offer the OP a shortcut. That may have been incorrect. Tar and feather me for that if you like, but do not accuse me of practicing or promoting sloppiness, as that is simply not true. My work speaks for itself. But apparently you've never even looked at it, despite it being mentioned here dozens or hundreds of times over the past few years. You've formed an opinion and are making untrue statements based solely on my few words in this thread. Look at it: http://www.hardwarefreak.com/fqrdns.pcre.txt Do you consider these regexes sloppy? I could remove the anchoring and they would still work in the targeted use case. And the additional CPU burn wouldn't be noticeable, if even measurable. But I started with fully qualified expressions years ago, hence the name of the table, and I've stuck with them, even though I don't really need to. Tell me that's what a sloppy person would do. -- Stan
Re: Postfix Repos
On 11/13/2013 11:16 AM, Steffan A. Cline wrote: > I asked this under a thread but am asking again in its own thread to see > if I get better visibility. > > Does anyone know of any good bleeding edge postfix repos? http://postfix.wl0.org/en/available-packages/ Postfix 2.9 for RHEL 5/6, which also works with CentOS 5/6. -- Stan
Re: need help with regexp in header_checks
On 11/13/2013 9:50 AM, Bill Cole wrote: > On 13 Nov 2013, at 6:39, Stan Hoeppner wrote: >> Also, note that the carat (^) anchor isn't necessary. The header fields >> you're testing for are in the left most position. Thus no reason to >> left anchor your expression. > > There absolutely ARE reasons to anchor RE's in header_checks: > > 1. Performance. In recent years email has developed a sort of header > cancer: new, often proprietary, and often opaque headers that routinely > have logical lengths of hundreds of characters. Not anchoring a header > check to the start of the header when you only want to check a few > specific headers wastes effort scanning for a match anywhere in a > header, potentially taking hundreds of times longer to confirm a non-match In recent years CPUs have become so blindingly fast it makes no difference. Any excess cycles burned by a non anchored regex were idle cycles anyway. There are good arguments for anchoring expressions, but saving CPU cycles is simply no longer one of them, not for years now. I used to make your argument here, but again, it no longer applies. > 2. Matching unanticipated headers. Except for the very few headers with > tightly defined structure (e.g. Date), *ANY* header could potentially > include any string that would match "(To|From|Cc|Reply-To): " starting > somewhere other than the start of the line. e.g. "Subject: I'm naive > enough to think I want to discard all mail with To: admin@ in a header" This is a stronger argument, though I'm not sure how realistic a scenario this is, with the email address in the subject. A better argument would be that without anchoring the expression would also match headers such as X-Original-To: ad...@example.com Delivered-To: ad...@example.com in which case I'd agree he should anchor. I didn't take these into account previously. -- Stan
Re: SPAM through postfix+postscreen
On 11/13/2013 5:38 AM, Wijatmoko U. Prayitno wrote:
> On Wed, 13 Nov 2013 05:52:28 -0500
> Paul C wrote:
>
>> ip and helo name do not match google. I don't use those content filters to
>> know enough to tell you what to do, but that's why the emails are getting
>> in. I'd be interested in hearing the solution to this as well.
>>
> you could try http://www.hardwarefreak.com/fqrdns.pcre rules into your
> postfix main.cf restriction. and see what happen next..
>
> $ cat /etc/postfix/fqrdns.pcre|grep vodacom
> /^vc(-[12]?[0-9]{1,2}){4}\.3g\.vodacom\.co\.za$/REJECT Generic -
> Please relay via ISP (vodacom.co.za)
Except that fully qualified expression doesn't match this vodacom rDNS
pattern. I just added the following expression
/^vc-nat-gp-s(-[0-9]{1,3}){4}\.umts\.vodacom\.co\.za$/ REJECT Generic
- Please relay via ISP (vodacom.co.za)
which matches this pattern, tested it with postmap, and uploaded the new
table.
Cheers.
--
Stan
Re: need help with regexp in header_checks
On 11/13/2013 2:34 AM, naser sonbaty wrote: > Hi, > > I need help with postfix regexp in header_checks. > I want discard all emails(any domain) from admin@ > > I use following: > /^(To|From|Cc|Reply-To): admin@(.*)/DISCARD > > but its not working Tests fine here: $ cat test.regexp /^(To|From|Cc|Reply-To): admin@(.*)/DISCARD $ postmap -q "blah: ad...@abc.com" regexp:./test.regexp $ postmap -q "From: ad...@abc.com" regexp:./test.regexp DISCARD $ postmap -q "To: ad...@abc.com" regexp:./test.regexp DISCARD $ postmap -q "CC: ad...@abc.com" regexp:./test.regexp DISCARD $ postmap -q "Reply-To: ad...@abc.com" regexp:./test.regexp DISCARD If these tests work but header_checks isn't working then you need to execute "postfix reload" to load your new/modified regexp table. Also, note that the carat (^) anchor isn't necessary. The header fields you're testing for are in the left most position. Thus no reason to left anchor your expression. -- Stan
Re: postfix 2.7.1 debian - does not query DNS
On 11/8/2013 4:05 AM, li...@rhsoft.net wrote: > there are only rare situations where a chrooted postfix > makes sense and so they should not making a problematic > default which gains nothing on 999 out of 1000 setups The reason for chrooting Postfix is due to a Debian policy established lng ago, and it is not Postfix specific. IIRC there's a class of services that all get chrooted in Debian, but for the life of me I can't seem to find the policy doc that explains this. So far I can't find it in the Debian Policy Manual http://www.debian.org/doc/debian-policy/ Not sure where it is, but the chroot policy is described somewhere. Debian is pretty good WRT documentation. Good at making it easy to find is another matter... -- Stan
Re: Multiple outgoing smtp servers
On 11/7/2013 7:52 PM, Roman Gelfand wrote: > Wouldn't the server be chosen round robin as opposed to random? This would require too much complex code for what is a simple Postfix operation. Your example is "poor man's round robin". That's the best Postfix can do without serious code changes. But why add such code when others have already solved this problem? I.e. do it in your DNS server, which supports true round robin. > From: Wietse Venema > Sent: 11/7/2013 8:21 PM > To: Postfix users > Cc: postfix users list; u...@porcupine.org > Subject: Re: Multiple outgoing smtp servers > Roman Gelfand: >> I am looking to load balance and distribute outgoing load. >> >> I read that all you need to do is add the following dns entries for >> each postfix box.. >> >> mxr IN A 192.168.1.121 >> mxr IN A 192.168.1.131 >> mxr IN A 192.168.1.141 >> mxr IN A 192.168.1.151 >> mxr IN A 192.168.1.161 >> >> and the following line in main.cf >> >> relayhost = mxr.mydomain.com > > One name that resolves to multiple IP addresses will work. > Postfix will choose IP addresses randomly. > > In this case you don't want to do MX lookups, so you could say: > > relayhost = [mxr.mydomain.com] > > Wietse >
Re: postfix 2.7.1 debian - does not query DNS
On 11/7/2013 5:53 AM, Simon Loewenthal wrote: > Damned chroot now turned off, and lookups now work like they should have > done :D The default Postfix chroot environment in Debian 6 Squeeze works fine out of the box, as did Lenny. You have to go back to Etch or Sarge to find it broken. I'd guess you've modified something in your configuration that broke the chroot. I'm not defending Debian's shipping of Postfix chroot'd, I'm simply stating it works correctly out of the box. It was broken way back in Etch or Sarge (5+ years ago), and Wietse assisted me in troubleshooting such at that time. But it has worked fine in both Lenny and Squeeze, out of the box. > And this nicely solved my RDNS_NONE scoring issue with SA, of course! > > Nov 7 12:49:16 lo postfix/smtpd[15712]: 32FD892: > client=english-breakfast.cloud9.net[168.100.1.7] > Thanks, I did not think that chroot had been turned on by default. > > Dag! > > On 2013-11-07 12:48, wie...@porcupine.org wrote: > >> Simon Loewenthal: >> >>> # service type private unpriv chroot ... # (yes) (yes) (yes) ... # >>> == >>> smtp inet n - - ... >> >> Turn off the damned chroot. >> >> Wietse > >
Re: Handling repeated lost connections (I assume from zombie/spammer)
On 11/6/2013 2:46 AM, Ian Evans wrote: > About three days into my postfix/postgrey experience after migrating from > qmail. Enjoying it. > > Of course, like a new dad, I'm sitting here watching the logs. For the last > two hours I've been getting "postfix/smtpd: lost connection after RSET from > unknown[x.x.x.x]" from the same IP, apparently in Iceland. > > The hits are coming about every 30 seconds. Safe to assume this is a > spambot/zombie? Any steps to slow it down or is it being rejected nicely > and without too much load on the system besides generating a huge log? Zombies try to deliver spam. This looks like SMTP scanner behavior. See: http://www.irongeek.com/i.php?page=backtrack-r1-man-pages/smtpscan You can put a stop to stuff like this with fail2ban. -- Stan
Re: Mail sent FROM me TO me is disappearing
On 11/5/2013 12:15 AM, George Adams wrote: > We're using Postfix 2.1.5 on an old Debian 5 Linux system ... If Postfix 2.1.5 then your Debian install is MUCH older than Lenny (Debian 5). IIRC Lenny shipped w/Postfix 2.5.5 and Etch shipped w/2.3.8. Which means you're running Sarge (3.1) or older. Sarge was released in June 2005, over 8 years ago. You just might want to consider upgrading that box. There have been just a few improvements to both Debian and Postfix in the past 8 years. > Mail from m...@companya.com to m...@companya.com: DISAPPEARS ... > Nov 4 17:35:48 www postfix/smtpd[10453]: > warning: smtpd_peer_init: 107.14.166.225: > hostname cdptpa-outbound-snat.email.rr.com verification > failed: Name or service not known These are warnings, not REJECTs. This hostname resolves to more than two dozen addresses. This is the cause of the warning, as Postfix does not traverse this entire list looking for a match, at least 2.1.5 does not, not sure about recent versions. You really need to upgrade, both Debian and Postfix. ~$ host cdptpa-outbound-snat.email.rr.com ;; Truncated, retrying in TCP mode. cdptpa-outbound-snat.email.rr.com has address 107.14.166.253 cdptpa-outbound-snat.email.rr.com has address 107.14.166.252 cdptpa-outbound-snat.email.rr.com has address 107.14.166.254 cdptpa-outbound-snat.email.rr.com has address 107.14.166.238 cdptpa-outbound-snat.email.rr.com has address 107.14.166.237 cdptpa-outbound-snat.email.rr.com has address 107.14.166.243 cdptpa-outbound-snat.email.rr.com has address 107.14.166.251 cdptpa-outbound-snat.email.rr.com has address 107.14.166.248 cdptpa-outbound-snat.email.rr.com has address 107.14.166.234 cdptpa-outbound-snat.email.rr.com has address 107.14.166.246 cdptpa-outbound-snat.email.rr.com has address 107.14.166.244 cdptpa-outbound-snat.email.rr.com has address 107.14.166.229 cdptpa-outbound-snat.email.rr.com has address 107.14.166.233 cdptpa-outbound-snat.email.rr.com has address 107.14.166.227 cdptpa-outbound-snat.email.rr.com has address 107.14.166.235 cdptpa-outbound-snat.email.rr.com has address 107.14.166.239 cdptpa-outbound-snat.email.rr.com has address 107.14.166.250 cdptpa-outbound-snat.email.rr.com has address 107.14.166.242 cdptpa-outbound-snat.email.rr.com has address 107.14.166.249 cdptpa-outbound-snat.email.rr.com has address 107.14.166.232 cdptpa-outbound-snat.email.rr.com has address 107.14.166.247 cdptpa-outbound-snat.email.rr.com has address 107.14.166.245 cdptpa-outbound-snat.email.rr.com has address 107.14.166.231 cdptpa-outbound-snat.email.rr.com has address 107.14.166.226 cdptpa-outbound-snat.email.rr.com has address 107.14.166.241 cdptpa-outbound-snat.email.rr.com has address 107.14.166.230 cdptpa-outbound-snat.email.rr.com has address 107.14.166.240 cdptpa-outbound-snat.email.rr.com has address 107.14.166.225 cdptpa-outbound-snat.email.rr.com has address 107.14.166.236 cdptpa-outbound-snat.email.rr.com has address 107.14.166.228 To see if you're actually rejecting these, search for rejections, i.e.: ~$ grep 107.14.166.225 /var/log/[your_mail_log]|grep reject -- Stan
Re: Postfix+pflogsumm+clamav = email blocked
On 11/4/2013 3:54 PM, Noel Jones wrote: > On 11/4/2013 1:42 PM, inteq wrote: >> Hello >> >> For some time now I was wondering why some of my pflogsumm emails were not >> received. >> Digging deeper into the problem today, I can see the emails are being >> blocked by Postfix because it "contains" a virus. >> >> Nov 4 21:36:52 ns4 postfix/smtp[9383]: 338E14303B: to=, >> relay=127.0.0.1[127.0.0.1]:10025, delay=0.14, delays=0.06/0/0.05/0.03, >> dsn=2.0.0, status=sent (250 Virus Detected; Discarded Email) >> Nov 4 21:36:52 ns4 clamsmtpd: 100013: from=r...@ns4.example.com, >> to=t...@example.com, status=VIRUS:Sanesecurity.Jurlbl.3425.UNOFFICIAL >> Nov 4 21:36:52 ns4 postfix/qmgr[4676]: 338E14303B: removed >> >> I have the latest version (beta) 1.1.5 of pflogsumm and I have tried >> everything I could find to make Postfix "play nice" and allow my log to be >> delivered. >> I am using additional ClamAV signatures, indeed. >> >> Any hints how to whitelist emails sent from r...@ns4.example.com, or bypass >> somehow the virus checks for some addresses? > > > Looks as if you're using the clamsmtp proxy. Arrange for you > pflogsumm reports to be submitted to the postfix reinjection port > after clamsmtp. > > One fairly tool to do this is with the simple mini_sendmail program. You should contact the author of Sanesecurity.Jurlbl.3425.UNOFFICIAL This script is not just badly written, but horribly broken. pflogsumm email output is a text only file, no binary attachment, so it obviously can't contain a virus payload. So this script is clearly matching hostnames and/or domains in the content section of the email, known to host viri/malware, and rejecting the email based solely on this, with a reason of "VIRUS". This concept, and the reason code, is simply wrong headed. If you say you're rejecting the email because it contains a VIRUS it better well have a binary attachment that contains a virus. Simply matching suspect domains should add score to a spam filter, not outright reject an email, and especially not with a reason code of "VIRUS". I don't use any of the CLAM software, but I'd guess "UNOFFICIAL" actually means something. Thus you can probably fix this by simply not using UNOFFICIAL Sanesecurity signatures. -- Stan
Re: Best practices for smtpd restrictions.
On 10/31/2013 12:19 PM, John Allen wrote:
> Which is "better", to put the various restrictions with the appropriate
> smtpd__restriction stanzas, or to put them all into the
> smtpd_recipient_restrictions stanza. I am assuming that
> smtpd_delay_reject is yes.
>
> I have always assumed that putting them in one place had the advantage
> of allowing me to order the various restrictions as I wanted.
Use the EURR method - Everything Under Recipient Restrictions
for the reasons you state. Anything more than trivial whitelisting is a
PITA with the other method.
> postconf_output.txt
>
>
> alias_maps = hash:/etc/aliases
> append_dot_mydomain = no
> biff = no
> bounce_size_limit = 65536
> broken_sasl_auth_clients = yes
> config_directory = /etc/postfix
> content_filter = smtp-amavis:[127.0.0.1]:10024
> default_process_limit = 20
> delay_warning_time = 12h
> disable_vrfy_command = yes
> header_size_limit = 32768
> home_mailbox = Maildir/
> html_directory = /usr/share/doc/postfix/html
> mailbox_transport = lmtp:unix:private/dovecot-lmtp
> message_size_limit = 3276800
> mydestination = localhost, localhost.localdomain, localdomain
> mydomain = klam.ca
> myhostname = smtp.$mydomain
> mynetworks = 127.0.0.0/8, 192.168.0.0/16, [::1]/128, [2001:470:b183:30::]/64
> myorigin = $mydomain
> readme_directory = /usr/share/doc/postfix
> recipient_delimiter = +
> relocated_maps = hash:/etc/postfix/maps/relocated
> smtp_sasl_security_options = noanonymous
> smtp_sasl_tls_security_options = noanonymous
> smtp_tls_cert_file = /root/ssl/certs/KLaM_Mail.pem
> smtp_tls_enforce_peername = no
> smtp_tls_key_file = /root/ssl/private/KLaM_Mail.key
> smtp_tls_note_starttls_offer = yes
> smtp_tls_security_level = may
> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
> smtp_use_tls = yes
> smtpd_banner = $myhostname ESMTP
> smtpd_client_restrictions =
> smtpd_data_restrictions = reject_multi_recipient_bounce,
> reject_unauth_pipelining
> smtpd_error_sleep_time = 5s
> smtpd_etrn_restrictions = reject
> smtpd_helo_required = yes
> smtpd_helo_restrictions =
> smtpd_recipient_limit = 128
> smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated,
> reject_unauth_destination, reject_invalid_hostname,
> reject_non_fqdn_hostname, reject_non_fqdn_sender,
> reject_non_fqdn_recipient,
> reject_unknown_sender_domain, reject_unknown_recipient_domain,
> check_sender_access hash:/etc/postfix/maps/sender_checks,
> check_recipient_access pcre:/etc/postfix/maps/recipient_checks.pcre,
> check_recipient_access hash:/etc/postfix/maps/recipient_checks,
> check_helo_access pcre:/etc/postfix/maps/helo_checks.pcre,
> reject_rbl_client
> zen.spamhaus.org, reject_rbl_client bl.spamcop.net, check_policy_service
> inet:127.0.0.1:10023
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_authenticated_header = yes
> smtpd_sasl_local_domain = $mydomain
> smtpd_sasl_path = private/dovecot-auth
> smtpd_sasl_security_options = noanonymous
> smtpd_sasl_type = dovecot
> smtpd_sender_restrictions =
> smtpd_tls_ask_ccert = yes
> smtpd_tls_auth_only = yes
> smtpd_tls_cert_file = /root/ssl/certs/KLaM_Mail.pem
> smtpd_tls_key_file = /root/ssl/private/KLaM_Mail.key
> smtpd_tls_mandatory_ciphers = medium
> smtpd_tls_mandatory_protocols = SSLv3, TLSv1
> smtpd_tls_received_header = yes
> smtpd_tls_req_ccert = no
> smtpd_tls_security_level = may
> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
> smtpd_tls_session_cache_timeout = 3600s
> smtpd_use_tls = yes
> strict_rfc821_envelopes = yes
> virtual_alias_maps = pgsql:/etc/postfix/sql/valiases.sql
> virtual_mailbox_domains = pgsql:/etc/postfix/sql/vdomains.sql
> virtual_mailbox_maps = pgsql:/etc/postfix/sql/vmailbox.sql
> virtual_transport = lmtp:unix:private/dovecot-lmtp
>
Re: Save mails into custom DB
On 10/20/2013 3:28 AM, Wijatmoko U. Prayitno wrote: > On Sun, 20 Oct 2013 06:50:07 +0300 > Merve Temizer wrote: > >> What is the most appropriate way to save mails into a >> database that i built before. I mean, i have a custom > > Use dbmail (www.dbmail.org).. dbmail isn't appropriate here despite the fact it uses a database for storing messages. It uses its own non-configurable database format AFAIK. The OP will likely need to write a custom mail delivery agent that accepts the msg from Postfix via pipe(8) and then speaks SQL to the database engine in order to populate the fields. -- Stan
Re: mxbackup quote
On 10/18/2013 3:17 PM, Dominik George wrote: > Patrick Ben Koetter schrieb: >> As a basic principle: Postfix routes and filters message transport, but >> it >> doesn't deal with the details of mailbox management etc. > Huh? > > http://www.postfix.org/postconf.5.html#mailbox_size_limit Surely you noticed the coarseness here. It only acts as a mailbox quota with mbox. With maildir it is enforced per file, not per mailbox. Maildirs contain many files. So when Patrick says 'As a basic principal, Postfix doesn't deal with the details of mailbox management' he is correct. What Postfix provides is a basic limit on mail file sizes. Real quota management is always configured and enforced at the filesystem level because, after all, quotas are about managing storage consumption. Errors due to quota violations propagate from the filesystem to the MDA, then to the MTA. Every MDA/MTA should be able to return the filesystem error message, or equivalent, to the sender. > Although, in the case of this thread, asking over at dovecot/cyrus/whatever > MDA the OP is using might seem more appropriate. Actually, the OP should be directed to his filesystem documentation. If his filesystem doesn't feature quota accounting, then he should switch to one that does. UNIX filesystems have offered quota support, and most accounting features, for a very long time as UNIX has always been a multi-user operating system. And Postfix is, after all, UNIX software. -- Stan
Re: local_recipient_maps set up, yet postfix continues to send bounce messages
On 10/15/2013 7:31 AM, Stan Hoeppner wrote: This should have read: /etc/postfix/shield_acct_names mrwh...@breakingbad.com REJECT unknown user jes...@breakingbad.com REJECT unknown user g...@breakingbad.comREJECT unknown user -- Stan
Re: local_recipient_maps set up, yet postfix continues to send bounce messages
On 10/15/2013 4:02 AM, Chad Elliott wrote: >> Make sure you understand address classes. > > We are not a virtual mailbox domain, we are a virtual alias domain > because we use UNIX accounts for the few mailboxes we have, ... Noel is correct. You're broken. And you are using virtual_mailbox_domains. Look at your "postconf -n": ... virtual_alias_maps = hash:/etc/postfix/virtual virtual_mailbox_base = /var/spool/mail virtual_mailbox_domains = hash:/etc/postfix/mydomains If I understand you correctly, you simply want additional aliases for your users, correct? To do that you use a *standard Postfix config* and simply add a virtual_alias_maps file. The left side are the virtual aliases. The right side are the UNIX account addresses (though they can be any valid email address): /etc/postfix/virtual walter_wh...@breakingbad.commrwh...@breakingbad.com jessie_pink...@breakingbad.com jes...@breakingbad.com gustavo_fr...@breakingbad.com g...@breakingbad.com That's it. It's that simple. Now, if you don't want to accept SMTP mail to the UNIX acct addresses, only the virtual aliases, simply put them in an access(5) table and have the following, in this order, in smtpd_recipient_restrictions ... check_recipient_access hash:/etc/postfix/shield_acct_names reject_unlisted_recipient ... /etc/postfix/shield_acct_names mrwh...@breakingbad.com jes...@breakingbad.com g...@breakingbad.com As long as your check is before virtual alias expansion this should work. Postfix should reject any mail to UNIX addresses, and any addresses not in /etc/aliases or /etc/postfix/virtual I've been using the first half of this setup for years so I know it works. I've not tested the 'UNIX address shielding', but it should work as well. -- Stan
Re: Google rejecting IPv6 mails
On 10/13/2013 1:12 PM, Dominik George wrote: > On Sun, Oct 13, 2013 at 01:09:52PM -0500, Stan Hoeppner wrote: >> On 10/13/2013 8:35 AM, Dominik George wrote: >>>>> It was posted to the list, so you will have received it, and any >>>>> reasonable MUA can search for it. Giving publlicm essage IDs is a >>>>> perfectly valid way of pointing to a message on a list. >>>> >>>> The string 'Pine.BSM.4.64L.1310010843490.20824' does not appear in my >>>> postfix-users@postfix.org folder, nor does that string appear in >>>> my postfix-users@postfix.org bounces folder. >>> >>> Yes. I asked the author, and it was bounced by your mailman because the >>> author is not a list member. Apparently, you haven't moderated it. >> >> If it has salient content, post the HTTP URL. > > http://blog.gmane.org/gmane.os.miros.general/month=20131001 WRT the first point in the blog post, Thorsten is incorrect. Google does publish lists of their outbound IPs via their SPF records. ~$ dig txt _netblocks.google.com _netblocks2.google.com You may want to pass this along. -- Stan
Re: Google rejecting IPv6 mails
On 10/13/2013 8:35 AM, Dominik George wrote: >>> It was posted to the list, so you will have received it, and any >>> reasonable MUA can search for it. Giving publlicm essage IDs is a >>> perfectly valid way of pointing to a message on a list. >> >> The string 'Pine.BSM.4.64L.1310010843490.20824' does not appear in my >> postfix-users@postfix.org folder, nor does that string appear in >> my postfix-users@postfix.org bounces folder. > > Yes. I asked the author, and it was bounced by your mailman because the > author is not a list member. Apparently, you haven't moderated it. If it has salient content, post the HTTP URL. -- Stan
Re: Google rejecting IPv6 mails
On 10/13/2013 7:43 AM, Dominik George wrote: >>> Just read . > It was posted to the list, so you will have received it, and any > reasonable MUA can search for it. Then Thunderbird is not a "reasonable MUA", even though it's the 2nd or 3rd most widely used... > Giving publlicm essage IDs is a > perfectly valid way of pointing to a message on a list. You must live on another planet, or in some parallel universe, because this is not a valid way of referencing the location of an archived list post. FWIW, Googling for the string pine.bsm.4.64l.1310010843490.20...@herc.mirbsd.org turns up zero results. Hitting http://herc.mirbsd.org/ in a web browser provides no link to search a list archive, nor even suggests it hosts a mailing list. -- Stan
Re: master.cf listed in dbl.spamhaus.org
On 10/10/2013 2:17 PM, John Levine wrote: >> I suspect either it's just a mistake, or stuff that actually used that >> domain in a URL (as opposed to just a random string in a message)q has >> been really spammy. > > I asked. There really is a domain master.cf, > and it really is used > in URLs in a lot of spam. I established this earlier. Your generous use of scissors in your reply to that message suggests you didn't read it. Here it is again. On 10/10/2013 5:06 AM, Stan Hoeppner wrote:... > ~$ whois master.cf > This TLD has no whois server. > > http://en.wikipedia.org/wiki/.cf > Central African Republic > > ~$ host master.cf > master.cf has address 62.116.181.25 > master.cf mail is handled by 0 FALLBACKMX.SPAMEXPERTS.EU. > master.cf mail is handled by 0 LASTMX.SPAMEXPERTS.NET. > master.cf mail is handled by 0 MX.SPAMEXPERTS.COM. This ccTLD is a central African country with almost non-existent internet infrastructure. The TLD has no whois server for Pete's sake. The domain in question, master.cf, is tied to hosts in German IPv4 space. Clearly the domain was registered for the purpose of sending spam or other criminal activity. It is also abundantly clear that this spammer was banking on Postfix' "master.cf" receiving good will in content filters, etc, which was the whole point of registering this domain. He was obviously wrong. Due to this overwhelming evidence I didn't find it necessary to bother any of my Spamhaus contacts for "confirmation". > Solution: don't look up strings in the DBL that aren't host names in > URLs. No, the solution is to not apply a larger than default score to dbl hits in SA. The OP in this case clearly stated he had: "Unfortunately I always found the DBL check quite reliable and I increased it weight over the default..." You're starting to slip in your "old age" John. ;) Focus on writing RFCs, your mayoral duties, etc, and leave the trenches to the rest of us. ;) (tongue obviously buried heavily in cheek) -- Stan
Re: master.cf listed in dbl.spamhaus.org
On 10/10/2013 4:30 AM, lst_ho...@kwsoft.de wrote: > > Zitat von Daniele Nicolodi : > >> Hello, >> >> recently I've see some emails from the postfix mailing list being marked >> as possible spam by Spamassassin. Investigating which rule caused the >> problem I found that dbl.spamhaus.org started to list master.cf as a >> "bad" hostname. Mails directed to the postfix list of course contain >> the string "master.cf" quite often. Unfortunately I always found the >> DBL check quite reliable and I increased it weight over the default... >> >> I guess there is not much we can do about it, but I found it funny. >> >> Cheers, >> Daniele > > Content inspection is evil by-design and doomed to fail. This is just > another example. I tend to agree. SA has a poor FP track record here. If you wish to lodge complaint(s): ~$ host master.cf.dbl.spamhaus.org master.cf.dbl.spamhaus.org has address 127.0.1.2 "The DBL is managed as a "zero false-positive" list, safe to use by production mail systems to reject emails that are flagged by it." http://www.spamhaus.org/dbl/ ~$ whois master.cf This TLD has no whois server. http://en.wikipedia.org/wiki/.cf Central African Republic ~$ host master.cf master.cf has address 62.116.181.25 master.cf mail is handled by 0 FALLBACKMX.SPAMEXPERTS.EU. master.cf mail is handled by 0 LASTMX.SPAMEXPERTS.NET. master.cf mail is handled by 0 MX.SPAMEXPERTS.COM. ~$ whois 62.116.181.25 ... % Abuse contact for '62.116.181.16 - 62.116.181.31' is 'ab...@internetx.com' ... inetnum:62.116.181.16 - 62.116.181.31 netname:TEAMINTERNET-NET descr: Team Internet GmbH descr: Lindwurmstrasse 25 descr: 80331 Muenchen descr: Germany country:DE ... -- Stan
Re: Temporarily block domain.tld from sending?
On 10/8/2013 7:15 PM, li...@sbt.net.au wrote: > On Wed, October 9, 2013 10:41 am, Stan Hoeppner wrote: >> On 10/8/2013 3:08 PM, li...@sbt.net.au wrote: > > Stan, Michael and other who responded, thanks > >> Others responded with some good ideas here, mostly locking down PHP >> itself so it can't use the sendmail binary. But it sounds like this is a >> generic web hosting server for your customers. Which means they may be >> using all manner of languages other than PHP, such as Perl, Java, etc. > > modified php.ini as per Micheal's suggestion; > yes, it is as you suggest, 'all manner..'; > >> In this case, the most thorough way to lock this down, other than >> disabling the pickup service in master.cf, is to restrict execute >> permissions on the sendmail binary to root. This prevents all web >> applications from using the pickup service. Then instruct all of your >> users to use the submission service on TCP 587 for sending mail. >> Disabling pickup is the easiest and quickest way to stop this spamming >> permanently. But it will likely break management functions that need to >> send mail via pickup, such as logwatch, pflogsumm, etc. Thus restricting >> which users can execute the sendmail binary is a better solution. > > I'll work towards that later today > > I'm still perplexed with access: the user claims no one else had ftp Look at every file in this user's publicly accessible directory tree. You may find that s/he saved the username/password in a text file (regardless of file extension, or name), which is quite common for many users, especially those who don't update the site but once every few weeks, months, etc. They bookmark the URL and "remember" the credentials this way when they need to work on the site. Crackers will often find such files, even if not exposed anywhere in the HTML content of the site. > password, ftp password was a random 8-char alpha/numeric string, > can there be any other reason that leaked password...? There are all manner of ways credentials can fall into the wrong hands. Above is only one. The simplest is the Post-it note, both literally and metaphorically. You can't control this. What you can is the password itself, and the frequency of change. Random passwords are meaningless if someone can simply copy or steal the Post-it. Changing passwords regularly helps mitigate this problem, but not if users simply put the new password in an accessible file, as in the scenario above. -- Stan
Re: Temporarily block domain.tld from sending?
On 10/8/2013 3:08 PM, li...@sbt.net.au wrote: > On Tue, October 8, 2013 4:44 pm, Stan Hoeppner wrote: ... >> Understood. For a more permanent solution to this script problem, you >> may want to consider locking down or disabling the pickup service, and >> configuring all web applications and MUAs to use the submission service >> with auth. This will prevent such scripts from being able to send mail in >> the event some crafty soul is able to get one uploaded via something other >> than FTP. > > how do I lock it or disable ? > there are several Joomla CMSs, I'll check and see about changing to > 587/smtp-auth Others responded with some good ideas here, mostly locking down PHP itself so it can't use the sendmail binary. But it sounds like this is a generic web hosting server for your customers. Which means they may be using all manner of languages other than PHP, such as Perl, Java, etc. In this case, the most thorough way to lock this down, other than disabling the pickup service in master.cf, is to restrict execute permissions on the sendmail binary to root. This prevents all web applications from using the pickup service. Then instruct all of your users to use the submission service on TCP 587 for sending mail. Disabling pickup is the easiest and quickest way to stop this spamming permanently. But it will likely break management functions that need to send mail via pickup, such as logwatch, pflogsumm, etc. Thus restricting which users can execute the sendmail binary is a better solution. -- Stan
Re: Temporarily block domain.tld from sending?
On 10/7/2013 11:19 PM, li...@sbt.net.au wrote: > On Tue, October 8, 2013 3:02 pm, Stan Hoeppner wrote: >> On 10/7/2013 9:10 PM, li...@sbt.net.au wrote: > >> Without the log entries Simon asked for we can't do anything more to >> help you, as we don't know how the spam is being injected. Please provide >> logging that demonstrates the problem. > > Stan, thanks, > > sorry, I thought that part was sufficient in my message: > >> there is a php script on their web as so, I'm trying to see how it was >> uploaded at this point: >> >> - >> head xmlrpcVZY.php > > there was a php script uploaded and called > > Oct 7 23:53:07 postfix/pickup[27638]: DA64B3829CE: uid=48 > from= > Oct 7 23:53:07 postfix/qmgr[10092]: DA64B3829CE: > from=, size=891, nrcpt=1 (queue active) > > ... > Oct 7 23:53:07 geko postfix/pickup[27638]: DA64B3829CE: uid=48 > from= > > 216.187.94.181 - - [08/Oct/2013:15:07:17 +1100] "POST /xmlrpcVZY.php > HTTP/1.1" 404 211 "-" "-" > > - > > I've removed the script, I stopped ftp (it seems it was ftp'd) > > at the time I've posted, I was on a 4" mobile, and, I was looking for a > stop gap measure to 'stop further damage' from that point Understood. For a more permanent solution to this script problem, you may want to consider locking down or disabling the pickup service, and configuring all web applications and MUAs to use the submission service with auth. This will prevent such scripts from being able to send mail in the event some crafty soul is able to get one uploaded via something other than FTP. -- Stan
Re: Temporarily block domain.tld from sending?
On 10/7/2013 9:10 PM, li...@sbt.net.au wrote:
> On Tue, October 8, 2013 11:31 am, Simon B wrote:
>> On 8 Oct 2013 01:54, "Voytek" wrote:
>
>> spam from many.na...@adomain.tld, how best to prevent any outbound mails
>> from adomain.tld till I can look at this?
>
>> Postfix stop
>>
>>
>> Then post your postconf -n and a log snippet of an outgoing span press.
>
> Simon, thanks
Without the log entries Simon asked for we can't do anything more to
help you, as we don't know how the spam is being injected. Please
provide logging that demonstrates the problem.
>
> # postconf -n
> address_verify_sender = $double_bounce_sender
> alias_database = hash:/etc/aliases
> alias_maps = hash:/etc/aliases
> anvil_rate_time_unit = 1800s
> body_checks = pcre:/etc/postfix/body_checks
> body_checks_size_limit = 15
> broken_sasl_auth_clients = yes
> command_directory = /usr/sbin
> config_directory = /etc/postfix
> content_filter = smtp-amavis:[127.0.0.1]:10024
> daemon_directory = /usr/libexec/postfix
> debug_peer_level = 2
> disable_vrfy_command = yes
> header_checks = pcre:/etc/postfix/header_checks
> home_mailbox = Maildir/
> html_directory = /usr/share/doc/postfix-2.4.5-documentation/html
> local_recipient_maps = unix:passwd.byname $alias_maps
> local_transport = local
> mail_owner = postfix
> mailq_path = /usr/bin/mailq.postfix
> manpage_directory = /usr/share/man
> message_size_limit = 1536
> mime_header_checks = pcre:$config_directory/mime_headers.pcre
> mydestination = $myhostname, localhost.$mydomain
> myhostname = server.tld
> mynetworks = 111.222.333.444 222.333.444.555 127.0.0.1
> myorigin = $mydomain
> newaliases_path = /usr/bin/newaliases.postfix
> queue_directory = /var/spool/postfix
> readme_directory = /usr/share/doc/postfix-2.4.5-documentation/readme
> recipient_bcc_maps = hash:/etc/postfix/bcc_r_maps
> recipient_delimiter = +
> sample_directory = /etc/postfix/samples
> sender_bcc_maps = hash:/etc/postfix/bcc_s_maps
> sendmail_path = /usr/sbin/sendmail.postfix
> setgid_group = postdrop
> smtp_tls_cert_file = $smtpd_tls_cert_file
> smtp_tls_key_file = $smtpd_tls_key_file
> smtp_tls_loglevel = 1
> smtp_tls_note_starttls_offer = yes
> smtp_tls_security_level = may
> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
> smtp_tls_session_cache_timeout = 3600s
> smtpd_client_connection_rate_limit = 50
> smtpd_data_restrictions = reject_unauth_pipelining, permit
> smtpd_helo_required = yes
> smtpd_helo_restrictions = permit_mynetworks,permit_sasl_authenticated,
>check_helo_access ${RE}helo.re
> smtpd_recipient_restrictions = permit_sasl_authenticated,
> permit_mynetworks, reject_unauth_destination, check_recipient_access
> hash:/etc/postfix/recipient_no_checks, reject_non_fqdn_sender,
> reject_non_fqdn_recipient, reject_invalid_helo_hostname,
> reject_non_fqdn_helo_hostname, reject_unknown_sender_domain,
> reject_unknown_reverse_client_hostname, reject_unlisted_recipient,
> check_sender_access hash:/etc/postfix/freemail_access,
> check_recipient_access pcre:/etc/postfix/recipient_checks.pcre,
> check_helo_access hash:/etc/postfix/helo_checks, check_sender_access
> hash:/etc/postfix/sender_checks, check_client_access
> hash:/etc/postfix/client_checks, check_client_access
> pcre:/etc/postfix/client_checks.pcre, reject_rbl_client zen.spamhaus.org,
> reject_rhsbl_client dbl.spamhaus.org, reject_rhsbl_sender
> dbl.spamhaus.org, reject_rbl_client psbl.surriel.com, reject_rbl_client
> bl.spamcop.net, reject_rhsbl_sender dsn.rfc-ignorant.org,
> check_policy_service inet:127.0.0.1:10031, permit
> smtpd_restriction_classes = from_freemail_host
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_authenticated_header = yes
> smtpd_sasl_local_domain =
> smtpd_sasl_path = private/auth
> smtpd_sasl_security_options = noanonymous
> smtpd_sasl_type = dovecot
> smtpd_tls_auth_only = yes
> smtpd_tls_cert_file = /etc/pki/tls/certs/server.crt
> smtpd_tls_key_file = /etc/pki/tls/certs/server.key
> smtpd_tls_loglevel = 1
> smtpd_tls_received_header = yes
> smtpd_tls_security_level = may
> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
> smtpd_tls_session_cache_timeout = 36000s
> strict_rfc821_envelopes = yes
> tls_random_source = dev:/dev/urandom
> transport_maps = hash:/etc/postfix/transport
> unknown_local_recipient_reject_code = 550
> virtual_alias_maps = proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf
> virtual_gid_maps = static:5000
> virtual_mailbox_base = /var/mail/vhosts
> virtual_mailbox_domains =
> proxy:mysql:/etc/postfix/mysql_virtual_domains_maps.cf
> virtual_mailbox_limit = $message_size_limit
> virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
> virtual_minimum_uid = 5000
> virtual_transport = lmtp:unix:private/dovecot-lmtp
> virtual_uid_maps = static:5000
>
>
>
> there is a php script on their web as so, I'm trying to see how it was
> uploaded at this point:
>
> -
> head
Re: Google rejecting IPv6 mails
On 10/7/2013 12:25 PM, Jim Reid wrote: > On 7 Oct 2013, at 18:15, Erwan David wrote: > >> Google is really rejecting emails in IPv6 because of a lack of PTR... > > If that's the case, good. Just do The Right Thing and arrange a valid PTR for > the IPv6 address that speaks SMTP. This should be simpler and less hassle > than changing the postfix config. Or adding more workaround to that when > someone finds yet more mail providers who reject connections from addresses > with no reverse DNS. > > SMTP from an address with no reverse DNS is a fairly good indicator of a spam > source. YMMV. Agreed. Postfix' reject_unknown_reverse_client_hostname is functionally equivalent to what Google is doing here. And I'd guess everyone here enables this restriction. And if not, they should. Hmm...that makes me wonder... Since Postscreen stops bots without checking for existence of PTR, I'm wondering if many folks have simply eliminated this restriction in main.cf, and thus forgotten how critical PTR is as a first level of trust evaluation of inbound SMTP connections. Yesterday reject_unknown_reverse_client_hostname accounted for 45% of rejected spam attempts here. I do not use Postscreen. And neither does Google, and their MTA is self baked. -- Stan
Re: repairing queued messages with invalid content filter field
On 10/6/2013 1:46 AM, m...@jama.is wrote: > Hi all, > > I tried to install spamassassin as a postfix content filter. It did not work > well, so I deactivated it. I am now having a couple of undelivered messages > pending in DEFERRED which have in the header "contentfilter: spamfilter" set. > postcat shows me: > > *** ENVELOPE RECORDS 151CB1180A42 *** > message_size:5881 693 1 0 > > 5881 > message_arrival_time: Sat Oct 5 21:08:46 2013 > create_time: Sat Oct 5 21:08:46 2013 > content_filter: spamfilter > named_attribute: log_ident=151CB1180A42 > named_attribute: rewrite_context=remote > [...] > *** HEADER EXTRACTED 151CB1180A42 *** > *** MESSAGE FILE END 151CB1180A42 *** > > Is there a way to repair these messages so they can be delivered? How can I > remove the "content_filter: spamfilter" attribute from the spooled messages? Reenable Spamassassin, flush the queue, confirm the messages were delivered. Then put all mail on HOLD. Stop/disable Spamassassin, make master.cf etc changes so Postfix doesn't try to pipe to SA, then restart Postfix. Then release the messages from the hold queue. This should prevent the defer problem from happening a 2nd time. -- Stan
Re: limit and monitor too many sasl login from same user
On 10/4/2013 2:29 AM, nik600 wrote: > Virus, botnet and user's bad policies about password allows many 3rd party > entities to stole passwords, in the last month i've experienced a grows of > hacked users, and in some case many spam messages are sent from my servers > before i can block the user. > > I've tried many combination > > smtpd_client_message_rate_limit > smtpd_client_recipient_rate_limit > anvil_rate_time_unit > > config options but as the sender changes frequently the client, sending > from different locations, so the limits above has no effect and i can't > stop the spammer. > > Does exists any configuration to limit the # of sasl login from an user? > > It could be very useful, and cloud be also useful monitor many login of the > same sasl user from different ip. > > What do you thing about that? Have you considered sending your users a monthly reminder explaining the dangers of phishing attacks, that no legit entity will ever ask for their login credentials, etc? Trying to address the problem with strictly technical means at the server is a losing endeavor. The problem begins on the users' end, and must be fixed on the users' end. You simply need to give users the tools and education to fix it, or in this case, avoid it. -- Stan
Re: Do not forward spam
Hello Azur, On 9/20/2013 12:45 PM, DTNX Postmaster wrote: > Has it occurred to you that the reason lots of your users enable > forwarding to Gmail may be the fact that you accept everything? And > that they are essentially using Gmail as the spam filter they need > because of this? Joni makes a very salient point here, and others made the same point as well. I can understand your false positive philosophy, but I don't agree with it, and neither does any other respectable mail OP today. This philosophy may have worked in the mid 1990s when spam volumes were low and merely an annoyance. But the situation "on the ground" of the battlefield in 2013 makes this untenable. The spam volume has increased over 1000 fold and is actively wrecking infrastructures when left unchecked. Thus, taking your currently flawed philosophy into account, *at bare minimum* you need to stop accepting spam from malware infected PCs into your queue. You can safely reject nearly all of this bot spam at smtp connect using Postscreen and similar methods. These look at the client sending the spam, not the content. Thus the FP rate is zero--nobody requests email from a spam bot. Nobody gives explicit opt-in permission for a bot network operator to send them email. Remember, spam is defined by consent, not content. Spambots are never given consent. Block them. Rejecting bots at connect should eliminate 80-90% of your inbound spam volume. Other than putting a huge dent in the forwarding problem, this will also: 1. Decrease network bandwidth consumed after connect 2. Decrease network bandwidth consumed during forwarding 3. Decrease disk space consumed by all the spam you're currently accepting 4. Cut down dramatically on CPU cycles currently burned analyzing all emails for spam 5. Generally reduce the physical hardware infrastructure required to support your user load 6. Dramatically increase the number of email users you can support with your current hardware infrastructure As you can see, there are many critical advantages to rejecting the "low hanging fruit" bot spam sources, without causing false positives. Frankly, if I was your employer I'd have fired you already for not having implemented measures to block bot spam, simply because of the financial burden it places on me due to the extra infrastructure required to ingest, forward, store it, etc. Others here likely share this sentiment. Ingesting all bot spam, all spam, will eventually bankrupt you. You cannot be profitable running a commercial email operation if you're ingesting all the spam. Either the infrastructure costs will eat all your profits, or, more likely, you will eventually lose your customers. On 9/20/2013 12:45 PM, Kris Deugau wrote: > To more directly answer your original question, it would help if you > posted an overview of your mail flow. It sounds like your forwarding > is done via alias rather than .forward or some similar processing on > final local delivery; choosing a different place for your forwarding > may help cut the volume of forwarded spam. A commercial email service should never configure per user forwarding at the MTA level. This is why Sieve, procmail, etc exist, to allow users to configure this themselves at the MDA level. Here, any forwarded email is resubmitted to the MTA. As someone else pointed out, you have an easier trail to follow if there is a problem with a specific user and forwarding. It also allows you, the administrator, to implement site wide MDA delivery rules that override individual user rules. In this case, you'd create an MDA rule that delivers any message with an appropriate SPAM tag in the header to a user's local SPAM folder. If the user creates a forward rule it will not forward the spam. Yes, you have work ahead of you to rearchitect this correctly. But this is how it should have been done in the first place. If you need additional assistance, the first thing you need to do is tell us which MDA you're using. Procmail, Maildrop, Dovecot LDA, etc. -- Stan
Re: anlyzing sudden spam flood, how?
On 9/18/2013 6:50 PM, Voytek wrote: > Stan Hoeppner wrote: >> On 9/18/2013 9:07 AM, Wietse Venema wrote: >>> Stan Hoeppner: >>>>> for other users, the old-syntax was working, now updated >>>> >>>> That's strange. Usually when new syntax is introduced the old >> syntax is >>>> removed and no longer works. 2.3 -> 2.6 seems a rather long grace >>>> period. Does the pre 2.3 syntax still work today? >>> >>> With Postfix, support for old syntax is removed from documentation, >>> but usually remains in the code. Examples are >> "reject_unknown_hostname" >>> and the use of an SMTPD access map without "check_mumble_access". Old >>> syntax is removed when maintaining it becomes a problem. >>> >>> Wietse >> >> >> On 9/18/2013 9:06 AM, Viktor Dukhovni wrote: >>> With parameter renames, Postfix introduces backwards compatible >>> defaults: >>> >>> new_name = $old_name >>> >>> with restriction class names the old form is left in place. >>> Incompatible changes are avoided whenever possible. >> >> >> Thank you both for the explanation. I've always updated my syntax soon >> after changes are made and never really tested this. Sorry for adding >> noise to the thread. >> >> -- >> Stan > > the fact that I have 'old syntax' in the main.cf , does that imply that at > some point, instead of upgrading postfix, a new installation was done, and > old config files copied across? (which is a distinct possibility when server > was 'moved' from physical to vps), just curious. > > Thanks for all the help, Wietse can answer this definitively. I can only relay my experience, which is, using the Debian Postfix packages for many years, it does not appear that the upgrade process walks main.cf and updates syntax. I do recall that somewhere around 2.9 Wietse added code to check for some configuration related issues but I don't recall the specifics. Maybe he can provide a more thorough answer. -- Stan
Re: anlyzing sudden spam flood, how?
On 9/18/2013 9:07 AM, Wietse Venema wrote: > Stan Hoeppner: >>> for other users, the old-syntax was working, now updated >> >> That's strange. Usually when new syntax is introduced the old syntax is >> removed and no longer works. 2.3 -> 2.6 seems a rather long grace >> period. Does the pre 2.3 syntax still work today? > > With Postfix, support for old syntax is removed from documentation, > but usually remains in the code. Examples are "reject_unknown_hostname" > and the use of an SMTPD access map without "check_mumble_access". Old > syntax is removed when maintaining it becomes a problem. > > Wietse On 9/18/2013 9:06 AM, Viktor Dukhovni wrote: > With parameter renames, Postfix introduces backwards compatible > defaults: > > new_name = $old_name > > with restriction class names the old form is left in place. > Incompatible changes are avoided whenever possible. Thank you both for the explanation. I've always updated my syntax soon after changes are made and never really tested this. Sorry for adding noise to the thread. -- Stan
Re: anlyzing sudden spam flood, how?
On 9/18/2013 8:09 AM, li...@sbt.net.au wrote: > On Wed, September 18, 2013 2:54 pm, Stan Hoeppner wrote: >> On 9/17/2013 10:40 PM, Viktor Dukhovni wrote: > >>>> reject_non_fqdn_sender, reject_non_fqdn_recipient, >>>> reject_invalid_hostname, reject_non_fqdn_hostname, >>> This should have blocked the example message, but did not. Why? >> He's using Postfix 2.6.6. The parms in his current config that would >> have triggered are for 2.2 or older, thus ignored I assume. He should be >> using >> reject_invalid_helo_hostname reject_non_fqdn_helo_hostname >> which should trigger on this. > > I've updated the syntax as per above, BUT, my fault was that the address > in question was exempted in "recipient_no_checks", I only work with what I can verify. You didn't provide the contents of recipient_no_checks. I try not to guess as that gets you into trouble. The only thing verifiably wrong was the syntax of those two restrictions. > for other users, the old-syntax was working, now updated That's strange. Usually when new syntax is introduced the old syntax is removed and no longer works. 2.3 -> 2.6 seems a rather long grace period. Does the pre 2.3 syntax still work today? -- Stan
Re: anlyzing sudden spam flood, how?
On 9/18/2013 4:27 AM, Emmanuel Fusté wrote:
> Le 18/09/2013 05:40, Viktor Dukhovni a écrit :
>> On Wed, Sep 18, 2013 at 01:00:48PM +1000, li...@sbt.net.au wrote:
>>
>>> Return-Path:
>>> ...
>>> Received: from p2p (unknown [124.11.170.87])
>>> by geko.domain.tld (Postfix) with SMTP id 9E40A3827C6
>>> for ; Wed, 18 Sep 2013 08:13:25 +1000 (EST)
>> Everything below this Received header is fiction. The EHLO name
>> is not an FQDN and the IP address does not have matching forward
>> and reverse addresses.
>>
>> You could try:
>>
>> main.cf:
>> # Preferred RE map type:
>> RE = pcre:${config_directory}/
>>
>> # HELO restrictions for remote clients
>> smtpd_helo_required = yes
>> smtpd_helo_restrictions =
>> permit_mynetworks,
>> permit_sasl_authenticated,
>> check_helo_access ${RE}helo.re
>>
>> helo.re
>> # Clients with non-fqdn HELO names MUST have working FCrDNS
>> /^[^.]*$/reject_unknown_client_hostname
>>
>>
>> [...]
> Hello Viktor,
>
> In an "access" table, could I use any postfix "reject_xxx" and
> "permit_xxx" directive ?
> I did not find it in the documentation. It could be very powerfull.
It's mentioned, sparsely, in access(5):
OTHER ACTIONS
restriction...
Apply the named UCE restriction(s) (permit, reject,
reject_unauth_destination, and so on).
No, you cannot use "any" restriction. You must use only those that
apply to the context of the check_foo_access restriction which targets
the table. However, if you think clearly about this for a moment,
you'll realize that these nested restrictions using tables are
completely unnecessary.
What Viktor is doing here is suggesting a workaround using a barely
documented trick in an effort to make something work which should
already be working, but is not. I already stated what I believe the
problem is and the simple solution. Just because you're seeing
something used in a way you didn't previously know was possible does not
mean it is powerful, nor something you should try to imitate. And in
fact trying to use this will very likely only cause you additional
problems, while solving none.
--
Stan
Re: anlyzing sudden spam flood, how?
On 9/17/2013 10:40 PM, Viktor Dukhovni wrote: > On Wed, Sep 18, 2013 at 01:00:48PM +1000, li...@sbt.net.au wrote: ... >> reject_non_fqdn_sender, >> reject_non_fqdn_recipient, >> reject_invalid_hostname, >> reject_non_fqdn_hostname, > > This should have blocked the example message, but did not. Why? He's using Postfix 2.6.6. The parms in his current config that would have triggered are for 2.2 or older, thus ignored I assume. He should be using reject_invalid_helo_hostname reject_non_fqdn_helo_hostname which should trigger on this. -- Stan
Re: block exe and other attachments
On 9/17/2013 5:08 AM, Rowland Onobrauche wrote: ... > Thanks to all that contributed to a possible resolution. I have decided to > allow the attachments and leave them to mailscanner to filter/quarantine as > some we are receiving are actually legit attachments. > At least if they are quarantined, i have the option to release. Have you ever been unable to see the forest because the trees are blocking your view of it? Those unwanted attachments are a symptom of your problem, not the problem itself. They are the trees blocking your view of the forest. The forest here is bot spam. Snowshoe spammers don't typically send malware attachments. You may also see this come from compromised hosts or webmail accounts. To stop the bot spam you need to use one of 1. Postscreen - requires Postfix 2.8 or later 2. A greylisting policy daemon such as postgrey for your Postfix 2.6.6. 3. fqrdns.pcre Google will give you information on all of these. After reading up, pick your poison. Mailscanner may do the job, but the above will do so without wasting machine resources (queue bandwidth, CPU time, RAM, etc). And don't forget, Mailscanner is not supported by Postfix, as it breaks API rules and acts directly on the queue. -- Stan
Re: Solution to SMTPAuth compromised accounts.
On 9/12/2013 9:45 PM, Jorgen Lundman wrote: > > Hello all, > > Talking about the customer outgoing SMTP servers, where customers > connect and are forced to SMTPAuth before they can send mail out to the > Internet. We use LDAP for SMTPAuth verification. > > Occasionally, a customer account is compromised, and used for sending > large volumes of spam. > > We have a system in place that detects this, and immediately sets the > LDAP "accountStatus" to "disabled". > > However, quite often the 3rd party involved uses software that can use > pipelining, and simply keeps sending mail, even though the SMTPAuth > account has been stopped. It's not pipelining that enables this. It's the fact that, IIRC, Postfix smtpd allows a client to keep sending messages over an open connection for up to 300s by default. > Naturally, we can simply restart Postfix, thereby dropping all > connections and forcing SMTPAuth again. But this is rather undesirable, > and unattractive. Yes, obviously. > Are there other solutions to consider? The quickest and most thorough way to thwart this is to identify the ID of the smtpd process handling the connection, and kill it. I can't tell you how, but maybe Wietse or Viktor can. You might also try, in your working detection script, adding the hijacked account address to an access(5) table and using check_sender_access to reject subsequent submissions until smtpd times out. This would obviously also require an automated process to remove the entry from the access table once the password has been changed and the account re-enabled. There may already exist a policy daemon that might give most of what you seek. Check out postfwd: http://postfwd.org/ At the least it offers per sender rate limiting. You may be able to inject your disabled account address in real time and set the rate to 0. > Can we add something similar to the "smtpd_client_restrictions" or > "smtpd_recipient_restrictions", and adding a new rule-entry which would > simply confirm that the "SMTPAuth LDAP 'user' used way back, is still > accountStatus=enabled" ? > > Or, can we set a maximum limit on number of pipelining emails allowed, > say, 50, that at least we still have the spammers get cut off, but > retain the efficiency of pipelining. > > Should we simply disable pipelining on the SMTP clusters? Customers > "probably" are not negatively affected by this setting. Again, pipelining isn't your problem. It simply allows smtp commands to be grouped together instead of issued serially, but this works only per message, not across a large set of messages. See: http://tools.ietf.org/html/rfc2920#section-3.1 What you seem to be asking for here is a way to limit total messages per session. I'm unable to locate such a restriction. The best I think you can do is limit message rate, which can be done with Postfix, or with postfwd. -- Stan
Re: spam - headers: from ME to ME, but different anvelope sender
On 9/6/2013 9:05 AM, Wietse Venema wrote: > Wijatmoko U. Prayitno: >> On Fri, 06 Sep 2013 16:43:27 +0300 >> wiseadmin wrote: >> >>> and the same message from postfix logs: >>> >>> /var/log/mail.log.1:Sep 5 17:10:06 cma postfix/pickup[17510]: A3E8C10BADF: >>> uid=1018 from= >> The email came from local user uid 1018 (service pickup). > > Good observation. This message did not come via SMTP. You have > a buggy web application. The default spamassassin spamc/spamd install on many OSes defaults to reinjecting via pickup. I have the same setup. This isn't the problem. The problem is "Nigerian 419" from 41.0.0.0/8. Block this class A net in a CIDR table and this problem is solved, unless you are in Africa and need to accept email from Africa. I've been blocking this /8 basically forever. I also take the extra step of rejecting any connection that has 41/8 in the headers. -- Stan
Re: ISP has no reverse DNS for ip address
On 9/1/2013 6:57 PM, Roman Gelfand wrote: > On every machine, at different locations, I have tried "dig -x ip > address" and it works correctly. > > I have 4 messages stuck in a queue which are complaining about the > very thing that works. > > refused to talk to me: 451 Sender's ISP has no reverse DNS for ip address Provide IP of Postfix host being rejected. Provide log entry corresponding to this NDR. Roman you've been on this list long enough to know you need to provide this information. You've read the posting guidelines, yes? -- Stan
Re: HELO
On 9/1/2013 7:04 PM, LuKreme wrote: > On 01 Sep 2013, at 15:35 , Noel Jones wrote: >> If you want your HELO to be consistent regardless of which IP is >> used, use a separate hostname that points to both A records. >> >> mail.example.com A A.A.A.A >> mail.example.com A B.B.B.B > > Won't this cause a problem with the MX records? They will both point at > mail.example.com and one of those IPs will not be available at any given time. Yes it will be a problem, for the reason you state. Roman described a dual homed backup architecture. Here he should use two distinct PTR, A, and MX records. If he creates two MX with different priority he should be fine. The one with lower priority (higher value) should be tied to IP/PTR/A records which are 'bound' to public IP B which is routed via the backup ISP link. SMTP clients should only attempt IP B when IP A isn't responding. This is just like the primary/backup MX architecture, but in this case there is only one host on a dual homed backup network, instead of two hosts on the same network or separate networks. -- Stan
Re: newbie check Was [Re: port 25 submission settings sanity check]
On 8/30/2013 10:12 AM, Terry Gilsenan wrote: > I am not talking about implementing SMTP on UDP, I am taking about the > possibility of adding a side-channel for bulk data that would use UDP. I'm really surprised nobody has mentioned this yet. It seems there's a far simpler solution to the described high latency low bandwidth attachment transfer problem: TCP send/receive buffer size. If all receiving systems advertised a sufficiently large receive buffer and clients could match it, then this latency/bandwidth problem pretty much evaporates. A 1MB buffer allows a 50MB attachment to be sent requiring only 50 ACKs. Assuming the path is fairly reliable, which has been your assumption in your UDP argument, then this is a far less invasive solution with similar performance. IIRC, not may years ago, a team comprised of personnel at Argonne and CERN achieved sustained saturation of a 1 Gbps link between Chicago and Geneva, using parallel FTP and an insanely large TCP buffer, like in the multiple GB range. I'll have to dig it up. This demonstrates that high bandwidth TCP over high latency links is achievable. -- Stan
Re: Disabling user submission on port 25
On 8/27/2013 6:34 PM, John Allen wrote: > On 27/08/2013 6:09 PM, Jeroen Geilman wrote: >> A simpler way to do that would be to not put these networks in >> mynetworks. >> > If I remember correctly the question was how do I stop local users using > port 25, while allowing them to access port 587. I felt that the > restriction should be applied to SMTP and not to SUBMISSION. > I agree that my solution is not very good and I think that Stan > Hoeppner's response is a much more elegant solution than mine. To be clear, I wasn't offering a solution to the OP's requirement, but simply cleaning up and optimizing your approach into something that would actually work. Jeroen offered the solution. -- Stan
Re: iptables based spam prevention
On 8/27/2013 5:01 PM, Jeroen Geilman wrote: > On 08/25/2013 08:11 PM, Niclas Arndt wrote: >> Sorry if this is slightly off-topic, but at least a bunch of experts >> are listening. >> >> I am using Spamhaus (and other methods) and over time I have amassed a >> list of IP ranges that (according to Spamhaus) shouldn't be sending >> e-mail at all. Given your description this would be the PBL list, typically filled with consumer broadband IP ranges. >> One problem is that this list tends to become quite >> long and another is that I would like to verify it so that I don't >> eventually block legitimate e-mail. This suggests you've collected these IPs from your logs and have built a local table. Why? I don't understand what you mean by "verify it". WRT blocking legitimate email that's always a risk with dnsbls, though in the case of the Spamhaus lists a very low risk. >> On the other hand, I would like to place as little a load as possible >> on Spamhaus. See below. But note you are allowed 300K queries/day to Zen. >> Here are my questions: Is the iptables approach at all viable in the >> long run? Is there any non-commercial way to upload a text file >> containing spamming IP addresses and have it verified for correctness? > > postfix 2.8 and later offer the postscreen(8) triage service, which > deals very efficiently with large amounts of DNSBL lookups. > Run a local DNS cache on the postfix machine and point postscreen at zen. > You'll be hitting the spamhaus non-commercial limit long before you hit > the local cache's limits. > > This automatically adds and expires DNSBL entries without any effort > from you, as a free bonus (this is the biggest problem with your > iptables approach.) A local caching resolver is a good start. I use pdns_recursor. If you're concerned about your query load to Spamhaus public Zen servers then block spam connections without using dnsbls, or more precisely, block as much as possible before querying dnsbls. This is what myself and many others do. I.e. use the least expensive tools first and the most expensive last. Expense being defined as time to completion and resources consumed (net/CPU/RAM/disk IO). This not only decreases the load you put on dnsbls, but it also increases throughput due to decreasing remote lookup latency per message. Judicious use of inbuilt Postfix features and local tables can cut per msg latency from a few dozen milliseconds down to a few microseconds. To do this, enable Postcreen in its standard mode. Do not configure dnsbl block lists in postscreen. This will stop nearly all bot traffic. Next, use the "everything under smtpd_recipient_restrictions" main.cf model so you can precisely control the order in which restrictions are processed. Inbuilt Postfix restrictions are the least expensive, then CDB, hash, and CIDR tables. REGEXP and PCRE tables are a little more expensive, possibly much more if tables are large (and without loops) and expressions complex. Header checks are normally next in expense followed by body checks, and local policy daemons and content filters can be more expensive still. So as a general starting point you'd want something similar to this. This configuration assumes the Postfix server is an MX as well as a submission relay. smtpd_recipient_restrictions = # These are inbuilt Postfix restrictions permit_mynetworks permit_sasl_authenticated reject_unauth_destination reject_unknown_reverse_client_hostname reject_non_fqdn_sender reject_non_fqdn_helo_hostname reject_invalid_helo_hostname reject_unlisted_recipient # These check a hash table of domains which have sent spam here # or that have been obtained via intelligence (A/S mailing lists) # and check dnswl.org for sender that should be allowed through check_reverse_client_hostname_access hash:/etc/postfix/blacklist check_helo_access hash:/etc/postfix/blacklist check_sender_access hash:/etc/postfix/blacklist check_client_access hash:/etc/postfix/whitelist permit_dnswl_client list.dnswl.org=127.0.[2..14].[2..3] # This checks a rather larger CIDR table of snowshoe spammer netblocks # that I've been building for ~4 years now check_client_access /etc/postfix/spammer # If none of the previous restrictions reject the spam I then query # various [dns|rhs]bls. reject_rbl_client zen.spamhaus.org reject_rbl_client b.barracudacentral.org reject_rbl_client psbl.surriel.com reject_rhsbl_reverse_client dbl.spamhaus.org reject_rhsbl_sender dbl.spamhaus.org reject_rhsbl_helo dbl.spamhaus.org If you want to be able to score [dns|rhs]bl results you can use a policy filter here such as postfwd or policyd instead of the simple reject/allow offered by these Postfix restrictions. Combining this with a local caching DNS resolver as Jeroen suggested you should cut down on your dnsbl query load pretty substantially
Re: Disabling user submission on port 25
On 8/26/2013 10:24 PM, John Allen wrote: > I based it something that Noel Jones wrote way back in 2008. I doubt that Noel suggested anything like this. > Create a file of the networks you wish to deny access to eg. > “Deny_Mynetworks_Access” the content of which will be the same networks > as those found in the mynetworks parameter of the main.cf file for example: > > 192.168.0.0/16 REJECT local access not permitted > n.n.n.n/28 REJECT local access not permitted > [::::]/64 REJECT local access not permitted > > remove the permit_mynetworks from all the various > smtpd__restrictions stanzas of main.cf. Then modify the master.cf by > adding >-o smtpd_client_restrictions=hash:Deny_Mynetworks_Access,. > to the smtp service, and add >-o smtpd_client_restrictions=permit_mynetworks,. > to the submission service. This unnecessary and complex and actually won't work as stated. All that is required is a one line change to master.cf and a CIDR file: /etc/postfix/master.cf ... smtp inet n - - - 20 smtpd -o smtpd_client_restrictions=check_client_access,\ cidr:/etc/postfix/deny-local.cidr /etc/postfix/deny-local.cidr 192.168.0.0/16 REJECT local access not permitted Aug 27 01:28:21 greer postfix/smtpd[31670]: NOQUEUE: reject: RCPT from gffx.hardwarefreak.com[192.168.100.53]: 554 5.7.1 : Client host rejected: local access not permitted; from= to= proto=ESMTP helo=<[192.168.100.53]> -- Stan
Re: Block certain remote hosts on submission port
On 8/24/2013 1:18 PM, LuKreme wrote: > > On 22 Aug 2013, at 21:28 , Stan Hoeppner wrote: > >> ~$ wget http://ipdeny.com/ipblocks/data/countries/us.zone >> ~$ sed 's/$/ OK/g' us.zone > us.cidr >> ~$ cp us.cidr /etc/postfix >> ~$ postfix reload >> >> and you're off to the races. > > Interesting idea. I'm in much the same boat. Although I do have international > users, they all use webmail to access mail, so I'm interested in trying this. > > A couple of questions: > > 1) I wouldn't think that CIDR list changes very often, but how often should > it be refreshed? How often does APNIC reassign, for example, a /22 from an entity in Vietnam to one in Japan, if ever? I don't have the answer to that. But this is the only type of situation that would prompt you to refresh, now that all IPv4 space has been allocated to the RIRs. We now know every IP by region, but what country it is assigned in may or may not change in future. And BTW, it's better to do this at the firewall if at all practical. > 2) If I did this I also would like to log these rejections to a separate > file, possible? Not directly. You'd specify a custom reject code then parse your mail log for that, pipe to another file. If you do it at the firewall it would depend on the firewall's features. > Under 2.10, would it make sense to put those restriction in the > smtpd_relay_restrictions if port 25 is open for connections? In the other half of the instructions I gave, which you cut, I show that this needs to be done in master.cf. smtpd_foo_restrictions in main.cf are global. You want this restriction only on the submission port, not the public smtp port. -- Stan
Re: Block certain remote hosts on submission port
On 8/22/2013 9:57 AM, Stan Hoeppner wrote: > On 8/22/2013 6:51 AM, Charles Marcus wrote: > >> The simple fact is, we do not have any users based *anywhere* but the >> US, so, is what is the simplest way to block any/all non-US based client >> connections on my submission port? > > > Use the us.zone ipdeny file to build a CIDR table to accept any US > client IPs and reject everything else. > > http://ipdeny.com/ipblocks/data/countries/us.zone > > But not now as it's currently broken. It's fixed now. > Anyway, your solution should be as simple as something like this: > > submission inet n - - - - smtpd > ... > -o smtpd_client_restrictions=check_client_access\ >/etc/postfix/us.cidr, reject After you modify master.cf as above, do ~$ wget http://ipdeny.com/ipblocks/data/countries/us.zone ~$ sed 's/$/ OK/g' us.zone > us.cidr ~$ cp us.cidr /etc/postfix ~$ postfix reload and you're off to the races. -- Stan
Re: Block certain remote hosts on submission port
On 8/22/2013 6:51 AM, Charles Marcus wrote: > The simple fact is, we do not have any users based *anywhere* but the > US, so, is what is the simplest way to block any/all non-US based client > connections on my submission port? Use the us.zone ipdeny file to build a CIDR table to accept any US client IPs and reject everything else. http://ipdeny.com/ipblocks/data/countries/us.zone But not now as it's currently broken. Already notified the OPs. Not sure how this happened. This is a big deal as automated systems rely on this data. I'd think it'll be fixed today, within hours. Anyway, your solution should be as simple as something like this: submission inet n - - - - smtpd ... -o smtpd_client_restrictions=check_client_access\ /etc/postfix/us.cidr, reject You could do the reverse and reject the rest of the world with your table, however building an maintaining that CIDR file is a massive PITA. If you have personnel traveling in other countries they use a VPN client to get into your network. That's what roaming VPN clients are for. You can setup a FLOSS VPN server for no cost but your labor/learning curve. Or simply enable/configure it on your edge router if it has VPN capability. -- Stan
Re: greylisting generates error email?
On 8/20/2013 3:06 AM, Grant wrote: > Has anyone had a confirmed false positive with zen.spamhaus.org ? http://lmgtfy.com/?q=spamhaus+false+positive -- Stan
Re: postfix content_filter source address
On 8/20/2013 1:04 AM, Jimmy Stewpot wrote: > Hello, > > I have recently done a deployment of Postfix 2.10. It seems that the > behaviour of postfix has changed slightly in the way that it handles the > content_filter variables in the configuration file. We are using > content_filter to pass through the emails to Sophos PureMessage for UNIX like > so. > > content_filter = smtp:[127.0.0.1]:2500 Is this the verbatim line you used on the RHEL5 box? > On our old server (Redhat 5) when the content_filter line was in place the > spam service would "just work" in that it would see the source and correctly > process the emails as an external email.. However with the same version of > Pure Message on a new version of Postfix we see that the system is seeing > "localhost" as the from relay which means it goes through the localhost > whitelist in the spam policy... "seeing 'localhost' as the from relay" What was seen previously where you now see "localhost"? > Am I missing something in the new version of postfix or is that expected > behaviour? This is a fresh Postfix install not an upgrade, correct? New main/master.cf? Parameters copy/pasted? I'm guessing you simply missed something when creating the new main/master.cf. It would be nice to see your 'postconf -n' output, and any service definitions that exist for the Sophos program. -- Stan
Re: Setting up SPF in Postfix for sending
On 8/16/2013 12:56 AM, Rob Tanner wrote: > I've googled around a quite a bit and while I can find lots of instruction on > what I need in order for Postfix to validate incoming mail, I find nothing > about what I need to do to make sure Postfix does whatever it needs to do to > make sure the MTA receiving the mail validates it. And the dearth of > information in that category also begs the question, is there a special > header that Postfix need to include in the message (as in DKIM) or do the > receiving MTAs, if they're setup to use SPF just automatically do the DNS > lookups? What is it, besides adding the correct the DNS TXT records, do I > need to do on my end. Nothing else. Just the TXT record in DNS. This should have been clear to you after reading the receiver side requirements, i.e. how the receiver checks SPF records. -- Stan
Re: How to send more than 1 email per sec per domain?
On 8/14/2013 10:12 AM, Philippe Bloix wrote: > Of course it's easy to contact our customers! > But in some cases, it can be difficult to contact the mail provider of our > customers in order to ask to belong to their whitelist... If this is truly the case and this is legitimate transactional mail, then contacting the receiving organizations is the proper way to go about this. But since this is difficult, there are some other things you can try before implementing a multi-instance or multi-host relay farm. For instance, setting smtp_destination_concurrency_limit to a low value. The default value is that of default_destination_concurrency_limit (default: 20) Decreasing parallel connections will decrease your msg rate. Start with a value of 2 and see if that works, and if delivery rate is acceptable to you. If yes, and no, increase by 2 until you hit rate limiting at the receivers or you find the msg rate acceptable. If you run into rate limiting, decrease by two, and keep the resulting value. Receivers may also be rejecting you for delivering too many recipients/msg, not purely inbound msg or connection rate, if they count total recipients delivered instead of msgs accepted by smtpd. So you can try lowering the value of smtp_destination_recipient_limit to 25, lower if necessary. The default value is that of default_destination_recipient_limit (default: 50) Do NOT set this value lower than 2. See the postconf (5) entry for why. By tweaking the two values above it should be possible to avoid your rate limiting problem but without dropping delivery rate all the way down to 1/sec. The above are global settings. You can also do this on a per receiving domain basis by using a transport table and a corresponding custom master.cf message delivery transport. See: http://www.postfix.org/postconf.5.html#transport_destination_concurrency_limit http://www.postfix.org/postconf.5.html#transport_destination_recipient_limit -- Stan
Re: How to send more than 1 email per sec per domain?
On 8/14/2013 7:14 AM, Philippe Bloix wrote: > Thanks for your response > > I'm not a spammer :-), i'm working in a telecom firm where we send emails > to our customers. Ok, so you're a telecom company and the receivers in question are your customers. > In fact, it's not easy to contact some receivers who is rate limiting, So even though the receivers are your customers, it's "not easy to contact them"? So you're telling us you do not have contact information on file for your customers. How do you bill them for your services? And yet you want to email addresses at said customer domains at a rate of 10/sec. Obviously you do have a way of contacting them, yes? What type of emails are you sending your customers whom you're unable to contact, that require such a rate as to prompt them to rate limit you? > then in theses cases the goal is to reduce the rate per sec (about 10 mails > per domain per sec); You're a "telecom firm". You're flooding your CUSTOMERS, whom you are not able to "easily" contact. They are rate limiting you due to the flood of mail. So instead of contacting them to work this out, you instead want to circumvent their rate limiting. Sorry "Philippe" but I'm calling BS on this. Nothing you've said here makes any sense. Nobody floods their own customers to the point that said customers enable rate limits. They'd contact you first before enabling limits, yet you claim it's "not easy" to contact them. All of this is doubletalk Bull$hit. > i'm astonished that postfix (without addons) is not > allowed to do that but at best only 1 mail per domain per sec. Postfix is not a good platform for sending spam. You should find other software to do this with. Maybe botnet rental is a good choice for you. -- Stan
Re: How to send more than 1 email per sec per domain?
On 8/13/2013 7:43 AM, Philippe Bloix wrote: > I would like to set a limit rate per domain. I know i can use > « destination_rate_delay » and it works ! The problem is that the minimum > period is 1s. It permits to send 1 email per domain per second . > > If i want to send for example 5 emails per domain per second, how is it > possible by using postfix? Rate problems are rarely encountered with normal mail traffic. When recipient domains reject your mail due to rate, you're either sending spam, bulk mail, running a very busy list server, or an aggregation relay/proxy for people living in tyrannical countries. If you're relaying spam we won't help you. If you're doing one of the other three the typical solution is to simply contact each receiver who is rate limiting you and make arrangements with them. The big freemailers have forms for this on their websites, i.e. Google, Yahoo, Hotmail, etc. As a general rule, if you're sending legitimate bulk or other high volume mail, not spam, receivers are willing to work with you. Why? Their users who pay their bills signed up for the mail you're sending and they need to keep those users happy. -- Stan
Re: basic level configuration: non-standard maildir location
On 8/6/2013 1:57 AM, The_Ace wrote: > On Tue, Aug 6, 2013 at 10:10 AM, David Benfell wrote: >> >> Hi all, >> >> I'm trying to move my maildirs to a non-standard location (trying to balance >> disk activity) and there's something I think I'm missing. Here's what I >> tried: >> >> home_mailbox = /Maildir/$user/ That's not how it works. home_mailbox is a relative path within a user home directory. Postfix already knows the username, already knows the path of the user's home directory. What you specify here gets tacked onto the home directory path. I.e. homedir: /home/stan home_mailbox=Maildir/ Maildir style mail is written into /home/stan/Maildir/ http://www.postfix.org/postconf.5.html#home_mailbox >> But when I ran 'postfix check' it said, several times: >> >> /usr/bin/postconf: warning: /etc/postfix/main.cf: undefined parameter: user >> >> What I want is if the recipient is benf...@parts-unknown.org for the mail to >> be delivered to /Maildir/benfell/ This is a really important point you need to clarify. Are you wanting to write different users' mail to different filesystem locations, different disks? I.e. David's mail to disk A and Susie's to disk B? Or do you want to move everyone's mail to a new location? Each requires a different main.cf config. And if these are system user accounts, not virtual, then you may not be able to specify storage path on a per user basis. > The home_mailbox parameter works for local shell accounts and its > relative to the user's home folder. > look up the mail_spool_directory parameter. It looks like thats the > one you need to use. This is only valid if he wants to deliver all users' mail to a single path/location. It won't work for the per user case. -- Stan
Re: Three trivial filtering questions
On 8/5/2013 6:16 PM, Ronald F. Guilmette wrote: > In message <520023b2.1070...@megan.vbhcs.org>, > Noel Jones wrote: >>> OK. Works for me! I just wish that it wasn't necessary to >>> have to run an external PCRE to catch it, and that the PCRE tables don't "run externally". They're simply tables. Postfix smtpd processes them by calling libpcre to which it is linked, just as it is linked with other libraries including libc, libresolv, libssl, etc that handle other functions: ~$ pmap 10296 10296: smtpd -n smtp -t inet -u -c -o stress= -s 2 ... ... b7104000200K r-x-- /lib/libpcre.so.3.12.1 b7136000 4K rw--- /lib/libpcre.so.3.12.1 b7137000 12K r-x-- /usr/lib/postfix/dict_pcre.so b713a000 4K r /usr/lib/postfix/dict_pcre.so b713b000 4K rw--- /usr/lib/postfix/dict_pcre.so ... b74f3000 88K r-x-- /usr/lib/libsasl2.so.2.0.23 b7509000 4K rw--- /usr/lib/libsasl2.so.2.0.23 ... b773e000 16K r-x-- /var/spool/postfix/lib/libnss_dns-2.11.3.so b7742000 4K r /var/spool/postfix/lib/libnss_dns-2.11.3.so b7743000 4K rw--- /var/spool/postfix/lib/libnss_dns-2.11.3.so ... b7763000184K r-x-- /usr/lib/postfix/smtpd b7792000 8K r /usr/lib/postfix/smtpd b7794000 4K rw--- /usr/lib/postfix/smtpd b9178000264K rw---[ anon ] bfd19000132K rw---[ stack ] total 7664K >> I can see where one might get confused. I'll submit a one-line doc >> patch rather than argue the point. > > I have no wish to belabor the point either, however for the record > I am not confused. An FQDN is an FQDN, and [A.B.C.D] quite certainly > isn't one. Indeed. You're not the first to be stumped by the discrepancy between this parameter's behavior and that described in the docs. I commend Noel for submitting this long overdue patch. -- Stan
smtpd restriction order, rbl dnsbl rhsbl usage -- WAS: Re: Three trivial filtering questions
On 8/5/2013 2:52 AM, Ronald F. Guilmette wrote: > Actually, having adjusted my smtpd_recipient_restrictions rather > dramatically today, and looking now at the day's maillog file, > I think that I am entirely less sure that the problem is what > I said it was earlier. I am now getting at least _some_ > rejects based on SURBL and URIBL, whereas earlier I had not > yet seen any at all in the maillog. > > I think that I should ask everyone to ignore my earlier question > about this until I have time to gather more data and see if I can > see what's actually going on. Perhaps there's nothing wrong at > all! Fair enough. In the mean time I'll share my experience with dnsbl and rhsbl restrictions. YMMV. I use the following *BL restrictions after all other main.cf restrictions, which is why the absolute numbers are so low. RBL checks are the most latency expensive built-in smtpd restrictions so I evaluate them last. reject_rbl_client zen.spamhaus.org reject_rbl_client b.barracudacentral.org reject_rhsbl_reverse_client dbl.spamhaus.org reject_rhsbl_sender dbl.spamhaus.org reject_rhsbl_helo dbl.spamhaus.org 'gcml' is my simple keystroke saving script that greps the mail log for an input string. ~$ gcml reject|wc -l 9957 ~$ gcml reject|grep zen|wc -l 149 ~$ gcml reject|grep barracudacentral|wc -l 118 ~$ gcml reject|grep dbl|grep Unverified|wc -l 15 ~$ gcml reject|grep dbl|grep 'Sender address'|wc -l 30 Here we see the relative effectiveness of *BLs in general on this MX, accounting for only 3% of rejections. rhsbls account for 0.3% of rejections. 45 of 9957 messages may seem not worth the effort, but that's 45 fewer msgs going through Spamassassin spamd. Body scanning those 45 eats far more resources than rejecting the other 9912 connections combined, so for me it's worth the extra 3 lines in main.cf. On 8/5/2013 3:11 AM, Ronald F. Guilmette wrote: > Last, first, does the order make any difference in the end? I'm responding a bit out of context to what you were asking with this in your other post, but the question is a perfect lead-in to demonstrate why main.cf restriction order matters. Note above that reject_rhsbl_helo didn't reject a single connection. This is most likely due to the fact that snowshoe spammers using $domain in HELO also use $domain in the rDNS string and/or the envelop sender address. So if we rearrange the restriction order to something like this reject_rhsbl_helo dbl.spamhaus.org reject_rhsbl_reverse_client dbl.spamhaus.org reject_rhsbl_sender dbl.spamhaus.org reject_rbl_client zen.spamhaus.org reject_rbl_client b.barracudacentral.org then we'll likely see the rhsbl checks rejecting many more connections. If I put this entire block near the top of my restrictions the numbers would skyrocket with a much higher percent of that 9957 being rejected by *BL Restrictions. With all restrictions under smtpd_recipient_restrictions they are processed in strict order. The first match wins, so if the rhsbl_helo check evaluates to true the msg is rejected and no other smtpd restrictions below it are processed. This strict ordering currently allows 97% of the spam rejected in smtpd to be killed off with the fewest resources consumed, first via inbuilt Postfix checks, then by my various custom tables, and finally by *BL restrictions. Any spam that runs this smtpd restriction gauntlet is then rejected by header_checks and if not enters the queue and is piped to spamd for tagging. This strict evaluation ordering allows one to optimize resource consumption per spam connection by using the least expensive restrictions first and most expensive last. This is not only critical for very high volume MTAs, but also for low power machines or those that serve multiple functions such as SOHO servers. *BL checks won't introduce sufficient latency to cause serious delays on the latter class of machines, but they certainly can on high volume MTAs, even if using a local resolver and/or rbldnsd. Obviously it's best to reject spam connections with the least number of DNS queries possible, from a latency/throughput and/or resource consumption perspective. I'm sure already know most of this Ron. I'm using this opportunity to get a recent post into the archives covering these topics, hence the subject change with added search keywords. -- Stan
Re: Outsourced anti-spam and Issues with VRFY
On 8/5/2013 9:09 AM, Charles Marcus wrote: > On 2013-08-05 9:21 AM, Noel Jones wrote: >> Set those three limits to 100 or higher. Those controls are >> intended to prevent random clients from wasting your time. Since >> you don't allow connections from random clients, it's safe to >> increase them. >> >> # main.cf >> smtpd_hard_error_limit = 100 >> smtpd_soft_error_limit = 100 >> smtpd_junk_command_limit = 100 > > Thanks Noel... I'll do this, unless I can get them to change their VRFY > service to properly close these connections - or stop using a MAIL FROM > that is in my domain name for their SMTP RCPT TO option so we could use > that option. ... I'm sure you've already covered this Charles but just in case you haven't I'll mention it anyway. No matter what you do here with this outsourced service, I'd suggest you document all Postfix config changes you're making, or save a copy of your main/master.cf files as they were before embarking down this path, should you later decide to ditch this service. You don't want these custom setting biting you in the backside if/when you switch back to direct-to-MX, or possibly to another outsourced service. -- Stan
Re: Three trivial filtering questions
On 8/4/2013 10:13 PM, Ronald F. Guilmette wrote: > Do I need to use that if I want to perform RHSBL checks? BTW, if you want to maximize potential hits on RHSBLs just short of doing body checks, you may want to give Sahil Tandon's TCP server based RHSBL header checker a spin. It grabs domains from headers and checks them against the 3 most popular RHSBLs: DBL, SURBL, and URIBL. You can add or subtract from the default server list if you choose. http://www.hardwarefreak.com/checkdbl.pl.txt He may have a newer version somewhere. This is the last version I used. I quit using it because it wasn't stopping much with my small mail stream, after all of my smtpd restrictions. With larger flows it may be useful for catching some that may otherwise make it to your content filter, or make it through entirely if you don't use one. -- Stan
Re: Three trivial filtering questions
On 8/4/2013 10:13 PM, Ronald F. Guilmette wrote: > In message <51ff13eb.8090...@megan.vbhcs.org>, > Noel Jones wrote: > >> On 8/4/2013 8:06 PM, Ronald F. Guilmette wrote: >>> Does reject_non_fqdn_helo_hostname, when placed in the >>> smtpd_helo_restrictions, permit clients to HELO/EHLO >>> with a square-bracket enclosed dotted quad IPv4 address? >> >> Yes. > > The documentatation should probably be adjusted to make that more clear. > Right now it reads: > > Reject the request when the HELO or EHLO hostname is not in fully- > qualified domain form, as required by the RFC. You'll find elsewhere in the Postfix documentation and in RFC that address literals must be accepted. >>> If so, is the dotted quad checked to see that it properly >>> represents the actual IP address of the actual current client? >> >> No. > > Is there any restriction verb that would cause a HELO/EHLO which specifies > a square-bracketed dotted quad IPv4 address to be rejected when & if the > dotted quad does not match the actual current client IP address? No. You would need to use a policy daemon for something like this. > Would reject_unknown_helo_hostname do it? No. This rejects when no DNS A or MX record exists for the HELO string. This test is skipped for address literals. > If not maybe a new restriction > verb would be useful to perform this exact check. Maybe you should explain why you're having a problem rejecting spamware that HELO's with an IP literal. If rejecting based on a HELO string is your last line of defense you're in trouble Ron. Surely a spamfighter of your experience isn't pinning his hopes on HELO. ;) If your IP literal HELO problem is indeed bot ware, then using Postscreen will stop these clients, before they have a chance to HELO. >>> Certainly, some spam >>> that I believe should have been rejected on the basis of one or another >>> of the above RHS filters I am instead seeing (in my maillog file) being >>> rejected instead by one or another of the subsequent reject_rbl_client >>> filters. What could I be doing wrong? >> >> Doing RBL client checks in postscreen? > > I am not using postscreen at the present time. > > Do I need to use that if I want to perform RHSBL checks? No, they are independent of one another. But if you want to easily stop bots Postscreen is the way to go. DNSBL checks in Postscreen are feature creep, they are not required. I.e. you can setup default Postscreen to stop bots and still do your reject_rbl_* checks in smtpd_client_restrictions. With your current setup and described problem you could simply remark all of your reject_rbl_client statements temporarily and see if your reject_rhsbl_* statements catch anything. -- Stan
Re: Three trivial filtering questions
On 8/4/2013 9:54 PM, Noel Jones wrote: > On 8/4/2013 8:06 PM, Ronald F. Guilmette wrote: ... >> Also, I have just added all of the following to my >> smtpd_recipient_restrictions: >> >> reject_rhsbl_reverse_client multi.surbl.org >> reject_rhsbl_reverse_client multi.uribl.com >> reject_rhsbl_reverse_client dbl.spamhaus.org >> reject_rhsbl_sender multi.surbl.org >> reject_rhsbl_sender multi.uribl.com >> reject_rhsbl_sender dbl.spamhaus.org >> reject_rhsbl_helo multi.surbl.org >> reject_rhsbl_helo multi.uribl.com >> reject_rhsbl_helo dbl.spamhaus.org >> >> For the time being, and mostly just to see how effective these filters >> are on their own, I have these listed in my smtpd_recipient_restrictions >> *prior to* several subsequent reject_rbl_client clauses. Oddly however, >> in spite of the ordering, it is appearing to me as if perhaps the above >> RHS filters are either not actually being applied or else are being applied >> _after_ the subsequent reject_rbl_client filters. Certainly, some spam >> that I believe should have been rejected on the basis of one or another >> of the above RHS filters I am instead seeing (in my maillog file) being >> rejected instead by one or another of the subsequent reject_rbl_client >> filters. What could I be doing wrong? > > Doing RBL client checks in postscreen? That would be one cause. Another could be having duplicate reject_rbl_client statements in smtpd_client_restrictions. Ron, putting all of your restriction statements under smtpd_recipient_restrictions and removing the others, i.e. smtpd_client_restrictions smtpd_helo_restrictions smtpd_sender_restrictions is beneficial especially when troubleshooting things of this nature, where evaluation order matters. Since smtpd_delay_reject is enabled by default you can put all restrictions in smtpd_recipient_restrictions. http://www.postfix.org/postconf.5.html#smtpd_delay_reject In your current case, if you have a reject_rbl_client statement in smtpd_client_restrictions it will evaluate first, and first match wins. So the rejection occurs before evaluation reaches say reject_rhsbl_helo dbl.spamhaus.org in your smtpd_recipient_restrictions. This may not be what's happening in this case, but putting all restrictions under smtpd_recipient_restrictions is good practice regardless. It also makes complex whitelisting setups much easier, etc, etc. -- Stan
Re: how to stop facebook spam emails
On 7/29/2013 2:16 PM, motty cruz wrote: > Thank you Mr. Wietse, > I added spamcop to my rbl since to be holding the line for now. Motty, note that using bl.spamcop.net for direct rejection is discouraged by the Spamcop team. The chance of FPs is pretty high with this DNSBL. It is recommended that you use bl.spamcop.net only in a scoring system such as SA and with a relatively low score. SA in fact does this with spamcop in the default configuration. Using Postscreen w/Zen and BRBL, along with client/sender/helo rhsbl checks against dbl.spamhaus.org, should REJECT 90-95% of your inbound spam connections including all bot spam. Then all you have to worry about is snowshoe. For that you'll need a good content filter, and/or much manual work building CIDR tables of revealed snowshoe networks. There exist both public and private mailing lists that specialize in publishing such snowshoe spammer CIDR ranges. > On Mon, Jul 29, 2013 at 12:04 PM, Wietse Venema wrote: >> The IP address is listed at zen.spamhaus.org, bl.spamcop.net, and >> b.barracudacentral.org, and perhaps more. Just a few. ;) I omitted the APEWS listing, for obvious reasons. 173.200.156.65 abuse.ch combined zone Listed 173.200.156.65 abuse.ch spam blacklist Listed 173.200.156.65 Barracuda Reputation Block List Listed 173.200.156.65 CBL Listed 173.200.156.65 Mailspike Blacklist Listed 173.200.156.65 McAfee RBL Listed 173.200.156.65 nsZones.com SBL Listed 173.200.156.65 nsZones.com SBL+Dyn Listed 173.200.156.65 Project Honey Pot (http:BL) Listed 173.200.156.65 SORBS Aggregate zone (problems) Listed 173.200.156.65 SORBS Spamhost (any time) Listed 173.200.156.65 SORBS Spamhost (last 28 days) Listed 173.200.156.65 SORBS Spamhost (last year) Listed 173.200.156.65 SpamCop Blocking List Listed 173.200.156.65 Spamhaus SBL-XBL Combined Block ListListed 173.200.156.65 Spamhaus XBL Exploits Block ListListed 173.200.156.65 Spamhaus ZEN Combined Block ListListed 173.200.156.65 Unsubscribe Blacklist UBL Listed 173.200.156.65 V4BL/DDNSBL Listed 173.200.156.65 Hostkarma Listed 173.200.156.65 Mailspike ReputationListed 173.200.156.65 Quorum.to Listed The fact that just about everyone in the DNSBL world is listing this IP, and you accepted mail from it, would suggest that you are fairly new to using DNSBLs, and anti-spam controls in general. It may prove valuable to search the list archives for "DNSBL" and/or "spam". -- Stan
Re: Mail Bounces
On 7/25/2013 11:53 AM, Roman Gelfand wrote: > I am using postfix as outgoing mail gateway. Outside of non-delivery > notification, is there a way to produce a report of email addresses > and the reason for the bounce of all emails, that were, in conclusion, > rejected. I believe the Logwatch Postfix module provides summary detail of bounces as well as everything else logged by Postfix. Pflogsumm might as well, I don't recall. I haven't use it in years. -- Stan
Re: Postscreen
Wietse: > Turn OFF postscreen chroot in master.cf asn indicated with >>> <<<: > > smtp inet n - >>>n<<< - 1 postscreen Phil: > At present in master.cf I have: > smtp inet n - n - - smtpd Phil do you see the discrepancy here? It appears you are loading smtpd instead of the postscreen daemon. Might not be a bad idea at this point to post your complete master.cf and 'postconf -n' output. -- Stan
Re: Postfix not accepting remote connections
On 7/19/2013 5:11 PM, Sam Flint wrote: > Sorry, Gmail. > > I'm testing by attempting to connect with my android tablet Ok, so this is the real problem you're trying to solve. You believe you cannot connect to Postfix with the Android tablet, correct? What operation are you performing that is failing? 1. Are you attempting to send an email from the tablet to a mailbox on the Postfix server, and it's failing? 2. Are you trying to read your IMAP mailbox and it's failing? 3. Are you trying to send an email through Postfix to some other address, say exam...@yahoo.com? Answering these questions should allow us to get you on the right path pretty quickly. -- Stan
Re: Error 550
On 7/18/2013 7:44 AM, Roman Gelfand wrote: > would you have more info on this, as far as, how to go about researching this? What is left to research? The remote host told you the address doesn't exist. What more do you need to know? What is the -real- problem you are wanting to solve Roman? > Thanks again > > On Thu, Jul 18, 2013 at 6:50 AM, Wietse Venema wrote: >> Roman Gelfand: >>> I am sorry. I posted this only to Stan before. Looking at the >>> rejected line, it seems to be postfix/smtp. >>> >>> host smtp.secuaid: 550 #5.1.0 Address rejected. (in reply to RCPT TO >>> command) >> >> THAT is qmail not Postfix. >> >> Wietse
Re: Error 550
On 7/17/2013 9:58 PM, Roman Gelfand wrote: > relay=smtp.secureserver.net[216.69.186.201]:25, delay=10, > delays=0.08/0.01/10/0.16, dsn=5.0.0, status=bounced (host > smtp.secuaid: 550 #5.1.0 Address rejected. (in reply to RCPT TO > command)) Your Postfix relayed the msg to smtp.secureserver.net, which then returned "550 #5.1.0 Address rejected". Either you're sending to a non existent address, or there is some configuration problem at the remote MX. You'll need to contact the administrator of the remote system. This is not a Postfix problem. Postfix is only generating the NDR. -- Stan
Re: Error 550
On 7/17/2013 6:28 PM, Roman Gelfand wrote: > I am trying to send out a message my server and getting an error below > from my server > 550 #5.1.0 Address rejected. (in reply to RCPT TO command)) > > Is it this server that is rejecting this email or target server? Why? Not enough information. Show the log entries. -- Stan
Re: How best to eliminate "domain mismatch" warning in mail clients when TLS is used
On 7/15/2013 3:35 PM, Viktor Dukhovni wrote: >>> Unfortunately there are not a lot of development cycles for adding >>> a decent SNI implementation to Postfix. > > I have no time for this. And this is precisely why an entire VPS industry has sprouted over the past few years. As someone stated down thread, give your customers what they want and charge them accordingly. This is trivially easy to do with your choice of hypervisor with memory consolidation (same page merging) and a guest OS template. If your pool of IPv4 addresses is limited charge them extra for that. If they're exhausted, well, you can go IPv6 only but that really has downsides. Here's an even better idea. Do what everyone else in your shoes does: partner with a VPS provider and farm the bulk of this out. There are tons of small companies that do exactly this. They buy X number of VPS instances each with an IP address from a provider and rebrand them. The VPS provider does all the heavy lifting WRT provisioning. You would simply do the customization for your individual customers, i.e. DNS, hostname, domain name, certificate, etc. A basic VPS for this kind of thing can normally be had for well less than $10/month. The really stripped down VPS services I see offered are $4.95/month. All prices USD. If you already have a mailbox (IMAP/POP) server that currently handles MX duty for all these customers, moving MX to these VPS instances and relaying the mail to your mailbox server is easy as well. -- Stan
Re: Delivery Retry
On 7/13/2013 11:02 PM, Roman Gelfand wrote: > What setting determines how long postfix should attempt to deliver an > email if target server is not available? http://www.postfix.org/postconf.5.html#bounce_queue_lifetime http://www.postfix.org/postconf.5.html#maximal_queue_lifetime > Will this setting work with smart host configuration where smart host > is temporarily unavailable? The nexthop is irrelevant. Doesn't matter if it's a local smarthost problem or destination MX problem, or DNS resolution problem, network problem, etc. If Postfix can't deliver after 5 days it bounces the msg. -- Stan
Re: Backup mx on cable
On 7/7/2013 4:29 PM, Fred Zinsli wrote: > I have primary and secondary MX servers, but my secondary server is on > cable. My primary server is on the backbone. > > How can I configure my primary server to accept connections/mail from the > secondary server but still refuse connections/mail from all other cable > connections. You've said "cable" twice now, plus once in the subject. Postfix doesn't know what "cable" is. "We" don't know what "cable" is. Do you actually mean to say "dynamic IP address" here? Likewise, when you say "backbone" do you simply mean "static IP address"? This is a technical mailing list. We can't help you if you don't provide technically accurate information. If the backup MX indeed has a dynamic IP address then Wietse's suggestion obviously won't work for you and a different solution is needed. -- Stan
Re: Option to log clients that execute invalid commands or disconnect with no email delivery
On 6/28/2013 12:31 PM, John Fawcett wrote: > One type of connection which I cannot block in fail2ban are clients that > try the AUTH command on port 25, where I have disabled it. I got 245 > connections this morning in the space of 5 minutes and those are the > ones that got through despite the connection concurrency limit being hit > 277 times. In a span of 26 minutes on June 9th I got hit with parallel connections of this "AUTH bot" junk, totaling over 5,100, from a hacked Argentinian MX server. This with a concurrency limit of 4. That's just over 3 connections/second. Above you show less than 1 connect per second. ~$ zgrep " connect " /var/log/mail.log.3|grep -c 190.210.114.210 5116 ~$ zgrep "concurrency limit" /var/log/mail.log.3|grep -c 190.210.114.210 3755 Jun 9 11:01:17 greer postfix/smtpd[30422]: warning: Connection concurrency limit exceeded: 5 from mail.cqr.com.ar[190.210.114.210] for service smtp . Jun 9 11:27:43 greer postfix/smtpd[30525]: warning: Connection concurrency limit exceeded: 5 from mail.cqr.com.ar[190.210.114.210] for service smtp None were rejected. The client disconnected each time. ~$ zgrep reject /var/log/mail.log.3|grep -c 190.210.114.210 0 ~$ zgrep AUTH /var/log/mail.log.3|grep -c 190.210.114.210 1360 Looks like Anvil was responsible for the bulk of the disconnects. Anvil did its job preventing a DOS condition on smtpd. Even if these had progressed far enough to be rejected they'd still have not put significant load on the server. Thus the sum total negative impact of this attack on my MX is a bloated log. For me, personally, it's not worth the hassle to implement fail2ban simply to keep the log tidy. In your case John are you suffering anything more than a bloated log? Is one extra connect/second causing problems? -- Stan
Re: reject_unknown_client_hostname and 450s
On 6/30/2013 3:12 AM, LuKreme wrote: > When reject_unknown_client_hostname triggers on an NXDOMAIN it returns a 550 > error, which is great. When it triggers because there is no PTR record, it > returns a 450 error, which is also great… except. > > What I see is servers that connect hundreds of times, getting 450 errors and > ignoring them and trying to send their spam again and again and again. > > I have some IPs that have tried to connect hundreds of times to send a > message that is always going to generate a 450 error since the host does not > have a PTR record and never will. I have over 10,000 of these failures on an > average day. > > Does anyone have any suggestions? Hosts that have no PTR/rDNS are almost certainly end user broadband PCs. Which means the clients are likely spambots. They ignore rejections, and they do not retry. They simply keep pumping out new connections. If they're all currently being rejected, and are not tying up your smtpds, then as Noel suggested, simply ignore it. If single clients are using concurrent connections and eating too many smtpds then fail2ban is one option. Postscreen is another. Or... Postfix allows 50 concurrent connections per client by default with a max of 100 smtpds. Set smtpd_client_connection_count_limit to something like 10 and watch your log daily for a week or so to make sure you're not burdening legit clients. The proper value here, if any, depends on your mail flow. This will limit concurrent connections of all clients. -- Stan
Re: postfix rejecting valid mail server
On 6/29/2013 7:15 AM, Wietse Venema wrote: > T?ssio Fechine: >> What!? How the user running the client library affects DNS response? This >> makes no sense. > > This is a frequent problem with novice system administrators > who mess up file or directory access permissions. > > If a program doesn't run as root, then the tests should not > be done as root. And if I'm not mistaken, this kind of thing can also happen with a broken or poorly implemented chroot, wherein the resolver Postfix uses can be different than the resolver everything outside the Postfix chroot is using. I vaguely recall this happening to me many many years ago with Debian, when I modified /etc/resolv.conf and the change was not picked up in /var/spool/postfix/etc/resolv.conf. The two resolvers were returning different results so testing in a root shell with host and dig was counterproductive and masked the problem. Wietse helped me identify the chroot as the problem and I was able to track down how to fix it after I knew where to look. He is trying to do the same for you here. He is simply not spoon feeding you the complete answer, complete picture. He's pointing you in the right direction so you can do the rest of the sleuthing yourself. Some folks here will hold your hand start to finish at times. But for the most part I think most folks here try to be enablers, not function as consultants. This is all volunteer after all. -- Stan
Re: Local UNIX accounts, aliasing & rejecting mail to non-public UNIX accounts
On 6/22/2013 4:10 PM, Wietse Venema wrote: > I agree with Viktor's description: > > /etc/postfix/main.cf: > # The domain that users are aliased to: > mydestination = localhost localhost.$mydomain > > # The domain in DNS that you receive mail for: > vitual_alias_maps = example.com Shouldn't this be virtual_alias_domains here? > # The alias mapping from "DNS" domain name to UNIX system accounts: > virtual_alias_maps = hash:/etc/postfix/virtual > > /etc/postfix/virtual: > # All right-hand addresses have @localhost > postmas...@example.compostmaster@localhost > us...@example.com unix-user1@localhost > us...@example.com unix-user2@localhost > > # Legacy sendmail-style aliases: > /etc/aliases: > # Here, no @domain in LHS or RHS. > postmaster: unixaccount > abuse: unixaccount > > There is no need for this thread to drag on for so much time. Sorry for dragging it out a bit further Wietse. Just wanna make sure this is squared away for those searching the list archives, as folks read your posts as gospel. -- Stan
Re: Local UNIX accounts, aliasing & rejecting mail to non-public UNIX accounts
On 6/22/2013 6:13 AM, Craig R. Skinner wrote: ... > Stan's idea of a plain canonical domain & rejecting specific Unix > accounts via smtpd_recipient_restrictions check_recipient_access > reject_system_accounts.map works. Everyone whose replied in this thread knows and understands aliasing much better than I do. The only thing of value I think I can add at this point is that using a recipient restriction gives you some flexibility, maybe a greater degree of control. For one you can tailor the reject code and reason text on a per address basis in the map file. You can also use the same map to arbitrarily reject mail for any address in the future, should the need arise, though the latter is pretty quick to fix up in a pinch. Having the map in place simply makes it a little quicker. But the key is really that you're directly specifying which addresses for which you will reject inbound mail via smtp. There's no guesswork no matter what's going on in the back end WRT aliasing. -- Stan
Re: Local UNIX accounts, aliasing & rejecting mail to non-public UNIX accounts
On 6/19/2013 1:37 PM, Craig R. Skinner wrote:
> On 2013-06-19 Wed 10:55 AM |, Stan Hoeppner wrote:
>>
>> I'm anything but an expert in this particular area of Postfix, but I
>> think the problem is that Craig is trying to use virtual_alias_maps when
>> he should probably just be using the local aliases file. His Postfix
>> hosts a single mail domain IIUC.
>
> To start with at least.
>
>> He's simply wanting to create alias
>> addresses presented to the public for each local UNIX mailbox address.
>
> Correct.
>
>> Additionally he wants to reject any inbound mail destined for the actual
>> local UNIX addresses, as well as system/role accounts.
>
> Correct again.
>
>> These last two are straightforward. For the first:
>>
>> /etc/postfix/reject-local-system
>>
>> jb4...@example.com reject Unknown User
>> jb8...@example.com reject Unknown User
>> s...@example.com reject Unknown User
>> na...@example.comreject Unknown User
>> dove...@example.com reject Unknown User
>> sq...@example.comreject Unknown User
>> post...@example.com reject Unknown User
>>
>> and use
>> smtpd_recipient_restrictions
Note this is an smptd restriction.
>> ...
>> check_recipient_access hash:/etc/postfix/reject-local-system
>> ...
Thus this only applies to mail arriving via smtpd, not pickup, not pipe,
etc.
> $ for account in $(cut -d: -f1 /etc/passwd | grep -v master$); \
> do \
> print "${account}@example.com reject Unknown User" >> \
> /etc/postfix/reject-local-system.map; \
> done
>
> $ postmap
>
> $ postmap -q s...@example.com reject-local-system.map
> reject Unknown User
>
> main.cf:
> smtpd_recipient_restrictions =
> reject_non_fqdn_hostname
> reject_invalid_hostname
> reject_non_fqdn_sender
>
> ...
> ...
> check_recipient_access btree:$config_directory/reject-local-system.map
> ...
> ..
>
>
>>
>> To satisfy the second:
>>
>> jb4...@server1.example.com --> reject as unknown
>> jb8...@server2.example.com --> reject as unknown
>>
>> Simply do not put "$myhostname, localhost.$mydomain" in mydestination,
>> assuming $myhostname is an FQDN equal to "serverX.example.com". In fact
>> there's likely no need to have anything in mydestination other than your
>> domain name.
>>
>
> main.cf:
> mydestination = $mydomain
> # no virtual_alias_* stuff
>
>
>
> restart postfix and then system accounts are still getting mail;-
>
> $ uptime | sendmail post...@example.com
Note you are injecting the mail in this test with the sendmail
compatibility command, which does not involve the smtpd service.
> Jun 19 19:12:16 server1 postfix/pickup[2654]: 0776A6753: uid=1097 from=
> Jun 19 19:12:16 server1 postfix/cleanup[8207]: 0776A6753:
> message-id=<20130619181216.0776a6...@server1.example.com>
> Jun 19 19:12:16 server1 postfix/qmgr[8538]: 0776A6753:
> from=, size=344, nrcpt=1 (queue active)
> Jun 19 19:12:16 server1 dovecot: lmtp(9851): Connect from local Jun 19
> 19:12:16 server1 dovecot: lmtp(9851, postfix): Error: user
> _postfix: Initialization failed: Namespace '': mkdir(/var/mail/postfix)
> failed: Permission denied (euid=507(postfix) egid=507(postfix) missing +w
> perm: /var/mail, dir owned by 0:0 mode=0755)
> Jun 19 19:12:16 server1 dovecot: lmtp(9851): Disconnect from local: Client
> quit (in reset)
As you can clearly see in the logging, your test message entered Postfix
via the pickup service, not via smtpd. You are not testing properly.
Send the msg into smtpd and it will be rejected, as long as
check_recipient_access precedes any other user lookups, such as
reject_unknown_user
> $ uptime | sendmail us...@example.com
> Jun 19 19:12:33 server1 postfix/pickup[2654]: C90DB6765: uid=1097 from=
> Jun 19 19:12:33 server1 postfix/cleanup[8207]: C90DB6765:
> message-id=<20130619181233.c90db6...@server1.example.com>
> Jun 19 19:12:33 server1 postfix/qmgr[8538]: C90DB6765:
> from=, size=344, nrcpt=1 (queue active)
> Jun 19 19:12:33 server1 dovecot: lmtp(9851): Connect from local
> Jun 19 19:12:33 server1 dovecot: lmtp(9851, user1): w9hyI0r0wVF7JgAANm01jw:
> sieve: msgid=<20130619181233.c90db6...@server1.example.com>: stored mail into
> mailbox 'INBOX'
Same thing. Improper test using pickup instead of smtpd.
If you really want to restrict locally generated mail messages to such
address formats, we can address that later, but such a thing is probably
not necessary.
> My next thought is to rem
Re: Local UNIX accounts, aliasing & rejecting mail to non-public UNIX accounts
On 6/19/2013 10:16 AM, Wietse Venema wrote: > Craig R. Skinner: >> On 2013-06-19 Wed 06:51 AM |, Stan Hoeppner wrote: >>> On 6/19/2013 6:11 AM, Craig R. Skinner wrote: >>> >>> What happens when you try >>> >>> mydestination = >>> >> >> That's something I didn't think of trying. >> >> Either blank, or with localhost: >> >> status=bounced (User unknown in virtual alias table) > > This suggests that you had the domain name listed in both mydestination > and in virtual_alias_domains. Now you also need to remove the domain > name from virtual_alias_domains, in order to make that error go away. > > Until now Postfix will have logged numerous warnings with "do not > list domain X in both mydestination and virtual_alias_maps" to > remind you of a configuration error. Maybe it should just abort > deliveries, that might get people's attention. > > Wietse I'm anything but an expert in this particular area of Postfix, but I think the problem is that Craig is trying to use virtual_alias_maps when he should probably just be using the local aliases file. His Postfix hosts a single mail domain IIUC. He's simply wanting to create alias addresses presented to the public for each local UNIX mailbox address. Additionally he wants to reject any inbound mail destined for the actual local UNIX addresses, as well as system/role accounts. These last two are straightforward. For the first: /etc/postfix/reject-local-system jb4...@example.com reject Unknown User jb8...@example.com reject Unknown User s...@example.comreject Unknown User na...@example.com reject Unknown User dove...@example.com reject Unknown User sq...@example.com reject Unknown User post...@example.com reject Unknown User and use smtpd_recipient_restrictions ... check_recipient_access hash:/etc/postfix/reject-local-system ... To satisfy the second: jb4...@server1.example.com --> reject as unknown jb8...@server2.example.com --> reject as unknown Simply do not put "$myhostname, localhost.$mydomain" in mydestination, assuming $myhostname is an FQDN equal to "serverX.example.com". In fact there's likely no need to have anything in mydestination other than your domain name. -- Stan
Re: Local UNIX accounts, aliasing & rejecting mail to non-public UNIX accounts
On 6/19/2013 6:11 AM, Craig R. Skinner wrote: > > I'm setting up Postfix for a domain that hosts Dovecot IMAP mail dirs > for real Unix accounts. Postfix needs to accept mail for users' public > aliases, but not their Unix login, and reject mail for daemon accounts. > e.g: > > > joe.blo...@example.com--> jb4356 > jane.blos...@example.com --> jb8921 > postmas...@example.com--> postmaster > ab...@example.com --> postmaster > hostmas...@example.com--> hostmaster > > > The above are in /etc/passwd: > postmas...@example.com--> postmaster > hostmas...@example.com--> hostmaster > jb4...@example.com--> reject as unknown > jb8...@example.com--> reject as unknown > s...@example.com --> reject as unknown > na...@example.com --> reject as unknown > dove...@example.com --> reject as unknown > sq...@example.com --> reject as unknown > post...@example.com --> reject as unknown > > jb4...@server1.example.com --> reject as unknown > jb8...@server2.example.com --> reject as unknown > ... > ... > > > main.cf [part]: > mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain > myorigin = $mydomain > mail_spool_directory = /var/mail/ > mailbox_transport = lmtp:unix:private/dovecot-lmtp > local_recipient_maps = proxy:unix:passwd.byname $alias_maps > alias_maps = btree:$config_directory/aliases > alias_database = btree:$config_directory/aliases > local_transport = local:$myhostname > canonical_maps = btree:$config_directory/canonical.map > virtual_alias_domains = > btree:$config_directory/virtual_alias_domains.map > virtual_alias_maps = btree:$config_directory/virtual_alias_maps.map > > > $ cat virtual_alias_domains.map > example.com virtual > > > $ head virtual_alias_maps.map > postmasterpostmaster > abuse postmaster > hostmasterhostmaster > joe.blo...@example.comjb4356 > jane.blos...@example.com jb8921 > > > $ head canonical.map > hostmasterhostmas...@example.com > postmasterpostmas...@example.com > jb4356joe.blo...@example.com > jb8921jane.blos...@example.com > > > I've experimented with various settings and found that it works if I > list the valid public address mappings as virtual aliases, but Postfix > complains with: > postfix/trivial-rewrite[3585]: warning: do not list domain example.com in > BOTH mydestination and virtual_alias_domains. What happens when you try mydestination = > I've thumbed through 'The Book of Postfix' & the packaged HTML *READMEs. > The examples appear to be for either fully virtual accounts, or Unix > accounts where joe@ has a Unix account of 'joe'. > > There's probably something simple I'm not understanding here. Has happened to me on more than one occasion. ;) -- Stan
Re: Getting around Comcast Port 25 Block with a Local + Remote Postfix Server?
On 6/18/2013 11:43 AM, Steve Jenkins wrote: > That STILL sounds less simple than those four lines, but you make an > excellent point, Stan (as usual). I'll look into that in anticipation of > the next issue that will surely come up. :) Well sure, quick hacks are always easy. Call me a purist, "no frills", "efficiency freak", maybe "reliability freak", or just plain freak. ;) A few of salient points: 1. The header alone may be a kilobyte, for a msg body of a few dozen bytes--horrible overhead, a waste of resources. 2. An SNMP/syslog message will be one or two lines, a few dozen bytes 3. Comcast's SMTP relay may delay delivery due to any number of causes. You don't control it. You can't look at nor flush its queue. Do you need these alerts in real time? Guaranteed delivery? 4. SNMP/syslog is realtime. You control it. SNMP/syslog were designed specifically for this type of application. They are better suited. While using SMTP is not wholly inappropriate, it's far from optimal. And, is Comcast's relay infrastructure reliable in the long term for sending such alerts? -- Stan
Re: Getting around Comcast Port 25 Block with a Local + Remote Postfix Server?
On 6/18/2013 11:19 AM, Steve Jenkins wrote: > A good reminder that we often try to over-complicate things, and that the > simplest answer is often the best. :) You mean like using SMTP for a job best handled by SNMP or syslog? ;) IIRC both are supported by the "Gen 1" APC net cards. And given your description of Colo+home, setting up a site-to-site VPN between the two would not only fix this issue, but likely many to come up in the future. -- Stan
Re: how to stop massive email attack in Postfix
On 6/16/2013 12:59 PM, Viktor Dukhovni wrote: > On Sun, Jun 16, 2013 at 07:55:28AM -0500, Stan Hoeppner wrote: > >>> Looks more like a botnet, so the connections may not in fact recur. >> >> Quite right, it is a botnet attack. And without further logging, I'd >> guess this is a DOS attack on TCP 25. The clients are probably not even >> attempting delivery, but simply tying up TCP sockets. > > It could be a dictionary attack, or receiver-side DNS latency, or > greet pauses in the SMTP server, or delays due to sender or recipient > verification probes, or insufficient smtpd(8) concurrency to deal > with reasonable peak loads. It's a bit of a pity the OP didn't follow up and participate. Some interesting statistics surrounding this apparent botnet attack. I say "apparent" now because I'm beginning to think this may not have been the case at all. Of the 128 IPs he listed from netstat: 54 return NXDOMAIN [1] 50 would have been REJECTED by fqrdns.pcre [2] 128 listed by Zen with 127.0.0.4 (CBL) [3] 5 listed by Zen with 127.0.0.10 (PBL) [4] 108 listed by Zen with 127.0.0.11 (PBL) [5] reject_unknown_reverse_client_hostname would have rejected 54/128, 42%. That plus fqrdns.pcre, 104/128, 81%. These alone would have stemmed the tide. Now, assuming not all of these had yet hit the CBL, if the OP had been using Zen he'd have still rejected at least 113/128 of these because they were already listed in the PBL at the time of the event. It almost seems as if this Postfix simply had no A/S countermeasures configured at all. Either that or SA was installed assuming it would "just do it" by itself. Maybe one of those insane govt/corp policies that requires all spam to be archived? We can only guess without further input from the OP. ... > Carefully selected augmentation of the PBL may well be effective. > I also hope Stan or someone else reputable can from time to time > nominate particurly bot-active CIDR blocks consisting exclusively > of consumer-grade DHCP addresses for the PBL (send an email to a > contact at SpamHaus). As noted, the PBL already contains 113 of the IPs, and the CBL had all 128 either before and/or after this event, most likely before. 113 were dual listed in both the PBL and CBL. This tends to suggest the PBL listings are relatively old. The host in question apparently wasn't configured to use Zen. I have recommended netblocks for inclusion in the PBL in the past. These are taken under advisement. Note that the trap network feeding the CBL is vast, global, on the order of 1 million+ addresses across 10K+ domains in just about every country with IP transit. Thus Spamhaus have a much better view of where bots are emitting than me or just about anyone. AIUI, after some $_threshold, if a netblock has constant bot activity, and the provider hasn't voluntarily listed it, Spamhaus will. That's the difference between 127.0.0.11 (Spamhaus maintained) and 127.0.0.10 (ISP maintained). Of these 128 Spamhaus listed 108 of them, while ISPs only voluntarily listed 5. This is characteristic of South/Central America, and some other parts of the world. My perception is that in North America, Europe, and the English Commonwealth countries there's typically much larger PBL buy-in among ISPs, less so in other parts of the World. Note these are my perceptions based on word of mouth, personal connections, etc. I do not work for Spamhaus, nor do I speak on behalf of Spamhaus. -- Stan [1] $ grep -i nxdomain hostrdns.txt Host 155.200.192.2.in-addr.arpa. not found: 3(NXDOMAIN) Host 115.243.105.37.in-addr.arpa. not found: 3(NXDOMAIN) Host 151.140.42.77.in-addr.arpa. not found: 3(NXDOMAIN) Host 250.208.175.83.in-addr.arpa. not found: 3(NXDOMAIN) Host 93.105.162.90.in-addr.arpa. not found: 3(NXDOMAIN) Host 175.82.3.103.in-addr.arpa. not found: 3(NXDOMAIN) Host 3.128.166.109.in-addr.arpa. not found: 3(NXDOMAIN) Host 36.18.251.146.in-addr.arpa. not found: 3(NXDOMAIN) Host 116.195.152.181.in-addr.arpa. not found: 3(NXDOMAIN) Host 59.31.65.181.in-addr.arpa. not found: 3(NXDOMAIN) Host 59.31.65.181.in-addr.arpa. not found: 3(NXDOMAIN) Host 254.148.66.181.in-addr.arpa. not found: 3(NXDOMAIN) Host 196.192.66.181.in-addr.arpa. not found: 3(NXDOMAIN) Host 103.3.66.181.in-addr.arpa. not found: 3(NXDOMAIN) Host 37.101.67.181.in-addr.arpa. not found: 3(NXDOMAIN) Host 105.61.67.181.in-addr.arpa. not found: 3(NXDOMAIN) Host 224.72.72.181.in-addr.arpa. not found: 3(NXDOMAIN) Host 18.117.119.186.in-addr.arpa. not found: 3(NXDOMAIN) Host 66.0.46.186.in-addr.arpa. not found: 3(NXDOMAIN) Host 236.21.50.188.in-addr.arpa. not found: 3(NXDOMAIN) Host 176.16.52.188.in-addr.arpa. not found: 3(NXDOMAIN) Host 166.157.102.190.in-addr.arpa. not found: 3(NXDOMAIN) Host 88.38.209.190.in-addr.arpa. not found: 3(NXDOMAIN) Host 192.164.232.190.in-addr.arpa. not found: 3(NXDOMAIN) Hos
Re: how to stop massive email attack in Postfix
On 6/14/2013 11:19 AM, Viktor Dukhovni wrote: > On Fri, Jun 14, 2013 at 06:00:37PM +0200, Simon B wrote: > >> On 14 June 2013 17:44, c cc wrote: >>> >>> Hi, >>> >>> For the last few days, I noticed that our postfix server had crawl to a halt >>> due to some kind of email attack. As you can see below, there were a lot of >>> smtp connections. I was wondering if there is a way to stop this from >>> Postfix? Thanks! >>> >>> /etc/postfix $netstat -plan | grep ':25' | grep ESTAB >>> tcp0 0 xx.xx.xx.xx:25 181.66.192.196:11798ESTABLISHED >>> 17329/smtpd >>> tcp0 0 xx.xx.xx.xx:25 77.42.140.151:54112 ESTABLISHED - >>> tcp0 0 xx.xx.xx.xx:25 109.166.128.3:36208 ESTABLISHED - >>> tcp0 0 xx.xx.xx.xx:25 186.46.0.66:16698 ESTABLISHED >> >> Presumably they are connecting more than once? Fail2ban? > > Looks more like a botnet, so the connections may not in fact recur. Quite right, it is a botnet attack. And without further logging, I'd guess this is a DOS attack on TCP 25. The clients are probably not even attempting delivery, but simply tying up TCP sockets. > I would consider disabling reverse DNS resolution under stress. > Anything that reduces latency in the SMTP server. Also make sure > recipient lookups are fast (SAV and RAV may lead to concurrency > spikes, try to have static sources of recipient information). > > Also raise the number of smtpd(8) processes. The postscreen(8) > feature may help, but this is best with Postfix 2.10.0 or so. This is a scenario purpose built for postscreen, is it not? In lieu of postscreen, and in addition to Viktor's other suggestions, two simple restrictions may have greatly reduced the impact of this attack: 1. reject_unknown_reverse_client_hostname 2. http://www.hardwarefreak.com/fqrdns.pcre fqrdns.pcre is missing some of the rDNS patterns of those IPs, but contains many of them. I'll be adding the others in the near future. -- Stan
