Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by gnarlymarley

  1. I am a long time user, looks like this time is taking longer to fix the issue than in the past, a week is a long time....I am not upset with Spamcop, but whoever is behind this (if there is one) is causing a lot of damage, both in reputation and perception of reliability!

    This is an issue. From the stats page, I noticed that is has dropped considerable. From my time on a university helpdesk, the hardest problems to diagnose were the intermittant ones. Since this works at the high usage times of the day and stops at other times, it is much more difficult to diagnose. If I knew how to help, I would start gathering information. This I know, the problem is the same between me and both IPv6 and IPv4 frontend servers. This looks like a backend server issue. I wonder if the frontend servers are trying IPv6 to the backend servers and failing?

  2. If you will email me a complete copy of the configuration message you're having trouble with, I should be able to help.

    Send it to: service[at]spamcop.net

    Do NOT post it here.

    - Don D'Minion - SpamCop Admin -

    - Service[at]Admin.SpamCop.net -


    Well, all is working again and I am not able to duplicate it with the received lines. I noticed that gmail puts a bunch of spaces at the beginning of the RFC822 message, but the "Return mailhost configuration" screen still accepts it. The only wait I can get the error to duplicate is to start the headers with "Hello SpamCop user,". It could have been related to the partial outage. Don will find something when you forward the message to him.

  3. I apologize: I originally wrote that I copied/pasted from View Source. But in fact I copy/pasted from Show Original. So yes, I did paste the complete RFC [2]822 message with all headers intact.

    What mystifies me is that I was able to perform this exact procedure and validate three other Mailhosts. It seems there must be something about this particular specimen e-mail which is frustrating the parser.

    Ouch on my part, as "Show Original" was called "View Source" on the last gmail template. If I recall right, there is a body box and a header box. It sounds like you are pasting the whole thing as one message into the header section as expected. I am not able to test it as I have a permanent "Gateway Timeout". As soon as it comes back, I can try this myself.

  4. Note this is a Mailhosts configuration specimen e-mail. That is, it's not a spam, but one of those e-mails you get back during Mailhosts configuration, that you then copy and paste into the box titled "Paste headers" for analysis and adding to your list of Mailhosts.

    Consequently there is no tracking URL. In any case, the content of such messages specifically states: do not post this email in public.

    Ah, when you copied out the mail host email out, did you use the drop-down option on the right for "show original"? Gmail has the headers hidden there. SpamCop needs these headers to see all servers that test message goes through.

  5. I am configuring my Mailhosts. After making considerable progress, one specimen e-mail is being refused with the error:

    Sorry, SpamCop has encountered errors:
    Headers not found.
    It appears you did not provide all email headers.  Please consult this FAQ
    for more information on getting full headers from your software, then try

    The specimen was delivered to me in Gmail, and I copied/pasted it from View Source into the box titled "Paste headers (or entire intact email)". This exact procedure worked fine for all previous specimens.

    I have looked closely at the specimen and found nothing unusual. Unless I missed something, it's 7-bit ASCII and conforms to RFC 822.

    Where do I go from here?

    A tracking URL could be also helpful. When I get a message like this, it could means that SpamCop could not see any headers. This could be that your spam came from and internal Gmail users.

  6. I have stopped reporting spam until such time as I have a complete configuration.

    Please note that once you get your mail host configuration setup, that you go back to the old tracking links and verify that they are picking up the setup properly.

  7. <snip>

    It's highly unlikely that you will see a reduction in spam as the result of using our service.


    This is true for the immediate future, however, over time, if you keep up a regular schedule of reporting spam, the spammers will get fed up and leave your address alone. This took me about six years after signing up for SpamCop for my received spam to trickle down to one message every two days from twenty messages a day.

    Thanks to the SpamCop block list, my average rejection rate is 6 spam messages a day. Please take special note in what Don says about accept and bounce, which should never be deployed. The only true options are to either reject the message during the connection, or to send it to the bit bucket.

    thanks for the reply insight and advice.

    I suppose if everyone does their bit then in time things may get better.


    Yes, once we all work together as a group, we can trim down the spam.

  8. Good news to all the IPv6 folks out there.


    There is some stuff still lacking like this tracking link I found couldn't find a person to report to, but that should be a minor fix. It is something about "Cannot find ip range in whois output".

    turetzsr, I think you have connections with Julian. Can you pass on the congratulations?

  9. What does this mean -- No Source IP address found??

    A tracking URL would be most useful, but without it, I will try to answer the question.

    SpamCop tries to track mail-hops, but there exists in both IPv4 and IPv6 something called private (or internal) addressing. This is used when the message is behind a NAT (,,, FEC0::/10, or FC00::/7) and is using one of these addresses.

    When SpamCop encounters one of these addresses which is not globally route-able, it cannot track the source of the spammer. If SpamCop thinks the internal mail-hops is tainted, it will stop tracking all remaining mail-hops.

  10. The "Right" way of doing this would have been to add the IPv6 detection code, and have it log to a file for debugging. This doesn't change the existing behavior from the user perspective.

    The detection code should include checks for the IPv6 loopback address [::1], and treat it the same as

    We should face the facts that IPv6 is not human, nor code friendly. IPv4 was easy to code for because it HAD three periods. IPv6 can have any number of colons, but not more than eight. Code that matches IPv6 will always be complex and never as simple as IPv4, as seen below. I suspect this is partly why SpamCop has not fully implemented it yet.


    ...Steven, while I share your frustration and agree with your point, I think it may be misplaced to direct it at techie. IIUC, techie is making a suggestion about how to code for IPv6 in general, not how specifically to do it in SpamCop and has made no public judgment about whether the time it has taken is appropriate. On the other hand, techie's "The wrong way is to simply add a check for IPv6, and puke if found, which is what currently happens, as of the update in March 2011" comment seems to assume something that isn't true -- that the current code was intended to address IPv6, which (IIUC) it was not!

    These are some generic questions, but I believe they get to the root of the problem. How do you go about reporting IPv6 to the upsteam, which is to say the ISP? How do you add the IPv6 address to a block list?

    I believe the main reasons for the delay is that they do not need to just match IPv6, but they also need to get other underlying code updated as well. We know that they are able to find the IPv6 address now, because the page says it found IPv6 and stops. I believe that SpamCop is working on the whois, reverse DNS, blacklisting servers, and also working with the abuse.net DB to get all of it IPv6 compatible. SpamCop needs to get all of their code updated so it handles IPv6 in all of the code, not just the detector portion.

  11. http://www.spamcop.net/sc?id=z5285983184zd...8860d2889f680bz

    Hostname verified: dukecmimpo02.coxmail.com

    Trusted site 68.99.120 received mail from

    Then these SCUMBAGS don't accept reports (fools SpamCop reporting and SCBL)

    Re: (Administrator interested in intermediary handling of spam)

    To: abuse[at]cox.net (refuses to accept this type of report)

    Trusted means that someone has tested the relay site in question. The two major requirements are that it is not an open relay and that the server is not owned by a spammer.

    A quick forum search returned the following:


  12. I know that you are still unable to process IPv6 and although I don't understand why it has taken so long, I'm only a programming hack, so I fully accept this explanation.

    But in looking at this report that my wife just received

    <http://www.spamcop.net/sc?id=z5289635500z16378c05fd5d4dde0a8c11817145f277z> I see only one IPv6 associated with server <MailboxCluster3.adsroot.uts.edu.au> which I can easily locate as IP I'm not understanding why you would not use such a workaround to process such spam?

    There is no way to know whether they intentionally inserted an IPv6 to thwart SpamCop in this case, but I'm sure you are aware of instances where that has been done.

    The main problem as to why IPv6 is taking so long is, how can you properly check for accurate IPv6 headers? Below is a snippet of email that I get which uses IPv6 in transit. I was not immediately able to locate the RFC that is more specific than RFC 2822. RFC 2822 does not dictate the format as exact as one would like. This can make decoding the lines by scri_pt or program more difficult to decode.

    Received: from hub.freebsd.org (hub.freebsd.org [iPv6:2001:4f8:fff6::36])

    by mx2.freebsd.org (Postfix) with ESMTP id 22EA01587C2;

    Mon, 26 Mar 2012 00:37:01 +0000 (UTC)

    Received: from hub.freebsd.org (localhost [])

    by hub.freebsd.org (Postfix) with ESMTP id 0C3841065675;

    Mon, 26 Mar 2012 00:37:01 +0000 (UTC)

  13. ...That's a very good question and one to which I'm sure everyone here wishes she or he knew the answer, so that we all could have taken that step and it would have been done long ago! My naive guess is that SpamCop is working hard to get it right, rather than just throwing out some solution that doesn't work and that it's harder to get it right than anyone thought.

    You are correct there when we talk about it being harder than we thought. In IPv4 we had periods to divide the octets and colons to separate the port number. We would have been fine if they had kept the same number of colons in IPv6, but they have "allowed" IPv6 to collapse the address. This will make it near impossible to find the address, especially since some mailers put a port number in with the host address, and that means there might be an extra colon and a port number. Tack on top, the idea of the collapsing address and it could change the IP that fast.

  14. ...It appears to me that the offending entry is

    Received: from localhost ([::1]:53899 helo=mjail0.freenet.de) 
     by mjail0.freenet.de with esmtpa (ID suburbium[at]orenda-dryadis.de) 
     (Exim 4.76 #1)	id 1Rv7Uw-0007Qb-W1; Wed, 08 Feb 2012 14:23:46 +0100

    When I remove that line and submit it to the parser, I do not get the error message about IPv6.

    You have some localhost IPv6 header. Here is a teredo IPv6 header that may help in the debugging process:


    BTW, what else can I do to help get IPv6 support going? It seems that SpamCop has been planning IPv6 support for over two years now.

  15. Until IPv6 address's become the first IP in the headers, anything after the first occurrence of an IPv6 address is invalid anyway and useless for reporting.

    Interesting. I had a message that had the IPv6 address in the first occurrence about a year ago that I posted to these forums, however, the reporting link has already expired. The issue is that some mailer programs put the port along with the IP in the headers. IPv6 uses that same colon delimiter in its address. This will make the parsing portion much harder if you have to decipher the port difference from the IP.

  16. Today out of the Blue my e-mails are being stopped by SpamCop??????

    Spamcop does not block emails. They provide a blocking list service. Individual vendors block emails.

    I have checked my IP & it does not appear on your blocked list????

    SO WHY ARE YOU BLOCKING ME !!!!! I have spent hours this morning doing all this!!!!

    This is a user based forum. Please provider more information that we can help you with, like the error message from the email server to which you are trying to sent a message. Sounds to me like someone misconfigured their email server.

  17. That won't stand up in court. SpamCop doesn't decide what is or is not spam. That's up to you. YOU are the one who decided the email is spam and then submitted it to SpamCop for tracking. All SpamCop does is trace the email you submit, and then prepare a standardized report you can send if you want.

    I'm not sure what you mean by "report." SpamCop doesn't keep copies of the reports we send. We keep copies of the spam for 90 days, but that's all. The links you're talking about only show a new parse of the spam you have already reported.

    The "Quick Data Report" will show you the "From" address and "Subject" line of each spam, along with the SpamCop report numbers, and who the report was sent to.

    - Don D'Minion - SpamCop Admin -

    - service[at]admin.spamcop.net -


    I believe that Fred is just looking to see when and which admin was notified. The reports, however, only show that an email was sent at what time and not whether it bounced back. If the bounce was tracked, it may have held up in court. Since the bounce is not tracked, there will be issues maintaining whether an admin actually saw the report. (This is why it will not hold up in court.)

  18. SpamCop encountered errors while saving spam for processing:

    SpamCop could not find your spam message in this email:

    This is normal for message that were forwarded inline to your reporting address. Since SpamCop can only trust intact and untouched messages, it will only allow messages that were forwarded as an attachment.

    the respone email also has quite a bit of other information including what i think is the forwarded spam with all of its underlying technical header info.

    This message will contain the headers of the email that was sent to the delivery address

  19. Received: from [] by web88507.mail.bf1.yahoo.com via HTTP; Sat, 17 Dec 2011 09:12:09 PST

    If you look closely, you will see that your mail is coming from You should be able to trace it back via the RIPE whois to Amsterdam.

    As for reporting, technically you should only report the bounce you got from Yahoo's mail servers. The actual UCE messages was sent to them, so it is their spam.

  20. Ancient Galaxy

    hotmail.com is known to present the raw messages in this kind of format with blank lines in between the each line. In order to report these message from you would need to remove the blank lines between the headers such as found in http://www.spamcop.net/fom-serve/cache/22.html.

    Notice the blank lines all throughout the headers.

    SpamCop is looking for the full headers in one contiguous block of text, followed by a blank line, which signals the end of the headers, and then followed by the body text of the spam. The parse won't accept headers if there is no body text with them.

    - Don D'Minion - SpamCop Admin -


  21. I need to see the report you sent.

    Can you email me a report ID number, or maybe a complete copy of the email from Cloudflare? A Tracking URL would work, too.


    I agree that a tracking URL would help a bunch here. Anyone can get an old tracking URL by going back to reports and looking at the history. Without a tracking URL, all I can say is that from what I know, moomurl.com points to cloudflare. At this point, we cannot verify their "proxy service", so shouldn't they be the ones to report back to the original site?

    Non-authoritative answer:
    Name:	moourl.com

    CloudFlare, Inc. CLOUDFLARENET (NET-199-27-128-0-1) -
    CloudFlare, Inc. CLOUDFLARENET (NET-173-245-48-0-1) -

  22. I just got a spam from an external IPv6. Below is what you will see from exim. I suspect that due to IPv6 World Day, we just might starting seeing more of these. This is my second one. I did not think to report my first one that was about five months ago. FYI, tracking link below.

    Received: from [2a01:c0:2:dd:21e:c9ff:feff:66d] (helo=Kook.kookhost.com) by kaysville.yaritz.net with esmtp (Exim 4.66 (FreeBSD)) (envelope-from <proseguros-insure[at]msn.com>) id 1QWHSC-0005K6-CZ for me[at]yaritz.net; Mon, 13 Jun 2011 18:25:37 -0601

    Unable to process header. IPv6 addresses are not supported.

    No source IP address found, cannot proceed.


  23. but I never received an email with the link to the parsing information. I submitted it a second time and still got no reply from SpamCop.

    Today I got a similar message from "FedEx Inc.". Again, I submitted it to SpamCop, but got no parsing information response. All other messages that I submit to SpamCop are processed quickly. What's going on here? Why is SpamCop not processing these messages?

    What are you tracking URLs?I got one of these too and the parser is working for me.