|
FreeBSD Ports and Packages Installation and upgrading of ports and packages on FreeBSD. |
|
Thread Tools | Display Modes |
|
|||
Recent problems with Postfix
I've been having a problem that's been a bit perplexing to me. Over
the last few weeks, it seems that postfix-policyd-weight and postgrey have not been processing messages, even though I should have postfix set up properly to do so. As such, I've seen a marked increase in spam that's getting through. I'll be happy to answer any questions and provide as much information as I can to get this problem resolved. The only thing I can think of is a few months ago I upgraded postfix, first from 2.5.1_2 to 2.5.4,1 (Aug 22nd) then to 2.5.5,1 (Oct 6th). I also updated postgrey from 1.31 to 1.32 on Aug 26th. I have not updated postfix-policyd-weight (no updates available since installed in April). I'm using FreeBSD. There have been no other changes that I'm aware of. I've rolled back Postfix to 2.5.1_2 and postgrey to 1.31 (both versions were known to work) and it still appears that it wasn't working. Below are a few bits of (hopefully) important information: uname -r 7.0-RELEASE-p5 smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, permit_mx_backup, reject_unauth_pipelining, 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, reject_unverified_recipient, reject_rbl_client list.dsbl.org, reject_rbl_client sbl.spamhaus.org, reject_rbl_client cbl.abuseat.org, reject_rbl_client dul.dnsbl.sorbs.net, check_policy_service inet:127.0.0.1:60001, check_policy_service inet:127.0.0.1:10023, permit From what I can tell the RBL lookups are not taking place either. The prior reject_* rules appear to be working: Oct 25 02:54:13 fb1 postfix/smtpd[1862]: NOQUEUE: reject: RCPT from ip-88-199-176-164.tczew.net.pl[88.199.176.164]: 504 5.5.2 <xyz-2sggsf7qwk1>: Helo command rejected: need fully-qualified hostname; from=<fsdxtxi@bos.mcd.mot.com> to=<<email removed>> proto=ESMTP helo=<xyz-2sggsf7qwk1> I'm completely baffled by this. I can verify that the proper services are running on their respective ports: postgrey perl5.8.8 698 5 tcp4 127.0.0.1:10023 *:* polw perl5.8.8 758 4 tcp4 127.0.0.1:60001 *:* Any help would be grealy appreciated. Let me know if you need any more details/configuration information. Thanks for any help you can provide.
__________________
I just saved a bunch of money on my car insurance by fleeing the scene of the accident! |
|
|||
You can check whether you server is doing RBL lookups (a kind of DNS lookups) by running tcpdump
Code:
tcpdump -ni bge0 'port 53' According to http://wiki.centos.org/HowTos/postgrey the greylisting is rather easy to spot in the maillogs.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump |
|
|||
My net adapater is em0, but I got what you meant
Strange... Code:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes 06:03:04.089551 IP 10.9.0.1.54207 > 10.0.0.1.53: 37557+ PTR? 19.73.94.192.in-addr.arpa. (43) 06:03:04.209472 IP 10.0.0.1.53 > 10.9.0.1.54207: 37557 1/0/0 (73) 06:03:04.209801 IP 10.9.0.1.54646 > 10.0.0.1.53: 37558+ A? mx.freeshell.org. (34) 06:03:04.351025 IP 10.0.0.1.53 > 10.9.0.1.54646: 37558 1/0/0 A 192.94.73.19 (50) 06:03:04.722480 IP 10.9.0.1.50895 > 10.0.0.1.53: 37559+ MX? sdf.lonestar.org. (34) 06:03:04.807629 IP 10.0.0.1.53 > 10.9.0.1.50895: 37559 1/0/0 MX[|domain] You're right, greylisting is very easy to spot in the mail logs... and it's gone I have a cgi script that checks the mail logs for the last week and counts up the number of greylisted emails. I would help if I would check it occasionally, as it shows a big "0" which should have been a clue something wasn't working right (after all, not every email can be white-listed...).
__________________
I just saved a bunch of money on my car insurance by fleeing the scene of the accident! |
|
|||
The tcpdump snippet you posted does not do RBL lookups.
The first one (PTR?) is a reverse lookup (IP address -> name). The second one (A?) asks for the IP address of mx.freeshell.org. Third and last asks for the Mail eXchanger (MX?) or SMTP server for the sdf.lonestar.org. domain. A RBL query for 192.94.73.19 at zen.spamhaus.org looks like this Code:
192.168.222.20.24544 > 192.168.222.10.53: 27286+ A? 19.73.94.192.zen.spamhaus.org. (47) 192.168.222.10.53 > 192.168.222.20.24544: 27286 NXDomain* 0/0/0 (47) An example of an IP address that has been listed: Code:
$ blcheck.sh 92.101.76.6 IP 92.101.76.6 NAME ip-006-076-101-092.pools.atnet.ru. 2008-10-29_00:39:49_UTC 6.76.101.92.cbl.abuseat.org. 127.0.0.2 2008-10-29_00:39:49_UTC 6.76.101.92.dnsbl.sorbs.net. 127.0.0.7 2008-10-29_00:39:49_UTC 6.76.101.92.bl.spamcop.net. 127.0.0.2 2008-10-29_00:39:49_UTC 6.76.101.92.zen.spamhaus.org. 127.0.0.11 127.0.0.4 2008-10-29_00:39:49_UTC 6.76.101.92.combined.njabl.org. --- Code:
sudo tcpdump -ni bge0 -s512 port 53 192.168.222.20.41580 > 192.168.222.10.53: 44311+ PTR? 6.76.101.92.in-addr.arpa. (42) 192.168.222.10.53 > 192.168.222.20.41580: 44311 1/0/0 PTR ip-006-076-101-092.pools.atnet.ru. (89) 192.168.222.20.11188 > 192.168.222.10.53: 39105+ A? 6.76.101.92.cbl.abuseat.org. (45) 192.168.222.10.53 > 192.168.222.20.11188: 39105 1/0/0 A 127.0.0.2 (61) 192.168.222.20.16514 > 192.168.222.10.53: 6322+ A? 6.76.101.92.dnsbl.sorbs.net. (45) 192.168.222.10.53 > 192.168.222.20.16514: 6322 1/0/0 A 127.0.0.7 (61) 192.168.222.20.1968 > 192.168.222.10.53: 16255+ A? 6.76.101.92.bl.spamcop.net. (44) 192.168.222.10.53 > 192.168.222.20.1968: 16255 1/0/0 A 127.0.0.2 (60) 192.168.222.20.6546 > 192.168.222.10.53: 55003+ A? 6.76.101.92.zen.spamhaus.org. (46) 192.168.222.10.53 > 192.168.222.20.6546: 55003 2/0/0 A 127.0.0.11, A 127.0.0.4 (78) 192.168.222.20.48966 > 192.168.222.10.53: 11236+ A? 6.76.101.92.combined.njabl.org. (48) 192.168.222.10.53 > 192.168.222.20.48966: 11236 NXDomain* 0/0/0 (48)
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump |
|
|||
I managed to get everything working again after removing the lines:
permit_sasl_authenticated, permit_mx_backup, From the recipient_restrictions. Now I need to figure out why. I'm thinking it has something more to do with the sasl authentication than the mx backup line. Currently I use dovecot as the POP3/IMAP server, and also for sasl authentication. Back to the drawing board. At least my anti-spam rules are working again! I should see a marked decrease in spam now.
__________________
I just saved a bunch of money on my car insurance by fleeing the scene of the accident! |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Intesting reading on recent X11 changes | vermaden | General software and network | 4 | 14th May 2009 03:39 AM |
Problems with Postfix virtual domains | juris98 | General software and network | 2 | 11th February 2009 12:14 AM |
Postfix error on 7.1 | windependence | FreeBSD Ports and Packages | 3 | 2nd February 2009 10:42 AM |
Postfix exporting | skywalker | FreeBSD Ports and Packages | 4 | 11th June 2008 11:40 AM |
Need Help Configuring Postfix | iainnitro | General software and network | 6 | 8th June 2008 04:55 AM |