Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by elvey

  1. Next day: Seems to be back up. Moderator Edit: fixed Quoting Tags, deleted unnecessary duplication in the Quoted material.
  2. I know I'm reviving an old thread... Seems like much bezeqint IP space is totally unreachable from my quadrant of the galaxy (comcast). http://www.robtex.com/as/as8551.html#bgp shows a whole lot of 'MISSING' Client fring.com, srv.co.il, and much of are unreachable. Traceroute shows I can't get outside of comcast's network on my way there; normally it would be comcast-level3-bezeqint. Tests are http://www.dotcom-monitor.com/task_hot_test.asp?id=1 show that fring is consistently unreachable from Florida, Colorado, and Sydney Or maybe there's something on my current network; I haven't seen this 'till just now: Google Sorry... We're sorry... ... but your computer or network may be sending automated queries. To protect our users, we can't process your request right now. See Google Help for more information.
  3. Yeah, now the site contains the following stupidity: Stupid, but not nefarious. This requirement they've set doesn't match any best practice document I've ever heard of.
  4. NEVER MIND. ORIGINAL POST: Anyone agree/disagree that the blame for this is being misplaced: http://www.spamcop.net/sc?id=z1533290469z9...77093d497fe80bz Spamcop has decided that all the headers are trustworthy and is defaulting to sending no complaint: internet.abuse[at]sjrb.ca refuses munged reports. The unmunged "To:" suggests it was bcc'd to an aya.yale.edu account that alumniconnections.com hosts. So I think either shaw needs to be notified to fix their security problem, or alumniconnections.com needs to be notified to tighten up their filters. DOH! sjrb.ca IS SHAW CABLE! I'm loathe to switch to Mailhosts; my forwarding config is very baroque. This post has been edited by elvey: Nov 21 2007, 02:23 PM
  5. It seems there isn't a forum for spamcop report recipients other than this thread, so posting here. I recently received a legit report of a spam apparently sent from an IP in an IP range I monitor that also referenced an URL that resolves to an IP in that same range. Oddly, I only received one report, for the domain. Is that normal? I do normally get reports for SUBE from that IP. FYI, for admins: the report id:2372902008 It makes me wonder if some of the reports I should be getting are going missing. I don't spam-filter reports from spamcop; e.g. I see one from the 1st that scored 19. Actually, I just noticed it happened again, with report id:2378805404 ! If I have spamcop analyze the spam, it seems to accept the hand-off the Received lines indicate an blame another IP. I should hear back soon about whether logs show the spam went out from the IP range in question.
  6. elvey

    [Resolved] Missing report?

    Rate limiting and outgoing spam detection are already in place. They're quite effective; I estimate the mail stream from FM is about 99.9% ham. But FM has been the subject of a header-forging joe-job attack... I'll write more soon.
  7. elvey

    [Resolved] Missing report?

    You understand correctly (except I'm technically a 3rd-party report recipient). Ok, turns out nothing is wrong; spamcop is working correctly. The spam was indeed sent through the system at the IP range I monitor (let's call it "FM") and spamcop blamed the IP of the machine that submitted it to FM via (authenticated) SMTP, because spamcop in this case accepted the Received header line FM had added. I was thrown because abuse of FM via (authenticated) SMTP is very rare. Thanks, folks. And I'll be sure to post a tracking URL next time I have a question/issue, so more folks here can look/help. As for "looking for ways to stop the spam from leaving that IP address": for FM, this has to a great extent come down to figuring out how to detect credit card fraud, such as with FraudCall.
  8. elvey

    Reporting backscatter

    Right. Thanks for pointing this out. In this case, I was NOT talking about one of the usual spamcop ([qu...]YBQWERTYUIASDFy5[at]spam.spamcop.dom) addresses folks use to send in spamcop reports. Forwarding to one of those will indeed NOT work. (Apologies for the belated reply.) -elvey, not quite just another .
  9. elvey

    Reporting backscatter

    A also got feedback from Ellen on a closely related question - whether it would be a good idea to redirect backscatter to an official spamcop spamtrap or not, so I thought I'd report it here. The gist of her response was that they didn't do much with SUBE that appeared to be backscatter, so I could, but I might as well not bother.
  10. This is a request for feedback from experts/regulars to help reduce spam blowback from Sieve-based systems. The IETF's SIEVE Working Group is modifying/updating the way scripts written in Sieve (the mail filtering language) can handle messages to be refused/bounced/sent to where they purportedly came from. The current method, as defined in the Sieve standard (RFC 3028) is not good, IMO. It results in tons of spam blowback/backscatter when the sender is forged, including when Sieve scripts are part of a Challenge/Response system, or out-of-office system, or spam-filtering system. I've gone through a great deal of effort to remedy this; I've written several versions of an Internet-Draft to fix the problem to a great extent; see refuse-reject, which explains the problem in more detail to those not familiar with the issue. At the last Sieve meeting a few days ago (I attended remotely), it was determined that there was a rough consensus among implementers who were present (at least there was support from Alexey, Chris, and Philip; the others abstained or did not support it) to keep the current behaviour as the default. It was stated that Sieve is not used as part of spam-filtering systems, and that the current behaviour was not causing problems. I'm here to solicit feedback as to whether that's the case. I've said that I regularly receive blowback from such systems (along with tons of blowback from other kinds of systems), but I was the lone voice. In my effort to fix Sieve the way I think it needs to be to best address the problem, I could use some support for my argument. If you have expertise and can speak credibly and/or provide statistics on receiving blowback from such systems, your feedback would be most appreciated; the best forum for such feedback would be the Working Groups mailing list (you must subscribe to post). If you just need to vent or yell semi-incoherently, please don't do so on the list. How to identify such blowback: for example, if you get lots of blowback that says, " Your message was automatically rejected by Sieve, a mail filtering language.", or is "From: Mail Sieve Subsystem <postmaster[at]somedomain.dom>", it's coming from a Sieve-based system, and that's what I want to hear about. (Though if it's not there, that does NOT mean its wasn't from such a system.) Questions? Post here?
  11. Thanks for the stats. Right, except the current Sieve RFC is an excuse, as it just about mandates it; I'm trying to get rid of that excuse...
  12. The idea of running outgoing spam through a spam detector isn't a bad one; it just needs to be implemented cluefully. E.g. Email to abuse[at]*, postmaster[at]* or *[at]*spamcop.net should be ignored, and the action should not be a silent drop. The main system I use sends an error to the MUA during the SMTP transaction, e.g. if it detects a syntax error in a destination email address; works very well. Keep in mind, many spammers like to use an ISP's mail gateways; these detectors are essential to dealing with that desire.
  13. Wazoo: I indicated in my first sentence, I'm interested in spam blowback from Sieve-based systems. The top line in the table of sieve implementations is a list indicating that Sieve is widely used. (I understand there's lots of blowback from other systems (and that that's bad too) but that's NOT what I'm trying to address here, it's out of scope. However, I bet there's an RFC or BCP that discourages blowback that I could point to for additional support; anyone recall one, offhand?) To continue the analogy, they don't want to stick their necks out; there was no objection to this: http://www.imc.org/ietf-mta-filters/mail-a...e/msg03235.html The only argument that's been put forth (by Chris, IIRC) in favor of keeping the behaviour the way it is was not that there was any direct reason not to make the change, but only that it would take significant effort to explain to Japanese clients why it was a good idea, because they always asked such questions and insisted on answers. (Really! recording, starting (Discussion from 2:46:50; mtg from 2:29:19) The unstated argument against the change is laziness. (I suppose we could also be dealing with wolves (i.e. folks wishing to perpetuate the spam problem) in sheep's clothing, but I doubt that's the issue.) The architecture of some (most?) implementations will require significant rework in order to comply with the Internet-Draft I have written. This is because they will have to perform Sieve processing before responding to the end-of-data command during the SMTP transaction. This will require rearchitecting some implementations, such as the ones where a gateway speaks SMTP and LMTP, and the sieve engine accepts messages over LMTP. However, during the same talk, it was asked if the implementers present (about 7 of them) would be able to implement the new standard, and all of them said they would. If I can say that Sieve engines are currently sending about x spam blowback messages per time period y, requiring end-users worldwide JHD z times a day, at a total time cost of d, and d >> the time cost to change the implementations, I have a good argument. If I can't get the numbers for that argument, I can always make the assumption that Sieve becomes so popular that the vast majority are using it, and make calculations based on that assumption. A protocol must be designed so that it works well if everyone adopts it, after all. In fact, I now realize that this is a better way to argue the point. I'll go make that argument shortly... I suppose I could mention that on November 8th alone, I received at 68 NDRs, just to my personal account, and that's excluding the ones blocked by greylisting or the blacklists used to block mail. Right. The current spec, which I'm trying to change, actually requires that SMTP error codes (e.g. 550) NOT be used, rather that MDNs (see RFC 2298) MUST be sent. Right, I'm looking for some quantification as to how bad it is. Perhaps Ellen could tell us how much of her time she spends dealing with backscatter senders and receivers, and/or how much backscatter gets reported to spamcop, but since many folks think backscatter shouldn't be reported to spamcop, I think that these numbers would underestimate the problem, so I haven't asked her directly.
  14. Ah, well. I tried. (It's funny when their customers get all flustered when I respond to challenges to spam I didn't send.) Hopefully they're smart enough to at least not intermingle the challenges with normal mail. Then again, they can't spell 'cannot', so I doubt it... Just sent to abuse[at]abuse.earthlink.net: On 11/2/06 8:17 PM, EarthLink Abuse Department wrote: > Hello, > > > The email you reported is an automatic challenge by our SpamBlocker email filter. It is intended to prevent unsolicited emails from being received by our customers. Yes, I know that. > It is not spam or unsolicited, it's an automated response. > It's spam, it's unsolicited, and it's an automated response, actually. > If you didn't send email to our customer, then your email address was used, probably fraudulently by a spammer to send UBE/UCE/unsolicited email. That's what happened. > EarthLink can not selectively block your domain from receiving the challenge/responses messages. > Since you refuse my request, your spam will be reported as spam to spamcop, per http://www.spamcop.net/fom-serve/cache/14.html > > Regards, > > > EarthLink, Inc. > Network Abuse > abuse[at]abuse.earthlink.net > ==================================== > > > *ATTN: Earthlink administrator > > Do not send challenges to the domain domain.dom or it subdomains. > domain.dom is frequently forged in the From: of spam, i.e. the subject of joe-job attacks. > (NOTE: domain.dom was NOT thusly munged in the actual email to Earthlink.) > If you ignore these instructions, your spam will be reported as spam to spamcop, per > http://www.spamcop.net/fom-serve/cache/14.html : > * > > *"Messages which may be reported:...* > > 4. Misdirected challenges from challenge/response spam filtering systems" > > C/R is a BAD IDEA. STOP IT! * > This includes > From: <anything>[at]domain.dom > including > **From: <anything>[at]matthew.domain.dom > > Got it? * > > >
  15. Thanks. Happy to have anyone use my msg as a template. I hereby GPLv3 it. I'm sure I'm far, far from the first complainer; their response suggests that they are willfully ignorant, indeed. They're much like 0spam: http://forum.spamcop.net/forums/index.php?showtopic=2527 and MailBlocks: http://forum.spamcop.net/forums/index.php?showtopic=96 . I just wanted to show/publicly document that someone's gone the extra mile in attempting to educate them first. I'm documenting for the record how/why Earthlink sucks. They refuse to be a good netizen - to stop knowingly sending spam in the form of bogus C/R Challenges. (I've been getting Joe-jobbed far more than usual for the past month or so, so I'm getting lots of challenges from Earthlink.)
  16. elvey

    Why not whitelists

    No reputation? "On July 1, 2004, Kelkea, Inc. purchased the assets of Mail Abuse Prevention Systems, LLC." If you haven't heard of MAPS, you, well.... MAPS was the ORIGINAL DNSBL (A.K.A RBL) based on the ideas of Paul Vixie/Dave Rand, its founder(s). MAPS reputation is well known. Partering with an organized crime syndicate like SBC is not a good thing... But I just see them listed as a customer (which probably just means they use the MAPS blacklists). There's nothing wrong with taking SBC's money, IMO.
  17. Yup, Sieve doesn't currently support forwarding email as an attachment. But it could be an extension. I've been meaning to enhance http://linuxmafia.com/~karsten/Download/SpamTools.tar.gz to include SpamCop in the destinations to which it reports spams.
  18. Are the "Additional Comments" entries Important? Who uses these for what? I'd be interested to hear from someone who finds this field important to them. I won't drift off topic. E.g. consider these: Feb 16 11h/1 0 11 0 0 delisted manually, marked resolved Feb 11 17h/3 0 14 0 0 marked resolved These IPs are the source of a lot of legit mail, but an ongoing small percentage (I'd guess .1%, but let's not get off track) is from fairly quickly (0-2 days, 1/2 day typical) closed freemail accounts. The accounts (around an account every couple days) are rate limited and hence don't get off much spam before they get closed. These IPs are generally "marked resolved". I'm wondering if folks see this comment and decide not to report abuse. That would be bad. I may have asked Ellen this a couple years ago, but I can't find the question or recall the answer. I'm guessing they're not used for much.
  19. Yes, I did that; was waiting 'till I got a reply to say thanks/confirm it worked/that address was still valid. But, I hear 'deputies[at]' is taking a holiday break, so I expect it'll be a while. Thanks!
  20. Hi. I want reports of spam from some ranges that concern me, and from some ranges I'm in charge of. I have a spamcop ISP account. (ISP control center access) How do I change Third party interested in daily aggregate summary reports to Third party interested in all reports or <IP range admin> for ranges that concern me, and for ranges I'm in charge of, respectively? Email Julian? I get abuse[at]<domain of rDNS of IP> where I consider myself <IP range admin>...
  21. elvey

    Forum configuration

    Thanks for the info. "...anything except SpamCop reporting and account issues and spam fighting" IS "the misc category" I was referring to. Should SpamCop Reporting Help & SpamCop Blocklist Help only be for Help with these things, or should "Help" be removed and they be about these things in general? They're still tightly defined, but then general ranting about the topic would no longer be OT. Bad thing?
  22. elvey

    Do not report viruses as spam

    That's inappropriate use of SC. You should be looking at the SUBE you report to see that it's not 1)viruses or 2)blowback from a joe-job. (I.e. spam that is bounced to you because it was identified as spam and bounced to you because your address was in the spam's FROM address and the recipient's server is not configured per best practices.)
  23. elvey

    Spamtrap addresses

    I hope spamcop traps do not ignore bounces or only ignores bounces that are in a recognized, well-defined format (specific MDN/DSN, 2821.MAIL FROM <> WITH appropriate stuff in the body. (e.g not just from postmaster[at] Or we'll get lots of spam 'from' postmaster[at]..
  24. elvey

    Forum configuration

    You might be creating too many fora. No, never mind. Sending rants to the lounge doesn't make sense currently - the lounge is said to be for stuff NOT relates to spamcop. And the thread I started about SpamcopIsNotHarmful is something about spamcop that doesn't fit into any category and suggests that the new misc category would be useful. BTW, is using the faq-o-matic to sugggest edits pointless?
  25. Two links I think everyone should see: Excellent information on China and spam: Trip Report AOL (et. al.) lobbies for spam legalization: here