This REALLY sounds like a copy of Sendmail Inc.'s Rate Control component, which has been deployed to many sites for the last several years. Rate Control allows the admin to throttle or otherwise block email that breaks various TCP-related thresholds (messages/second, bad recipients/second, connections/second, etc.). Further, recent real world indications show that spammers are sending fewer spams per second from individual IP addresses--they make up the volume by increasing the size of the botnet, and coordinating activity so that not too many bots hit the same relay at the same time. This is why Rate Control added an IP Reputation subcomponent a couple of years ago.

It appears these Navy guys have simply come up with a tool that has already existed for years.

As far as being a solution to spam, I agree that spam is 99% a financial problem. The problem with attacking it as such, is that one tends to also hurt legitimate endeavors. If all the advertising were removed from the Internet, there would not be much of a non-commercial Internet--the advertising tends to keep many things free or very cheap. Also, education is great, but as soon as you teach one person to not fall prey to spam, there's another person born who will fall prey. Thus you need to do many things in concert to fight spam--educate, identify, legislate, prosecute. The closer to the front end we can identify spam, the more cheaply we can block or redirect it. Why redirect it? For prosecution and legislation reasons. If you can identify where the money goes, this evidence become important to justify cutting off the ability of that spammer to get funds--credit bureaus, etc.

Watching the video, two things were apparent: Sendmail wasn't being used--Exim was, and the fault was not the MTA, but rather the use of a single SAN backend for everything.

I've been in the Messaging Infrastructure business for many years. The UC problem is poor design. They left themselves open to a single point of failure by not splitting the mailbox load across multiple SANs. Their load isn't really all that great--I've designed for much larger email volumes. What they need is an LDAP-based routing (or similar) mechanism to send different recipients' emails to different SAN backend stores--say, alphabetically by last name, or by entry (employee/student/alumnus/account) id. When a disk failure occurs, it then would only affect a small percentage of the population, and for a much shorter time. By enforcing RFC compliance on the front end, they would also reduce the load on the back end, and could easily handle their traffic load with far fewer servers--thereby costing far less than what they currently have.

They certainly can pay someone else to do proper design, of course, but they should understand that technology and budget did not cause their problem, their poor design did.

-David Gillam
www.davegillam.com

Bypassing all the arguments for and against this plan, I notice an interesting detail in the article. It applies to employers and employees (form W2) only. It apparently does not apply to business owners or freelancers (form 1099). So all the independent people (lawnkeepers, housekeepers, pool cleaners, handymen, freelancing programmers, etc) won't be affected by this either way, at least at first. They'd have to expand it to apply to everyone asking for any kind of service (hospitals, unemployment, banks, groceries) to have it affect 100% of the population. So if you want to avoid this card as long as possible, just start your own service business, or convince your employer to convert you to a form 1099 contractor, instead of a form W2 employee. You'll have to work out the pay scale to afford your vacations, insurance, and other perks, but that's workable. Also, if a lot of people become their own bosses, they technically always will have a job (their own business), so the unemployment lines would diminish. Theoretically. ;-)

Agreed on all counts, and don't forget adding honeypot MX records, as many bots will either target the highest-numbered MX, or only the lowest-numbered MX. Proper MTAs will follow RFC, and get around the honeypots, to the "real" MX hosts.

SPF, SenderID, and DKIM are not spam-fighting techniques. They are forgery-fighting techniques. Some spammers use SPF and SenderID records to give their spam a higher sense of legitimacy. A spammer cannot forge "paypal.com" because Paypal publishes SPF records. A spammer CAN pretend to be Paypal by using a look-alike domain with its own set of SPF records (ie: paypall.com, paypal.org). SPF and SenderID simply publish what IPs are authorized to send email claiming to be from a particular domain. DKIM does essentially the same thing, but is arguably better since it uses a cryptographic mechanism to assure the message in question was not appreciably altered in transit.

I'm not an expert, but from what I read of the XML files, launchd seems more of a wrapper program than a replacement for cron. Translated: ProgramArguments = /usr/sbin/cron; QueueDirectories = /var/cron/tabs; ps -wwax|grep cron # shows two cron processes in memory; So launchd takes the place of init, and starts up cron, with the proper arguments. Cron then takes care of its own.