Jump to content

Richard W

Forum Admin
  • Content Count

    78
  • Joined

  • Last visited

Everything posted by Richard W

  1. Richard W

    Why URL whois lookups are failing

    The blocking of Ironport/SpamCop lookups of Polyakov sites - and others connected to Leo Kuvayev - is a known issue and something that is being worked on. Several things were tried over the years, some successful, some not. Those that were successful usually also meant a heavy drag on our own resources, which were abandoned when the system was crawling on its knees last year. Whether our development team will come up with something that satisfies everyone, including the need to conserve resources, only time will tell. I obviously can't comment publicly on things that have been tried or may be on the drawing board. Richard
  2. Richard W

    My SpamCop reporting page is gone

    I've changed the account for the address that Wazoo provided us from an ISP account to a reporting account. I do have to wonder whether you have a different account though, as it looks like this account has always been an ISP account. There's no history of spam being reported on the account, but there is an old history of the address receiving reports a long time ago. Richard
  3. Richard W

    Broken Link in FAQ

    Thanks. I've updated the pdf link to the new one (at least for now). I will not put the tester link in the FAQ because it involves exploiting the known vulnerability on outside servers. Ironport/SpamCop does not support the abuse of any server for any reason. Richard
  4. The answer is contained in the various posts provided by our most valuable resource, our users. To summarize: When you submit an address through the mailhost configuration tool the system does a mx lookup on the domain and sends an email to you through each of the mx's, regardless of priority. Generally a domain isn't going to have more than three mx servers listed, with all others being internal hops. Basically, you 'send back' each of the emails received and the system will work through the headers to identify each server involved in the mailpath between the sender (us) and your mailbox. Each server identified is added to the mailhost record for that domain. If a mailhost record already exists for that domain (i.e. another user on that domain) your account is simply pointed at that already existing record. If any new servers are identified they are added to the existing record. If a new server is found subsequently, yes we have to manually add it. Similarly, if the domain changes hosts we have to add the new servers and remove the old ones. For opentransfer.com, the mailhost record contains 11 server/hostnames and 24 IP addresses. It does contain "opentransfer.com" which will act as a wildcard on subdomain names, but only if dns and rdns are correctly set up. Richard
  5. Richard W

    [Resolved] Comcast blocking Spamcop?

    JT is contacting Comcast about this. My guess is that because Ironport added some new servers last week and this is a new IP, the sudden surge in email from that IP is often a pretty good indicator of a virus, but it is also common for a high volume mail server like SpamCop's. This practice isn't uncommon and is used by many filtering services including Spamcop with its "probationary listing" of an IP suddenly showing up as sending mail when there is no history of mail from that IP. http://www.senderbase.org/?searchBy=ipaddr...g=204.15.82.125 Richard
  6. You have to read carefully what I wrote. The listing of the IP falls within the description provided in the FAQ. "While several people have reported mail from your server in the past," That means more than one person has reported mail from this IP. The number of reporters is also historical, not necessarily current. "the recent reports have all been from a single user" For the past few weeks the only reports against that IP (31 in total) have been by a single user. Even though it's a single user, the history on the IP is many more users reporting spam, which qualifies the IP for listing. "I have written them and am awaiting a response with their explanation of why they are reporting the mail as spam." I have heard back from the user and will be responding to the contact with more infomation tonight. Richard
  7. Richard W

    How do I see the details on spam being reported?

    Most zombies have 'send engines' only and ignore errors your server provides. The usual response is to drop the connection and no bounce/error report is sent. The zombies aren't full smtp servers, so aren't set up to respond as a normal server would. This is a good thing because it means the mail is simply dropped rather than a misdirected bounce being sent by either the sending or receiving server. Richard
  8. Richard W

    How do I see the details on spam being reported?

    Sorry, you're going to get a different answer here than I gave in response to your email to us. I'm not sure where you got 1425957615[at]reports.spamcop.net from, as the report number you are looking at is 1568561770, and that should be the number in the return address. 1425957615 is an old report that has timed out of our database. SC doesn't use the dns/rdns setup of the server. Doing so would result in reports winding up in the hands of spammers, who often have control of their dns setup. Instead, the system looks to the whois records, finding the owner of the block, providing it is a /24 or larger. It searches the addresses in the whois record. If a role account address is found, the domain for the role account address is checked with abuse.net. In your case, role accounts abuse-arin [at] caltrans.ca.gov and noc-arin [at] caltrans.ca.gov are found so caltrans.ca.gov is checked with abuse.net: whois -h whois.abuse.net caltrans.ca.gov ... postmaster[at]ca.gov (for ca.gov) abuse[at]ca.gov (for ca.gov) This may be a limitation of abuse.net not being able to go beyond 2nd level TLDs, I'm not sure, but that's the way it appears. BTW, even if SC did take the rdns name, dot.ca.gov to abuse.net, we get the same results: whois -h whois.abuse.net snaspam01.dot.ca.gov ... postmaster[at]ca.gov (for ca.gov) abuse[at]ca.gov (for ca.gov) This is the results of several years of trial and error. The current configuration, in place for at least the last three years is the most successful at keeping reports out of the hands of the front line spammers. The only way around this for this situation is to direct route reports for the block so it goes around the abuse.net lookup. route added:198.31.97.0 - 198.31.97.255, all, abuse-arin[at]caltrans.ca.gov = 1646227 http://www.spamcop.net/sc?id=z832545018z6a...bc4c3568e3c9f5z Richard SpamCop Deputy
  9. There seems to be two topics under discussion here. The original question was "user defined recipients", the second is referring to third party checkbox/settings. I just changed my preferences to third party off by default and the box is unchecked when I parse spam. Changing the preference back to default on, the box is checked. The third party report preference setting seems to be working as designed. I added a user defined address into my preferences and the box is in fact checked by default, which IIRC is opposite of what used to be done. Changes to the user-defined report handling went live today after about a week of testing on the beta system. Obviously the changes (which I think Don posted about earlier) did change the default behaviour. I'll put through a bug report on that. Richard
  10. There's a couple of issues here. First is the internal LAN IP's, which I've fixed for you in your account. The second, which Wazoo wrote us about (217.174.252.50) -- RIPE now hides email addresses in their records, which the record holder can turn off. If they haven't, SpamCop comes up with "no master found, cannot send reports", because there is no address to send reports to. Maybe I should write RIPE and ask them if we should send all such reports their way Richard SpamCop Deputy
  11. Because every MH setup mail comes from a cesmail server, the handoff from SC shows up in every one. Somewhere along the line that IP ended up in a bunch of different records for Hotmail, MSN and Yahoo. I took it out so it now only shows up in the SpamCop/Cesmail record. Hopefully it didn't break anything. Richard
  12. Richard W

    Habeas Reporting?

    Where Habeas headers are picked up, SC will send a report to them through our internal routing. However, where a user has chosen to be a "mole", no reports are sent to anyone, including Habeas. The report record for this shows: # xxxx ( http://www.62mort.net/book ) To: mole[at]devnull.spamcop.net # xxxx ( http://www.62mort.net/?id=a67 ) To: mole[at]devnull.spamcop.net # xxxx ( 80.64.90.94 ) To: mole[at]devnull.spamcop.net Interestingly, this is the only spam of 15 in our db for that IP with the Habeas header. There are several that show up when looking at the report history on the URL though, so habeas should be aware. Richard SpamCop Deputy
  13. Richard W

    [Resolved] trouble reporting to website

    There have been no changes to the servers that remove this functionality. I have just confirmed it still works using Mozilla and Firefox. As another user has already mentioned, you cannot log in using this method with Internet Explorer, as Microsoft removed this function from IE some time ago as part of a security update. I suspect your old computer had an older, unpatched version of IE, whereas your new computer is using a current version. Richard SpamCop Deputy
  14. Richard W

    [Resolved] Spamcop recommending faulty software

    It's gone. Richard
  15. First off, there are two types of quick reporting available. The first is what is available to SpamCop/CESMail customers and done through the webmail or Held Mail link on the SpamCop site. My recollection is this has alway been referred to as Very Easy Reporting (VER). The second, available to all users is what we have referred to as Quick Reporting (QR), must be manually turned on in user accounts and permits them to 'quick report' spam via mail. Since I don't get to hang out here or the newsgroups often, users may have come to use the terms interchangeably, but they are really two different things. Because of the very problems experienced by some users in this thread, all forms of quick reporting are supposed to shut down in a user's account as soon as they start adding mailhosts to their account. I believe a button to turn "VER" back on is supposed to appear somewhere on the user's SC page. Just as we have to turn QR on in a user's account, we have to manually turn it back on after mailhosts turns it off. I did send this issue to Julian on Friday night based on Gary's experience. I don't expect to hear back until Monday at the earliest. Richard
  16. Richard W

    URLs not reported

    I played around with it but couldn't get the URLs to parse either, although very similar spam is parsing fine. There is something in this that I'm missing. Sent upstairs to Julian. Richard
  17. 203.135.15.198 is a valid outgoing mail server for the sending IP though. Note the statement "Trusted site 203.135.15.198 received mail from 203.135.41.223". That statement means the admin of that server has contacted us and provided satisfactory information proving the server is properly relaying mail only for authorized IPs and it properly identifies and stamps the originating IP. Our goal is to identify the correct source of the mail and prevent more spam from that source from reaching our users. Wherever possible we do not cause collateral damage by listing outgoing mail servers. The parser is correctly finding the source and correctly wanting to send 203.135.15.198 for relay testing because we have not yet done so to date. Richard
  18. Richard W

    Blacklisted... where are the header details?

    Jumping into this late, but I have scanned through most of the posts to date. Quite simply, we are out of necessity very protective of the data we have on file. We don't supply information to just anyone and have to make sure it falls only into the hands of someone in a position to make all the spam stop. The trouble I have is in your statement, "make sure the recipient isn't contacted again", which to me equates to list washing. SpamCop does not and will not support list washing as this only solves our users' problem, not the overall problem of unsolicited mail coming from a server. We're in this for the long haul, trying to make email a better place for everyone, not just the minority who use our service. Specific to 67.43.151.116, the mail hitting our traps all have "Ziba Music" in the subject line, so I suspect that is your customer with the dirty list (as far as spamtraps go). I also see recently reported mail from SunTrust, a realtor and a travel agency, as well as something from "publisher[at]forbes.com" <info[at]life2where.com>, which to me looks downright deceitful. As I mentioned, we have to have trust that reports are being used for the right reasons, not to simply aid a customer to "stay out of trouble". While you state you have cancelled a few spammer accounts, I'm not convinced that would be the case for problem customers. Richard
  19. Richard W

    Refused or not refused, that is the question

    Despite their having a fairly early SC account (in the 400K range), the system shows they have only been sent 8 reports for all time. IIRC from couple or three years ago, one of their abuse folks had a real fit over some spam reports and came out very anti-SC, stating he didn't want any more SC reports. His name is on the tip of my tongue, but I can't seem to spit it out. Perhaps he has moved on to bigger and better things. Richard
  20. Richard W

    No response from SpamCop

    I had a look at your account and confirm the last spam reported was Wednesday, August 25, 2004 02:02:03 -0600. There has been no spam received by SC since that time (if the mail was reaching us but not followed through it would still show up in your past reports as "no reports filed". Write us at deputies at admin.spamcop.net with more particulars, such as the where you are forwarding the mail from/through. There was a problem with mail being sent from Cox, but I think/thought that was resolved. We should be able to assist with more info. Richard
  21. Richard W

    This service really sucks

    Hi David, 66.225.215.32 does have a listing history, but is currently delisted (as of about six hours ago). A spammer(s) have gained authenticated access to the server through the smtp-auth exploit (http://www.spamcop.net/fom-serve/cache/372.html) and has been using the server to relay spam to traps on our systems. Your problem is over (for now), but these spammers are known to come back repeatedly once they have a hole poked in a server. If the admin for the service contact us (deputies at admin.spamcop.net) we'll give them more information, but all they should really need is in the faq above. Richard
  22. Richard W

    SpamCop FAQ problem

    Perhaps a better way would be to change the link in the faq to the Forums front door and let the user pick the group. The groups names are already pretty self explanatory, though a couple of name changes might assist; i.e. SpamCop reporting system help. I realize the description expands on the group name and the names were chosen to reflect the more familiar (to us) newsgroup names, but I do believe this is a different audience and you don't need to cater to the news groupies ;-) Richard
  23. Richard W

    spamcop listed on rfc-ignorant.org

    SpamCop does not offer SMTP, so you are either sending from your ISP's server, your own smtp engine or webmail. Postmaster[at] and abuse[at] do exist, but the sender gets an auto-ack back listing the addresses to use depending on their problem. It sounds like the problem is your recipient is rejecting mail based on your "from" address rather than the server the mail is coming from. If you are sending from webmail, the servers identify themselve's as cesmail, not SpamCop. Your recipient should change their setup to reject mail based on the server the mail is from, not the email address. Richard
  24. Richard W

    SpamCop FAQ problem

    This FAQ has been changed, also. Richard
×