I am a SpamCop subscriber who, for the past several days, has been seeing mail from PayPal (regarding payments made to my account) end up in Held Mail, the reason given being that the PayPal server IP is on bl.spamcop.net. For example:

X-SpamCop-Checked: 74.208.4.202 208.97.132.47 66.211.168.230
X-SpamCop-Disposition: Blocked bl.spamcop.net

66.211.168.230 is mx0.phx.paypal.com

Each time I get one of these, I instantly go to the SpamCop "query" page to look up the IP, and each time it tells me the IP is not listed.

The only thing I can think of is that these IPs are being listed and then quickly delisted, but maybe something else is going on. Unfortunately, there no longer seems to be the ability for individuals to look up listing histories for IPs.

Any clue as to what is going on here? It's really just an annoyance to me, but it might be more serious for others.

Edit: I have always been told that it was the last IP lin the "Checked" line that was the culprit. However, I decided to look at the others and see that 74.208.4.202 is listed. So I guess I now need to check all the IPs. Curious as to how it seems it's only the PayPal emails being caught by this...

74.208.4.202 and 208.97.132.47 look really bad also actually much worse than the paypal IP.

It would be interesting to see the headers and email.

Actually, I think you're a SpamCop Email customer, like me...


It seems that the problem is with the first of those three IPs, which is on a 1and1.com shared box. The next IP is on a Dreamhost box. I'm guessing that you're having some email forwarded to your SpamCop email account from a domain on the 1and1.com host....correct? In any case, that's the IP that's actually blacklisted, and it happens a lot to those kind of servers, due to the sharing of outbound SMTP IPs and lack of control over what gets sent out.

DT

I agree with Merlyn that a Tracking URL would help a lot. Yet, I'll also assume that as these are 'good' e-mails and deaaling specifically with your account, much munging of the personal (paypal account) data would also have to be recommended before submitting to the parser.

and not currently listed at the time of this posting.

However, 74.208.4.202 is in fact currently listed.

Actually, I wasn't aware that users ever had this ability, especially since IronPort involvement.

I am not aware of any change in this parameter. Neither JT or Trevor have made any postings, e-mails, etc. about something as major as this change would be.

Report History on this IP address shows the last user Reported actions as happening back on 18 April. The implication that any listing would be due to spamtrap hits, but ... based on a SenderBase traffic measurement of 5.3, there would have to be a somewhat massive amount of 'bad' traffic to get this IP Address listed ...???

EDIT: As David suggests, I also believe that this is more an issue of the e-mail application rather then the SpamCopDNSBL directly .. although without more data about the issues raised in my e-mail, it's kind of hard to tell. Again, a Tracking URL would seem to be desirable to see what else might be going on ...

Anyway, moving to the E-mail System & Accounts Forum section with this edit ....

The items in the last 90 days of SpamCop reporting history on the Paypal IP (66.211.168.230), all look like false reporting to me...we've got some people who "over-report" (such as reporting all their Held mail, or the like) and of course, with all the Paypal spoofs out there, they are probably the victims of a lot of false reporting, because spam reporters see "Paypal" and assume (sometimes incorrectly) that it's yet another spoofed phishing attempt.

DT

66.211.168.230 = mx0.phx.paypal.com is not on the SpamCop blocking list, and never has been. At least not in the last 90 days.

It looks like the reports are either erroneous or reports about misdirected automatic responses resulting from forged spam sent to the PayPal addresses.

74.208.4.202 = mout-xforward.perfora.net is sending spam like crazy and is on our blocking list since Thursday, April 24, 2008 06:19:29 -0600.

- Don D'Minion - SpamCop Admin -

Thanks for that. Guess the waiting now is for JT/Trevor to answer the e-mail application code and displayed data issues.

First of all, the "email application" is SpamCop webmail. There is no tracking URL because I never submitted the email for reporting.

It is correct that the email gets received by Dreamhost and forwarded to 1&1 which forwards to Spamcop. (I collect all my mail at Spamcop.) I have since changed things so that Dreamhost forwards directly to Spamcop.

The only puzzle remaining is my, perhaps mistaken, belief that in the "Checked" line, the last IP listed is the one that was blocked. If this is incorrect, then the whole thread merits a "Never Mind!".

I used to be able to look up listing history for an IP - at least pre-Ironport.

Well, maybe there is another puzzle. Here are the munged headers

Return-Path: <payment_at_paypal.com>
Delivered-To: spamcop-net-me_at_spamcop.net
Received: (qmail 16556 invoked from network); 4 May 2008 20:29:24 -0000
X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on filter8
X-Spam-Level:
X-Spam-Status: hits=0.0 tests=HTML_MESSAGE,SPF_HELO_PASS version=3.2.4
Received: from unknown (192.168.1.107)
by filter8.cesmail.net with QMQP; 4 May 2008 20:29:24 -0000
Received: from mout-xforward.perfora.net (74.208.4.202)
by mx70.cesmail.net with SMTP; 4 May 2008 20:29:24 -0000
Received-SPF: softfail (mxus0: transitioning domain of paypal.com does not designate 208.97.132.47 as permitted sender) client-ip=208.97.132.47; envelope-from=payment_at_paypal.com; helo=spunkymail-mx4.g.dreamhost.com;
Received: from spunkymail-mx4.g.dreamhost.com (mx1.spunky.mail.dreamhost.com [208.97.132.47])
by mx.perfora.net (node=mxus0) with ESMTP (Nemesis)
id 0MKoTA-1Jskpj35bl-0008MK for me; Sun, 04 May 2008 16:29:24 -0400
Received: from den01imail02.den.paypal.com (outbound1.den.paypal.com [216.113.188.96])
by spunkymail-mx4.g.dreamhost.com (Postfix) with ESMTP id 2606019B158
for <xxx>; Sun, 4 May 2008 13:29:19 -0700 (PDT)
DomainKey-Signature: s=dkim; d=paypal.com; c=nofws; q=dns;
h=Received:Date:Message-Id:Subject:X-MaxCode-Template:To:
From:Sender:X-Email-Type-Id:X-XPT-XSL-Name:Content-Type:
MIME-Version;
b=0kjXDQbyvaaJmW5xurvSWrbATnhb6syNo5Ffa8dYtoxjfPLaBJlS4vMw
4FHUpLABShPUvDeUzg+DzJ4I0RazuT/hJyawa3SS2/S7oi3Vb5NoRuPp7
eAg1WSnVEARh1Bcqtl3jbtZQAdeKwbagYA2Y5/7rLD13zh9fHsXYp/fJl
E=;
Received: (qmail 13671 invoked by uid 99); 4 May 2008 20:29:15 -0000
Date: Sun, 04 May 2008 13:29:15 -0700
Message-Id: <1209932955.13671[at]paypal.com>
Subject: Notification of Donation Received
X-MaxCode-Template: email-xclick-donation-notification
To: "xxx" <xxx>
From: "xxx" <xxx>
Sender: sendmail_at_paypal.com
X-Email-Type-Id: PP1304
X-XPT-XSL-Name:
email_pimp/default/en_US/customer/donations/XClickDonationNotification.xsl
Content-Type: multipart/alternative;
boundary=--NextPart_048F8BC8A2197DE2036A
MIME-Version: 1.0
X-SpamCop-Checked: 74.208.4.202 208.97.132.47 216.113.188.96
X-SpamCop-Disposition: Blocked bl.spamcop.net

Look at the Received-SPF line - who added that and why did it think that Dreamhost's IP was the one it should check? I'm guessing, based on the position, that 1&1 added it.

I know that people say that all the time, but I'm not so sure that it's correct.


You still can...if there's any history on the ip. Simply log into either:

http://mailsc.spamcop.net/
(with your account credentials)

or go to:

http://www.spamcop.net/
and login with those same credentials, enter the IP in the box on the "Report Spam" page, and once you "process" it, if there's a "report history" link, click on it, and then change the parameter on that page from "24 hours" to "Last 90 days." When I do that, I'm presented with information about any reports filed on the IP.

p.s. - taking out the "hop" through the "1and1" neighborhood was a good idea...lots of junk coming off those servers, apparently.

DT

Thanks. Most of my domains are at 1&1 as they've been more reliable than Dreamhost, but I have one major domain still at Dreamhost. Now I'll know what to look for the next time "good" email ends up in Held Mail.

Understood. That was the reason for the hint to mung specific data before submitting to the parser

Please see my e-mail'd request for help again.

The reson for asking for a Tracking URL is to save the database storage requirements in a (somewhat) massive posting like this.

Received: (qmail 16556 invoked from network); 4 May 2008 20:29:24 -0000
internal cesmail handoff

Received: from unknown (192.168.1.107) by filter8.cesmail.net with QMQP;
internal cesmail handoff

Received: from mout-xforward.perfora.net (74.208.4.202) by mx70.cesmail.net with SMTP;
cesmail received this from an IP address that is currently listed on the SpamCopDNSBL (perfora.net)

Received-SPF: softfail (mxus0: transitioning domain of paypal.com does not designate 208.97.132.47 as permitted sender) client-ip=208.97.132.47; envelope-from=payment_at_paypal.com; helo=spunkymail-mx4.g.dreamhost.com;
This is a 'standard' / known issue with SPF records .... Forwarding is 'the' problem with SPF records

Received: from spunkymail-mx4.g.dreamhost.com (mx1.spunky.mail.dreamhost.com [208.97.132.47]) by mx.perfora.net (node=mxus0) with ESMTP (Nemesis)
perfora.net received the e-mail from dreamhost

Received: from den01imail02.den.paypal.com (outbound1.den.paypal.com [216.113.188.96]) by spunkymail-mx4.g.dreamhost.com (Postfix) with ESMTP id 2606019B158
dreamhost received from paypal

Received: (qmail 13671 invoked by uid 99); 4 May 2008 20:29:15 -0000
internal handoff, assumedly at paypal

Message-Id: <1209932955.13671[at]paypal.com>
suggests a paypal server as the source

Sender: sendmail_at_paypal.com
suggests a paypal server as the source

X-SpamCop-Checked: 74.208.4.202 208.97.132.47 216.113.188.96
X-SpamCop-Disposition: Blocked bl.spamcop.net
and again, the question about the left-hand IP Address as being the decision point.


As above, forwarding is an issue with SPF records. Noting that this did not have any impact on the handling by the cesmail servers.

Report History isn't the same as a SpamCopDNSBL Listing History, My recollection is that this was removed way back in the Julian days .. when it was determined that spammers were gaming the system.

Right...I misunderstood....but looking up reporting histories is still often useful.

DT

David: The reason it is said all the time is that it is documented that way (http://www.spamcop.net/fom-serve/cache/312.html) and this is the first official time (Don's post) that has documented it may be wrong. There have been several posts that indicate it may be wrong, but we have never been able to get confirmation. I for one will stop using this explaination (rather stating it is likely one of the IP's listed).

My follow-up;

Yes, I knew it was in a FAQ, but I also remember expressing skepticism in the past about the accuracy of that concept.

DT

A lot of what I have reported as superficially looking like paypal e-mail in the past also looked suspiciously like phishing attempts in the name of paypal, there were times I had to report dozens of them in a single day.

Here I think is an example

http://www.spamcop.net/sc?id=z1834072064zf...f0e704e744243dz

X-SpamCop-Checked: 216.154.195.53 212.74.100.190 85.98.219.238 206.131.46.20
X-SpamCop-Disposition: Blocked pbl.spamhaus.org

Where I think it was the (mailhosted) source 85.98.219.238 that was on the block list

The change may only date from the pbl introduction since it introduced the rule that the last recieved IP address was not to be checked against pbl (unless in fact it was a direct to MX to a SpamCop server) so requiring a look-ahead to find if there was a 'next IP'.

HTH

I am hoping that you are not talking about a MailHost Configuration of your Reporting Account action item / Host addition to 'your' MailHost Configuration when you typed the "(mailhosted)" thing ....

MailHost Configuration data is only used during the Parsing of your submitted spam. It has nothing to do with a SpamCop.net e-mail account.

True...and that's unfortunate, especially in conjunction with such BLs as the PBL, which includes ranges of IPs which "should not be delivering unauthenticated SMTP email to any Internet mail server except those provided for specifically by an ISP for that customer's use."

Therefore, if the SC email system were aware of our configured Mailhosts, and the IP of the machine delivering to one of our Mailhosts was PBL-listed, the SpamCop email system could very accurately dump that message into the Held folder with a "pbl.spamhaus.org" blocking action. The system *would* be much better than it currently is at catching "direct-to-MX" spam. The way it is currently configured, for those of us having other mail auto-forwarded to our SC email accounts, this is generally not happening.

It's something that didn't get properly addressed last year, back when TrevorB (SC email staff) was active here, but he hasn't even dropped by since February....

DT

No worries Wazoo, I only mentioned mailhosting because I was presenting evidence (of the rightmost IP address not being the blocklist hit) as a TRACKING URL so my 'Source' might not be what others see.

DavidT, there is a bug in your sketched idea. I use dial up and have has a couple of false drops on email I sent to myself at SpamCop because some of my provider's dialup pool are listed so Blocked cbl.abuseat.org and Blocked list.dsbl.org. If the mailhost list included the providers SMTP then pbl would have had a hit on all such emails which isn't what you want.

Maybe so...but I'm not convinced. And what is a "false drop"?

DT

Feedback from JT pretty much confirms what you suggest.

However, he also states that something sure seems wrong in the example offered (the IP Address causing the 'blocked' disposition being the left-most of three IP Addresses.) More analysis to be accomplished as time allows.

Yeah, like:

and

A False Drop or False Positive as in

(April) 3249 spams (108/d), 144 leakers (=4.4 %), 4 False positive(s)

Is trad terminology (Statistics, pre-computer card databases) for an data item that in the wrong place, here, ending in the Held folder.

The cards, the needles - good heavens, I remember those.

...but not in the email world. The universal usage is "false positive." I found a number of references to "false drop" like this:


but thanks for clarifying. There are plenty of systems using the PBL for spam filtering...I'm just a bit disappointed at its implementation here, but I'll get over it.

DT