I can appreciate trying to raise the floor with a dress code or basic code of conduct, but a culture of contempt is actually counterproductive. It results in a "blame culture", which is inherently less secure. And both these negative qualities reduce the viability of the community and stunt its growth and progress. There are other ways to raise the floor.

pfSense is a distribution whose whole purpose is simplifying the administration of pf? With another major goal of reliability? What would you expect, then?

I should point out that SMTP transport is by nature complicated.

And that's only item #4 out of their goals. Everything else is pretty much covered.

And what the hell are people doing using Sendmail? Use Postfix or qmail.

The editing around here normally stinks, but either the editor or the submitter (more likely) did a great job of averting the possible ambiguity here by judicious application of a hyphen. "13 hour-long episodes" is perfect. As much as I'm inclined to roll my eyes at the editing and snark it in comments, I should point out when it works. Well done.

People like to hear that DNSBLs are a problem. And then they like to repeat the accusations. Not sure how folks have gotten attached to the idea, but I'm certain it's not from detailed investigation.

For one thing, don't conflate the mechanism with the implementations. Anyone can publish a DNSBL. You could. And you could make your list all false positives. It would be a bad idea for people to subscribe to your list. Caveat emptor, right?

And that's why you get false positives. You've chosen badly. And you're not using the lists for scoring — sounds like you're using them as final arbiters.

The "trick" to getting DNSBLs to work is to choose wisely. You have to do some research into how the lists are made, and since it's you who will be blocking emails based on the information provided by the lists, it's your responsibility to understand the nature of that information. What are the listing/delisting policies? If you don't know, you're not being a smart consumer. "... everytime some angry recipient with a vengeace decided to file a spam-report ..." Hopefully you know better than to think that every DNSBL is made this way.

And the "smart" spam filters, so you know, are resource intensive. Instead, it's possible to eliminate lots of spam using extremely low resource checks. Validating the SMTP "HELO" (requiring they give FQDN, non-bare address literals, not your domain or IP, and a couple other checks as per RFC) will nix half of spam off the bat. And you can eliminate another third of spam (two-thirds the spam passing HELO checks) by using (well-chosen) DNSBLs. DNS lookups are cheap (and you can download zone files of you're worried about outages). That's 83% of spam cheaply nixed, all before you even get to "MAIL FROM:". If your "smart" checks are building Markov chains and feeding a naive Bayes classifier, that's gonna take time and effort in processing power, in disk resource, in procedures and staff attention/knowledge for maintenance.

DNSBLs are clearly a way to fight spam. But you have to know what they are and how to use them.

Shopping for DNSBLs takes effort, it's true. If you want to do a good job. Once upon a time, Al Iverson's http://www.dnsbl.info/ was up-to-date and gave wonderful statistics on success rates of the various lists (using his (rather knowledgeable) measures). Doing the research now without such a resource is much more challenging.

I use Spamhaus's XBL and SpamCop's SCBL. That's it. Combined, those give me the aforementioned inexpensive 33% spam reduction. (If I used them before the HELO checks the reduction would probably be near 75%, my guess.) I vetted the lists for efficacy (true positives v. false positives), policy (how they're made, listing and delisting), and longevity/reputability. I've been using these guys for 5 years without a hiccup.

Can you forward me one of those spam-binned emails (with full headers)?

It's a good question. You would do well to read up on how DNSBLs and DNS work. If a DNSBL's authoritative server goes down there's no risk of false positives. You don't get a positive response for random IPs when the list is not answering. And if you look up the IP of someone who's actually sending spam and you don't get a positive result, that's okay too. The list shouldn't be your only check for whether something is spam. And if you look up an IP and the server doesn't give any response, that's okay too. Your mail system shouldn't freak out and mark the email as spam or otherwise fail to handle the email.

You feel dirty for using the Spamhaus blacklists? Which ones do you use? Do you know how they're generated?

I don't use the SBL, though I'm philosophically not that far from approving of it.

I don't use the PBL, I just disagree with the idea behind it.

I don't use ZEN, obviously, being an aggregate including lists I don't agree with.

I do use XBL. To me it just makes sense. And I don't have one whit of regret about it.

The different lists published by Spamhaus distinguish whether the IPs are directly responsible or are organizationally related. There is no abuse of power here — customers subscribe to the lists that they want, and use those lists to block as they see fit. Spamhaus isn't forcing anyone to use the lists, nor is it misrepresenting what's in the lists.

I think the idea is that acting as you imagine you would behave correlates more highly with how you actually would behave than randomness does. Take the data as a correlation, be cognizant of the possible degrees of accuracy, and extrapolate from there. You maybe get broad strokes showing you the directions things could go in an actual situation, but that's not nothin'.

Actually, moving sshd to a different port is for added security.

It'll be some time before automated scans and worms try to find SSH on something other than port 22 in any substantial frequency. So moving the port gets you a reduction in attack frequency. That's of value. It's additional security.

Requiring a remote system to send SYN packets to 16111 28123 and 22222 before opening port 22 to them is just another way to reduce frequency (albeit using a much higher hurdle). The difference is degree, not kind, so it's not that one of these actions is actual security and the other isn't.

The point behind having 4 different solutions was to be flexible in my thinking, ready for whatever a scenario might call for. The question, being a test question without a genuine context, leaves open the range of possibilities, using only a hint (in place) to constrain the solution. There are situations that could use the two algorithms you find unsuitable (unsuitable presumably for the situations you commonly experience and thus judge things by).

This is fun. Okay, I'm not a JavaScript programmer, but here are my submissions (the first two solutions taking 2-3 minutes to create):

First we create the array.

    var ary = [1,2,3,4,5];

Now... First reversal method, assuming static array size and these particular numbers:

    ary = [5,4,3,2,1];

Whether this is "in place" depends on how JavaScript works. Seems likely to me that it'll do it in place.

Second method, assuming static array size, this particular array size, and using any (numeric!) values within the array:

    for (i = 0; i < 2; i++)
    {
        t = ary[i];
        ary[i] = ary[5-i-1];
        ary[5-i-1] = t;
    }

Obviously uses a temporary variable. Depending on what was meant, that may violate the "in place".

Okay, after a couple more minutes, here's another:

    for (i = 0; i < 2; i++)
    {
        ary[i] += ary[5-i-1];
        ary[5-i-1] = ary[i] - ary[5-i-1];
        ary[i] -= ary[5-i-1];
    }

Again, assuming a 5 element array. No memory aside from the array used, though more (simple arithmetic) operations used.

Oh, shit, hey... Does this work?

    for (i = 0; i < 2; i++)
    {
        ary[i] ^= ary[5-i-1];
        ary[5-i-1] ^= ary[i];
        ary[i] ^= ary[5-i-1];
    }

Seems to. I'm not that knowledgeable, so I don't know this, but I get the sense that binary manipulations may be faster than arithmetic.

Also, I expect things like the 5-i-1 to get evaluated once and for the compiler to not bother calculating it again. If this were a concern, then storing the result in a temporary variable might make sense, depending on the overhead (and whether this again violates "in place").

Critiques, please?

More seriously, who's to say the writers of this algorithm can't run it in reverse to frame someone?

Oh, clever.

But now future courts can point to your post to show that the idea was common or at least public knowledge, empowering stylometric identification deniability in cases of plausible framing.

The Syrian civil war is one of the main topics. The other, arguably primary main topic is Apple's censorship. The sub-topic being discussed under Apple's censorship was platforms and social pressure. The sub-topic underneath that was Internet Explorer as an example of such. To think of IE and the civil war as a dichotomy is a mistake, though I certainly also feel the emotional impact of contrasting the two.