The guys were *NOT* kicked out. None of the three were kicked out. According to the official statement and my personal conversations with other conference organizers:

"Both parties were met with, in private. The comments that were made were in poor taste, and individuals involved agreed, apologized and no further actions were taken by the staff of PyCon 2013. No individuals were removed from the conference, no sanctions were levied."

http://pycon.blogspot.com/2013/03/pycon-response-to-inappropriate.html

The short answer is: If you tell us that an e-mail from you is not to be trusted, we will honor that request. But if our system falsely catches an e-mail from you, say because of a bad SPF record, we will whitelist that sender.

We have a custom system I built and haven't yet had time to polish for a open source project (and it needs it before it could be publicly released). It has an awesome feature though...

Messages are rejected at the SMTP level, for things like SPF, greylisting, and SpamAssassin. The bounce message has a URL that the sender can visit to release the message. I was anticipating this might get abused and have to have a captcha on it, but so far it has not. Actually, it's worse than that, 99+% of people who get this message don't read any further than the subject, which is generated by their mail server, so they usually contact us some other way saying "Your mail server is broken".

BUT, the killer feature is that our users can go to a website and see the messages sent to them, and "release" them. So if you are looking for an important message no problem! You go to that page, type Control-F and the sender name or subject you are expecting, and click a button, and you have the message. It's kind of like a quarantine, but it's controlled by the sender AND the recipient.

Now, as far as what we do about senders that have broken SPF... We add them to a whitelist and tell them "You've been whitelisted, but your domain is publishing a notification that says this e-mail is invalid, you probably want your mail server admin to fix this because other places are honoring this as well."

No big deal, not ideological stands, we just deal with it and report it on.

Because that's the crucial thing: Your domain is telling me that this e-mail is not to be trusted. The CEO of our company understands that yelling "You can never have a false positive" means that they are going to have to deal with an inbox full of sewage -- they understand what false negatives are.

Sean

"Internet access is as crucial to everyday life as having a phone connection [...]"

The telcos *WISH* that having a phone connection were as crucial to everyday life as Internet access...

The thing is that the script is not run until *DELIVERY TIME*, so postfix can't trigger that 550 error that the AC is talking about. The AC also is a bit off because they say it should be sent in response to the "TO: header". Actually, what they meant to say was in response to the "RCPT" SMTP command where the envelope sender is specified. That is done before the message is queued, while the remote host is still on the line.

So, yes, what you were doing causes backscatter, and is a problem for the reasons you found out. You *WERE* sending messages to the honeypots, via the piped scripts you mention. These happened at delivery time, which caused postfix to generate a bounce message and then connect to the servers handling e-mail specified in the envelope as the sender address, and then try sending a message to it. So if the spammer put a honeypot address in as the sender (either accidentally by selecting a random sending address to use, or on purpose), you were sending a message to the honeypot from your server.

Spammers seem to like to use honeypot addresses when they can find them. Because this causes other people to get annoyed at the blacklist owners and make the DNSBLs less effective or increase their workload because people stop using them or contact the DNSBL about getting removed, etc...

What you should have done was to set up a "check_recipient_access" with a map for the "smtpd_recipient_restrictions". Something like: "smtpd_recipient_restrictions = permit_mynetworks, check_recipient_access hash:/etc/postfix/access-rcptto, reject_unknown_recipient_domain".

Then in the "access-rcptto" file you can list the recipient address and then: REJECT "Please send e-mail to user@example.com instead."

Sean

Comcast doesn't seem to block outgoing port 25 *UNLESS* you start sending spam through it. My Comcast line allows me to make direct SMTP connections out from it on port 25, but other people in my area have theirs blocked. This came up because one guy was using his Comcast line to send e-mail but it suddenly stopped working. After some investigation, we found that it got blocked around the same time one of his machines got infected...

Unfortunately, vacation replies *CANNOT* currently be sent before accepting the mail. The reality is that people simply *DO NOT READ* SMTP error messages at all.

I've been running an experimental system on my main mail server for a couple of years now, which quarantines messages at the SMTP DATA phase if it is uncertain about the message (based on SpamAssassin, greylisting, etc...). It includes a URL that the sender can visit to release their message for immediate delivery.

I've only ever had *ONE* person use this URL to release their message. On the other hand, I've had dozens or hundreds of people contact me by other means saying "My message wouldn't go through to you. I don't know why."

I deal with e-mail problems a lot, and I'm constantly surprised by the people who get an e-mail bounce and then call me to find out why. They think I do magic, when actually I just read the e-mail they received with the bounce information in it. :-)

Sean

I run a small hosting company (an add-on to our consulting), and we run burn-in testing on every drive we put into production.

Before we did this, we would regularly run into drives that would sporadically fall out of the RAID array because a block couldn't be read during validation. Once we started testing our drives, this all but stopped. My guess would be that some parts of the platters were marginal, and after a few read/write cycles they would fail and need to be relocated. So doing some testing would cause these blocks to be remapped.

What we do is "badblocks -svw -p 10". However, we've reduced it from 10 down to 3 because 2TB drives take so long to test now and that is our standard drive now. We target a few days to a week of burn-in testing.

Other things that this resulted in:

There was a Linux kernel bug with the LBA access code that caused one specific block on the drive to always report as bad with certain firmwares. The old firmware used to silently do the right thing with what the kernel was asking, the newer firmware reported a read error on this sector.

We've also found some drives that passed the testing fine, but did so at around a tenth the throughput. We were never able to track down why this was, we had a batch that were exhibiting this and we just gave the 10 or 15 drives away that were impacted.

We also had a batch of 10 or so drives that half of them were reporting high numbers of failures. We figured something had happened upstream (at the reseller or during shipping) and so we replaced even the ones that tested out ok.

So, yes, test your drives. Even though we're putting them in RAID arrays, we like to run the tests.

Sean

Your program manager probably wants this project to succeed as much as you do. Keep that in mind.

Be mature and communicate with them. Tell them your concerns, something like "This project is very important professionally and personally to me, and I want to work with you to make sure that it succeeds. However, I'm concerned that bringing in new team leads and consultants be done in a way that most improves the project. We've all heard the stories of new people being added to a project and causing problems . So how can we work together to make sure that this is a success."

Keep away from phrasing that is too accusatory, stay more neutral like I have above. For example, I said that I was concerned about new team members being the most successful, rather than saying "I am concerned about the new people you are bringing in will cause problems". Also, try to work with the program manager rather than being sure that they're just going to wreck things and you are the only hope.

If your program manager is any good, you can almost certainly accomplish more together than either of you can apart. Remember that and work together.

Sean

Over about the last 2 weeks, one of our hosting clients OpenVPN connections to their machines in China have been failing. We can still SSH into the machine in China, glad they haven't blocked that. We ended up setting up a block of several hundred ports with DNAT to the normal OpenVPN port, and then set up 64 (the max allowed) servers in the client config so it can cycle between them. That's been effective so far.

It took a while to figure out, because I was able to send test traffic via "date | nc -u server 1194", and that would go through, but the OpenVPN connection wouldn't.

Sean

>Debian Stable is the epitome of long term support

Actually, it's absolutely not. Long Term Support means that when I deploy a set of services on a system, I know exactly how long I have before I need to qualify, test, and roll out that application when the current version reaches EOL. Many of the clients I've worked with take a year or more to do such a qualification (because of complex applications, lacking test suites, lacking development resources, etc...).

Note on the Debian Wikipedia page that the only supported version (6.0/squeeze) lists "supported until" as "TBA".

Every other LTS release out there (Ubuntu, RHEL/CentOS, SLES), lists multiple supported releases, with end of life dates in the future. For example, Ubuntu lists 5 currently supported releases, the most recent of which is supported until April 2017. CentOS lists 2, the most recent of which is supported until the end of 2020.

I love Debian, but I do not recommend my clients use it for servers. Right now, if a client deployed their services on the most recent Debian server, they have no idea when the End of Life is going to be. The current release will go End of Life a year after the next version is released. The next version has been in freeze since June 30, 2012, so this could be any time now. If testing for migration to a new OS takes a year (which is not uncommon in my experience), you could deploy a service and immediately need to start working on migrating it.

RHEL, on the other hand, you can deploy it today and know that you don't HAVE to migrate until 2020.

As a production sys admin I assert that it's not reasonable to run a server in production that is not receiving security updates.

So, as far as Debian as an LTS release: Just don't.

Many of the receivers I have looked at say that they won't honor the warranty if it is not purchased through an authorized reseller, and the authorized resellers all seem to have the same price for the units, including online and brick-and-mortar...

If you want to save a ton of money, it seems like buying last years higher end model, which likely has very similar features to this years lower-end model, can be a huge price savings.

Sean

This is similar to the reason I ended up leaving the pool 7 years ago... The week I left the pool I had two different people call me telling me that one of my machines was hacked because it was attacking their network. "Hmm, what port are you seeing the attacks on?" "123." "You know what 123 is, right? NTP... Those packets your intrusion detection system is complaining about are in response to packets you sent that server."

It was actually the guy that hung up on me while I was telling him that his machines were causing this, that caused me to leave the pool. I'm sorry, but I just can't be providing individual phone support to everyone who uses the NTP pool, that's kind of how I was feeling...

I haven't been in the pool for 7 years, and I'm still getting around 8,000 packets per second on NTP, around a megabit per second. There's one DSL line in Italy that sends an average of 15 packets/sec.

Here's a blog post I wrote in relation to this: http://www.tummy.com/journals/entries/jafo_20050412_123522

Sean

Hopefully you don't have any of those BluRay discs that require an Internet connection to play... I presume that if they can't reach whatever they're trying to reach, it doesn't matter if you physically have the Blu-Ray disc and player, you still can't play it...

I looked seriously at hybrid discs around a year ago, and basically ignored them when I found that they only use the NAND portion for read caching, not write acceleration... With the exception of the initial boot, which I'm not that interested in since I suspend and usually only boot my laptop once a month, it seems like you're better off adding 4GB of RAM to your box rather than using a hybrid drive. At least for my rare reboot case.

You haven't found anything that Xubuntu can't do? How about un-mute your audio?

You see, Xubuntu (at least precise, possibly others) uses PulseAudio, but XFCE doesn't support PulseAudio for dealing with audio. The author of the offending package has basically said "Maybe one day I'll add PulseAudio support, but I'm busy". Which is fine, but it does mean that there are issues with audio. https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/999026

I'm mostly happy with XFCE, though there is a bug in the mapping of some hot-keys that required me to edit config files, and create external commands for the handling of desktop switches (so I could map a key that would take me back to the previous desktop I was on, without having to remember which one it was). I also was able to work around the above bug by mapping Windows-O to something to fire off a script to re-enable the sound.