Help with the SpamCop process

[dibz]

I am hoping you can help as I am currently at a bit of a loss.

We are having a problem at the moment whereby some of our field operatives are unable to send email back to headoffice (and elsewhere) as they are getting blocked (error returned that the ip is on spamcop's block list), but neither of our mail domains are linked to spamcop as far as we know.

The current constant is that it 'appears' as though the field agents only encounter problems when connecting through a roaming service (they have 3g datacards provided by vodafone).

We have spoken to both mail providers and vodafone and all claim to know nothing about spamcop, so my question is this really... How is spamcop getting involved, when no component of the communications channel makes any connection/reference to spamcop?

[Farelf]

... error returned that the ip is on spamcop's block list...

The IP address(es) is/are the key element. What is the message, what is the IP address? Or, feed an address yourself into the lookup http://www.spamcop.net/bl.shtml If nobody is using the SCBL, it can't be that doing the blocking - but sometimes SC gets cited for other BL actions. Try an IP address in the BL lookup at http://www.dnsstuff.com/ All sorts of hypotheticals are possible. You need to provide the details.

[GraemeL]

We are having a problem at the moment whereby some of our field operatives are unable to send email back to headoffice (and elsewhere) as they are getting blocked (error returned that the ip is on spamcop's block list), but neither of our mail domains are linked to spamcop as far as we know.

The current constant is that it 'appears' as though the field agents only encounter problems when connecting through a roaming service (they have 3g datacards provided by vodafone).

We have spoken to both mail providers and vodafone and all claim to know nothing about spamcop, so my question is this really... How is spamcop getting involved, when no component of the communications channel makes any connection/reference to spamcop?

Spamcop cannot intercept random email. If mail to your head office is being blocked, then the provider of your head office mail service must have the system configured to block based on the SCBL.

If you can provide a copy of the error message that your employees in the field receive, we should be able to tell you which of your suppliers it is.

[dibz]

ah ok

From: System Administrator

Subject: Undeliverable: 311006

Your message did not reach some or all of the intended recipients.

Subject: 311006

Sent: 31/10/2006 18:56

The following recipient(s) could not be reached:

'someone[at]lvg.co.uk' on 31/10/2006 18:56

451 Blocked - see http://www.spamcop.net/bl.shtml?212.183.134.65

was the error the sender received... he was sending from a [at]letsdrive.com account

[Telarin]

The administrator of mxa.hostedservice.com that handles incoming email for lvg.co.uk has configured that server to use the SCBL in a blocking fasion. The listed contact address is sysadmin[at]cobwebsolutions.com.

212.183.134.65 has been listed for repeated hits on spamtraps over the past 25 days. There may also be some user reports, but a paying subscriber would have to post those for us.

Spamtrap hits can be caused by another user of that IP address sending spam if it is a shared mail server. They can also be caused by a mailserver incorrectly sending bounces to forged from addresses, or by excessive use of autoresponders on that IP address.

Additionally, 212.183.134.65 does not have the reverse DNS entry that is REQUIRED by RFC822. You may not be able to send mail to many services because of this issue (AOL for instance will not accept email from a mail server configured without proper PTR records). You need to contact the owner of this IP address (Vodafone) to resolve this issue.

You may also want to contact deputies[at]admin.spamcop.net to find out what kind of traffic has been hitting the spamtraps from this IP address. Be sure to provide all pertinent information so they can help you as quickly as possible. However, ultimately it is Vodafone that will have to take action to correct this problem unless it is your computer that is compromised and sending spam.

Edit: 212.183.134.65 does not accept incoming connections to port 25, so misdirected bounces are unlikely. What outgoing mailserver do your remote users have configured?

[dibz]

Many many thanks for the help and info folks, you have saved me from tearing my hair out!

Strange how everyone we have spoken to has denied knowledge when in fact there is a link in the chain connected with spamcop!

thanks for the info, I will relay to those that need and see where we go from here.

Thanks again,

~Dibz

Edit: Just seen your edit Will, letsdrive.com is set up for authenticated SMTP. I have a feeling that isn't configured for Reverse DNS too as historically some accounts have had intermittant problems sending to AOL

[Merlyn]

You are also listed in the following blocklists:

NJABLDYNA NJABL list of dynamic ip spaces: dynablock.njabl.org -> 127.0.0.3

Dynamic/Residential IP range listed by NJABL dynablock - http://njabl.org/dynablock.html

--------------------------------------------------------------------------------

NJABLCOMBINED NJABL & NJABLDYNA combined: combined.njabl.org -> 127.0.0.3

Dynamic/Residential IP range listed by NJABL dynablock - http://njabl.org/dynablock.html

--------------------------------------------------------------------------------

CBL The CBL - Composite Blocking List: cbl.abuseat.org -> 127.0.0.2

Blocked - see http://cbl.abuseat.org/lookup.cgi?ip=212.183.134.65

--------------------------------------------------------------------------------

XBL Exploits Block List (includes CBL): xbl.spamhaus.org -> 127.0.0.4

http://www.spamhaus.org/query/bl?ip=212.183.134.65

--------------------------------------------------------------------------------

SPAMCOP SpamCop Blocking List: bl.spamcop.net -> 127.0.0.2

Blocked - see http://www.spamcop.net/bl.shtml?212.183.134.65

--------------------------------------------------------------------------------

SBLXBL Combined zone to reduce queries. Includes both SBL and XBL zones: sbl-xbl.spamhaus.org -> 127.0.0.4

http://www.spamhaus.org/query/bl?ip=212.183.134.65

--------------------------------------------------------------------------------

UCEPROTECTL1 UCEPROTECT®-Network Project - Level 1: dnsbl-1.uceprotect.net -> 127.0.0.2

IP 212.183.134.65 is Level 1 listed at UCEPROTECT-Network. See http://www.uceprotect.net/en/rblcheck.php?ipr=212.183.134.65

--------------------------------------------------------------------------------

DNSBLAUT1 Reynolds Technology Type 1: t1.dnsbl.net.au -> 127.0.0.2

Blocked - see http://cbl.abuseat.org/lookup.cgi?ip=212.183.134.65

--------------------------------------------------------------------------------

DNSBLUCEPN External Block List - UCEPROTECT®-Network Project: ucepn.dnsbl.net.au -> 127.0.0.2

PLEASE SEE http://www.uceprotect.net/

[StevenUnderwood]

The only publically available report is:

Report History:

--------------------------------------------------------------------------------

Submitted: Tuesday, October 17, 2006 10:33:09 AM -0400:

STRONG RESULTS PROVE THE PACE OF BIOFUEL IN SILVERSTONE TOURING CAR FINALS

[dbiel]

Since your problem, as I read it, seems to be remote users sending mail to your main office, is there any why you can allow them to connect directly to the email server at the mail office rather than using the SMTP services of the roaming host that they happen to use to connect to the internet. Another issue is to make sure that you have white listed your own employees. Generally speaking it would be your mail services that are blocking your own employees from sending mail to you. Looks like your IS department needs to wake up and learn what they need to know to run a business. I am sorry if that just happens to be you, but today business email is not simply a matter of plug and play. I wish you success in fixing the problem. There is not much you can do about random remote SMTP services other than not to use them. Your employees need a reliable email account that they can log directly into and send the mail using the SMTP services of that account. For most businesses that account would be their own email server. But if for some strange reason that can not be done, then a separate account such as SpamCop email, or any one of the other large email providers that your company is willing to receive mail from.

Note spending time trying to find out what caused an IP address to be listed that is not one under your own control is a waste of time. The effort needs to be spent in finding out ways you can get around the blocking issue; finding a different way to send the mail so it can be received regardless of the IP address that it originated from as it appears you will have no control of what IP address your employees happen to connect to while at remote locations. Good luck.

[dibz]

dbiel, i accept the tone of your email as unneccessary but it seems i may not have been clear.

The field agents have email accounts with one service hosted at letsdrive.com from which they use POP and Authorised SMTP.

They are sending mail to employees based on site who utilise exchange through the lvg.co.uk domain.

At this time, the field agents are required to keep their current mail services.

When an internet connection is unavailable to them, they use wireless datacards to provide an internet connection, but they still use the authenticated SMTP hosted at letsdrive.com, the IP address that is being blocked and reported etc etc above is that from a shared pool, relating to the dynamic internet connection from the roaming host. They don't use an SMTP service provided by the roaming hosts, I don't even know if that host provides an SMTP service.

It is here where I don't understand why email is being blocked as shouldn't it be coming from the known source that is letsdrive.com?

Our email services are not hosted by ourselves, which is the route of this issue as we are not in control of the spam and virus countermeasures they choose to employ.

[Telarin]

You mentioned an exchange server. Do you have control over that? If so, you could use it to handle all of your email (including remote users via RPC). That way you would not be at the mercy of a 3rd party provider. This is the route we had to go years ago because we couldn't seem to find a competent email provider that didn't want to charge us a not-so-small fortune.

It is here where I don't understand why email is being blocked as shouldn't it be coming from the known source that is letsdrive.com?

Agreed.

MX for letsdrive.com is cluster3.eu.messagelabs.com

cluster3.eu.messagelabs.com is:

195.245.231.163

195.245.231.211

85.158.136.3

85.158.136.115

85.158.137.35

85.158.137.67

85.158.137.83

85.158.137.99

85.158.137.131

85.158.137.147

194.106.220.35

194.106.220.51

194.106.220.67

None of which are the listed IP address (or even owned by the same people for that matter). There is a remote possibility that your provider is checking all IP addresses in the mail headers, but this would be very unusual. Is it possible for you to have one of the blocked users send an email to an account that they can successfully reach and then post the headers here so we can get an idea what path the email is following? That might give us some additional clues to troubleshoot this issue.

[dibz]

i think you may have hit the nail on the head there Will.

Our exchange server is in itself a hosted service, there was talk and maybe plan of migrating the 'field ops' mx records to the same hosted service and bringing everything under one roof (so to speak) but it just isn't viable at this time.

I don't think we have an email header available at this time that we could check... I will have a look

I think the answer I have stumbled blindly to with all your help and advice is to re-contact the exchange hosts (who originally said they didn't do anything with spamcop...) and see if they will modify how it checks mail headers or at least get the other smtp-auth server added to a safe list if that is possible.

[dbiel]

Sorry about the tone, but glad for the additional information and glad Will was able to respond.

Remember that it will be easier to fix the problem relative to getting mail to / from your own employees, but they will still have problem sending to other users who may also be using blocking lists when the shared mail servers happen to be listed. And unfortunately, since they are shared, your options to fix anything are greatly limited. Good luck.

[dibz]

little more info, just had a look at a mail header of an email from one of the remote guys (strangely enough, one that got through originially reporting the block!) and in the header, the sender appears to be fully qualified as: person[at]ourdomain[at]roamingip

i am starting to wonder if the provider of our SMTP service is passing on too much information!! ideally speaking the receiver doesn't need to know the information behind the second [at], might be something that can be truncated/disabled/whatever.

i have also started communication with the exchange hosts who are the ones using spamcop to see if anything can be done at that end. I will replay back here if I find a resolution in all this, incase it can be of use for others.

[Telarin]

Can you post the "Received" lines of that mail header. Complete and in order. There is still something strange about the fact that you are being blocked from the origin IP address rather than the connecting address, and I'd like to see what is actually going on header wise.

[dibz]

given this forum is public read i have removed a couple of things but most is in tact (probs still way too much but hey ho)

Received: from hostedexchange.hostedservice.com ([192.168.16.27]) by <deleted> with Microsoft SMTPSVC(6.0.3790.1830);

Fri, 3 Nov 2006 12:53:58 +0000

Received: from GW1.hostedservice.com ([192.168.26.5]) by hostedexchange.hostedservice.com with Microsoft SMTPSVC(6.0.3790.1830);

Fri, 3 Nov 2006 12:53:57 +0000

Received: from mail.letsdrive.com (adi.onyxnet.co.uk [195.97.193.8])

by GW1.hostedservice.com (spam Firewall) with SMTP id 54854EC71C2

for <user[at]lvg.co.uk>; Fri, 3 Nov 2006 12:53:55 +0000 (GMT)

Received: (qmail 27832 invoked from network); 3 Nov 2006 12:53:54 -0000

Received: from host212-183-132-39.uk.access.vodafone.net (HELO ?10.167.98.131?) (user[at]letsdrive.com[at]212.183.132.39)

by adi.onyxnet.co.uk with SMTP; 3 Nov 2006 12:53:54 -0000

its this final Received line that is the culpret, not sure i understand it tho'... note the IP (212.183.132.39) is another shared remote host ip, not one of "ours". also something that throws me is the IP on the HELO, 10.x.x.x is a private address? why would it be reported on a HELO...

[GraemeL]

Looks like you did a good job of the munging. Left enough for analysis, but stripped out the stuff the bad guys don't need to know. the only other thing you might have removed were your internal IANA reserved IP addresses, but posting them isn't a significant risk.

My best guess on "(user[at]letsdrive.com[at]212.183.132.39)" is that it's part of the logging done by your email supplier and shouldn't affect anything important. It simply informs them that the mail was sent by a particular user at your company and the IP address that they were using when connected. This would help them track down any abuse by users of their services.

[dibz]

My best guess on "(user[at]letsdrive.com[at]212.183.132.39)" is that it's part of the logging done by your email supplier and shouldn't affect anything important. It simply informs them that the mail was sent by a particular user at your company and the IP address that they were using when connected. This would help them track down any abuse by users of their services.

yes probably, it just appears to be that IP that is later causing the issue... or rather that of host212-183-132-39.uk.access.vodafone.net