Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by hadaso

  1. I was wondering if the same can be applied to those who hire the spammers to do their advertising, either directly or indirectly. I've been following an Israeli spammer that seems to be botnet-based (statistics show that 270 messages I got from them over more than a year came from 268 different IP addresses in 40 different countries + 26 US states, and different networks within each country.). The reason I follow this particular spammer is that this spammer is that they are very successful in marketing their product to what people call "kegitimate businesses", and that the service they sell is the use of people's computers without the owner's knowledge). I was trying (still am) trying to get positive evidence that the different IP addresses actually represent infected machines and so I include with every spamcop report on this particular spammer a request to the ISP to check and confirm if it is actually an infected PC used without the owner's permision. I had only one ISP respond. It was a local ISP in Oklahoma the sent a reply to my SpamCop report saying he believed that this was an infected PC, that the IP address got complaints about other spam, and had open ports sending out binary traffic. Now the particular spam sent from the said machine advertised government loans being offered by an Israeli government agency, that has already sent spam using the services of this spammer in the past. So the story here is that an Israeli government agency has spent Israeli taxpayer money to hire a criminal to provide them a service by using hijacked private machine in Oklahoma and its network resources (probably thousands of hijacked machines but we know for sure only one of them was hijacked). I went with this info (list of IP addresses, copy of the above quoted correspondence and some more email) to the Israeli police computer crime unit, and they said they were interested, that they would investigate, that they would very much like to stop the spammers but there's very little they can do with what I brought them and with the way the law limits them (and of course they are severely understaffed and have to deal with lots of other things, fraud, child porn etc.). I also filed a complaint with the State Comptroller about the use of taxpayer's money to hire criminals. Anyway what I see is "legitimate" businesses such as several academic colleges (real ones, not the "get whatever degree you like" type), an investment house offering to handle your portfolio if it's worth $100000 or more (would you let a botnet spammer do that for you? Apparently people do because they hired the spammer several times) and many more businesses selling "legitimate" products. So I think there should be some way to take those that hire these services to criminal court. Several times I saw complaints about companies that advertise through this spammer, and the replies were usually of the sort "we don't directly work with them, we use a marketing agency that hired them" and "we made sure to ask that there would be a removal link". If they would have to pay a price because they purchased stolen goods (or stolen services) they would check more carefully what they are getting before they give their money to the criminal!
  2. That's a problem that needs to be solved. What the FBI really needs from the ISP is not personal info of a subscriber. What they need is information about the type of traffic going out of that computer that is not the subscriber's personal info. They need to have details of the kind of trojan on that machine, the kind of activity the trojan conducts and the spam going out of the particular machine (that would carry information leading directly to whoever paid money to use that trojan). So there's a need for a way that law enforcement can ask for this info and get it without the ISP providing private information of the subscriber. I have been following a particular Israeli spammer that seems to be sending using zombies. In every spamcop report of spams I get from this spammer I now include a request to the ISP that they inform me if they can positively identify that it really is a compromised PC. Only one ISP replied. It was a local ISP in Oklahoma. They checked the traffic out of the (dynamic) IP address that received several reports and saw that it was sending out spam and also some binary data thru some open ports, and said it was definitely an infected PC. With that I went to the Israeli police. They said they cannot do anything with spam, but using a compromised PC is a different thing, and they would investigate. Anyway, reporting spam from zombie PCs is quite frustrating. It seems that most ISPs do not care too much since it is not affecting their mail servers and thus not affecting their subscribers' outgoing mail. What is needed is that each such IP address that can be assciated with a real spam email from an identified spammer (or advertiser) be checked for abuse and then if it can be posotively verified that spam advertising a product or service has been sent using a trojan horse on a PC criminal charges would be brought against the advertiser. I don't want to argue with anyone who thinks that businesses should be allowed to legally hire a spammer to send spam (I don't think they should). They certainly should not be allowed to hire a botnet to send their spam, since that is not much different from purchasing stolen goods (hiring botnet based services is purchasing stolen services and resources) so they should be punished if they do. If some advertisers go to jail for hiring botnet-based services we would see much less of that since most advertisers would be much more careful in choosing their service previders.
  3. An email provider should not block a user's incoming email without letting the user opt-out or adjust the settings (well, there are exceptions. Very conservative BLs such as those listing known open relays/proxies can be used, as they block almost no legitimate email, and not blocking them exposes an email system to possible denial of service attacks. SpamCop is not such a BL. IP addresses listed on SpamCop often send much more legitimate mail then spam, so it's senseless to block them. But it's a very good indicator that some other spam tests should be applied). If they would not let you receive all your email and you really need to receive your email then you should probably host your email elsewhere. If they are good webhosts you might want to keep them as webhosts and host your email separately. Webhosts are professional webhosts, and not necessarily very professional mail hosts. SiteGround's response certainly shows they are not very competent as email providers. It is possible to host email for a domain and website for a domain at different hosts (actually you can also host different subdomains at different hosts, independently for web and for email). What's possible is only limited by your host. If your webhost insists on hosting your email and your DNS then you have no choice (except changing webhost). I they don't insist on hosting your DNS than you can host your DNS elsewhere (e.g., at Zoneedit.com) and point your MX (mail server) record to any mail provider. If they insist on hosting your DNS they might allow pointing the MX record elsewhere. There are other considerations: e.g., they might not insist on hosting DNS for you but still be running chacks to verify that you point your MX record at their mail servers. EmailDiscussions.com has lots of threads discussing different comfigurations of using separate web/mail/dns hosts (and also multiple mailhosts for redundancy and all sorts of strange comfigurations...)
  4. Two kinds:The kind that doesn't read the faq, and just blocks any listed IP (e.g. your recipient's email host). The kind that reads the faq and feeds the listed/unlisted info into a filter that gives it appropriate weight (e.g. my email host, using Spamassassin). If your email was blocked and whoever blocked it claims it was blocked because it was listed on SpamCop BL then the cause of the blocking is at list one of two: whoever implemented the blocking either haven't read SpamCop's recommendations before using the BL, or chose to ignore it, and your provider received (or chose not to receive) complaints about spam going out of the IP address you used and haven't done enough to prevent these complaints. The combination of these two causes your email to be bounced. If one of these causes is avoided your mail would get through.
  5. Not really. Their biggest problem (related to this SC listing issue) is stopping spam sent from their servers. FastMail.FM had a similar problem with SpamCop listing and now the problem is practically non-existent, without listing the IP addresses of http clients. The real solution is comprised of monitoring many aspects of the system and catching the spammers when they try to send (and includes things like scanning outgoing mail for spam, monitoring outgoing rates, bounce rates, and more), and then acting fast (disabling spammers accounts as fast as possible). The best way to fight spammers is to get rid of them when they're "young" ("Children, watch out for the baobabs!" from The Little Prince by Antoine de Saint Exupéry).
  6. But then if Gmail revealed the IP address of the web-client used to access their web server by the user it would not be shared by hundreds of email addresses, but would be an IP address allocated to exactly one person working on one machine, and if that person happened to work on that one machine in a country that doesn't value free speech or human rights, thae person can be easily located and sent to jail (or elsewhere).
  7. Honesty is good! I only had time to read all these posts because it was in portions over several months. As much as we like to hate M$, they're not that bad, and I don't think they'd stoop so low. What an exaggeration! What do you compare it to? Hotmail and Yahoo? there's lots of basic email functionality that's unavailable in Gmail, and thaere are lots of email providers that you may never have heard of offering functionality you don't have with Gmail. There is no such thing as a "best e-mail provider" since email is very complex, and what is "good" depends on how you are using it. SpamCop listings are not based on email addresses. They are based on parsing email headers to locate the machine that originally sent the email message. So it's not so easy to get SpamCop to generate false listings, but actually it's probably possible to forge email headers in a way that fools SpamCop into accepting false reports. So it's actually an interesting question: what mechanisms does SpamCop has to detect and avoid false reports? SpamCop blocks no email: SpamCop only publishes a list of IP addresses, and those are IP addresses that sent several email messages that produced complaints by their recipients. Some email providers or users refuse to receive email from these sources so they block them. SpamCop advises against using the list in this way and advises a more subtle approach that uses several parameters to decide what to do with a received message. The main cause of this long thread is not SpamCop or Gmail but rather stupid email admins that apply the SpamCop list without reading the manual.
  8. Spamcop listing should not depend on other listings. SpamCop listing is based on different criteria, so there's no reason why anything that is listed on SpamCop should be listed on anther list that employs different criteria, and vice versa. Nobody forces you to refuse all email from sources listed on SpamCop BL. SpamCop doesn't recommend doing it. It recommends using the listing as data to be fed to a more comprehensive solution such as SpamAssassin (that gives it appropriate weight among other criteria used to decide what should be discarded or diverted from users' inboxes). You mean if you send from a Gmail account to your server and your server bounces? If Gmail can detect that the cause of the "554 Service Unavailable ...etc..." message is a SpamCop listing then they might treat it as a "45x blah blah ..." and reschedule the email to be sent later, as a SpamCop listing is a transient condition (24 hours) and your server would accept the email once the listing is removed after 24 hours or less.
  9. This is becoming dangerously close to language that the average sysadmin of a small ISP (or junior staff at a major ISP) would not understand and does not care about. How about "SpamCop lists IP addresses that recently either sent a predetermined relative amount of email messages to some secret addresses or generated a significant relative amount of complaints about spam received. It doesn't list IP addresses that send only spam."... Simple language that makes every reader understand immediately that the list means that the IP generated email that has some spam but is not all spam, with a link to the details in the faq is best, in that a reader that understands nothing about email should be able to understand immediately upon reading the message that the fault is with the recipient's ISP not doing their homework, and then the reader can learn more if the reader wants to learn more. One problem is that ISPs sell ineffective filtering services. If mosti ISPs would have to learn how to filter spam more effectively (because users learn about it and demand it) then Spammers would have a real problem.
  10. Sometimes outgoing mail from gmail is blocked and tSpamCop is cited as the cause of blocking. SpamCop is not the cause of blocking. Gmail is not the cause of blocking. The cause of blocking are some stupid postmasters at some ISPs that use blocklists without understanding what they mean: SpamCop lists IP addresses that sent some spam. It doesn't list IP addresses that send only spam. So using SpamCop listing as the sole criterion for blocking is very bad and would result in lots of legitimate email being blocked. On the other hand SpamCop BL is an excelent resource when used in conjuction with other methods of filtering spam, as it it constantly updated and never contains old info. Some ISPs happily collect their $2/month for blocking spam and don't care if their users don't get all their email, and most email users don't understand much and would accept that losing some email is a technical problem that cannot be solved unless they want lots of spam. The problem is how to educate these ISPs about correct spam filtering. One way to do it is that if a bounce message contains a link to spamcop as explanation to why the message was blocked, the spamcop page reached would clearly say that this list is not appropriate for direct blocking, and is very good as input of a comprehensive filtering system, such as SpamAssassin or others. This would avoid most complaints about "SpamCop blocks my email" since anyone whose email is blocked would immediately get the explanation that the reason is the ISP that uses SpamCop incorrectly. And this would have another good effect in generating public demand for better spam filtering (as in: "My dearly beloved ISP: I pay you $2/month for spam filtering. Why do you supply me wih only basic and incorrectly implemented blocking when there are better tools that you can download freely and use in your server?").
  11. If Gmail forged "Received" headers like Hotmail and Yahoo do then spamcop reports about "source of spam" would go to the sender's ISP (or internet cafe or whatever...) that would certainly not close the sender's Gmail account. The way Gmail does it spamcop reports get to Gmail's abuse team that can act on it. And the way Gmail explains it to email admins might make them read spamcop's faq and perhaps use SCBL correctly (through spamassassin or something similar). When I receive spam sent from a Hotmail account and try to report it to Hotmail, I cannot do it using SpamCop because spamcop sends to a connectivity provider that cannot close the sender's email account that they do not control. I have to manually send a report to Hotmail's abuse that can then close the spammer's Hotmail account.
  12. Not really. The actual sending IP would be the one getting listed instead of the intermediate IP. The main difference would be the reduction of legitamate mail being affected.33772[/snapback] Not the sending IP. The IP of a machine that runs an interface controling the machine that sends the message. In webmail the user's machine is only an I/O device that controls an MUA running on a different machine (on the web server). Those services recording the web session in a "Received" header as if it was a transmision of an email message are just not following RFCs. SpamCop's logic would require that if I telnet a UNIX host and send mail by using the "mail" command in a UNIX shell like I did in the good old days before spam then a "Received" header should be added recording the IP address of the telnet client. What's the difference between controling an MUA using telnet or using http as the communications protocol that sends instructions to the MUA? The main difference between recording the IP address of the control mechanism and not recording it is not the reduction in legitimate mail blocked, but the reduction of the blocking of all mail, because that way the IP addresses getting listed doesn't run any kind of software that transmits email. What you are saying that the way to avoid legitimate email being blocked using SCBL is to fool spamcop by providing an IP address of a machine that does not transmit email. There are two sides to blocking legitimate email: the recipient loses the email too. And the main difference is that the recipient has no idea what email is not received. If the recipient is a business it means lost business. If the recipient needs info it means they'll have to live without that info. If they expect a job offer they'll have to find another job. So I guess Gmail counts on those recipients that need to have their incoming email to make their mail service stop blocking them. Edit: 2005/10/06 01:03 EDT -0400 Jeff G. fixed the quoting. Edit: lots of typos...
  13. ... and then they won't have any urgent reason to deal with any abusers of their system. So everybody's happy, except for those receiving the spam... But once a list of spamtraps is compiled, using it doesn't show any weakness in any other system. Any email system that allows signups using credit cards can be used to send a few hundred messages before being blocked. spam can only be recognized after it has been sent, and spammers look like any other email user before they start spamming. Being able to send a few hundred copies of a message before being stopped shows nothing about the ability to send tens of thousands or millions of messages.
  14. One possible reason to send email to spamtraps is to generate SpamCop listings. One possible reason to generate SpamCop listings is to cause the blocking of legitimate email and indirectly cause email providers to stop using SCBL. You seem to believe that spamtrap addresses used to by SpamCop are unknown to anyone but spamcop. However there are easy ways to extract those from mailing lists, because SpamCop responds to email sent to them by creating SCBL listings that spammers can access. It is not too difficult to take a mailing list and extract from it a sublist of addresses that have high probability of generating SCBL listing. At least it's not to difficult if you have access to a botnet of a few thousands compromised PCs that can relay email for you from different IP addresses and a list of a few millions addresses scraped of the net that you can purchase for a reasonable price on the web. Anyway, I've seen evidence that spammers have some knowledge of spamcop spamtraps. This post made early this year on emaildiscussions shows a SpamCop spam source report with an unreasonable percentage of spamtrap vs. user reports on one IP address compared to another. -- spam SOURCE REPORT -- IP Address Start/Duration Trap User Mole Simp Additional comments Jan 12 19h/0 0 11 1 0 Jan 10 15h/0 0 1 0 0 Jan 17 17h/4 210 13 1 0 There is no way that this "just happened". You don't have to be a statistician to see that this cannot be explained by chance. But anyway I did make a statistical comparison using this online chi-square calculator and the result is Trap vs. User comparison Trap User Total IP 1 0 11 11 IP 2 210 13 223 Total 210 24 234 Degrees of freedom: 1 Chi-square = 100.997757847534 p is less than or equal to 0.001. The distribution is significant. This means that the probablity of getting this unusual ratio of spamtrap vs. user reports without any real cause is less than one in a thousand. It looks like someone made the effort and got a list of spamcop "secret adresses" and spammed them. If spamtraps are not discarded weekly and replaced by new spamtraps they cannot be considered "secret" and cannot be used to reliably estimate the volume of spam sent to real people. Not if SpamCop responds to them by listing IP addresses.
  15. Spamcop doesn't list the last known IP address. It list the first known email address in the list of Received headers, i.e. the earliest verifiable IP address in the path the email takes. If there is more than one transmision it is not the same address that most systems use when determining whether to refuse or discard a message. And SpamCop does an excelent job in this respect. I report spam manually, I usually look at SpamCop analysis of headers, and almost always there are forged Received headers and SpamCop seems to stop at exactly the right header and avoid the forged ones. However, one thing that makes it possible is spammers' stupidity. It is possible to forge Received headers in a way that would be indistinguishable from real headers, by simulating the real process of email transmision. Now that spamming is moving from little private enterprizes run from mobile homes in Florida to a more global mega-business run by the Russian mafia things might change in this respect. The russian mafia has the resources to hire unemployed scientists or former KGB employees that can do a much better job than the scri_pt kiddies that used to run the spamming business. The fact that they haven't done it so far is that this kind of blocking probably doesn't bother them. There's another more important aspect of the difference between what is listed and what is checked by blocking software: SpamCop's original mission is to pinpoint the machine whare spam actually originates and make it easy for networks admins to find and eliminate the nuisanse. If blocking software using spamcop would actually do the same kind of header analysis (like in spamcop mail service) and check this originating IP against the SCBL, what would happen is like this: Joe User (after visiting several pron sites and gambling sites) would catch a spam relaying trojan. Joe User's PC would become a zombie PC, part of a botnet of spam relays, and start sending out spam. It would get listed on SpamCop. Joe would then try to send out email to the friends he hangs out with on thursday nights and some of it would bounce stating SCBL. Joe would call his ISP and complain. The ISP would check the SpamCop listing and tell Joe the problem is his PC is infected and he should clean it, and perhaps also tell him how to clean it. The spam from Joe's machine stops, and perhaps at the same time Joe learns a bit about ways to watch pron and gamble without getting infected... But what happens right now is that Joe's machine can continue to send out spam, and Joe can still send out email through his ISP, because the recipients' servers check the IP address of Joe's ISP server against SCBL and not the IP of Joe's PC. Using this IP for blocking spam works fairly well since zombie PCs send out email directly. But there is no incetive for the ISP to get rid of the spam relays on their customers' PCs. Actually it's better for them that these IP addresses remain listed. If what we want is to stop spammers, then it is better to promote using SCBL the correct ways. If email recipient use it correctly, the the ISPs of senders would have a financial incentive to keep their networks clean (avoid the cost of customer service related to blocked outgoing email). If it is used the incorrect way, it actually makes a negative incentive: it is cheaper not to deal with the problem than to deal with it.
  16. Stop using Gmail because Gmail policy does not include hacking around SpamCop? The main reason email from Gmail was blocked was not that a few spammers used it, but that a few ISPs followed the instructions provided by SpamCop here to setup blocking of email. They might have followed the advice that email is better tagged than blocked, but the instructions provided are for blocking. Even if they do the homework and find out how to tag or divert email based on SCBL, the information in the SpamCop faq does not instruct them correctly on what IP address to use when comparing to the SpamCop list. In describing how the SCBL works the faq wrongly says that SpamCop lists IP addresses that transmitted spam to SpamCop users that have reported it. That is clearly incorrect as the criterion for inclusion is not being the IP address that transmitted the spam to the spamcop user but rather an IP address derived from the "Received" headers in the message as where the email started its journey. For almost all legitimate email sent it is not the same as the IP address that transmits the message to spamcop users. Mail sent from an email client using SMTP through an ISP's email server has a Received header showing the client's IP address sending to the ISP's server, that then transmits the message to the spamcop user from it's own IP. Most webmail services record the http transaction of submiting a form that happens when a user clicks the "send" button in a "Received" header stating the web client's IP address as the origin. Then the webmail service transmits the message to the spamcop user from its own IP address, not the one that is identified by spamcop as the origin. If the webmail service wishes to protect its customers' privacy and still avoid spamcop listing it can replace those IP addresses with (almost) random IP addresses. SpamCop would not know the difference. Google's main fault is that it doesn't do it. And its minor fault is that it cannot totally prevent spam spam has to be sent at least in small quantities before it can be detected.
  17. Those are two different things. 1. Adding the IP address to the BL is justified by the rules used to decide what's added to the the list. And by the fact that spam actually originated from that IP address. 2. Blocking email based (only) on the sending server being listed on SCBL is almost never justifiable. And it is not recomended by SpamCop. But still many clueless sysadmins just use SCBL like any other list of open relays. The main difference is that SpamCop's main mission is identifying the source of spam within networks, and supply ISPs and network operators with identification of the source of spam within their network that they can use to quickly get rid of the problem. In many cases it is not the IP address from which a message is directly received. So what SpamCop lists is the source of the first hop in the message's route. But what most sysadmins do is compare it to IP addresses of servers that they receive mail from (i.e. the source of the last hop in the message's route). So blocking email this way is quite senseless! But it is mainly the fault of the receiving system for not using the SCBL correctly. To use it correctly the email headers should be analyzed, the originating IP address should be identified from the "Received" headers, and this address should be checked against the SCBL. Almost nobody does this, and using SCBL for blocking (or even tagging) any other way is wrong. Big email services like Gmail where first hop and last hop recorded in headers (using IP addresses that are not internal) are the same suffer from this the most. And the solution is very easy: Gmail can record one additional Received header that says that the email was sent internally from one IP address to the the IP address of the server that sends it out. Actually Google probably has so many spare IP addresses that are not used for sending email out that they can create a virtual network were each user is assigned a unique IP address and then getting on a BL would affect only the one user that really sent the spam. IMO SpamCop's only "fault" here is that it does not make it clear enough in the documentation that using the list should be with tools that analyze headers to find the source of the message.
  18. What does "Gmail is an exception mean here? Does it mean that they will end up more often on the BL or does it mean that SpamCop takes into account their different policy and scores them a bit differently to compensate for Gmail's policy?? Nothing is keeping them except ignorance. There's no hint about this being needed in the faq. Cesmail is not mentioned in the faq. A typical mail admin or just email user using filtering software usually configures the software to test the incoming session IP against several BLs, and there's nothing in the SpamCop BL hinting that this is not the best way to do it with SpamCop BL. The intructions that are included in the faq are for testing the IP of the incoming session for SCBL listing. The description of how the process of listing works doesn't mention anywhere that SpamCop tries to go as far back as is possible to do reliably in the transmission chain. The examples given in the faq on what might be listed sugggest the contrary
  19. I am not advocating the punishing of anyoen. I just say that currently the SCBL is useless for blocking spam from almost big ISPs the way described here in the faq. Not in direct rejection and not in the preferable way of tagging spam. For all big ISPs and most big webmail providers SpamCop lists IP addresses that will never send spam ito a recipient (I'm not refering here to listing based on reports about spam sent directly and not through an ISP's mail server). SpamCop is just allowing those ISPs to dillute the BL by listing IPs that no one will ever receive mail from, and at the same time it does not list the IP's from were the spam was received by the recipients that reported it. At the same time SpamCop advocates that services such as Gmail that only list the Received headers required by RFC821 (or 2821) should list an additional Received line that corresponds to internal transfer of info (input to a web application in Gmail's case) just to avoid the real server from being listed, so that if anyone uses SCBL to reject or tag spam, it would not reject any email from Gmail as only IP addresses of machines used for "internal" communications would be listed, never the IP addresses of the server that hands the spam over (here "internal" communications between the web browser acting as an i/o device of the web application and the host hosting the web application).
  20. What ISPs need in a report is the path of IP addresses that the message passes until it leaves their network. If SpamCop reports this in a nice useful way then abuse team members learn to prefer handling spamcop reports first because they save them time, as opposed to reports form other sources that make them have to parse the headers themselves (if headers are provided!). But what a user of the BL that sets an SMTP server to query SpamCop BL with the IP address of incoming SMTP sessions needs is just the last IP address in this chain. It is the only address that might connect to her server and send her spam. Letting ISPs get away with transfering listings to their (often large) pool of internal network addresses (I mean addresses they give to their connected users, or addresses of other ISPs in case of webmail) and keep their outgoing mailservers "clean" ("clean" from listing. Not from spam).
  21. Actually, they only need to have one more internal hop. They just have to designate one IP address that gets all email from users and forwards to a server that sends the email out, with this recorded in a "Received:" header. Then users IP addresses would not be listed, the single IP address used to pass mail to would be listed, and the mail servers sending the email out to the public internet will never get a single report. Just like Hotmail/Yahoo avoid their servers being listed, only without listing the users' IP addresses. Any IP address that is not used for sending email out of Google's network would do, and Google has hundreds of thousands of these (or more since they probably have class A IP range). Iam not suggesting that they do this. It is better that SpamCop list the real point of injection of spam to the internet (like it does with Gmail) instead of listing some internal addresses like it does with Hotmail/Yahoo (effectively listing the IP addresses of the keyboard used to type the email text into an email client running on the webmail server). What Yahoo?Hotmail and others are doing is just forging the transfer of HTML form data used as input to a program the outputs an email message as if the message itself was transported by an email transport protocol such as SMTP.
  22. My point was not that the IP used by the sending PC should not be reported to the ISP so they can deal with the spammer. It's useful info for them. Just that it is completely unuseful to include it in the statistics used to list/unlist in the blocking list, as almost anyone using the list to block spam (except probably only SpamCop email service) is testing the address used by the SMTP client conecting to their incoming SMTP server. So it is completely ineffective for blocking this spammer for almost anyone, and gives very little incentive for the ISP to get rid of the spammer. It has no effect on the listing staus of their mail servers. Actually, even if everyone were parsing their "received" headers to try to block according to the originating IP address and not the "last in chain", all it takes a spammer to avoid it is using DHCP to get a new IP address if there are "too many bounces". Pinpointing the originating PC's IP address is very useful in the report sent to the ISP, but is not useful in the blocking list. It just provides ISPs with a tool to avoid listings for servers that really spit out tons of spam by getting SpamCop to list IP addresses that never send out any email. If spammers were be a little bit smarter, they could use the same technique to avoid listing of the addresses they use to send. So I think that the correct implementation should be to report to the ISP all the internal IP addresses used in sending the spam out, that they can use to locate the spammer inside their system, but in the list that is used by many ISPs to block incoming SMTP sessions (or tag mail coming from these sessions) either the address that sends the email out using SMTP should be listed, or no address at all.
  23. In this example (http://www.spamcop.net/sc?id=z760893335z11...4199783d769b1ez an email message is sent from a PC (notebook ( [])) through an ISP's outgoing mail server (hector.inter.net.il []). The originating IP listed by SpamCop is the IP address of the sending PC ( However, the recipient's server is receiving the message in an SMTP session from the mail server (IP address If the originating IP gets listed and the receiving server is using the SpamCop BL to block or tag mail, the messages sent by this sender would not be blocked/tagged, because the receipient would see them coming from and not from the listed IP ( Actually no one is going to benefit from the listing of the IP of the sending PC, because it doesn't send any email directly out. Everyone receives the email it sends through the ISP's server, so if reporting this spam this is to affect blocking of this sender, it should be the IP address of the ISP that gets the listing, the one that actually sends the spam out to the public internet, not the PC that doesn't send out (of course if it were a zombie sending directly out it would be different.) This reasoning also aplies to webmail from webmail providers who record the IP address of the web browser used to upload the message to the webmail client. In this and in the first example the authenticated transfer from the email client to the service's outgoing mail server is irrelevant to blocking spam, and the only data that can be used to effectively block spam is the IP address of the server that actually uses unauthenticated SMTP to spit the spam out to the public internet (i.e., hands the message over to a party that might want to block spam sources).
  24. Well, it seems that Cnet got the "getting back on spammers" wrong. It's just a C/R system that tries first to authenticate the sender using DNS data, and then, if quite sure the sender's domain doesn't relate to the sender's IP address, then it sends a chalenge. In other words, if it's highly probable that the address is forged, it is sent a challenge, so whenever your address is forged on spam, in addition to the usual bounces, you're also going to get "Challenges" from lots of people you don't know.
  • Create New...