How would you feel if your Greek ISP blocked your outgoing port 25 today, following current industry best practices and recommendations?
Back in 2004, working in an ISP [*], spam was starting to become a big two-fold problem.
- For incoming e-mail, which contained a lot of spam.
- For outgoing e-mail, with our mail servers ending up in RBL lists due to infected school labs
(1) is a problem well understood, with numerous tools out there to address the issue. (2) on the other hand requires a more heavy-handed approach.
- It’s a bigger problem: spam makes you work more inefficiently but still allows you to work. Not being able to send e-mails at all prevents you from working altogether (at least via e-mail)
- It affects all users: it’s not just your problem anymore, being a clueless user that has typed in his address in thousands forms instead of using a temporary e-mail, it’s everyone’s problem.
It had become such a problem, with school labs being poorly maintained back in the time, that there was no option but to act and rather swiftly. Purchasing a solution was not an option, designing a sophisticated system would take too much time, so we opted for a
quick-and-dirty a rapid prototyping instead. It’s been so many years that the details evade me but it boiled down to this:
- A qmailstats log parser implemented in perl that analyzed data in “real-time” (actually fixed 5 minute windows)
- A MySQL DB backend that kept aggregate data on a per e-mailand IP address basis
- Some arbitrary limits on the amount of e-mails that a single user can reasonably send per day or in a 5-minute window before being considered a “spammer”
- IIRC maildrop to block “spammers”
- E-mail notifications, to notify offenders of their actions (this was CC’d to the appropriate helpdesk office)
- A simple web-based frontend that provided a “view” of the “spammers” (as well as a remove button) that the system had caught and their activity, to be consumed by the 1st and 2nd level helpdesk engineers.
A couple of thousand lines in PHP and Perl and another couple of weeks in testing later, the system was up and running. We braced ourselves for the storm of complaints and issues that would arrive from the 1st level helpdesk operators, crossed our fingers and launched it. Surprisingly it went quite well. Most users caught by our extremely simplistic filtering mechanism were indeed spammers, rather than frequent e-mailers, and understanding of the policy implemented, promising to try to clean up things before they requested the block to be removed and to use IMP based webmail interface till they do. Some of them pointed obvious holes in the system, especially administration offices (who might send an e-mail to a few hundred schools instead of using the designated mailing list for these schools). Others made positive comments about the performance of the e-mail service notably improving, not a really big surprise when your infrastructure is mostly based on aging V120 sparc boxes. Finally, helpdesk operators and 2nd level helpdesk engineers appreciated the crude web based interface that allowed them to check what’s happening in real time and notify people accordingly.
So to come back to the question … I have no idea since it never happened to me. That said, given my experience as someone who actually implemented such a block, and a rather good one, I’d say “not badly”. That is, as long as I get some kind of notification and didn’t have to wait 45′ in the helpdesk line for someone to respond.
[*] People may argue that the Greek Schools network is not an ISP per se but I digress.