In a large multi-datacenter environment you can't login to each users servers and tail their logs to see who's forwarding :( . I'm more of a windows person, but when working with a client on Linux using EXIM I think I did fgrep yahoo.com /etc/valiases/* > yahoo-fwds.txt Something like that to get a list of all of the addresses that forward to Yahoo...I think they used CPanel on their server too. Other then that I believe I was grepping through other clients logs for the most popular Yahoo email addresses... I think that if they are going to do CIDR blocks they should at least keep logs as to what caused them to escalate it to that not simply say 'it's your network you figure it out..' -Ray -----Original Message----- From: Chris Stone [mailto:cstone@axint.net] Sent: Thursday, April 10, 2008 4:08 PM To: Raymond L. Corbin Cc: nanog@merit.edu Subject: Re: Problems sending mail to yahoo? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Raymond L. Corbin wrote:
Yeah, but without them saying which IP's are causing the problems you can't really tell which servers in a datacenter are forwarding their spam/abusing Yahoo. Once the /24 block is in place then they claim to have no way of knowing who actually caused the block on the /24. The feedback loop would help depending on your network size. When you have a few hundred thousand clients, and those clients have clients, and they even have client, it simply floods your abuse desk with complaints from Yahoo when it is obviously forwarded spam. So it's more of pick your poison deal with customer complaints about not being able to send to yahoo for a few days or get your abuse desk flooded with complaints which hinders solving actual issues like compromised accounts.
I look at all my mail server log files and see which logs show obvious spam being forwarded (a lot of times the MAIL FROM address is a dead giveaway) or I tail -F the mail log for a bit and watch the spam coming in and forwarding back out. When I see the forwarding domain that's who I have contacted to upsell some spam filtering. But, we're a small ISP, so I don't have thousands, let alone hundreds of thousands of clients, to deal with... Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFH/nORnSVip47FEdMRCi+HAJ9CJoJ/VAkEssv6TznwcYQVGVWkIACfRwhI VYw0v4HWI8mWs2SHEF3jnq0= =YMQR -----END PGP SIGNATURE-----