Christopher Wagner wrote Thursday, February 27, 2003 13:11 > Recipient address rejected: Relay access denied; > from=<wf97vp1tl4at_private> to=<jgerfenat_private> > Feb 25 07:12:35 goober postfix/smtpd[31398]: reject: RCPT from > ppp-63-205-146-45.calvarycc.org[63.205.146.45]: 554 > <jgerkeat_private>: > Recipient address rejected: Relay access denied; > from=<wf97vp1tl4at_private> to=<jgerkeat_private> > And so on.. They seem pretty determined to relay, I dunno why, it ain't > gonna happen. This seems to happen once a month or so, obviously from a > variety of addresses. It almost looks suspiciously like these various > machines have either been hacked or they're hiring out their bandwidth to a > spammer. I've been bombarded by these types of distributed spam runs, too. All of the offending computers that I investigated belonged to known spam networks and were also individually listed in various RBLs. So in my case your second option appears most likely. Spam is very profitable, so I expect that some spamhauses maintain worldwide networks of relays and proxies in addition to taking advantage of any open box they can connect through. I also expect that multiple spamhauses sometimes pool their resources in pursuit of the $. > Any suggestions for tracking this down or should I just ignore it? It's not > a real drain on my bandwidth or server capacity, the frequency isn't > bothersome, just the log entries get annoying after awhile. It doesn't help > matters by having all the sources be out of the US, it makes it more > difficult to track down. I generally end up ignoring the traffic unless it becomes overly irritating. If the relayers belong to a spamhaus, complaints will not do any good. Upstream ISPs are sometimes responsive unless they too have a stake in the spam. You might have to go more than one level upstream. If you are going to try to complain, I suggest extra research into the trustworthiness of the abuse contact. Spammers can be very vindictive so you don't want to end up complaining to the spammers themselves. If you don't already, you might save yourself some bandwidth and some headaches by implementing DNSBL so known relays and proxies can't get their initial connection. Of course every blocking method has its pluses and minuses, and its own set of possible headaches. ---------------------------------------------------------------------------- <Pre>Lose another weekend managing your IDS? Take back your personal time. 15-day free trial of StillSecure Border Guard.</Pre> <A href="http://www.securityfocus.com/stillsecure"> http://www.securityfocus.com/stillsecure </A>
This archive was generated by hypermail 2b30 : Wed Mar 05 2003 - 08:25:28 PST