Jump to content

More info needed


JGAdmin

Recommended Posts

Our server, for the first time EVER, was blacklisted by Spamcop on Friday. The IP address in question was 204.167.223.86. Is there any way to find out why we got BL'd?

Thanks!

37650[/snapback]

Well, you could start by reading the extensive FAQ here!

Oh, and by the way, it is now listed for the second time EVER. Read the FAQ and see what might be causing you to hit spamtraps - iff you're hitting them then you're almost certainly abusing some real live people too.

Link to comment
Share on other sites

Our server, for the first time EVER, was blacklisted by Spamcop on Friday. The IP address in question was 204.167.223.86. Is there any way to find out why we got BL'd?

37650[/snapback]

I took a look and discovered this snippet:

* System has sent mail to SpamCop spam traps in the past week (spam traps are secret, no reports or evidence are provided by SpamCop)

So, it would appear that spam is travelling through your mail server.

We'd have to know about how you connect up and send Email to say what might be the reason... It could be that you're bouncing Emails back to the forged sender addresses rather than rejecting the messages, you could have an infected computer on a network or...

Andrew

Link to comment
Share on other sites

I took a look and discovered this snippet:

    * System has sent mail to SpamCop spam traps in the past week (spam traps are secret, no reports or evidence are provided by SpamCop)

<snip>

37654[/snapback]

...Andrew probably looked at SpamCop CheckBlock for IP 204.167.223.86. On that page, clicking on the "Trace IP" link presents the following information:
SpamCop v 1.514 Copyright © 1998-2005, IronPort Systems, Inc. All rights reserved.

Parsing input: 204.167.223.86

host 204.167.223.86 = dalmail2.jenkens.com (cached)

Routing details for 204.167.223.86

[refresh/show] Cached whois for 204.167.223.86 : wklaus[at]jenkens.com

Using last resort contacts wklaus[at]jenkens.com

...SpamCop spam traps send no reports but if this IP was reported by any real SpamCop users, reports would have gone to wklaus[at]jenkens.com. The only way to retrieve more information about spam going to SpamCop spam traps is to contact the SpamCop deputies at e-mail address deputies[at]spamcop.net.

...Good luck!

Link to comment
Share on other sites

...Andrew probably looked at SpamCop CheckBlock for IP 204.167.223.86. On that page, clicking on the "Trace IP" link presents the following information:...SpamCop spam traps send no reports but if this IP was reported by any real SpamCop users, reports would have gone to wklaus[at]jenkens.com. The only way to retrieve more information about spam going to SpamCop spam traps is to contact the SpamCop deputies at e-mail address deputies[at]spamcop.net.

...Good luck!

37660[/snapback]

Ok, well for the record....

We use tightly locked down W2K servers with IIS/SMTP for our DMZ email servers, passing email to Exchange 5.5 (yes I know its old), also tightly locked down. We are not using KB 837794 at this time as NDRs have been helpful in the past. We have always sent on NDRs, and looking at the logs, that is the only thing I can figure out we are sending. Why would that trigger all of the sudden?

Link to comment
Share on other sites

Ok, well for the record....

We use tightly locked down W2K servers with IIS/SMTP for our DMZ email servers, passing email to Exchange 5.5 (yes I know its old), also tightly locked down. We are not using KB 837794 at this time as NDRs have been helpful in the past. We have always sent on NDRs, and looking at the logs, that is the only thing I can figure out we are sending. Why would that trigger all of the sudden?

37663[/snapback]

Just lucky I guess. Misdirected NDRs are a big problem, and unfortunately, in exchange 5.5 all you can do is turn them off entirely rather than setting it to reject the connection with a 550 message, which is generally just as helpful as an NDR, but is not abusive. I would very strongly recommend upgrading to windows 2003 server with exchange 2003. This also gives you the option of using Blacklists like SpamCop to protect your own users from spam.

Link to comment
Share on other sites

Just lucky I guess. Misdirected NDRs are a big problem, and unfortunately, in exchange 5.5 all you can do is turn them off entirely rather than setting it to reject the connection with a 550 message, which is generally just as helpful as an NDR, but is not abusive. I would very strongly recommend upgrading to windows 2003 server with exchange 2003. This also gives you the option of using Blacklists like SpamCop to protect your own users from spam.

37664[/snapback]

My last nerve... thanks for standing on it. I have been trying to get them to upgrade to 2003 for 2 years, with zero progress. Even now with it being EOL'd.

Crap.

Link to comment
Share on other sites

My last nerve... thanks for standing on it. I have been trying to get them to upgrade to 2003 for 2 years, with zero progress. Even now with it being EOL'd.

Crap.

37665[/snapback]

Well, maybe this will be the problem that pushes them over the edge and finally gets them to do the upgrade. Its made a huge difference for me. I've cut spam received in inboxes in my organization down to almost nothing from the several hundred per day PER inbox that was being seen prior to the upgrade. That improvement in productivity from having 30 people not spending an hour or more sorting their email has more than paid for upgrades to hardware and software to run Exchange 2003.

Link to comment
Share on other sites

Why would that trigger all of the sudden?

37663[/snapback]

It is very simple given the following chain of events:
  1. SpamCop posts hidden SpamCop Spamtrap Addresses on web pages.
  2. Spammer scrapes one of those web pages and finds a SpamCop Spamtrap Address.
  3. Spammer sends a spam message to one of your existent but NDR-invoking email addresses using the Spamtrap Address as the SMTP Envelope Sender (MAIL FROM) and/or From and/or Errors-To Address.
  4. The spam message first goes to one of your four configured mailservers at Postini (although it could go directly to your bastion host, bypassing the next step).
  5. Postini passes the message on to one of your bastion hosts for some reason (not spammy enough), because it doesn't completely know which of your addresses to bounce with a 500-series error.
  6. Your bastion host blindly sends the message on to your real mailserver.
  7. Your real mailserver sends a bounce message (NDR) to its smarthost dalmail2.jenkens.com [204.167.223.86].
  8. dalmail2.jenkens.com [204.167.223.86] sends the bounce message on to a mailserver which delivers the bounce message to a SpamCop Spamtrap.
  9. dalmail2.jenkens.com [204.167.223.86] gets listed by the SCBL for 24 hours for sending a message to a SpamCop Spamtrap.

By "completely", I mean ALL conditions that could cause NDRs (like mailbox full), not just nonexistence of user account.

Also, it appears that you don't have a working abuse[at]jenkens.com address. Please see http://www.rfc-ignorant.org/policy-abuse.php and http://www.rfc-ignorant.org/tools/lookup.p...ain=jenkens.com, create a working abuse[at]jenkens.com address (account or alias), and notify update[at]abuse.net of its existence. Thanks!

Link to comment
Share on other sites

Misdirected NDRs are a big problem, and unfortunately, in exchange 5.5 all you can do is turn them off entirely rather than setting it to reject the connection with a 550 message

37664[/snapback]

My guess is that you should switch off NDRs for the time being. As Telarin notes, a misdirected report can lead to a rapid listing of your outgoing mail server.

Andrew

Link to comment
Share on other sites

It is very simple given the following chain of events:
  1. SpamCop posts hidden SpamCop Spamtrap Addresses on web pages.
  2. Spammer scrapes one of those web pages and finds a SpamCop Spamtrap Address.
  3. Spammer sends a spam message to one of your existent but NDR-invoking email addresses using the Spamtrap Address as the SMTP Envelope Sender (MAIL FROM) and/or From and/or Errors-To Address.
  4. The spam message first goes to one of your four configured mailservers at Postini (although it could go directly to your bastion host, bypassing the next step).
  5. Postini passes the message on to one of your bastion hosts for some reason (not spammy enough), because it doesn't completely know which of your addresses to bounce with a 500-series error.
  6. Your bastion host blindly sends the message on to your real mailserver.
  7. Your real mailserver sends a bounce message (NDR) to its smarthost dalmail2.jenkens.com [204.167.223.86].
  8. dalmail2.jenkens.com [204.167.223.86] sends the bounce message on to a mailserver which delivers the bounce message to a SpamCop Spamtrap.
  9. dalmail2.jenkens.com [204.167.223.86] gets listed by the SCBL for 24 hours for sending a message to a SpamCop Spamtrap.

By "completely", I mean ALL conditions that could cause NDRs (like mailbox full), not just nonexistence of user account.

Also, it appears that you don't have a working abuse[at]jenkens.com address.  Please see http://www.rfc-ignorant.org/policy-abuse.php and http://www.rfc-ignorant.org/tools/lookup.p...ain=jenkens.com, create a working abuse[at]jenkens.com address (account or alias), and notify update[at]abuse.net of its existence.  Thanks!

37667[/snapback]

Ok, fixing the Abuse addy now.

Is there anyway besides the hotfix to turn off NDRs in Exchange 5.5? I have to go through a lengthy change control process to add a patch or fix...

Roger

Link to comment
Share on other sites

Ok, fixing the Abuse addy now.

37669[/snapback]

Thanks!
Is there anyway besides the hotfix to turn off NDRs in Exchange 5.5? I have to go through a lengthy change control process to add a patch or fix...

37669[/snapback]

Sorry, not that I know of. I recommend avoiding sending misdirected bounces by avoiding sending NDRs entirely, specifically by applying "Update available in Exchange Server 5.5 to control whether the Internet Mail Service suppresses or delivers NDRs" per http://support.microsoft.com/default.aspx?...kb;en-us;837794 and using "Value data" of "10".

Another option may be to have your smarthost(s) eat NDRs destined for the Internet.

While you are going though the change control process, please make sure that you apply all available security, OS, BIOS, and firmware patches to all servers under your control. This time of year may be especially advantageous for patch application with extra budget money, especially if you are willing to do it (and your family is willing to do without you) a week from next Sunday at double or triple overtime. :)

Link to comment
Share on other sites

We have always sent on NDRs, and looking at the logs, that is the only thing I can figure out we are sending. Why would that trigger all of the sudden?

37663[/snapback]

Because at least one of the messages you returned was addressed to one of spamcop's spamtrap addresses. Most of the other messages are probably addressed to innocent third parties who could also report those messages as spam.
Link to comment
Share on other sites

This time of year may be especially advantageous for patch application with extra budget money, especially if you are willing to do it (and your family is willing to do without you) a week from next Sunday at double or triple overtime. :)

37670[/snapback]

Overtime??? Who gets overtime???
Link to comment
Share on other sites

Thanks!Sorry, not that I know of.  I recommend avoiding sending misdirected bounces by avoiding sending NDRs entirely, specifically by applying "Update available in Exchange Server 5.5 to control whether the Internet Mail Service suppresses or delivers NDRs" per http://support.microsoft.com/default.aspx?...kb;en-us;837794 and using "Value data" of "10".

Another option may be to have your smarthost(s) eat NDRs destined for the Internet.

While you are going though the change control process, please make sure that you apply all available security, OS, BIOS, and firmware patches to all servers under your control.  This time of year may be especially advantageous for patch application with extra budget money, especially if you are willing to do it (and your family is willing to do without you) a week from next Sunday at double or triple overtime. :)

37670[/snapback]

Overtime... LOL.

Naw, we do monthly outages and apply all patches, etc. We do not apply hotfixes that are not mandatory, which is why we missed this one and I have requested that we apply it and set it to 10. May not occurr at first, but I have hopes. :)

Our problem was OOOR's for a group of departed employees, who had to keep a email presence and who for budgetary reasons, were dropped from Postini. This meant that all the email they received got an Out Of Office Reply and one was undoubtedly a spamcop spamtrap address. We've put them back on Postini and turned the filters to high, so hopefully that is fixed. If not, then disableing OOOR to internet will be next, followed by NDR elimination (if I know my management, anyway).

Thanks for the help.

Roger

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...