Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • The material above was originally posted as a comment on Slashdot, before being pasted into journal entries on Slashdot and Each version of the writeup has attracted comments & emails, for which I thank you. A couple of corrections have come up, and I don't want the eventual archived versions of this not to reflect those contributions (hello, future Google spelunkers!), so here's a general cross-linked addendum:
    • []:

      Chrysflame posted [] detailed minutes for the proceedings, as pasted from Oliver Schmelzle's TechBlog [].Readers may find it useful to cross-check my notes against his times when looking for talks they would like to listen to.

      Matt Sergeant politely replied as well [], noting that the impressive claims about CRM114's accuracy were yet to be thoroughly tested, that in other tests CRM114 had not been significantly more accurate than other Bayesian strategies, and that the current performance of CRM114 is so much slower than many of the alternatives that any gains it may have to offer are more than offset by the low volume it can currently handle. Grain of salt taken :)

    • []:

      No comments as of this writing.

    • []:

      An anonymous coward [] added a couple of corrections which are worth noting:

      • Jon Praed was questioning IP spoofing, not message header spoofing. It is relatively easy to fake at least some of the headers on an email, but when tracked down & brought before a judge, no spammer has ever been able to explain a credible technique for spoofing IP data in any trial Praed was aware of. When this comment was made to the audience, ESR spoke up saying that he could show Praed how to do it, but I don't know what if anything came of any conversation they had after the talk.

      • The AC also expanded on Michael Salib's talk & how much mileage Salib was seeing out of a comically non-buzzword compliant filtering strategy, but came back to the point that his results were "probably unrepeatable and it would probably be best if we all just treated them as outright lies." As the AC noted, Salib seems to have played a big role in organizing the conference -- I think I read somewhere that when the attendee list swelled to 500+ people, he helped to find a last minute venue big enough to accomodate everyone. So not only do we have to thank Salib for an entertaining spiel of quackery, but also for bringing everyone together in the first place. :)

      I never said my notes were perfect :)

    • Emails sent to me directly:
      • Brad Spencer wrote to me asking if anyone had mentioned relay spam honeypots, citing [] as an example, and claiming that they are "100% accurate and can be devastating.". Respectfully Brad, I'm not sure that the speakers gathered together last week would agree that any approach is "100% accurate" unless you have a very generous definition of "accurate" (as in, "delete everything as spam" is 100% accurate, but 100% useless :). More fairly though, Brad claims that "if you deal with spam at the relay level you can be dumb -- it is the spammers who are forced to be smart. If they make an incremental move towards being smart you move beyond them." I won't argue with that, it sounds like a fine idea. I suggest taking ideas like this to Barry Shein et al, who would probably love to discuss these ideas & implement anything that works well.

        In his email, Spencer went on to expand on the value of honeypots, and how they seem like a very promising tactic for handling the spam problem. I agree, and maybe my writeup didn't give this enough attention, but I think many or all of the conference speakers would have agreed as well. Ken Schneider made it clear that Brightmail in particular seems to make heavy use of honeypot addresses: it sounded like when they set up service for an organization, they plant one or more dummy addresses at that organization as data points for spam collection efforts, and have mechanisms in place to gather & analyze this data in real time. Spencer suggests that honeypot addresses would be very hard for spammers to detect if they resemble legit MTAs as much as possible, and I have the impression that this is exactly what Brightmail is doing. I'm sure that others are using tactics like this as well, but Schneider was the most vocal user of the tactic that I noticed.

      • John Hanna wrote to me saying that he runs an anti-spam project at [], and noticed a surge in traffic after the conference. To answer John's question, I did not notice anyone mentioning ASSP [caps?] during any of the talks, but it could well be that people were discussing it amongst themselves off stage. *shrug*

      • Ashley Pomeroy wrote to a mailing list where I posted my notes, asking:It may have been raised before, but does the specific use of 'ham' to mean 'good' and 'spam' to mean 'bad' leave all these good people open to abuse from the people who make Spam, the nutritious meat-based food?

        I assume that Spam(r) is cool about the use of the term 'spam' to mean junk e-mail, but adding a converse makes it explicitly clear that 'spam=bad'.

        And what do the pigs think about all this? Its their flesh we're talking about. The ultimate expression of love is to consume the flesh of another being; we are sending out a mixed message as to whether we love pigs or not, which will surely effect the quality of the eggs they lay.

        By this token eating one's fingernails/bogies/earwax is a form of self-love, which is perfectly natural.

        To which I have no comment :)

    If I get any other material relevant to the conference, I may add it to the Slashdot or use.perl journals, but in any case I wanted to get this up while the pages are still getting traffic, so readers of one variation of the page are not missing out on what may be added to other variations. Thanks all for the feedback! :)