can't figure out why this is rejected

[cummings]

these are the headers from an email rejected by spamcop.

Remote host said: 521 Mail rejected - you are listed in Spamcop (spam) [FREE] - http://spamcop.net/bl.shtml

--- Below this line is a copy of the message.

Received: (qmail 3726 invoked from network); 29 Jul 2005 16:48:39 -0000

Received: from unknown (HELO tco-lat-exbh2.TRIBUNE.AD.TRB) (172.24.24.26)

by queue1.tis-in.trb with SMTP; 29 Jul 2005 16:48:39 -0000

Received: from tco-chi-exbh2.TRIBUNE.AD.TRB ([163.194.253.42]) by tco-lat-exbh2.TRIBUNE.AD.TRB with Microsoft SMTPSVC(6.0.3790.0);

Fri, 29 Jul 2005 09:48:40 -0700

Received: from TPC-HRT-EXMB1.TRIBUNE.AD.TRB ([192.168.36.70]) by tco-chi-exbh2.TRIBUNE.AD.TRB with Microsoft SMTPSVC(5.0.2195.6713);

Fri, 29 Jul 2005 11:48:34 -0500

the 192 and 172 numbers are not routable, so i put in the 163 IP to bl.shtml and it is not listed.

any ideas?

i have spamcap disabled until i can resolve this, and i'm suffering.

thank you.

[Jeff G.]

What mailserver generated the bounce email message you received? Can you please provide more info from the headers of the email message that bounced, especially more Received Header Lines and the intended recipient's domain name? Whatever mailserver that was, was not following SpamCop's recommendations for the use of the SCBL (SpamCop Blocking List) as per How do I configure my mailserver to reject mail based on the blocklist? and How do I configure my mailserver to reject mail based on the blocklist? : Sendmail, in particular the "$&{client_addr" bit.

In addition, please be aware that "TRB" is not a valid TLD (Top Level Domain).

Thanks!

[StevenUnderwood]

To start with, not enough information but I will work with what I have.

these are the headers from an email rejected by spamcop.

Remote host said: 521 Mail rejected - you are listed in Spamcop (spam) [FREE] - http://spamcop.net/bl.shtml

/i]

the 192 and 172 numbers are not routable, so i put in the 163 IP to bl.shtml and it is not listed.

30943[/snapback]

You don't say whether this is your original message being rejected by an external source or an incoming message you are rejecting at your servers (which would explain you turning off spmacop on your end).

In any case, that error message leaves a lot to the imagination. It should be spelling out exactly the host causing the problem rather than making the sender try and figure it out. With that quality, it may not even be spamcop causing the main problem but just a general message that is put no matter the reason for the block.

Does it make sense that your email would travel from the tribune.com network (where spamcop wants to report that 163 address)?

If this is a tribune message going to another tribune account, why are blocklists even being used. Also, perhaps the non routable IP's are causing the block in that instance.

Enough to start on.

[turetzsr]

these are the headers from an email rejected by spamcop.

<snip>

30943[/snapback]

...This may be a bit pedantic in the context of your question, but for the benefit of others I think it's important to point out that SpamCop did not reject the e-mail -- the "Remote host" did, alleging that "you are listed in Spamcop."

[GraemeL]

If you still can't figure it out after going through what StevenUnderwood said, then how about this?

Is the machine with the non-routable address 172.24.24.26 multi-homed with a second, routable, interface? If so, find that routable address and check to see if it's listed.

[Jeff G.]

In addition, use of a nonroutable public IP Address with a nonpublic name is not exactly conducive to successful SpamCop Parsing - generally, external/extranet bastion hosts should have legitimate names and IP Addresses to promote successful Parsing of spam received through them, and internal mailservers can have whatever nonpublic names they want, but should have RFC1918-compliant private IP Addresses to encourage the Parser to skip them.

[Jeff G.]

A few more things:

It is much easier for humans and the Parser to understand the situation when multi-homed mailservers use and call themselves their public names and IP Addresses in their Received Header Lines and when composing notifications.

Why is the fourth host in the chain blocking mail using the SCBL? If blocking (vs. tagging) is to be done at all, it should be done by the mailserver(s) with the IP Address(es) of the name(s) of the organization's MX(s), in this case probably smtp{1-4}.tribune.com, as follows:

smtp1.tribune.com 163.192.2.12 (calls itself smtp1.tt.xnet.trb)

smtp2.tribune.com 144.142.3.135 (protected by a slow obfuscatory firewall)

smtp3.tribune.com 163.192.2.14 (calls itself smtp3.tt.xnet.trb)

smtp4.tribune.com 144.142.3.136 (protected by a slow obfuscatory firewall)

Those mailservers should have access to the userbase so that they can reject email to unknown users at the SMTP level.

[KKadow]

Background: When I was an employee of the old "Tribune Information Systems", I originally built the machine called smtp1.tribune.com before it was taken over by two other teams inside Tribune. I am not privy to the current operational details of the hosts that call themselves smtp[1-4].

The hosts smtp[1-4].tribune.com are the inbound mail path for this and many other domains; outbound mail (including bounces) follows a logically and physically distinct path.

A few more things:

It is much easier for humans and the Parser to understand the situation when multi-homed mailservers use and call themselves their public names and IP Addresses in their Received Header Lines and when composing notifications.

Good point. I'm not sure if the internal team that manages those multi-homed servers will be able to act on it, but it's worth a try.

Why is the fourth host in the chain blocking mail using the SCBL?  If blocking (vs. tagging) is to be done at all,

None of the hosts shown in the original posts are blocking mail using any DNSBL, so I have to assume the message was rejected by the SMTP server of the non-Tribune internet destination SMTP server, but that information was omitted from the original post?

it should be done by the mailserver(s) with the IP Address(es) of the name(s) of the organization's MX(s), in this case probably smtp{1-4}.tribune.com, as follows:

smtp1.tribune.com 163.192.2.12 (calls itself smtp1.tt.xnet.trb)

smtp2.tribune.com 144.142.3.135 (protected by a slow obfuscatory firewall)

smtp3.tribune.com 163.192.2.14 (calls itself smtp3.tt.xnet.trb)

smtp4.tribune.com 144.142.3.136 (protected by a slow obfuscatory firewall)

First time I've heard of that particular stateful inspection packet filter called "slow and obfuscatory". I'd explain what it is, but I think my NDA is still in effect.

Those mailservers should have access to the userbase so that they can reject email to unknown users at the SMTP level.

30955[/snapback]

Unfortunately, in this particular enterprise environment, the edge mail servers cannot have access to the userbase, so they are technically unable to reject email addressed to unknown users at the SMTP initial conversation.

Regarding those strange internal headers with a mix of unresosolvable domains, unrouted public addresses and RFC1918 addresses, I suppose the best approach would be to just strip off those headers before the message sees the Internet? That sure would make internal troubleshooting a lot more difficult.

[KKadow]

If this is a tribune message going to another tribune account, why are blocklists even being used.  Also, perhaps the non routable IP's are causing the block in that instance.

Are there really sites that reject mail because some of the lower down "Received" headers contain "intranet" names and non-routable IP addresses?

Suprising that anybody that extreme even bothers turning on a SMTP listener at all.

[dbiel]

Could this be the same problem that Cummings posted last year where he also refered to "i don't want to have to shut off spamcop at our mail server"

somebody emailed us and got their emails kicked back to them stating .........

(reason: 521 Mail rejected - you are listed in Spamcop (spam) [FREE] -

http://spamcop.net/bl.shtml)

the rejected IP is [155.212.64.2]

when i search spamcop, i get this message.........

155.212.64.2 not listed in bl.spamcop.net

i don't want to have to shut off spamcop at our mail server, can anyone explain why this is happening?

<sinp>

18924[/snapback]

It would appear to me that it is his own servers that are doing the bouncing.

Note: SpamCop does NOT recommend bouncing email based on the SCBL

[StevenUnderwood]

Are there really sites that reject mail because some of the lower down "Received" headers contain "intranet" names and non-routable IP addresses?

Suprising that anybody that extreme even bothers turning on a SMTP listener at all.

30965[/snapback]

What I was referring to was a period of time last year where the RFC private addresses were mistakenly listed in the spamcop BL, causing some strangely configured systems to be blocking other internal hosts.

[Jeff G.]

Are there really sites that reject mail because some of the lower down "Received" headers contain "intranet" names and non-routable IP addresses?

30965[/snapback]

Only tagging (as the SpamCop Email System does), not blocking/rejecting.

[Jeff G.]

the mailserver(s) with the IP Address(es) of the name(s) of the organization's MX(s), in this case probably smtp{1-4}.tribune.com, as follows:

smtp1.tribune.com 163.192.2.12 (calls itself smtp1.tt.xnet.trb)

smtp2.tribune.com 144.142.3.135 (protected by a slow obfuscatory firewall)

smtp3.tribune.com 163.192.2.14 (calls itself smtp3.tt.xnet.trb)

smtp4.tribune.com 144.142.3.136 (protected by a slow obfuscatory firewall)

30955[/snapback]

First time I've heard of that particular stateful inspection packet filter called "slow and obfuscatory".  I'd explain what it is, but I think my NDA is still in effect.

30964[/snapback]

What I meant by "slow and obfuscatory" is that it is rather quick for smtp1 and 3 to give initial responses like "220 smtp1.tt.xnet.trb ESMTP Sendmail 8.12.10/8.12.7; Sat, 30 Jul 2005 11:00:42 -0500 (CDT)", whereas it can take many (as many as 20) seconds for smtp2 and 4 to give initial responses like "220 ****2*******************************2**0****2**********0 ****200*****0******0*00 *****", that obfuscate everything but "2", "0", and " ".

[Jeff G.]

Moving the bounces out to Tribune's border servers and letting them bounce during the SMTP transaction would preserve Tribune's capability of bouncing errant mail from the rest of the Internet, while eliminating blowback, making Tribune a better corporate citizen of the Internet, eliminating the source of the recent email disruption, and reducing the amount of spam Tribune's mail servers and their administrators have to deal with. I understand that the process for making this happen in such a large decentralized organization can be quite challenging, but I applaud anyone who participates in making it happen.

cummings, you appear to be running a mailserver that doesn't accept email to abuse[at]cummingsprinting.com ("550 abuse[at]cummingsprinting.com No such user here") and didn't reveal the IP Address of the connecting mailserver in its "521 Mail rejected - you are listed in Spamcop (spam) [FREE] -

http://spamcop.net/bl.shtml" messages last year per this post.

[cummings]

thank you for all of the responses to my post. i apologize for my lack of information. let me tell the whole story.

i run a mail server in the building (mail.cummingsprinting.com = 208.32.228.22) using mail server software entitled 602 LAN Suite http://www.software602.com/products/ls/.

i have the option to check messages against different spam filters, spamcop being one of them. here is a screenshot of the 602 screen where i can configure anti-spam options. http://www.cummingsprinting.com/602.jpg

as you can see, spamcop is now unchecked. the reason why is one of our customers who used to be able to send us email without getting a rejection notice is now getting rejected. i disabled spamcop and then asked the customer to send the rejection email to me. here is the email in its entirety, leaving off the person's exact email address and a few other personal details.

Subject: failure notice

Hi. This is the qmail-send program at queue1.tribune.com.

I'm afraid I wasn't able to deliver your message to the following addresses.

This is a permanent error; I've given up. Sorry it didn't work out.

<xxxxxx[at]cummingsprinting.com>:

208.32.228.22 does not like recipient.

Remote host said: 521 Mail rejected - you are listed in Spamcop (spam) [FREE] - http://spamcop.net/bl.shtml

Giving up on 208.32.228.22.

--- Below this line is a copy of the message.

Return-Path: <xxxxxx[at]courant.com>

Received: (qmail 3726 invoked from network); 29 Jul 2005 16:48:39 -0000

Received: from unknown (HELO tco-lat-exbh2.TRIBUNE.AD.TRB) (172.24.24.26)

by queue1.tis-in.trb with SMTP; 29 Jul 2005 16:48:39 -0000

Received: from tco-chi-exbh2.TRIBUNE.AD.TRB ([163.194.253.42]) by tco-lat-exbh2.TRIBUNE.AD.TRB with Microsoft SMTPSVC(6.0.3790.0);

Fri, 29 Jul 2005 09:48:40 -0700

Received: from TPC-HRT-EXMB1.TRIBUNE.AD.TRB ([192.168.36.70]) by tco-chi-exbh2.TRIBUNE.AD.TRB with Microsoft SMTPSVC(5.0.2195.6713);

Fri, 29 Jul 2005 11:48:34 -0500

X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0

content-class: urn:content-classes:message

MIME-Version: 1.0

Content-Type: multipart/alternative;

boundary="----_=_NextPart_001_01C5945D.5B264512"

Disposition-Notification-To: "xxxxxx, Jeff" <xxxxxx[at]courant.com>

Subject: Please xxxxxx

Date: Fri, 29 Jul 2005 12:48:33 -0400

Message-ID: <F32480D6FE6567488A06ED9AEABEDE87021DEC2B[at]tpc-hrt-exmb1.tribune.ad.trb>

X-MS-Has-Attach:

X-MS-TNEF-Correlator:

Thread-Topic: Please xxxxxx

Thread-Index: AcWUXVsox3OeRcHTTgG3fP5BK7wT7Q==

From: "xxxxxx, Jeff" <xxxxxx[at]courant.com>

To: "Cummings - CC pmt - Norma xxxxxx \(E-mail\)" <xxxxxx[at]cummingsprinting.com>

Return-Path: xxxxxx[at]courant.com

X-OriginalArrivalTime: 29 Jul 2005 16:48:34.0016 (UTC) FILETIME=[5BA24E00:01C5945D]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5945D.5B264512

Content-Type: text/plain;

charset="iso-8859-1"

Content-Transfer-Encoding: quoted-printable

Please xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx

Thank you.

Jeffrey xxxxxx

=20

------_=_NextPart_001_01C5945D.5B264512

Content-Type: text/html;

charset="iso-8859-1"

Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<HTML><HEAD>

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =

charset=3Diso-8859-1">

<META content=3D"MSHTML 6.00.2800.1505" name=3DGENERATOR></HEAD>

<BODY>

<DIV><SPAN class=3D814034816-29072005><FONT face=3DArial size=3D2>Please =

xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx </FONT></SPAN></DIV>

<P><FONT size=3D2>Thank you.</FONT></P>

<P><FONT size=3D2>Jeffrey xxxxxx<BR><BR><BR></P></FONT>

<DIV> </DIV></BODY></HTML>

------_=_NextPart_001_01C5945D.5B264512--

[Merlyn]

Many servers would not accept email with headers like that. That is also the worst block message I have ever seen. The message should at least show what IP is being blocked. I believe all answers above still apply. You have shown everyone nothing different. Still a lack of information.

[Wazoo]

thank you for all of the responses to my post.  i apologize for my lack of information.  let me tell the whole story.

i run a mail server in the building (mail.cummingsprinting.com = 208.32.228.22) using mail server software entitled 602 LAN Suite http://www.software602.com/products/ls/.

as you can see, spamcop is now unchecked.  the reason why is one of our customers who used to be able to send us email without getting a rejection notice is now getting rejected.  i disabled spamcop and then asked the customer to send the rejection email to me.  here is the email in its entirety, leaving off the person's exact email address and a few other personal details.

As stated before, I've used the free version of 602 Lansuite ... I can tell you from that experience that although some settings can be changed on the fly, this isn't one of them. A re-boot would be necessary to pull in the "new" setting. One of those Windows issues ....

You've not said what the folks at 602 have said in response to anything yet ....

But the real problem I'm having right now is getting hold of the actual issue. You're talking about "your" system, "your" e-mail application .... but you post a rejection notice that says;

"This is the qmail-send program at queue1.tribune.com" .. and it's apparently rejecting e-mail from the e-mail server that you say you run ...???? (Which again is currently showing "208.32.228.22 not listed in bl.spamcop.net")

I may not be fully awake yet?

[cummings]

As stated before, I've used the free version of 602 Lansuite ... I can tell you from that experience that although some settings can be changed on the fly, this isn't one of them.  A re-boot would be necessary to pull in the "new" setting.  One of those Windows issues ....

You've not said what the folks at 602 have said in response to anything yet ....

31071[/snapback]

unchecking spamcop took effect immediately, because the email i posted here was sent by the person who was rejected originally (and it made it to me).

i have not contacted 602 because the rejection only happens when i have spamcop checked off in the anti-spam. it appears that the software is working correctly. i just can't figure out why the email was rejected. the IPs in the email are not listed in the bl.shtml search.

my goal is to find out why this email was rejected by spamcop so i can either get them unblacklisted, or do whatever i have to do so i can get spamcop enabled again. thanks for the help so far. the terminology is a bit above my head but i'm trying to understand it the best i can.

[Jeff G.]

The external IP Address for queue1.tribune.com is 163.192.21.6, but it's not listed. However, the external IP Address for mail-la1.tribune.com [198.187.230.11] was listed yesterday, probably due to having sent email to spam Traps three days ago.

[StevenUnderwood]

i have not contacted 602 because the rejection only happens when i have spamcop checked off in the anti-spam.  it appears that the software is working correctly.  i just can't figure out why the email was rejected.  the IPs in the email are not listed in the bl.shtml search.

31073[/snapback]

I would contact them and ask why the reject is not stating which IP address is being found to be blocked. You can show them a better way to present all the data at: http://www.spamcop.net/fom-serve/cache/294.html

[turetzsr]

I would contact them and ask why the reject is not stating which IP address is being found to be blocked.  You can show them a better way to present all the data at: http://www.spamcop.net/fom-serve/cache/294.html

31099[/snapback]

...IIUC, "them" is him (cummings)!

[dbiel]

You have missed one very important point.

The SpamCop BL was NOT designed to be used to reject messages, but to be used as a filter to sort out spam.

Unless you implement a white list you will always have problems with blocking vaild email.

[Merlyn]

You have missed one very important point.

The SpamCop BL was NOT designed to be used to reject messages, but to be used as a filter to sort out spam.

Unless you implement a white list you will always have problems with blocking vaild email.

31107[/snapback]

I have never had a problem blocking valid email using Spamcop :-)

[StevenUnderwood]

...IIUC, "them" is him (cummings)!

31105[/snapback]

No, the "them" I am referring is the people who wrote/maintain/support 602 Lansuite.

[dbiel]

I have never had a problem blocking valid email using Spamcop :-)

31108[/snapback]

Even using white lists, I still get the occasional message that gets filtered into HeldMail due to the SpamCop BL

The following is a quote from the SpamCop.net FAQ SpamCop Blocking List

The SCBL aims to stop most spam while not blocking wanted email. This is a difficult task. It is not possible for any blocking tool to avoid blocking wanted mail entirely. Given the power of the SCBL, SpamCop encourages use of the SCBL in concert with an actively maintained whitelist of wanted email senders. SpamCop encourages SCBL users to tag and divert email, rather than block it outright. Most SCBL users consider the amount of unwanted email successfully filtered to make the risks and additional efforts worthwhile.

The SCBL is aggressive and often errs on the side of blocking mail. When implementing the SCBL, provide users with the information about how the SCBL and your mail system filter their email. Ideally, they should have a choice of filtering options. Many mailservers operate with blacklists in a "tag only" mode, which is preferable in many situations.