Jump to content

Is it possible for spam report addresses to be wrong?


elind
 Share

Recommended Posts

I sometimes see reporting addresses on my reported spam list that look suspicious to me. For example (I have seen other similar ones in the past), I recently noticed a spam report going to an address in the Bahamas (Bahamas Telecom) as follows:

hussain[at]batelco.com.bh

I don't know of any Arabs in government positions (or anywhere else) in the Bahamas, having lived there, and while it is of course possible I find it strange that the spam/abuse contact on record for Bahamas Telecom would be a Hussain.

Could this be faked somehow?

Link to comment
Share on other sites

I sometimes see reporting addresses on my reported spam list that look suspicious to me.

To paraphrase a popular statesman, I guess it depends on what you mean by "faked."

Assuming that SpamCop gets these addresses from IP-whois (either directly or from a cache), then the question becomes whether the info in IP-whois is genuine. Who knows?

I think that the info in IP-whois is generally more reliable than the info in domain-whois. I also think that the info for ARIN blocks is more reliable than for other RIRs (I often get spam for which no reporting address can be found, simply because the IP-whois info -- usually from RIPE for Russian blocks -- does not have one).

Of course, you don't have to be an Arab to have the name "Hussain," and you don't have to actually be named "Hussain" to use this for an e-mail address.

Hussain could be an employee of batelco whose job makes him the contact for the block. Or, he might have his own block and simply be using the batelco address for a contact.

If you can post the IP address on which the report was made, we might be able to dig a bit deeper.

-- rick

Link to comment
Share on other sites

Could this be faked somehow?

First of all, this is a Reporting issue, so moving it to the Reporting Forum section with this post. In general, the e-mail address involved in a parse result is part of the process that "you" are responsible for checking before sending the Report.

There are several entries in the Original/Official FAQ, the single-page-access-expanded version of that FAQ found here in the Forum, the SpamCop Wiki ..... if one turns on Full/Technical Details for the Parsing routin, the actual look-ups made are displayed, even offering links to 'see' the data and possible decision point made by the parser. There's even a 'refresh cache' link offered just in case the data is really, really bad .... So the actual return question would be .... what in the various FAQs and collections of words has left you in the dark? Have you ever turned on the Full/Technical Details in your own parsing to see just how things work?

There can be a difference as to how your queried result actually came up, based on just how it was obtained. The parse of a spam, the parse of a sourced IP Address, a single-entry parse of a Domain, e-mail or IP address .... As usual, the use of a Tracking URL would have shown/told the story .....

In general, look-ups are made to the various/appropriate IP Address coordination databases, possible look-ups to abuse.net, possible manually inserted over-rides in a local database .....

Can the address be wrong?

Sure, it can be wrong .... cache may be hosed/poisoned, look-ups may fail, abuse.net entries may be wrong, manually inserted addresses may be mistyped ..... again, this is "your" part of the process, to review those target address and agree with them before hitting the Send/Submit button. However, there really no way to deal specifically with your suggested address, as it is provided with no context .... Please provide the Tracking URL of the Parse result.

Link to comment
Share on other sites

To paraphrase a popular statesman, I guess it depends on what you mean by "faked."

..........

If you can post the IP address on which the report was made, we might be able to dig a bit deeper.

I only have this from the spamcop report which I happened to glance at.

spam report id 2756492780 sent to: hussain[at]batelco.com.bh

May be saved for future reference:

http://www.spamcop.net/sc?id=z1606922692zc...c85bb28e8f207az

I picked up on it because of my earlier comments and that I have seen similar reporting addresses in the past for, for example, yahoo. In my experience large companies, particularly governments, don't give individuals' names for their contact addresses, particularly non matching ethnic ones.

I don't know if this IP did point to Batelco, but if not it seems like a deliberate attempt to avoid spam reporting and presumably identifying, and a trivially simple one at that.

I'm not an expert on this stuff, but if spammer ISPs can set up with fake abuse contact addresses, or none, why don't they just all do none?

Would it not be practical to check for a domain match between the reporting address and the originating IP, and not bother to report if they don't match, just as one would do if there was no address?

Link to comment
Share on other sites

Would it not be practical to check for a domain match between the reporting address and the originating IP, and not bother to report if they don't match, just as one would do if there was no address?

MailHost Configured Reporting Account results;

1: Received: from unknown (HELO speedtouch.lan) (82.194.34.116) by mx70.cesmail.net with SMTP; 13 Jan 2008 12:23:35 -0000

No unique hostname found for source: 82.194.34.116

SpamCop received mail from sending system 82.194.34.116

2: Received: from [82.194.34.116] by email.branchoffice.com.au; , 12 Jan 2008 04:23:34 -0800

No unique hostname found for source: 82.194.34.116

Possible forgery. Supposed receiving system not associated with any of your mailhosts

Will not trust anything beyond this header

Tracking message source: 82.194.34.116:

Routing details for 82.194.34.116

[refresh/show] Cached whois for 82.194.34.116 : hussain[at]batelco.com.bh

Using last resort contacts hussain[at]batelco.com.bh

Message is 8 hours old

82.194.34.116 not listed in dnsbl.njabl.org

82.194.34.116 not listed in dnsbl.njabl.org

82.194.34.116 listed in cbl.abuseat.org ( 127.0.0.2 )

82.194.34.116 is an open proxy

82.194.34.116 not listed in accredit.habeas.com

82.194.34.116 not listed in plus.bondedsender.org

82.194.34.116 not listed in iadb.isipp.com

Hitting the "Routing details for 82.194.34.116" returns;

Reports routes for 82.194.34.116:

routeid:24269646 82.194.34.0 - 82.194.34.255 to:hussain[at]batelco.com.bh

Administrator found from whois records

Hitting the "Refresh/Show" link returns;

Removing old cache entries.

Tracking details

Display data:

"whois 82.194.34.116[at]whois.ripe.net" (Getting contact from whois.ripe.net)

hg9798-ripe = hussain[at]batelco.com.bh

whois.ripe.net 82.194.34.116 = hussain[at]batelco.com.bh

whois: 82.194.34.0 - 82.194.34.255 = hussain[at]batelco.com.bh

Routing details for 82.194.34.116

Using last resort contacts hussain[at]batelco.com.bh

Using other tools, much in contrast to your "Bahamas" description, the IP Address is seen to be under the control of some folks in Bahrain ....

inetnum: 82.194.34.0 - 82.194.34.255

netname: ADSL

descr: Bahrain Telecommunications Company

descr: Batelco ADSL service

country: BH

admin-c: HG9798-RIPE

tech-c: HG9798-RIPE

status: ASSIGNED PA

mnt-by: BATELCO-MNT

person: Hussain Ghasra

address: Batelco Telegraph House

address: Salmanya

address: PO Box 14 Manama

address: Batelco Telegraph House

address: Bahrain

phone: +0973 17 883858

fax-no: +0973 17 246221

e-mail: hussain[at]batelco.com.bh

nic-hdl: HG9798-RIPE

This is where the address came from. If you want to go with the 'fake' definition, you'd have to take it up with RIPE/ICANN, but you'll need to do some homework first to take some steps to 'prove' that it's a 'fake' address .. i.e., does it bounce, does snail-mail get returned, the phone number doesn't work, etc.

Link to comment
Share on other sites

Using other tools, much in contrast to your "Bahamas" description, the IP Address is seen to be under the control of some folks in Bahrain ....
My bad, too... "BH" is obviously "Bahrain" not "Bahamas" (which, unfortunately for them, is "BS").

So, "hussain" would be a perfectly logical e-mail handle for a person from Bahrain. Wazoo's work also indicates that this particular address is an ADSL line, so my first inclination would be to suspect a zombie. Perhaps when Hussain gets your report he will be able to do something about this small problem at least.

Would it not be practical to check for a domain match between the reporting address and the originating IP, and not bother to report if they don't match, just as one would do if there was no address?
I think this is a case of mixing apples (IP blocks) and oranges (domain names). I don't know of a reliable way to link the two except via DNS, and this is a very mutable linkage. Also, I don't think there's any requirement that you must use a particular e-mail address for IP-whois contacts, you could use anything you liked so long as it works and you respond to it.

-- rick

Link to comment
Share on other sites

My bad, too... "BH" is obviously "Bahrain" not "Bahamas" (which, unfortunately for them, is "BS").

So, "hussain" would be a perfectly logical e-mail handle for a person from Bahrain. Wazoo's work also indicates that this particular address is an ADSL line, so my first inclination would be to suspect a zombie. Perhaps when Hussain gets your report he will be able to do something about this small problem at least.

I think this is a case of mixing apples (IP blocks) and oranges (domain names). I don't know of a reliable way to link the two except via DNS, and this is a very mutable linkage. Also, I don't think there's any requirement that you must use a particular e-mail address for IP-whois contacts, you could use anything you liked so long as it works and you respond to it.

Oops. Silly of me, having had quite a few email exchanges with Bahamas Telecommunications, (also called batelco) I missed that altogether. So it would appear that Hussain is our man in this case. However as mentioned, I am sure I have seen some similar reports sent to Ali's or Mohammeds at Yahoo, but you say anyone can do that legally.

Also thanks to Wazoo for that scarily detailed analysis. very interesting to a novice like me.

Link to comment
Share on other sites

Looking at http://www.rfc-ignorant.org/tools/lookup.p...=batelco.com.bh

Current Results for batelco.com.bh lookup

blacklist_zone domain status Submitted Added Rejected Removed
whois bh Listed Jun 26, 2004 19:09 EDT Jun 27, 2004 4:41 EDT Never Never
postmaster batelco.com.bh Listed May 12, 2003 12:48 EDT May 14, 2003 18:27 EDT Never Never
abuse batelco.com.bh Listed May 8, 2003 3:17 EDT Jun 2, 2003 2:30 EDT Never Never
So - the whole .bh TLD has been listed by rfc-ignorant on the basis of wonky whois data (rfc-ignorant, unlike Edmund Burke, knows "the method of drawing up an indictment against a whole people," - but see the listing policy on the rfc tools link above and check whether it seems warranted in relation to batelco.com.bh). batelco.com.bh is listed for non-acceptance of abuse and postmaster addresses but using http://hexillion.com/asp/samples/ValidateEmail.asp
preference exchange IP address (if included)

100 batelco.com.bh [193.188.97.108]

SMTP session

[Contacting batelco.com.bh [193.188.97.108]...]

[Connected]

220 cgpfe1.batelco.com.bh ESMTP CommuniGate Pro 5.1.13

EHLO hexillion.com

250-cgpfe1.batelco.com.bh is pleased to meet you

250-DSN

250-SIZE 10485760

250-STARTTLS

250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5

250-ETRN

250-TURN

250-ATRN

250-NO-SOLICITING

250-8BITMIME

250-HELP

250-PIPELINING

250 EHLO

NOOP *** See <http://www.hexillion.com/MailAdmin/> for an explanation of this session

250 OK

NOOP *** HexValidEmail COM 1.4.12 <5c31a8fa73d35685c3baa1e0430da151bdc52a85>

250 OK

RSET

250 SMTP state reset

MAIL FROM:<HexValidEmail[at]hexillion.com>

250 HexValidEmail[at]hexillion.com sender accepted

RCPT TO:<hextest6719[at]batelco.com.bh>

550 hextest6719[at]batelco.com.bh unknown user account

RCPT TO:<abuse[at]batelco.com.bh>

250 abuse[at]batelco.com.bh will leave the Internet

RSET

250 SMTP state reset

QUIT

221 cgpfe1.batelco.com.bh CommuniGate Pro SMTP closing connection

[Connection closed]

Abuse is accepted, there is no catch-all, same result with postmaster (also with hussain). None of them is neccesarity read but it looks like a bum rap from rfc-ignorant to me, I would have to count this one as inconclusive and award "benefit of the doubt" to the domain in the absence of other evidence but if their abuse record says to send to hussain[at]batelco.com.bh then that would certainly be the initial approach to use.
Link to comment
Share on other sites

In fact http://www.abuse.net/lookup.phtml?domain=batelco.com.bh says

postmaster[at]batelco.com.bh (for batelco.com.bh)

helpdesk[at]batelco.com.bh (for batelco.com.bh)

abuse[at]batelco.com.bh (for batelco.com.bh)

I can imagine all sorts of reasons why these might not be used but anyway, if whois.ripe.net says hussain is the man, then that is what SC uses and, as seen, seems valid:

http://www.ripe.net/whois?form_type=simple...o_search=Search

Link to comment
Share on other sites

Yes, but rfc-ignorant does not automatically delist like spamcop when the problem is corrected, it actually requires a request from someone to do so. You might want to send him an email and let him know that those addresses seem to be working for that domain now so he can delist them.

Of course, you might want to test them first. Simply checking to see if the address is accepted does not mean the email will be delivered and not bounced later when the mail server decides the address doesn't exist.

Edited by Telarin
Link to comment
Share on other sites

...Yes, but rfc-ignorant does not automatically delist like spamcop when the problem is corrected, it actually requires a request from someone to do so. ...
Truth - though they have been listed for more than 4½ years with (presumably) little effect or harm so presumably they see little compulsion to seek change. My point was to just explore aspects of the initial query on abuse reporting. Incidentally, spamcop.net has been listed on rfc-ignorant for (very nearly) 5 years.
Link to comment
Share on other sites

Truth - though they have been listed for more than 4½ years with (presumably) little effect or harm so presumably they see little compulsion to seek change. My point was to just explore aspects of the initial query on abuse reporting. Incidentally, spamcop.net has been listed on rfc-ignorant for (very nearly) 5 years.

True enough. The few places I have seen rfc-ignorant used by spam systems, it is always in a scoring fasion, and always carries pretty low weight. Would be nice to see "required" RFCs enforced a little more rigorously, but there are so many large ISPs so far out of compliance that they don't want to start throwing stones I think.

Link to comment
Share on other sites

  • 4 weeks later...

I've noticed more and more lately that the SpamCop cache is in need of manual freshing for the reports to hit the right ISP/Host.

A recent one was:

http://www.spamcop.net/sc?id=z1645505149z0...73a763d6fa5dbez

It was cached to sent to a dev'null address for bounces (I don't recall the contact, but it was .az).

How often does the system refresh the cache?

Edited by btech
Link to comment
Share on other sites

Since there was a discussion in the newsgroups about caches, I asked Mike Easter - who generally knows the answer, how often the caches were refreshed. He said that he doesn't know.

My guess is that the 'system' doesn't automatically refresh them, but relies on sharp eyed reporters. Perhaps btech's observation that there are more needing refreshing is due to more reporters using quick reporting - if it is the source that needs refreshing. If it is the spamvertised site that is being reported, that's because spamcop gives only minimum attention to spamvertised sites because the focus is on the source.

If the system doesn't automatically refresh the cache and doesn't care, perhaps it is because of the heavier weight of spamtraps in the algorithym for listing since spamtraps don't send reports. And also because there are fewer and fewer server admins who, upon receiving a spamcop report, take any action either because they are blackhat or because they discover any 'mistake' quickly by other means. I don't know what the common opinion of server admins is about spamcop, but many responsible ones used to consider the spamcop reports a nuisance because they were generally reporter errors. Those who are interested in spamcop reports usually have a good relationship with the deputies and probably keep them updated on abuse addresses.

Many people, including Mike Easter, think the real value of spamcop is in the blocklist.

Miss Betsy

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...