Jump to content

elvey

Members
  • Content Count

    34
  • Joined

  • Last visited

Community Reputation

0 Neutral

About elvey

  • Rank
    Member
  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 82.80.0.0/20 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. 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.
  6. 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.
  7. 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.
  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. 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...
  11. 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.
  12. 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.
  13. 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?
  14. 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.)
  15. 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? * > > >
×