Hi Jeroen,
Let's not start this email security discussion by being focused on the bottom line or by being cynical and say some network will not care. We all know that out there, that shouldn’t stop legitimate providers from getting their act together. Let’s keep rational and positive.
Personally, I have enough resources available for protecting my network regardless of a technology or a vendor, so I do not want to take the problem by assuming how much money do I have to put on the table. The thing is, relying on a proprietary (fictional) protection appliance which filters SMTP at will, based on unknown decisions factors is probably not the way to solve issues and is probably not future-proof as the spammers tend to have a few smartass and they have their own ecosystems for acquiring new spam technology. However, if some do work brilliantly, with very little false-negative/false-positive overheads, why not give them a chance.
Getting back to the business, let me describe the goal of my previous message and the current deployments we have to cover such problems. I do not talk about DPI deployment and I am solely trying to solve abused-SMTP usage. The ultimate goal here is to protect IP reputation of servers. I do not want to filter dial-in, DSL, 3G network, but a Hosting network where the SMTP server will accept authentified customers to send their emails as long as they have proper credentials.
Let me describe what I call a spam in this case, because the word spam holds multiple definitions and multiple usages and hardly get everybody to agree on its meaning. To me a spam is a message which is unsolicited, by opposition to a one-to-one, one-to-many or a newsletter communications, which may or may not be wanted by the recipients, but assuming the double opt-in was done correctly, this is different and it requires administrative handling rather than technical handling. In my case, I refer to customers who get their accounts compromised (either POP/IMAP and SMTP) in their email clients such as Outlook, Thunderbird or their Web Account (FTP, HTTP) with either some malicious piece of code on their computers or compromised self-made or well-known un-updated, compromised CMS such as Joomla or home-made poorly programmed scripts.
We have two types of customers. Professional customers who know what they are doing. This kind of customer has no outgoing spam issue. They add a specific tag to their outgoing email, their emails are relayed to a smarthost which strips the header and do a few tricks such as DKIM signing and ultimately relay the message into the Internet. We can assume they send clean emails, unless somebody don’t want to receive them, but we handle this by Feedback Loop and that happens with a ratio of 1:200000. In addition, these customers usually have good security measures in place and we rarely see Trojan-infected hosts within their network. For the latter, we rate-limit the number of email they can send per hour (on some hosts) we look at the type of return we get in the incoming logs and we correlate sudden bursts of outbound message and NDR. Often we can quickly workout compromised accounts and we can identify the script, by looking at the source URI of the script or the SMTP- authenticated account which we reset the password and call the customer or wait for the call. This is usually not a rocket science and it requires a lot babysitting and don’t always prevent the arm of the being RBL.
It is actually way harder to protect regular, simple, customer sending an email with his email client than protecting scripts and mass-mailing customers. Now anybody who dealt with an Outgoing Spam attack have seen that spammers are not always subtle and they just try to flood any address usually within aol, gmail and hotmail with low-quality spam to help solve impotence. Shall we just provide free blue pills to just solve the issue, or are they cheaper ways to get these behaviours to trigger some mechanism that pause/drop and give a chance to resume the mailing or just drop it dead? I am not against a system which is not perfect but which can be influenced by the administrators to not reproduce mistakes.
Maybe somebody has more insights to share at this point. If somebody does, they are welcome most welcome.
Cheers,
Gregory