Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by william_

  1. again it was 9:26am GMT on a Monday and I get the following message: spam originated from, I see that IP is not currently in the Spamcop DNSBL. Has it ever been and did it leave the DNSBL over the weekend...
  2. when I visit: www.spamcop.net I see "Welcome, myspamreportingname. You have 15.4M bytes available. Your average reporting time is: 0 hours; Great! " I think the fuel is for (perhaps not only used for) making manual spam reporting quicker (and to show support for spamcop)? As a spam reporter & DNSBL user, I am left wondering where the 'investment' in feature development is occuring?
  3. that is a rather pessimistic view.
  4. Thanks Farelf, using that web archive facility: June-2010 to June 2011 Average spam: 28.4 Max spam: 59.9 Total spam: 895,748,034 June-2011 to June 2012 Average spam: 10.0 Max spam: 17.2 Total spam: 316,755,235 comparison between the above 365 day periods: Average spam: 64.8 % reduction Max spam: 71.3 % reduction Total spam: 64.6 % reduction.
  5. if you used the address on facebook etc, then on that site you can resolve email address to user by simply searching via email address.
  6. I wonder if a simple forum poll would gauge Spamcop user's opinions on the 48hour limit if it was appropriately constructed. Those of you who associate the request with 'surges over the weekend' or 'time zones' or similar are off the mark and have unfortunately not found extra reasoning for the proposed change. I simply want to report spam that I receive(at work), and to that end the (arbitrary) 48hours limit is simply inadequate (as detailed with the weekend example in the first post). Currently the Spamcop reporter cannot/will not wait mere seconds to resolve found domains in the body properly or process the email to properly extract links etc in a madcap rush to report to the ISP the existence of each spam item. (http://forum.spamcop.net/forums/index.php?showtopic=12209). In the last 365days the average was 10 emails per second.
  7. pretty sure 316 million is less that on previous periods? http://www.spamcop.net/spamgraph.shtml?spamyear
  8. tried to report a spam when it was Mon, 23 Apr 2012 09:25 +0100 but got the following message: I guess ideally it should allow from Friday close of business, i.e. 5pm when reporting on Monday morning?
  9. define slow? and why the madcap need to report so instantly?
  10. I was surprised to see that the manual submission webform now takes 73 seconds to complete, (I hardly ever use the web interface for submission), I thought it worth mentioning since I could not find a mention thus far. It seems like a fairly over the top adjustment, surely the process of manually submitting spam items individually via a webform is grueling enough of an undertaking? Merged with existing topic
  11. Hi, we have dnsbl blocking spam to legitimate addresses on our domain and a large collection of addresses that spammers have concocted which we feed directly to spamcop. That being said just recently over the last 7 days a number (15 which is quite alot really) of new dud addresses have emerged - mainly they are real addresses on our domain but with words, file name, or numbers added to the start of first part of the address. Any one else noticed an upturn in new bogus addresses recently? we have enough spam traps (215+) as it is and submit ~200 to ~800 spam a day to Spamcop.. Nov 3 252 Nov 2 465 Nov 1 538 Oct 31 438 Oct 30 508 Oct 29 529 Oct 28 622 Oct 27 518 Oct 26 457 Oct 25 615 Oct 24 435 Oct 23 396 Oct 22 634 Oct 21 757 Oct 20 582 . . Oct 10 190 Oct 9 391 Oct 8 479 just wondering if some new list of addresses has been generated and sold/used Thanks
  12. yes, thanks, that first one covers the questions in some detail. (though I noticed on the few ips I looked into that only four spam reports were seemingly needed for a listing). It seems to mention 24hours as the listing duration, but I am guessing that if the ip continues to spam, it will get a different treatment, ie a 24hour rolling block after the last spam report received? It is a pity that URLs such as http://www.spamcop.net/w3m?action=blcheck&...p= do not show any information if the ip is not listed. For a listed ip the amount of information shown is voluminous in comparison (compared to " not listed in bl.spamcop.net" it would be hard not to be), much of which is not strictly only pertinent to the current listing.
  13. Hi, would be very useful to see when the ip was listed into the blacklist. Thanks. EG: Got an email from at Thu, 2 Sep 2010 16:27:10 +0100 (UK time), and I wanted to see if the ip was listed in SpamcopBL via this url: http://www.spamcop.net/w3m?action=checkblo... which says now at Fri, 3 Sep 2010 09:20:10 +0100 (UK Time) : "will be delisted automatically in approximately 7 hours" No hint as to whether there is a normal listing duration or what that is, or whether there are variable listing durations, or if the continuation to listing durations is of a set period....all a bit 'mysterious'.
  14. I would just copy+modify the spamcop spf into your domains spf. There is space in the TXT record to be more descriptivtive than you have been in your quoted example. DNS records for webmail.spamcop.net No idea if webmail.spamcop.net is the correct host/domain to be looking at the SPF records for cribbing from. HTH
  15. http://forum.spamcop.net/scwik/SpamCopReportingAccounts seems to describe differences and features a bit.
  16. A form on the spamcop site accessible only via a logged in user of the reporting service so that: A test email can be sent from an ip address (a spamcop operated ip address specifically for the purpose) which is perma listed in the spamcop dnsbl. With the option to set forged return-path, from & to addresses (all from only your own domain - the domain of the accounts email address.) eg: The headers, subject and body would state it was a test email from spamcop. The feature perhaps limited to a set number of uses per time period. Thread http://forum.spamcop.net/forums/index.php?showtopic=10825
  17. The specifiaction merely developed (not even close to feature creep unless specification phase had been passed) - I see no back tracking, mistakes or corrections were made merely clarifcations to posters (who seemed to goad the specification process along with wild assumptions) . It was a logical progression. There are very few ways to do the described task, and I do not see many options to the specifications, do you? Fundamentally the finer details do not need to be discusssed here, as long as the general idea is communicated well then those reading it can draw their opinion without the need for 'clarification'. It is a fairly simple feature request after all. The thread title still describes the feature accuratly. You seem to be doing a critique of my posting where it is not warrented - a critique which is inaccurate, rude and uncalled for as well as slightly queer, as the following makes no sense atall.: Additionaly you quote me - but fail to answer the question which was actually posited because of your utterly fatuous ramblings about panic in ISP's. Instead you accuse me of various posting wrongs. Actually you will find that first request in this thead was enquire as to the possible location of the feature described. It is described in the title in a rudementary way. Please move this thread to the feature request forum.
  18. Removing the "from:ourdomain.com OK" from access.db seems to be the solution. Relevant computers/servers wre already accomodated via ip address listed in sendmail's access.db. Ourdomain name crept into the config from an auto learn on contact details for the whitelist. a single email - clearly marked in the header, subject and body is unlikely to cause a panic at any organisation's IT department. Do you think honestly to the contrary? The example tcpdump actually captured the dns lookup for an autoreporting event of a spam item to a quick reporting address. here is a negatory response from some blacklists - from a tcpdump in wireshark. Some pointless naysaying and fairly unfounded conjecture from you. I have never warrented that this feature request would be a fully fledged proposal with all possible angles covered. If you have constructive criticism fine, but this hopelessness is quite tiresome. I can accept that Spamcop may not want to for what ever reason do this feature request - I knew this before writing a word. To say some twaddle about time and money - well I do realise there would be a cost - but that is not my concern, and TBH I am not all that interested either beyond being satisfied within my own mind that the feature is not outside the limits of reason *(ie not wasting peoples time). I hope that is not too brusqe, I agree it is important to consider the different situations likely to occur, like in large isps etc. Does seem fairly far towards the feature request detailed. However the problem is solved here. The Feature request in whatever state it is in stands, and need to be moved to the feature rquest forum. You seem to act as if moving this thread to the feature request forum would be a bad idea (for unspecified reasons - perhaps undue validation of it is feared?) - as yet I persoanlly cant see the invalidity to the feature request - no matter how much of a corner case it maybe. I have now, thank you.
  19. It seems after getting tcpdump to record what happens (and looking into the sendmail setup) that a lookup request is not being triggered for these spam emails. currently a rule in access.db (in sendmail) "from:ourdomain.com OK" is figured to be a major factor in the problem observed, as whitelisted stuff is currently skipped of dnsbl lookups. the emails have these common headers: (where address1[at]ourdomain.com is a valid/used address) So the 'feature request' would need to forge 'return-path', and 'from' address to truely test for this scenario. Perhaps too much of a corner case? Certainly a common tactic by spammers. agsteel: The email sent from an ip listed in the dnsbl (a spamcop ip address from the purpose) - how is that impossible? I though I was clear - If I had meant forging ip addresses I would have said so, how is forging IP address even remotely (in this contect) a sensible/plausiable/possible/credible/reasonable suggestion anyway? Completely trivial configuration and you imply a request was made for something non trivial - why did you do that exactly? Thanks.
  20. The new feature request - is for a form in spamcop website so that a test email can be sent whose originating IP is on a blocklist to an address on your own domain - so as to test rejecting with that blocklist (in this case on just one address). The "logged data citing spam.spamcop,net" is clearly just example of format from quoted command. As stated Tools involved are tcpdump - sendmail and dnsbl. Yes, I think a configuration issue is the issue, it is not spamcops or other dnsbls fault - as I have ruled out dns lookup time-out errors (see second post from me - which would have been surprising if it was the solution in this case), however spamcop dnsbl is involved (along with several others) in a way - but I am trying to assertain why email that should be rejected is swanning into an inbox. I've not found anywhere that does the concept of the feature request - I have not spent time looking for this at other locatrions up to this point in time. The concept 'could' work - for logged in users of spamcop reporter service - unauthorised usage would not work, as their systems would be known to the system, and is a very low risk mechanism if limited also. I'll post back some info sometime re info about the problem described.
  • Create New...