On Tue, May 27, 2014 16:26, Marius Gologan wrote: > > Whois should definitely not be implemented in automated systems - read ToS > of RIPE, ARIN, LACNIC etc. > A special-made milter that will dig for details during the connection time > is not applicable. > A secondary benefit of greylist is IP rotation. That will provide you an > insight about some networks , IP ranges and ISPs. > Registrars or hosting providers are not behind attacks, but they play a key > role in providing resources and delisting - notice the delisting rules of > some popular RBLs for IP classes. Now are there, next day are gone despite > their own retention policy.
In my case I have a reasonable doubt that the registrar involved is entirely innocent. In fact, on the balance of probabilities I rather think not. However, the technique used in these recent spam attacks is that the domains are registered the same day, in some cases the same hour, that the UCE arrives and they are discarded within hours of their first use. It seems that most greylist/blackhole lists are incapable of reacting in such a brief window. > > I would go with reputation (mine or a third-party - the decision depends on > the messages volume) since some registrars are less tolerable than others, > volume and percentage are important too. I am not sure what this means so I have to ask you to explain it to me. I apologise in advance if I appear thick. > For example, you don't want to block domains registered with godaddy just > because they might have some spamming domains there. I am not out to block every registrar, or even most, and hopefully not even a considerable number. Right now it is only one. Based on recent experience I would settle for a timely entry in DOB, but it is not reasonable to expect them to add newly minted domain names within minutes of their registration. > > You can adjust the scoring in spamassassin for uribl.com if you want > to be more aggressive. As a fast doable solution, I would prefer a > custom meta rule (uribl.com & bayes_90+ & pyzor - maybe) and a > shortcircut rule to reduce resources and time. I have examined the messages and actually followed the links contained in some. What is happening is that the same fresh domain is used throughout the UCE and when one follows the message links then javascript is used to redirect one to the desired end address. uribl is no more likely to have the URIs contained in the messages than DOB and for the same reason. The URIs simply did not exist four to eight hours ago, were never used before and will not be used again, at least not for UCE. One at least has been re-purposed as a watering-hole trap. > Plus a script that will collect all those IPs/Domains and put them into > postfix or rbldnsd to reject next connections more efficiently. Yes, I suppose the easiest thing is to simply count the connections and after N then block further receipts from these domains. However, I have observed by visual inspection of the maillog that the UCE originating domains are rotated while sending so that one might have difficulty in picking a suitable time period to match domain connections within. > > Geographic rules may help reducing spam, but not in all cases. > Too many non-existing recipients is also a sign of spam. You can turn some > of them into spam traps. > The domains that I bothered to trace had mail sent from servers in the Czech Republic, Columbia, the USA, Canada, Taiwan, Vietnam, and Mexico. I presume that the dozens that I did not check originate from an equally diffuse collection of places. The non existent addresses is likely a fruitful line to pursue. Is it possible to configure Postfix as shipped to automatically add a connecting IP address to a block list based upon the address that it is attempting delivery to? And then thereafter simply disregard connection attempts from the same source? Thanks, -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:byrn...@harte-lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
