Jerich0 Posted September 9, 2004 Share Posted September 9, 2004 Having just reported a spam, I was surprised that the reported-to list did not include Yahoo... examing the headers, I noticed that Yahoo seems to have included a "Received:" line for the IP [69.88.7.226] that apparantly connected to Yahoo's mail server to initiate the email (note the "via HTTP" in this line). The SpamCop parser accepted the final Received line as valid, reporting to the connecting IP domain (HawaiiTeleport.com) and not to the Yahoo domain which apparantly inserted the email onto the internet. I followed up with a manual submission to Yahoo abuse (aka customer "care"), however: 1. If SpamCop is not going to report to Yahoo, it should be listed with something like "does not accept reports" so that SpamCop users are informed 2. If SpamCop is being mislead by Yahoo's additional Received line (results in ignoring Yahoo as part of the spamming process), perhaps an upgrade is needed to the parser/reporting process. Is this a problem, or a known "thing" (I didn't find any mention)? submitted report Original headers: NB: The email was sent to [at]Chamber... whose ISP (TigerTech) redirected it to a mailbox at SneakEmail who redirected it to Adelphia... this is normal. The "From:" is as delivered to me, and normal for SneakEmail (it permits anon replies), the apparant actual sourcing email address is "raharjo agus" <raharjo_agus2005[at]yahoo.com> which is what I reported to Yahoo. From - Wed Sep 08 16:33:52 2004 X-UIDL: <20040908034119.36165.qmail[at]web53403.mail.yahoo.com> X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: <YYYmungedYYY[at]sneakemail.com> Received: from monkey.sneakemail.com ([38.113.6.61]) by mta6.adelphia.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with SMTP id <20040908034124.WMUB23168.mta6.adelphia.net[at]monkey.sneakemail.com>; Tue, 7 Sep 2004 23:41:24 -0400 Received: (qmail 11695 invoked by uid 501); 8 Sep 2004 03:41:23 -0000 Received: from fry.tigertech.net (HELO fry.tigertech.net) (64.71.157.148) by mail.sneakemail.com with SMTP; 8 Sep 2004 03:41:23 -0000 Received: from localhost (localhost [127.0.0.1]) by fry.tigertech.net (Postfix) with ESMTP id 37CF53FC055 for <XXmungedXX[at]ChamberOrchestraOfTheSprings.org>; Tue, 7 Sep 2004 20:41:22 -0700 (PDT) Received: from web53403.mail.yahoo.com (web53403.mail.yahoo.com [206.190.37.50]) by fry.tigertech.net (Postfix) with SMTP id 6737C3FC041 for <XXmungedXX[at]ChamberOrchestraOfTheSprings.org>; Tue, 7 Sep 2004 20:41:20 -0700 (PDT) Message-ID: <20040908034119.36165.qmail[at]web53403.mail.yahoo.com> Received: from [69.88.7.226] by web53403.mail.yahoo.com via HTTP; Tue, 07 Sep 2004 20:41:19 PDT Date: Tue, 7 Sep 2004 20:41:19 -0700 (PDT) From: "raharjo agus raharjo_agus2005-at-yahoo.com |COS|" <YYYmungedYYY[at]sneakemail.com> Subject: catalog via letter,please.I am wholesale Link to comment Share on other sites More sharing options...
dbiel Posted September 9, 2004 Share Posted September 9, 2004 The first thing that I see in the parser report is the fact that you have not registered your MailHosts. By failing to register your MailHosts you make the job of the parser that much more difficult. There also seems to be a lot of problems listed regarding the varrious handoffs of the mail as recorded in the headers. Link to comment Share on other sites More sharing options...
Jerich0 Posted September 9, 2004 Author Share Posted September 9, 2004 Okay, all registered (I think). I presume this doesn't aid my prior report... (?) Link to comment Share on other sites More sharing options...
Wazoo Posted September 9, 2004 Share Posted September 9, 2004 The SpamCop parser accepted the final Received line as valid, reporting to the connecting IP domain (HawaiiTeleport.com) and not to the Yahoo domain which apparantly inserted the email onto the internet. I'm going to have to start out the fact that you are using some confusing terminology in your query. For example, I'm still trying to sort out why you try to connect a Received: header line and an advertising tag line in trying to define your "problem" ... There are two sections to the parsing .. the headers to look for the source of the spew and then the body contents for spamvertised crud. I followed up with a manual submission to Yahoo abuse (aka customer "care"), however: I'm not sure what you might have complained about, and you don't actually specify (though go on to talk about the header lines, thus the Yahoo server) 1. If SpamCop is not going to report to Yahoo, it should be listed with something like "does not accept reports" so that SpamCop users are informed Ummm, here's what is actually displayed with "Show Technical Details" selected; 3: Received: from web53403.mail.yahoo.com (web53403.mail.yahoo.com [206.190.37.50]) by fry.tigertech.net (Postfix) with SMTP id 6737C3FC041 for <x>; Tue, 7 Sep 2004 20:41:20 -0700 (PDT) Hostname verified: web53403.mail.yahoo.com Tiger Technologies received mail from sending system 206.190.37.50 4: Received: from [69.88.7.226] by web53403.mail.yahoo.com via HTTP; Tue, 07 Sep 2004 20:41:19 PDT No unique hostname found for source: 69.88.7.226 Trusted site mail.yahoo.com received mail from 69.88.7.226 (you may not have seen this before, resulting from your mail-host configuration) Tracking link: http://mail.yahoo.com [report history] ISP does not wish to receive report regarding http://mail.yahoo.com Resolves to 216.109.127.60 Routing details for 216.109.127.60 Report routing for 216.109.127.60: yahoo[at]admin.spamcop.net ISP does not wish to receive reports regarding http://mail.yahoo.com - no date available http://mail.yahoo.com has been appealed previously. and this last part deals with the advertising string at the bottom of the spam. 2. If SpamCop is being mislead by Yahoo's additional Received line (results in ignoring Yahoo as part of the spamming process), perhaps an upgrade is needed to the parser/reporting process. What problem? In this chain, the Yahoo server simply processed and forwarded e-mail properly. From what I'm looking at, it appears to be a Yahoo to Yahoo e-mail ... I'm off to go take a look and see how nuts I may be ..??? Link to comment Share on other sites More sharing options...
Jerich0 Posted September 9, 2004 Author Share Posted September 9, 2004 Thank you for your response. I clearly missed the reference that Yahoo "does not wish to receive reports" about mail.Yahoo.com now visable in the detailed report. It is very unfortunate that no similar reference appeared in the basic SC output when first submitting the spam to SC. Had I been aware then of this situation, I would not have bothered you all with these posts. My conclusion remains that someone accessing HawaiiTeleport's domain made an HTTP connection to Yahoo's mailserver (which requires an explicit login) to create an email which Yahoo proceeded to deliver. Using their service in this fashion is a violation of Yahoo's TOS (section 6.g) which I reported to Yahoo via their customer care abuse web-form. I have not been able to locate a TOS/AUP for HawaiiTeleport (unaffiliated with Yahoo IMHO). Link to comment Share on other sites More sharing options...
WB8TYW Posted September 10, 2004 Share Posted September 10, 2004 My conclusion remains that someone accessing HawaiiTeleport's domain made an HTTP connection to Yahoo's mailserver (which requires an explicit login) to create an email which Yahoo proceeded to deliver. Using their service in this fashion is a violation of Yahoo's TOS (section 6.g) which I reported to Yahoo via their customer care abuse web-form. I have not been able to locate a TOS/AUP for HawaiiTeleport (unaffiliated with Yahoo IMHO). 16658[/snapback] The system that made the connection to the Yahoo server is most likely a zombied computer under the remote control of a spammer. This is something that source ISP should fix because it is costing them cash in the bandwidth that the spammer is stealing by routing spam through them. A residential ISP makes it's money by the fact that most residential users, even the heavy downloaders only use a small amount of bandwidth. So the ISP buys bandwidth at an expensive metered rate that it shares with thousands of users at a fixed rate. It is basically a statistical calulation that normally allows a profit. Except that a spammer using a compromised machine can use more bandwidth in a week than the ISP would be making in profit from that customer in the whole year. In addition, they can use so much bandwidth that the ISP may even have to issue refunds to customers. Yet since the people in charge of getting rid of the zombies and answering the abuse mail box do not understand the relationship between the bandwidth costs, and the e-mail they are reading, many will not take quick action to block such zombies, and may be giving the owners warnings with out understanding why it is hurting their employer's bottom line. Media reports that the retail value of the bandwidth stolen by a spammer is over $1,200 U.S. per week. An ISP obviously gets a better rate, but if the spammer saturates a link, then that is money that they are not collecting from a paying customer. I would not be concerned as to if it is a violation of the TOS. If you can verify the source, send the lart. -John Personal Opinon Only Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.