Jump to content

gnarlymarley

Memberp
  • Content Count

    441
  • Joined

  • Last visited

Posts posted by gnarlymarley


  1. As a paying SC customer, it's a pain.

    The front-end we all connect to is hosted by Akamai (EdgeSuite), so the ability to ping or connect to that is meaningless: it just means your nearest Akamai edge node is live, which should always be the case whatever is happening to Spamcop.

    One way or another, this attack is taking out the back end servers that do the actual analysis and DNS lookups for spam reporting. My suspicion would be the DNS side of things, unless it's a pure brute force crapflood or an old load balancer in front of the servers - although with the current codebase, junk submissions with lots of slow-resolving hostnames in might be enough to hit concurrency limits or disk thrashing.

    Ping is not completely a good test with the default settings. I have worked with switches that only let through 122 bytes. Ping by default is 80 bytes. The diagnosis too longer until we made the ping packet size closer to the MTU. I can say that the front-end server are responding perfect, but seem to be timing out when trying to contact the backend servers. Both the spam emails and the whois information will be stored and cached in the database. The issue could be either along the lines of the database, or also could be when it tries to go out and perform an external query such as whois or DNS from abuse.net. I believe we would see something different if this was a brute force on the Akamai servers.


  2. Okay, so why do I have to dig down into this forum to find out where to find out the status?

    I would expect to see something on the “Report spam†page, which has a link to a report that hasn't been updated in over a month.

    Thanks.

    You mean the news page http://mail.spamcop.net/news.php.

    The status page is in the upper right corner in the link found by the white, blue, and green image: http://forum.spamcop.net/forums/index.php?...&page=stats


  3. FYI, once I get my first gateway timeout, it is about 30 minutes for it to work. From what I see, it times out at each mail message hop. The database could be affecting the whois lookups too.

    Gateway Timeout

    The proxy server did not receive a timely response from the upstream server.

    Reference #1.76a7ab41.1341778670.13a8e432


  4. This tracker goes with all of the following: http://www.spamcop.net/sc?id=z5366876323z2...e538cb80f83f3cz -> 2600:6:340:1::41ab:a77a

    Gateway Timeout

    The proxy server did not receive a timely response from the upstream server.

    Reference #1.84a7ab41.1341737067.41941d40

    Gateway Timeout

    The proxy server did not receive a timely response from the upstream server.

    Reference #1.76a7ab41.1341739096.1300861f

    Gateway Timeout

    The proxy server did not receive a timely response from the upstream server.

    Reference #1.76a7ab41.1341739299.1300f576

    Gateway Timeout

    The proxy server did not receive a timely response from the upstream server.

    Reference #1.76a7ab41.1341739551.130158b2

    Parsing header:

    got sigalarm, taking too long to process, aborted.

    Perhaps you can wait a few minutes and reload?

    0: Received: from 127.0.0.1 (EHLO mail5.zrffluouledrh.com) (130.255.230.115) by mta1304.mail.gq1.yahoo.com with SMTP; Sat, 07 Jul 2012 21:45:50 -0700

    No unique hostname found for source: 130.255.230.115

    YahooMain received mail from sending system 130.255.230.115

    got sigalarm, taking too long to process, aborted.

    Perhaps you can wait a few minutes and reload?


  5. Thank you for the update. Again, all the best for the team's efforts to find a long-term solution. It seems that the best those of us who use the service can do for now is to be patient as things return to normal.

    Just a quick note that I got the following from 2600:6:340:1::41ab:a791, if it helps.

    Gateway Timeout

    The proxy server did not receive a timely response from the upstream server.

    Reference #1.76a7ab41.1341613235.10034406

    EDIT: It appears to be working again.


  6. 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?


  7. 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.


  8. 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.


  9. 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.


  10. 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
    again.

    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.


  11. 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.


  12. <snip>

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

    </snip>

    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.

    kevin

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


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

    http://www.spamcop.net/sc?id=z5324131362z4...47234ee1c0da1fz

    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?


  14. 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 (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 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.


  15. 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 127.0.0.1.

    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.

    m/^([0-9A-Fa-f]{1,4}:){1,7}([0-9A-Fa-f]{1,4}){1,1}|([0-9A-Fa-f]{1,4}:){1,6}(:[0-9A-Fa-f]{1,4}){1,1}|([0-9A-Fa-f]{1,4}:){1,5}(:[0-9A-Fa-f]{1,4}){1,2}|([0-9A-Fa-f]{1,4}:){1,4}(:[0-9A-Fa-f]{1,4}){1,3}|([0-9A-Fa-f]{1,4}:){1,3}(:[0-9A-Fa-f]{1,4}){1,4}|([0-9A-Fa-f]{1,4}:){1,2}(:[0-9A-Fa-f]{1,4}){1,5}|([0-9A-Fa-f]{1,4}:){1,1}(:[0-9A-Fa-f]{1,4}){1,6}$/
    

    ...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.


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

    Hostname verified: dukecmimpo02.coxmail.com

    Trusted site 68.99.120 received mail from 68.99.120.135

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

    Re: 68.99.120.135 (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:

    http://forum.spamcop.net/forums/index.php?showtopic=1172


  17. 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 138.25.27.135. 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 [127.0.0.1])

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

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


  18. ...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.


  19. ...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:

    http://www.spamcop.net/sc?id=z5267442767zf...eac94b71891f3fz

    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.


  20. 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.


  21. 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.


  22. 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.)

×