Unknown senders and spam
in [Postfix]
|
Prev: Question about bounce related spam
Next: Wanting incoming and outgoing e-mail montiroed for spam andvirii
From: Alex on 18 Apr 2010 17:45 Hi, >> Is it common practice to have that restriction in a production environment? >> >> It appears to be the third case here, that the name->address mapping >> does not match the client IP address. Could this be from a legitimate >> cause, or typically intentionally to be evasive? >> > > since they put their domain name in their HELO (zaphod.chipchaps.com), > they're not trying to evade anything. Yes, I guess they would have been rejected as a result of my helo checks. > you could try > > check_client_access hash:/etc/postfix/access_unknown > > > smtpd_restriction_classes = > ... > policy_strong > > policy_strong = > reject_rbl_client bb.barracudacentral.org Is it possible to use maps_rbl_domains instead of reject_rbl_client here? It appears this machine has a version of postfix that doesn't understand reject_rbl_client. Thanks again! Best regards, Alex
From: Stan Hoeppner on 18 Apr 2010 18:36 Alex put forth on 4/18/2010 4:45 PM: > Is it possible to use maps_rbl_domains instead of reject_rbl_client > here? It appears this machine has a version of postfix that doesn't > understand reject_rbl_client. maps_rbl_domains (default: empty) Obsolete feature: use the reject_rbl_client feature instead. reject_rbl_client rbl_domain=d.d.d.d .... *** This feature is available in Postfix 2.0 and later. *** (emphasis mine) Your statement leads me to believe you're using a Postfix version less than 2.0. IIRC, versions less than 2.3 are no longer supported. It appears you _really_ need to upgrade Postfix on that host. And given that it's likely a distribution package, you probably really need to update the OS on that host as well. -- Stan
From: Alex on 18 Apr 2010 19:43 Hi, > maps_rbl_domains (default: empty) > > Obsolete feature: use the reject_rbl_client feature instead. Yes, that was why I was asking. It's a really old version of postfix I'm still using on this host for now, until I can migrate to an entirely new server and at the same time keep this one running. I just wanted to confirm that this feature, or an equivalent, isn't available in old versions of postfix? Thanks, Alex
From: Wietse Venema on 18 Apr 2010 20:36 Alex: > Hi, > > > maps_rbl_domains (default: empty) > > > > ? ?Obsolete feature: use the reject_rbl_client feature instead. > > Yes, that was why I was asking. It's a really old version of postfix > I'm still using on this host for now, until I can migrate to an > entirely new server and at the same time keep this one running. > > I just wanted to confirm that this feature, or an equivalent, isn't > available in old versions of postfix? If in doubt read the documentation. man 5 postconf ... reject_rbl_client rbl_domain=d.d.d.d ... This feature is available in Postfix 2.0 and later.
From: /dev/rob0 on 18 Apr 2010 22:56
Note: just before sending this I went back to read the rest of the thread, wherein I see that you're using a pre-2.0 Postfix. Some of my advice below is thereby not relevant to this host, namely, the suggestion to use newer syntax and the newer restriction, reject_unknown_reverse_client_hostname. IMO that would be worth an upgrade. On Sun, Apr 18, 2010 at 02:19:15PM -0400, Alex wrote re: reject_unknown_client_hostname : > Is it common practice to have that restriction in a production > environment? Recently I had a failure of reverse DNS at my colo provider. It went some days before I was aware of the issue (it's a small site and I don't monitor the logs.) When I discovered the issue, I found a lot of mail in the queue, but few outright 5xx rejections had been done. Temporary rejections were occurring from numerous large providers, including Gmail, AOL, Yahoo, and Comcast. I temporarily shut down outbound mail and set up a relayhost while the provider fixed the rDNS issues (my PTR query was returning NXDOMAIN during this time.) Note, from the documentation suggested for you, that there are different conditions which trigger reject_unknown_client_hostname. Mine was lack of PTR, which also triggers the less aggressive reject_unknown_reverse_client_hostname restriction. This is fairly common, and IMO, a pretty likely spam sign. Given my experience, I think it is time to use reject_unknown_reverse_client_hostname. At least you know you're not alone in enforcing that policy. Another condition is when there is a PTR, but the name given does not resolve. This, too, is not unusual. But IMO it's probably less likely a spam sign. You might block a few sites where the understanding of DNS and mail issues is not so strong. A third condition is when the PTR name resolves to a different IP address. This is arguably the "worst" case, because it could mean that a spammer or scammer/spammer is trying to spoof a legitimate domain. IRL this is not usually the case; more likely just another poorly managed site. Most spam is going to come from malware-infected Windows machines or other compromised hosts being used as a zombie. There are many useful strategies in dealing with those, including Spamhaus Zen and reject_non_fqdn_helo_hostname. reject_unknown_reverse_client_hostname is also very effective, as I think some ISPs might deliberately not provide reverse DNS for their dynamic ranges. Most of the rest of it is going to come from large "snowshoe" ranges. These networks will typically have perfect FCrDNS for every IP address. > It appears to be the third case here, that the name->address mapping > does not match the client IP address. Could this be from a legitimate > cause, or typically intentionally to be evasive? > > Could it be found in a legitimate dynamic environment, such as at an ISP? > > Is there a way to log these specific failures so I can get a better > idea of under what circumstances they occur in my environment? > > I'm currently rejecting the following, in this order: > > reject_non_fqdn_sender, Reasonable, not going to block much; not likely to block any spam, but the mail it blocks is mail you should not accept anyway. > reject_non_fqdn_recipient, Harmless but useless. > reject_unknown_sender_domain, ditto reject_non_fqdn_sender > reject_unknown_recipient_domain, Harmless but useless. Who is giving you invalid recipients at this point? > reject_unauth_pipelining, Might catch some zombies. > reject_invalid_hostname, Old syntax, ditto reject_non_fqdn_sender except might also catch a zombie here and there. > reject_non_fqdn_hostname, Old syntax, very effective against zombies, safe and reasonable. > reject_unauth_destination, (Necessary, no comment needed.) > reject_maps_rbl, Old syntax, could be good or could be disastrous. Switch to the "new" syntax (new since Postfix 2.0 IIRC) of "reject_rbl_client zone.name". At this point I'm only using zen.spamhaus.org, but I might be adding spameatingmonkey. Most important advice regarding DNSBLs is to be familiar with their policies and aware of their status. Given the dominance of ancient syntax in your restrictions, I wouldn't be surprised to see some dead lists among your maps_rbl_domains. :) -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header |