Hi,

a client reported that his mails got identiefied as spam:



The blocked IP 80.187.101.113 is a Client-IP from his ISP.



I looked it up at spamcop.net but it says that it is not blocked or reported.

He sent the very same mail again today with another Client-IP and it got not reported as spam.

I wrote in another post in this forum that SpamCop not only checks the SMTP server IP but also the Client-IP. As the clients get different IPs every time they connect to the internet I don't know how I could prevent my users mails to be reported as spam.

Is there some way to disable Client-IP checking or another solution/workaround?

Thanks,
Frank

Hi Frank,

I can see that there was one report back in May for that IP address and there may have been others from 'spam traps' which are not available to ordinary users to view.

I think this appears to be a dynamically assigned IP address (tmo-101-113.customers.d1-online.com) so it is very possible that your client was assigned an IP address that had been used to send spam in the past.

This is VERY common, for example, with ip ranges used by phone companies to give connection to mobile devices/mobile broadband.

I can only suggest you take a look at the helpful FAQ found via links at the top of this page. This will explain how the SpamCop parser identifies the source of spam.

As you note the IP address is not currently listed. Indeed it is possible that it never was listed. Some ISPs incorrectly identify the SpamCop BL as the source of a block when it is really another BL. Sometimes SpamCop is used as a generic label for all block lists.

Andrew

Hi Andrew,

thanks for your reply.

Yes, that seems to be the case. If this problem is very common, how can admins and/or users avoid it?

I mean, better get some more spam mails instead of loosing some ham mails ...

Frank

That would be your current POV... but when you get inundated with 100's or 1000's of spam messages, your POV may change.

That being said, the majority of DNSBL systems only check the connecting IP address so as long as the Client is using their ISP's mail server (and the ISP is not blocking their own customers), the message would go through. SpamCop email is one of the few I am aware of that checks the entire set of IP's, but since it is designed to be the point to forward all your other spam receiving accounts, that kind of makes sense. If it did not look at all headers, it would only be useful for mail sent directly to the SpamCop account.

In short, the way to avoid it is to not use your filtering on your SpamCop email account or not use your SpamCop email account. It may not fit your situation, find a different tool.

IMHO, it is not better to get more spam!

If someone is sending spam via that IP address, then whoever is responsible for that IP address, needs to find out who is sending spam and stop it. Only the *sending* end can stop spam. If your client is not sending spam - either deliberately or because his computer is infected, then the people who are also using that IP address ought to be investigated. Who can do that investigation? Not the receiver of the spam. Only the sender of an email has the leverage to say to his ISP, 'Give me a clean IP address or I take my business somewhere else!' Only the ISP can tell, from his logs, who is sending spam and has the power to disconnect that person.

The problem with 'more spam' is that then ISPs have to use 'more' filters to take out the spam. Naturally, they do not want to share their methods. Why did the ISP reject your client's email? Probably no one will ever know. At least, he sent notification so that your client knows the email was not delivered. ISPs who are anxious never to reject a ham mail often try to detect spam after accepting everything and then if there is a mistake, no one ever knows that the email was not delivered. That happened to me recently - an email I sent was never delivered or returned.

Tell the rejecting ISP that his methods of filtering out spam are not good. Actually, it is recommended that the spamcop blocklist be used to tag mail, not reject it. But many server admins think that his filters are just fine and it is the sender's problem to use an IP address that is acceptable.

Your client needs to find a reliable way to send email - one that does not have a history of sending spam. I don't need more spam to filter because he has a problem. I am sorry for his problem. I have gone through a difficult time as the sender - completely innocent, but the outgoing filters made a mistake. However, that's life. Now I have to have a photo id to cash a check. It used to be that I didn't need an id at all.

Miss Betsy

Up until three days ago, 80.187.101.113 = tmo-101-113.customers.d1-online.com was sending spam to our spamtraps. It was removed from our list Wednesday, June 24, 2009 because the spam has stopped for some reason.

Many other IPs in the range 80.187.101.0 - 80.187.101.255 are sending spam, or have been recently.

When a receiving system is testing incoming mail, SpamCop does not do any of the testing. The receiving system has total control over what gets checked in an incoming email.

SpamCop is simply a list of known spam sources that the receiving system consults about an IP it has found in the headers of incoming email.

- Don D'Minion - SpamCop Admin -
- service[at]admin.spamcop.net -
.

Use an ISP that deals with the problem effectively. According to Don it seems that some action was taken - probably by the ISP.

But in the end the solution is in the hands of the receiving ISP. As Don notes, it is the receiving ISP that can choose to reject, tag or do nothing.

Andrew

Hi,

thank you all for your replies.

I understand that the ISP is responsible to give the clients a 'clean' IP. Too bad that it affects the customers who have no control over it at all.

Frank

...As long as there's no effective monopoly, clients have all the control, don't they? They can choose to do business with an ISP that does not give them a "clean" IP or take their business to one that does.

It's not that easy. If my client now tells the ISP to give him only clean IPs they will tell him that they'll do the best they can - but they won't promise him that he'll receive clean IPs every time he connects to the internet.

If it happens again he has to start a fight against the ISP to get out of the 24 month lasting contract.

And how can he find out which provider does have clean IPs only or is removing bad IPs? I wouldn't now how ...

A number of issues raised here, quite a few details missing in the scenario description. Some of them;

The actual ISP/Host generating the rejection notice is not defined. As noted previously, most ISP/Hosts only check the connecting IP Address on the incoming e-mail attempt. You may need to have some dialog with that ISP/Host about how to work with/around their e-mail0server configuration.

Some more detail about just how T-Mobile Deutschland GmbH is actually handing out IP Addresses. Is tmo-101-113.customers.d1-online.com a single customer or not. (A different IP Address at each connection would seem to imply a single user, but ...???) Per the current SenderBase page, traffic has not seemed to have slowed down, and a few thousand e-mails a day seems pretty excessive, (especially for a "mobile" user)
http://www.senderbase.org/senderbase_queri...=80.187.101.113
Volume Statistics for this IP
Magnitude Vol Change vs. Last Month
Last day ....... 2.3 .. -1%
Last month ... 2.3

Notice the Poor Reputation, the listing in other BLs, just for this IP Address. Note the status of so many others.

Nothing has come up about checking and clening of this client's system/network. Nothing stated about the client's system configuration, specifically a wireless router being in the mix. If that client/network is still spewing, it would seem like a bit of a waste of time for you to try to keep his e-mail flowing elsewhere.

...Okay, you walk into a grocery store and walk out with vegetables you thought were good but were spoiled. You take them back to the store and ask the manager for fresh vegetables. The manager tells you "we'll do the best we can but we won't promise that you'll get fresh vegetables every time you buy them." The only difference I see here is that you don't have a 24-month contract with the grocery store. Fine, you committed to 24 months with a provider whose service quality you did not know, you've learned a valuable lesson -- and you have 24 months to find a better provider. <g>...And how, in my previous example, would you find a grocer whose vegetables are guaranteed fresh?

Nice comparison But I think it's a little bit more complicated than with vegetables. It's not me (the mail administrator) that has the contract - it's one of my users.

To tell the users to go and find "good" ISPs ... I guess they would rather change the mail provider if I would tell them so. But that's not something technology (here SpamCop) can change, that's right.

Frank

Hi, Frank,
...It may be somewhat more complicated to effect a change in ISPs than grocers but it's identical in principle. The users have all the control because they can (however complicated it may be for them) find a different ISP --others have (one of several examples you can find in these Forums).

Having to note that none of my last was responded to .. just tossing yet another data point, assumedly, the client has moved elsewhere, based on no other data provided ...
Volume Statistics for this IP
Magnitude Vol Change vs. Last Month
Last day ...... 0.0 .. N/A
Last month .. 2.3

Hi,

I checked with the user and the client is clean (no viruses, no trojans etc). And I assume you are right that the "bad" (spamming) client has moved elsewhere (got another IP) as my user did the next day he connected. With a new and "clean" IP he was able to send the same mail that got marked as spam without any issues (no spam).

I already told him that the only thing that can be done is to tell the ISP about it and/or change to another ISP which was not very welcome but understood.

As mail administrator I just hope that this was a singular case but I highly doubt it

Frank