Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Cedders

  1. Since the time is mostly taken up with "Wait for browser", I'd suggest a faster working method. Submit as normal, or indeed forward multiple emails so that you only get one back from SpamCop with all the reporting links. In your email client, click on each of the reporting links so that they each open in a new tab in your default browser (or if you haven't been able to configure an email client and have to use a webmail system, I suppose you can middle-click to open a new tab). This then means all the reporting forms are rendered simultaneously, but you still get to check the orignating IP abuse addresses and link parsing destinations - SpamCop does make mistakes, or sometimes it's useful to see when it hasn't gone to any abuse contact. After clicking "Submit form", you can use Ctrl+F4 to close the tab. HTH.
  2. Yes, this is effectively UK automated spear malware. It's not technically phishing (as defined by PhishTank at least) since it's not attempting to obtain credentials. As the expert on that story says it's probably getting the correlation between email address and postal address from a website data breach. 419 frauds aren't designed to look convincing. Phishing and malware is. Also note that the ransomware business model seems to be working well for some scammers who have access to a fair amount of technical know-how as endpoint antivirus is frequently too slow to catch their latest VBA or WScript downloaders. Action Fraud also incorrectly describe this attack as "Phishing" at http://www.actionfraud.police.uk/news/alert-fake-debt-collection-and-council-tax-emails-apr16. BTW another news story, this time in the US and highlighted by https://www.us-cert.gov/: https://www.irs.gov/uac/Newsroom/IRS-Warns-Washington-DC-Maryland-Virginia-Residents-of-New-Phishing-Scam-Targeting-National-Capital-Area No information what was involved in the data breach.
  3. Yes, sounds like you were dealing with a responsive host there. Hostinger gets a lot of abuse (I think it's some kind of free service), but seems to take pages down quickly. There may well be some organisations you don't get a personal reply from for policy reasons, but they are just as fast.
  4. I disagree. SpamCop clearly is used a lot for reporting spamvertised websites and does the task pretty well - I've even received such reports myself when a site we host is used as an authority for a news story (effectively a "joe job" rather than the spammer's intended landing page). Also there is a URIBL based on reports of spamvertised websites reported to SC: SpamAssassin has a rule URIBL_SC_SURBL that hits about 20% of incoming spam with a nice low rate of false positives. I think this inconsistency in parsing is just an omission. A low-priority one, admittedly, but fixing it would enable SC to behave more consistently from the perspective of both user and abuse desk. Er... what? A big advantage of reporting via SpamCop is that it anonymises the report. If I don't want the ISP's abuse desk to see the recipient address, I'm not going to post it (or the tracking URL which might still include the receiving server name, although as you can see the report was months old) to a public webpage. I don't want "help" in any case - I wanted to report a bug. And, besides, I don't think I can find the original Tracking URL any more It was you who I noticed said it lacked context, so I supplied the context (cutting and pasting it into SC will be parsable, so long as you indent the second line of headers appropriately. It's text/plain and there are no other MIME parts, if that is really relevant.) I cannot understand at all why you say you don't know have any idea what it looked like. There it is in post number 3 with only the recipient address and receiving server omitted. BTW as I do abuse work (even at the weekend ), I don't just have my own spam to handle, but that of thousands of users. Yes, the dotted hex quad is what SpamCop doesn't parse correctly. The deobfuscator link is indeed a useful one for users, but I know my sixteen-times table anyway To clarify, I wasn't suggesting altering the headers submitted to SpamCop, and did indeed (I think I recall) report it outside SpamCop manually. Firefox 2 and Opera 9 both recognise it. So does wget (which I use in place of curl). IE6 does not, and IE users are usually the more naive users. I agree that the spammer is therefore artificially restricting the number of people who they might defraud. Actually I can find any references in RFCs to hex quads, but I'd imagine with moves towards IPv6, it's a newer trend rather than one being phased out. Certainly RFC 1630 (1994, formalising URIs) doesn't seem to be conscious of hex quads - I'll test it on Amaya. I'm seeing a 404 page in Chinese (Big5), not getting a timeout. Maybe your upstream provider is firewalling it? I don't think there's any risk in posting the link since the page was presumably taken down months ago, and phishing only works in context, (if it weren't a 404 it would now be more likely to come up in searches for "spam" than for "IxRxS". I was reporting the bug in the hope that it's fixed in future - the spam was only an example. Thanks for the info. It would be nice if there were some sourceforge-style bugtracker to keep hold of minor issues like this, but I can understand that SC is not open source and there's no public access to this.
  5. Interesting. But that argument works equally for spamvertised HTTP URIs, in fact more so in my experience. I for one do untick uninvolved websites mentioned. SC could provide unticked tick boxes for the email category. You say there is no way for the parser to know, but presence of a Reply-To with a different domain in practice does distinguish, and think we will come to an arrangement with MSN that they get automated alerts when webmail phishing is detected by us (no FPs so far with rules that catch >90% of webmail phishing). I accept that composition of the spam burden changes over time and so an decision algorithm would need occasional maintenance. Good point - I was using a free account for this particular report. But SC doesn't do the lookup for the MX abuse address for me in any case, which still means it's more time efficient for advanced users to report directly, and for others, I think they are unlikely to do what you suggest. Thanks for reply.
  6. Interesting that this issue recurs often (for sysadmins) and has been going on so long. I do discourage users setting up auto-responders and encourage forwarding to a colleague instead but some people expect them and there may be confidentiality issues as the OP says. Then there is software like mailman that responds to spam sent to certain list admin addresses; there could also be any number of things users have installed on their own site or gateway. We don't enforce a single outgoing smarthost, but obviously do make one available (as dbiel and petzl say, provided SC trusts your smarthost's headers, it should be reported to the owner of the user's mail gateway). The vacation program in common use on *nix systems does not include the email being responded to, and I'm not sure it should (also the default is to only send a maximum of one response per week - per hour is indeed excessive). The point is that anything that can create backscatter for a genuine reason may occasionally respond to spam that somehow gets through milters (incoming and outgoing), and that spam may forge an address that happens to be a SpamCop trap, and so generate a trap hit, which will not be accompanied by a Report of the email that triggered it. So we don't even know if it is and out-of-office message or something else, and that is the point Per G was making, and with which I wholeheartedly agree. I also argued at http://forum.spamcop.net/forums/index.php?...ic=9532&hl= that there is on the face of it no reason why if a human Reporter can have an email address anonymised, a spamtrap address cannot be similarly anonymised and the data sent to the appropriate abuse address. The information that the deputies may provide on request may just be the subject line, which isn't necessarily going to be helpful to find a backscatter source (or in a worse case, an intrusion or user abuse): full headers including a username or x-php-scri_pt header is better. Otherwise summaries listing only trap hits are pretty unhelpful. BTW most of the spamtrap addresses I maintain (usually adding to Bayesian detection and blacklisting more than anything) are single email addresses that spammers send to - would love the whole domain to get excluded by spammers. Basically, it seems SpamCop does not trust all abuse desks. I think it should ideally be possible to get accredited as an abuse desk somehow and receive full data (headers and body) relating to trap hits, but with the spamtrap address anonymised. It's only with this information that you can really take action as Per G says. However, if it's been going on this long, I expect it's unlikely to change, which is why the page at http://forum.spamcop.net/scwik/TipsForSystemAdministrators is there.
  7. For info, the problem still exists. If there is any SpamCop development going on, it is worth the time reporting bugs or feature requests if we know where they should go - but if there is very little happening, maybe we should know. I'm not interested in discussing stuff just for the sake of it, unless it helps the SC developers. I think you misunderstood. Perhaps I presented the issue too tersely. It's not "embedded stuff" - the quote was SC output. Actually what could be said from my evidence is that there is a way of presenting a link that browsers understand but SpamCop doesn't, and that is something it would be good to fix. But I suppose the context might make it clearer: Return-Path: <refund[at]irs.tax.gov> Delivered-To: somewhere[at]munged.org Received: from qbsrv011.QBASCO.COM (mail.qbasco.com []) by munged.org (Postfix) with ESMTP id 136A814C7F9 for <somewhere[at]munged.org>; Tue, 9 Sep 2008 17:13:30 +0100 (BST) Received: from service ([] unverified) by qbsrv011.QBASCO.COM with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Sep 2008 23:50:28 +0800 Reply-To: <noreply[at]irs.tax.gov> From: "Internal Revenue Service"<refund[at]irs.tax.gov> Subject: IRS Tax Refund Date: Tue, 9 Sep 2008 11:44:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <QBSRV0118AVIBsOPd8s00003098[at]qbsrv011.QBASCO.COM> X-OriginalArrivalTime: 09 Sep 2008 15:50:41.0312 (UTC) FILETIME=[CFD55A00:01C91393] To: undisclosed-recipients:; Internal Revenue Service (IRS) United States Department of the Treasury Dear Applicant, After the last calculations of your annual fiscal activity we have determined that you are eligible to receive a tax refund (Stimulus Payment) of $620.50. Please submit the tax refund request and allow us 6-9 days in order to process it. A refund can be delayed for a variety of reasons. For example submitting invalid records or applying after the deadline. To access the form for your tax refund, please use the following link: http://0x7C.0xA.0x7F.0xA4/Internal.Revenue...refund-form.php Applicant ID: (0x7C.0xA.0x7F.0xA4). Regards, Internal Revenue Service Reporting this does not correctly parse the spamvertised URL, and you need to covert the hex bytes to decimal yourself to find the most effective reporting address. This is the SpamCop output: Finding links in message body Parsing text part Resolving link obfuscation http://0x7C.0xA.0x7F.0xA4/Internal.Revenue...refund-form.php Host 0x7c.0xa.0x7f.0xa4 (checking ip) IP not found ; 0x7c.0xa.0x7f.0xa4 discarded as fake. Tracking link: http://0x7C.0xA.0x7F.0xA4/Internal.Revenue...refund-form.php No recent reports, no history available Cannot resolve http://0x7C.0xA.0x7F.0xA4/Internal.Revenue...refund-form.php Remains a bug, but I've not seen it exploited much, probably perhaps such a way of representing a host is inherently suspicious.
  8. This specifically concerns receipt of 419, job scams and similar scams, and most clearly spear phishing for webmail passwords. Unlike botnet spam and bank phishing, such frauds (often originating in Nigeria, Gabon etc.) usually request a response to a stated email address, either in the body text or the Reply-To header (or sometimes the Subject line). Phishing for mail account passwords increased in 2008, and typically they were sent from a student's account at an academic institution, where the student had responded to identical spam. From: "Surname, Forename" <Forename.Surname[at]cit.act.edu.au> (a compromised account) Subject: mailbox has exceeded the storage limit Your mailbox has exceeded the storage limit set by your administrator.You may not be able to send or receive new mail until your mailbox size is increased by your system administrator. You are required to contact your system administrator through e-mail with your Username:{ } and Password:{ } to increase your storage limit. System Administrator E-mail: system_webincrease[at]live.com You will continue to receive this warning message periodically if your inbox size continues to exceed its size limit.This email is intended only for the use of the individual or entity towhich it is addressed and contains information that is privileged and confidential. Sysadmins at the institution will usually respond quickly to a report of a compromised account by closing the account or changing the password, so SpamCop is a quick way of doing this. Occasionally it seems SpamCop is able to parse the HTTP submission all the way to the Nigerian ISP, although sometimes it is the abuse address of the institution hosting the compromised account. Of course the same report is not currently also forwarded to the live.com abuse address, which clearly should be notified. This therefore has to be done manually, as described at http://forum.spamcop.net/scwik/ReportingEMailAddresses . So unfortunately SC is not a big time saver in reporting scams where the From and Reply-To address (or From and address that appears in the body) differ. The decision to not implement an option to report to sysadmins responsible for, e.g. Reply-To address or a single address in the body is understandable if you accept the assumption that all email addresses in spam are forged - but in fact Reply-To and body email addresses in a large fraction of spam are genuine, and the wave of webmail phishing in 2008 changes the situation significantly, as allowing collection accounts to continue for hours or days after a phishing mailout vastly increases the possibility of the inconvenience of a compromised email account, and also of fraud against vulnerable people. Reporting collection account addresses is analogous to reporting "spamvertised websites" - for example, if a 419 includes a web link it is very likely to a news article on a genuine server. It has to be to the discretion of the reporter to choose which addresses are appropriate to receive the report. Ideally SpamCop itself would make a default decision about whether the type of spam means it could or should be reported to the provider (I have SpamAssassin rules to do this relying on phrases such as "System Administrator E-mail...", but the presence of an account at a free email provider is also evidence). I think adding the ability to report mailto URIs in the same way as HTTP URIs would be effective and worth a bit of development time.
  9. I've sent this to deputies[at] but thought it's worth reporting here too. SpamCop's not dealing with hex-obfuscated URIs (found in the current IRS phishing) as well as might be expected, e.g.: Tracking link: http://0x7C.0xA.0x7F.0xA4/Internal.Revenue...refund-form.php No recent reports, no history available Cannot resolve http://0x7C.0xA.0x7F.0xA4/Internal.Revenue...refund-form.php It's attempting to resolve something that is clearly not a domain name, because the TLD begins with a digit. Really a report should go to the reporting address for, i.e. spam[at]anet.net.tw Note that 2081062820 and 0x7C0A7FA4 (different ways of parsing the same IP address) are parsed correctly.
  10. That is indeed a shame, as it's the place I would imagine most sysadmins would look for information about reports. There are links to the main site from the reports to get more report details. Well, people will most likely look for help from the main site (in which case they see the old FAQ), or a web search, in which case they might find information here. Therefore if you have a discussion that turns up something useful, you may want as many search terms and synonyms mentioned on the one page as are relevant. In particular, can I suggest a new forum specifically titled "For abuse-desks and system administrators"? The perspective of a Reporter is different from the perspective of a sysadmin, which is different again from the perspective of a SpamCop expert. I only fall into the first two of those, and perhaps should also point out that most sysadmins probably don't have as much time as me. I see a sysadmin got a similar response to a query here: http://forum.spamcop.net/forums/index.php?showtopic=9392 (although in that case the numbers seemed to indicate actual customer abuse rather than occasional backscatter). Again, there is an issue of confidentiality about an IP address when you want to uphold the reputation of the organisation you work for and its customers. Maybe it shouldn't be so, and sysadmins should let it all hang out, but it's generally responsible to get consent from several other people. IMHO I don't think a forum is the best medium for a FAQ, compared to static HTML, since it lists stuff chronologically rather than logically. I gather you intend to migrate help content to the Wiki, which I think would make it more accessible. Having the two apparently identical indexes 'SpamCop Discussion' and 'Discussions & Observations', and two different pinned links to the same FAQ, also confused me. In any case, I have made additions to http://forum.spamcop.net/scwik/ISPAccount since I found it misleading (it was about receiving summaries and alerts, not reports themselves), and added a lengthy page at http://forum.spamcop.net/scwik/TipsForSystemAdministrators giving some context that is not necessarily specific to SpamCop, but likely to be relevant to sysadmins, and summarising what I have found out in the last few days. Clarity for other people on this forum including visitors and to distinguish a summary report from a Report. What I was calling a "trap report" was a summary report listing one trap hit with all other variables as zero. I hope that is clear. As you may have gathered, these can be confusing for recipients since there is no additional information about these spamtrap hits that means you can take action. Well, I guess I have access to public/subscriber information myself - ideally what I wanted was someone with access to the SpamCop source code, or detailed documentation for it. I didn't bring up domains or URLs; I thought you did. I emailed them at the deputies[at]admin address, but haven't heard anything back yet. Maybe they're taking a break. I included the reports from SpamCop in question as attachments. I know succinctness is appreciated, but I did have four separate questions. It gave instructions for getting alerts and summary reports only. Third-party status wasn't the issue, and I think it is likely to be far less common than simple queries you might get about interpreting and acting on summaries, hence my additions. As I say above, I think the communication problem stems from coming from different perspectives. I imagine other people who have staffed an abuse email have a similar perspective on SpamCop to me. (1) User spam source reports and (2) "spamvertized URL reports" to the main abuse address; and (3) alerts and (4) summary reports to a secondary address (abuse2[at]). I assumed that would have been clear from my first post, at least to anyone else who was similarly subscribed. Types (1) and (2) are described in http://forum.spamcop.net/forums/index.php?showtopic=4540 ; type (4) is described at the bottom of http://forum.spamcop.net/forums/index.php?showtopic=5619. Whether (3) and (4) fall under "Report" with a capital "R" in the SpamCop definition, I doubt, even if (3) is described as a "summary report" in the subject line. I am trying to use the same terminology as the SpamCop system itself uses. If I referred to 'site' previously I would probably have meant a virtual host on a web server, usually with one domain, sometimes with additional aliases, owned by one user account. There are usually multiple sites on one 'IP address' (and usually only one IP address per 'host' or 'server') and multiple IP addresses in one 'network' or 'block'. This is how I understand the terms, anyway, and am unaware of any different meaning they have in SpamCop. A summary report may summarise one or more hit. I'm sorry, I'm a bit confused now too. I don't see the post that says "Domains have not been mentioned". Someone complaining about a spam may include URLs etc. I'm not. I'm trying to make sense of SpamCop reports (specifically summaries and alerts) and get more information about them. The spam source reports contain the body of the Reported email, but summary reports do not. Keep fighting spam! I'm almost certain it does increment the number under 'User', but the actual spam source report containing the message details (i.e. what you need to handle the complaint) is sent separately. The summaries come from summaries[at]admin.spamcop.net, while the other reports come from userid [at]reports.spamcop.net Well, I've just tried submitting a spam (from outside my network) and unticking the report address - this just gives an empty SpamCop page. I'd hope it doesn't contribute to the BL (except as Mole) because it would be confusing for sysadmins, and a little unfair and open to abuse. That seems logical. The main problem is when there is no data available - as in the case of the trap hits.
  11. I meant the messages headed "[spamCop] summary report" that are described in your link http://forum.spamcop.net/forums/index.php?showtopic=5619 and look something like: Start/Length Trap User Mole Simp Comments Jun 17 08h/0 1 0 0 0 I should have said "spamtrap summaries" for clarity. But spammers fake From headers and envelope senders from addresses in their database. So 'out-of-office' (or mailman automaton etc.) backscatter to trap addresses will happen unless the server admins take conscious steps to prevent it. Yes, you seemed to be saying the same thing earlier, but I think you are mistaken. The spammers cannot of course tell the difference between harvested addresses of active mailboxes belonging to people to annoy, and harvested addresses of spamtraps. So it isn't intentional when a spammer either sends to a spamtrap address or fakes the spamtrap address when sending elsewhere, causing backscatter to be sent to trap addresses. Typical of the internet as a whole perhaps, but atypical in the non-commercial arena in which I work. I followed the links to the other forum postings, but couldn't find answers to my questions there except at http://forum.spamcop.net/forums/index.php?showtopic=7818 . Steven Underwood has already posted that information here. It would be useful to have it in the main FAQ at http://www.spamcop.net/fom-serve/cache/75.html, because the amended version on the forum looks sufficiently similar that I initially assumed it was identical. Well the link above states "Only the SpamCop Deputies have access to detailed information about e-mail hitting spam traps", which implies to me that posting IP addresses here won't help. There is no URL involved, since any information about the content of the spamtrap hit isn't included in the summary report. Well, just regard me as one of those, but with a few more detailed questions and a bit more verbose . That Summary Reports aren't intended as anything other than a warning indicator (useful in differentiating legitimate user mailouts from intrusions) and aren't helpful in tracing backscatter or user abuse is important information that I can't find within either the main or amended version of the SpamCop FAQ. Cheers Cedders
  12. Another sysadmin I know says he has such an arrangement. <content elided .... as stated above, guidance from Deputies is that subject matter is not for public consumption> Thanks - yes, that's partly my situation. But also, when I get trap reports, I want myself or the relevant server administrator to do something about them, as in the best case it indicates a source of backscatter that might be able to be stopped if identified, and in the worst case, a compromised server. The problem is that in response to a summary with no content, and just the IP of a host that acts maybe as a web host for a hundred domains, and as a mail server, all one can do as a sysadmin is check mail logs and netstat for the previous hour, and a set of general-purpose system monitoring tools. If it's an intrusion, or an inappropriate use of (say) Mailman (or more likely, webbots submitting random addresses to a subscription forms and an issue with confirmation by the mailing-list software) it'll probably be taken care of anyway, but the sysadmin won't even know for sure that's the cause of the trap report. That was an additional potential source of confusion, but as I said in my second post in this thread, referenced websites (sometimes just quoting a site to give the message some authority), don't or shouldn't of course show up in the summary report since they are no reflection of the spam source. So it doesn't explain all the discrepancies unfortunately. I believed that "spamvertized" sites were contributed by SpamCop to URIBL / SURBL, but maybe that's wrong. Indeed I intend to email the deputies shortly with the IPs concerned and full details. I'd also like to contribute a wiki page aimed at sysadmins, saying in my experience how best to respond to trap reports. (If the wiki admins enable this account, I can do so in due course.) I think you're right, and it's mostly the latter. I just thought I'd try out my questions here before submitting a private enquiry. But I doubt I'm the only recipient of reports/summaries/alerts with these questions.
  13. Thanks for the replies. Sorry if I'm not explaining things properly. Steven answered it, really. So 'Trap' reports don't send the full message to the abuse address in order to protect the honeypot addresses? That seems slightly odd to me at first because if user reports can be anonymised, why can't trapped email? On reflection, I can see why they are protected - otherwise spammers who gain access access to an abuse[at] address might more easily be able to develop an exclusion list, without any benefit for an end user who would be all too happy to be excluded. I can't think why any servers in our range would be sending to trap addresses unless there's an intrusion or exploit (most likely) or abuse by a client who has somehow added harvested addresses. OK, maybe it's an autoresponder sending through the server in question. I guess we rely on users (of Spamcop, feedback loops, or just directly) to report an offending email at the same time, but they don't, which is what confused me as recipient of the summaries. Yes, I tested the IP address and the abuse addresses are correct. I selected hourly summaries - there's no option for weekly. And http://www.spamcop.net/mcgi?action=listroutes lists the ISP account (abuse2[at]) as "Third party interested in daily aggregate summary reports", but doesn't come up as an optional reporting address when you submit a spam. That's fine and as expected. It still leaves the less important puzzle of why user reports aren't always reflected in the summaries. If people are reporting a spam than incidentally includes a link to an innocent website, then it makes sense too that this is not listed in a summary of spam sources. http://www.spamcop.net/fom-serve/cache/89.html says reports about email sources are more serious than about website addresses, but if both happen in the same message, the website is given in the subject line (could this be a bug?). However, I think that that report, although it doesn't mention the IP the email originated from, probably counts as "User: 1". Sometimes it looks like user reports (where we do get most of the email and can see what is going on) get listed as "Trap", but it's possible both are happening at the same time. OK, we're getting there... I'm looking at all email received to the abuse and abuse2 addresses from reports.spamcop.net or admin.spamcop.net; and that leaves one other occasion where there is a report about mail from an IP, but no corresponding summary at all. This one is described as "appears to be sending unsolicited bounces", so maybe those are regarded as not serious enough to add to the summary? (It is an out of office message originating on a client's MSExchange server - we exclude SPF softfails and suspected spam from the vacation system on our own server.) Then there's one other last year when there was a genuine intrusion, one user report for the originating IP, but no summary or alert for that IP, although there was a helpful trap report for the relay it passed through, also on our network. By 'help pages' I meant the pages shown when you click 'Help' at the top right of the screen. Although there's lots of interesting information under 'Help for abuse-desks and administrators', I couldn't find a manual page or other centralised documentation about how to make the most out of the reports. Yes, there is a proliferation of wiki pages and other sources, and even a Usenet server - it's the multitude of sources that's daunting. I'm not saying the information isn't there somewhere, but I have spent over an hour looking and if someone could provide a link to where the relationship between summaries and individual reports, and the corresponding relationship between abuse addresses and ISP accounts, is described, I'd be grateful. I didn't give the exact IP address partly because while it's in our rack space it's used by a different organisation, to whom we forward the reports for action. (Perhaps they should have a direct abuse address for those IPs, but they're mostly run by volunteers.) Also, I don't like to admit publicly that sites we host might have had professional intruders, however quickly I'd like to think we detect, stop, and patch against it. SpamCop admins could deduce the full details from my email address for this forum, although there's no point unless there is access to log files. I'm just trying to work out what's happening using these forums - if something still seems not right (it's hard to say "not as documented", because I haven't found the documentation), then I'll contact the deputies via email (I hope logs go back a year). Finally, we never get anything listed under 'Simp', which I'd presume we'd get if a message were reported using, for example, spamassassin -R. What sort of weighting do these get? So to summarise - there are SpamCop ISP accounts, which are available to anyone to get hourly/daily summary reports and alerts, and which are distinct from the ability of an abuse desk to declare an issue resolved (quite rightly, but I still don't understand what the 'Close Issues' action on the drop down menu in the ISP account "Control Centre" does). There is the implication at http://www.spamcop.net/fom-serve/cache/266.html that there is a link between ISP account and abuse address, although that isn't necessarily so, e.g. where we have abuse[at] and abuse2[at] - in order to be able to set preferences and alerts for an abuse desk, a password for the public abuse address needs to be requested at http://www.spamcop.net/denied.shtml. Where there is an alert and summary to the ISP account, but nothing to the abuse[at] address, it could be because the reporter has chosen not to send the report, the abuse address had unwisely chosen not to accept munged reports, or that it's gone to a trap address and no registered user has reported it. Trap alerts are still useful to confirm compromise of a server. Where there is a report sent to the abuse desk, but nothing to the ISP account, it could be because it is a more informational message about a website referenced in the reported message, or because SpamCop has identified it as backscatter, or possibly because a relay it passes through has already had an alert (?). In short, alerts and reports arriving at similar times should not be expected necessarily to correlate to the same incident.
  14. We're an ISP/host with a range of 63 IPs. Our correct abuse[at] addresses come up for this range, and we do get occasional SpamCop user reports (3 so far this year, last on 25 May). However, we have also subscribed other postmaster addresses to get alerts and summary reports for the same range. Sometimes we get these ("[spamCop] Alert"), but there is no corresponding email to abuse[at] With just the IP address specified in the alert, but no message id (or X-PHP-scri_pt header, which is useful for detecting intrusions into client Apache sites), it is harder to act on these. I've checked the server logs this last time it's happened but see no attempt to connect from SpamCop or to abuse. Occasionally the opposite happens too: We see [spamCop ( id..] but if there is any summary for that IP, it comes 5-7 days later, and shows a '1' under 'Trap', and a '0' under 'User'. Is there any reason this might happen? Mostly when we get the summary but not the full report, it is listed as "Trap: 1" and refers to one of our IPs which we actually sub-let to a sister network - however, we are still the abuse contact for this IP address if I feed it into SpamCop. Should we get full reports for "Trap"? Also when we do get the summaries, there is a link to mark the issue as closed, but shouldn't that be done by the abuse[at] address? As I understand it, anyone can get 3rd party summaries for any range. I may be missing something obvious here. Any explanation appreciated. Thanks to SpamCop for a great reporting tool, although sometimes I wish it were easier to find info on the help pages.
  • Create New...