An Internet dependency
Our main Internet connection is effectively down at the moment, and hasbeen for over an hour and a half by now. It's startling how much of mywork and the little stuff I do, including things I do more or less tofidget, turns out to be in some way dependent on the Internet.
(I have a pile of little fidgets that I do just to fill time, thingslike checking every so often to see if the mail server is OK or if thereare any new Fedora Core
A basic principle of website security
In theory I shouldn't have to say this, but in practice I probably do.One of the most basic principle of designing secure websites is simplythis:
Never trust anything you get from the network .
Everything you get from the network is under the control of asufficiently determined attacker, no matter how it is 'supposed' tobe generated. Every request, every form POST , every cookie, andevery AJAX callback. No amount of obfuscation can do more than slow anattacker down.
(In fact
Weekly spam summary on December 16th, 2006
This week, we:
- got 16,689 messages from 271 different IP addresses.
- handled 21,893 sessions from 1,229 different IP addresses.
- received 207,766 connections from at least 62,254 different IPaddresses.
- hit a highwater of 8 connections being checked at once.
This is about the same volume as last week ,although the number of different IP addresses connecting to us isunusually large.
| Day | Connections | different IPs |
How to get me to block your web ads in a flash
Tim Bray :
The animation in Web display ads is outta control, outta control, I tellya!
What he said (except that it's been going on for years). The fastest andbest way to get me to really kick your ads to the curb has always beento make them blink and get in my face, and it amazes me that anyone hasever thought such ads were a good idea.
(Huge, page-disrupting and modem-saturating ads don't help, but they are
An unsurprising discovery about spammer behavior
Here's a recent, not entirely surprising discovery about spammerbehavior: some spammers are really slow to pick up DNS updates.
We changed MX entries to point to our new SMTP frontend on late Monday afternoon. Our MXentries had the standard 24 hour timeout and our secondary servers hadupdated to the new zones by Tuesday morning at the latest, so by nowit is more than two days after our old MX entries were required tohave been purged from caches, even if they were gotten from asecondary using
Fedora Core's memory problem
; chkconfig --list autofs
service autofs supports chkconfig, but is not referenced in any runlevel (run 'chkconfig --add autofs')
; rpm -U autofs*.rpm
[...]
; chkconfig --list autofs
autofs 0:off 1:off 2:off 3:on 4:on 5:on 6:off
Is it too much to ask that Fedora Core remember what services Iwant and don't want running over package upgrades? Apparentlyit is, because this happens
A SMTP implementor's conundrum
Today I ran across a good example of the sort of engineering conundrumthat bedevils people who implement things like SMTP clients:
In a multiline SMTP reply , which replycode should you use if different lines of the reply have differentcodes?
That is, in a regrettably non-hypothetical example, if you send aserver ' Should your client go on and send a If you walk up to the console of some Linux machines that have theircapslock turned on and try to log in, an interesting thing happens: (This works with Ubuntu 6.06, but not with Fedora Core 6.) Why does this happen? Once, long ago, there were terminals that only did upper case, and therewere people who wanted to connect them to Unix systems. So Bell Labs puta We put a new SMTP frontend machine in front of our core mail servertoday to handle incoming email from the outside world (for the usualreasons: dealing with spam better, shielding the core server fromsix zillion zombies all trying to talk to it at once, etc). Rather than wait for updated MX entries for all our domains to propagatearound and for people to switch to them, we figured we could speed upthe process by having our bridging firewall send connections for the coreserver's port 25 Our SMTP frontend crashed and restarted three times this week, twice onWednesday around 6pm and the third time today at 3:16pm, so some of ourstats are really fragmentary. Still, this week we: MAIL FROM:250-There's a problem.454 please try later
RCPT TO ,
An example of Unix's slow fossilization
keyx login: CKSPASSWORD:[...]CKS@KEYX:~$
A limitation of OpenBSD bridging NAT firewalls
Weekly spam summary on December 9th, 2006
Menu