“We are currently contacting affected customers to help them clean their PCs which, as you can imagine, is a time-consuming task,” it said.

Which, while it needs to be done, is exactly the wrong way to fix this. They may as well have added “and once we’ve contacted all 16,000 of the infected users we imagine nobody on our network will ever be infected with a virus or trojan ever again.”

The proper solution I’ve long supported is blocking outgoing port 25 from dynamically allocated addresses.

Now, in theory, all receiving servers could just refuse to accept mail from these addresses. Unfortunately there’s no simple way to do this. MAPS had an RBL for this purpose the dial-up user list, the “DUL”, I’ve no idea if this still publically usable, or if it’s still maintained. Regional IP registries don’t seem to record this information in a way that’s publically queryable. You might encode it into DNS in some way, but given the pathetic level of reverse DNS deployment by many providers I wouldn’t expect that to be done.

You have to stop the spam from leaving your network. You have to block it, not at the application layer – but at the network layer. Any solution that requires effort on the side of the receiver is already broken.

Today, it seems that blocking port 25 is what the US Federal Trade Commission is advising ISPs to do as part of Operation Spam Zombies.

• block port 25 except for the outbound SMTP requirements of authenticated users of mail servers designed for client traffic. Explore implementing Authenticated SMTP on port 587 for clients who must operate outgoing mail servers.

However, the advice about port 587 seems a little confused to my mind.

The solution for “clients who must operate outgoing mail servers”, presumably those who need to send direct-to-MX mail (operators of mailing list servers, for example), is for those customers to be allocated static IP addresses, with correct and useful reverse DNS records. Just putting machines on static addresses doesn’t make them less susceptible to trojans, of course.
But it does allow for some level of “reputation” heuristics, if only to allow others to adjust their filters and back/whitelists.

Port 587, specified in RFC2476 (back in 1998), concerns how clients submit to an authenticated relay. Not necessarily operating a outgoing mail server from within the ISP’s ranges (which I take to mean a machine that performs direct-to-MX SMTP delivery).

The concept has two major benefits – firstly by separating submission and relay/delivery it should simplify the configurations and operation of mail servers and also firewall configurations. At the client end it allows you to configure the mail software on a network roaming laptop to use the same outgoing mail server without having to worry about port 25 blocking.

And note that in some circumstances it is a requirement that people relay mail though a specific, external, mail server. Some regulations require that all business mail be auditable, and usually this means using the mail server to store a copy.

If you’re already running a mail server that requires SMTP Authentication then you should make it available on port 587 as well as (or instead of) port 25. So in terms of advice – it’s not the network providing ISPs that need to be talked to – it’s the third party providers of mail relaying services, it’s the providers of mail server software, and it’s the providers of mail client software.

The second group isn’t too much of a problem. Sendmail certainly supports port 587 though its MSA (Mail Submission Agent). And, since the only real difference in protocol terms between port 25 and port 587 is that port 587 traffic must require SMTP Auth, you can get away with running another server on the other port (if that’s possible) or, as a hack, just redirect port 587 traffic to port 25 on the same address.

It’s the client software that I’d expect to be problematic. Despite being a Standards Track RFC for six-and-a-half years, I’ve never really encountered much support in mail clients.

At best, I’ve seen clients that allow you to change the port number from a default of 25 – but nothing that acknowledges the “official” status of 587. Just as a test I’ve checked the configuration of Evolution, and it makes no reference to using alternative ports at all (although you can apparently suffix “:587″ to the host name for the same effect.

Ultimately, I guess you could set up some thing locally that listens on localhost port 25 and relays on to the remote server with SMTP Auth.

If blocking port 25 is going to work on a larger scale, people need to be submitting bug reports for the software that they’re using right now.

The email you receive is apparently from a lawyer based in your own country apparently representing the estate of a (recently deceased) rich relative. A scenario that would pique the interest of quite a few, I’d imagine.

The number of data points is pretty low – a surname and a country (probably generated based on the top-level-domain of the email address) in a simple mail merge. We probably haven’t reached a future where rogue AIs are crunching online genealogy resources and spidering FOAF files in order to actually impersonate your friends and family, but we’re a small step closer.

Obviously, the next great advance in the deception will come when one of the Nigerian scammers pays someone to actually proof-read their form letters.

I’ve reproduced the message below. The address given is that of an actual solicitors office, but given the weird extra line on the address, I’m guessing it’s pulled at random from a list of London solicitors addresses. The only other references I can find to the Gravens mail online are in a German blog entry and a recent consumer warning story on a US website. It looks like information about this varient was added to the wikipedia hivemind in April.

Gravens & Associates
37 Bedford Row
London
WC1R 4JH
DX 75 Chancery Lane
Phone:+44-704-0112915

Email:gravens_chamb1@fastermail.com
Dear YourSurname,  

With all sincerity my names is Mr.Vincent Gravens, a practicing financial attorney representing the late Mr.RandomFirstname YourSurname, my late client who died Recently leaving some estate funds Amounting(5.5million US Dollars)Five Million,Five Hundred Thousand Us Dollars deposited with his Finance House in Europe.Since he died, I have received from his Finance House, an order of MANDAMUS, mandating me to locate any of his relatives/confidant for purpose of Preparing them to receive ! the deposited sum.

However,The fund may be Donated to trust fund if there is no response to this Mandamus Within the period the Finance House permitted the search. I am currently in London and I decided to seek your collaboration in confidence. To permit me present you to the payment institution as the beneficiary/Next of kin to the deceased. There is evidence to back up our claims On presenting you as the Bonafide beneficiary to the fund.

All I require is your cooperation to work it out. I guarantee that this will be executed under a legitimate arrangement that will protect you and me from any breach of the law.Please reach me with your personal details. I will be sending you the transaction Detail of the transaction lmmediately. I repeat I have covered every legal side of the transaction.

Respond most urgent.I anticipate your urgent response to enable us meet the required date.

Please reply through this private email box

Email:gravens_chamb1@fastermail.com

Best regards,
Vincent Gravens

Anyway, to repeat the main problem with SPF: SPF validated using envelope sender addresses. This was good because it meant that validation an rejection could happen before accepting the email, but was bad because it meant that traditional mail forwarding (where the envelope sender is preserved) wouldn’t work. I wasn’t a fan of the proposed solution which involved sender rewriting.

I imagine, if this proposal goes through the IETF wringer, we’ll eventually end up with a standard SPF ESMTP extension being advertised and recognised by ”SPF2″ compliant mailservers. This will be the hook to communicate the additional information for dealing with forwards and bounces. Servers that do not advertise or recognise the extension would work as normal, and be candidates for a local whitelist.

Well, that’s similar to the Draft for the SUBMITTER extension which was submitted to the IETF in August.

SenderID, unlike SFP (or “SPF-Classic”) doesn’t validate the envelope sender, but rather attempts to determine the “responsible address” by accepting the email and parsing the header. This means that rejection can’t happen until after the email has been accepted, which is non-optimal. (And given the number of broken mailers out there that refuse to regard post-data rejections as fatal, just asking for trouble.)

The ESMTP extension allows the responsible address to be specified up-front by the submitter during transaction time, allowing for instant rejection (and then a second chance if the approved sender is not listed in the headers). I don’t know if there are any specific IP claims on this proposal, but since it’s just about the simplest and obvious ESMTP extension, I’d be surprised if there were.

Regardless of the SenderID scheme being adopted as a whole, I’d like to see this extension supported by not only the software for receiving mail, but also the software used in sending mail, just so that when the dust of the current disputes finally settle, the bulk of the infrastructure will be there.

Brickbats to the Slashdot monkeyboys who can somehow spin a positive antispam development into a Microsoft-is-evil story. Sigh.

NTK usually skirts close to the thresholds many filter systems – its invitation to unsubscribe, WHOLE LINE OF YELLING, the occasional IP addresses in a URL. Every week we get a handful of automatic mails from corporate email systems either accusing it of being spam or asking us to clean up the language and resend (far easier just to unsub the mollycoddled).

But this week we were in DNSBLs.

Not the listserver, that was fine. The machine that was listed was the first link in the chain. The PC the mail was sent from.

The normal focus for DNSBL/RBL schemes (at least historically) is to only be concerned with one IP address: the IP address of the machine connecting to an MX of the recipient’s domain, the last of the “untrusted” addresses. This model also assumes that PCs send their outgoing SMTP mail via a ”smarthost”, usually provided by their ISP. Indeed, sending mail via the smarthost is often recommended as the solution to those adversely affected by DNSBL listings.

This facility isn’t of much use to someone receiving mail via POP3, so some client-side mail scanners will pull the relevant IP addresses out of the headers in order to test them. SpamAssassin includes a variety of RCVD_IN_??? tests that are, apparently, applied to all IP addresses found the Received: headers and (I assume) treats them with equal suspicion.

I believe this “overloading” is dangerous when using traditional DNSBLs.

Dave sent out the mail from his home PC this week. His home PC is on a BT ADSL line. IP addresses for his ADSL provider (like many others) are dynamically allocated via DHCP. At some point, probably last week, a new DHCP lease was issued with a new IP address.

One of the previous users of this IP address, back in June, was operating an open proxy (possibly one that had been used for spamming). As a result it found itself on many blacklists. That an open proxy was listed isn’t, in itself, a bad thing (although I’m not too sure about lists of open proxies being kept indefinitely without re-testing) since in traditional DNSBL deployment only the listing of a smarthost will be expected to cause issues with legitimate mail.

SpamAssassin, however, provides extra opportunity for false positives that affect single senders, seemingly at random. Every mail, regardless of whether it is sent directly or via a smarthost, will probably contain a header containing the IP address of the PC. If that’s a DNSBL listed IP address, then that mail is tainted. And since it only affects a few at a time there’s no swell of complaints to the ISP to get things ”fixed”, just the potential for a few silently dropped mails (more in the case of mailing lists). And, for those that discover the problem before they are assigned a new address, a rude introduction to DNSBLs.

So every mail that got sent out from the NTK list server contained one Received: header containing a tainted IP address, and on some systems this was enough to push it into the threshold of spam (although setups, whitelists and scoring differs, so we can’t know how many subscribers this affected.)

Of course there are things that could be done to get around this: pre-process the mail headers to remove the offending headers, send mail from somewhere else, etc. But these don’t fix the problem, i.e. the same problem that’s probably going to affect a future user of this IP address, and those similarly affected.

And I imagine the address will still be in those DNSBLs for the foreseeable future. I looked into requesting removal on the various websites. Getting it removed from NJABL was painless. DSBL, however, requires that the removal request comes from the listed admin of the address. Their insistence on mail being read by abuse@ and postmaster@ would normally be commendable. But, lets face it, any process that requires mail to abuse@btopenworld.com to be read isn’t going to be completed. Especially if it only affects one bemused user at a time.

For anyone who uses dynamically allocated IP addresses my advice is to check it against OpenRBL. You probably won’t be able to do anything about it if it is, but at least you’ll have a heads up on potential problems.

For anyone using SpamAssassin, or other tools that do retrospective DNSBL lookups – please be aware of this when adjusting the scores. My simple philosophy is that if your anti-spam filter identifies non-spam as spam, then it’s your software that’s broken.

Modifying mail in an attempt to prevent your software from exposing its own shortcomings would be a disservice.

One correspondent questioned the validity of using SMS-spam as some indication that micropayment systems wouldn’t necessarily deter spam. It’s a fair point, I suppose. Message charges are set (and collected) by the sender’s service provider and can traverse to recipients on other networks. Bulk message senders are free to shop for the cheapest service provider and thus pay a fraction of the usual cost. Surely any charging system designed for email would feature negotiation (automatic or not) directly between the sender and the receiver?

Well, yes. A well thought-out proposal could feature this. But I don’t think you’d ever see it adopted. There’s a lot of discussion and a lot of proposals flying around, and I’m not au fait with them, but I haven’t seen anything to convince against the following:

• any widely deployed currency-based per-message charging will ultimately be set and collected by the sender’s service provider
• currency-based charging will never be successfully integrated into the existing global SMTP infrastructure

It’s not that I don’t think it’s technically feasible to implement a fair sender/receiver currency-based charging system globally, I just don’t think it’s politically feasible.

Imagine all the email you get in a day. Subtract all of the mailing list traffic. Subtract all of the mail that comes from addresses in your address book, addresses you have mailed, and addresses from which you have received legitimate mail from in the past. This is the mail that can be white-listed (ignoring the issue of spam infiltrating mailing lists for now). What you have left is the problem – probably 99% of it spam, and what’s left after that is legitimate “initial contact” mail from new addresses. The problem isn’t separating the spam from the mail, the problem is separating the “initial contact” mails from the spam.

(Yes, the ability to forge identities can reduce the effectiveness of a whitelist approach. The solution to that problem isn’t payment, but rather the adoption of signing. Public-key based message signing at the client side, TLS on the delivery side - where some use can eventually be made of certificates for authentication and trust relationships.)

You wouldn’t want your friends and contacts to be charged for the privilege of emailing you (well I wouldn’t), so that leaves the spam and the “initial” mails. The ideal charging level is that which doesn’t dissuade legitimate correspondence but does dissuade unwelcome commercial messages. Does such a level exist? I have no doubt that any cost barriers that are introduced will have a direct effect on the amount of unwanted commercial messages, but I don’t know that there’s a level that produces a neat line separating the two. I have always received more (paper) junk mail than normal mail, thankfully nowhere near the depressing ratio of spam to email,yet what value of postage stamp would dissuade me from, say, informing a random webmaster of a minor mistake on their site?

I consider the idea that some middle-ground would thrive – that, for example, busy executives would charge large amounts to receive email - to be fanciful. It’s usually the fear of the odd overlooked gem that has rendered anti-spam techniques impotent. A salutation from a long lost friend with the subject “Hi”, an important business mail sent out-of-hours from the kid’s computer, that domain renewal reminder. Most people would apply no charge on the things they want to read, and a bajillion dollars on spam. And if there’s mail you don’t want to read but have to? Chances are you’re being paid to read them already – get back to work.

So if you price too high for the spammers, no money changes hands. And if you set a price of nothing for your friends, no money changes hands. Whoa, hold on! To the Internet Service Providers this is a potential Critical Revenue Source. If they’re going to have to develop and deploy these system  (assuming they aren’t out-of-band charging systems) their slice of the pie is going to have to be worth something.

In fact, why wouldn’t it be their pie? Why can’t your Service Provider bill for email like the phone company bills for calls, or SMS messages. An analog to the phone company, while possibly flawed in the network sense, is clear. It’s their systems that will be handling the mail, their systems that will likely negotiate the financial transactions, and it’s they who receive the complaints when things go wrong. If anyone’s going to benefit from email charges it’s going to be them. And while we’re at it, why would charges be the ”nominal” amounts that proposals promise. Why wouldn’t they be whatever the market will accept (which will be some point between significant and insignificant – more that nominal by definition).

It’s often said of phone companies that it costs them more to bill for a call than it does to facilitate it. I can guarantee that will be the case, many times over, for email.

One of the effects of the big players arriving late to the email party is that, while it’s difficult for any of them to unilaterally dictate the community’s technical standards, it’s easy for them to stymie the adoption of new ones. If your proposal doesn’t sit well with the big boys, the likes of Microsoft (Hotmail) and AOL, it doesn’t stand a chance of being adopted in any useful sense.

And if email is left to continue it’s dissent into a cesspool of spam and Windows viruses? Well, it’ll still be to the likes Microsoft whom the world will come begging for an alternative.

If you want an rough idea what a replacement for email might look like, keep an eye on the IM networks over the next couple of years. On the one hand is what I would consider the ”traditional” approach to Internet services, favoured by Jabber, of decentralisation and open standards. On the other hand is the commercial approach of MSN, AOL, and Yahoo: proprietary protocols, user lock-in, software lock-in, and possible advertising or subscription revenue. As far as I know there’s no way to send messages between these commercial networks. Currently the best solution is a single application managing multiple separate accounts, but – when these networks begin to monetise – these temporary freedoms may prove short lived.

But maybe we won’t see this in email. Maybe the infrastructure won’t be built for the benefit of the big commercial players. Maybe a payment infrastructure would be built that, if it actually worked, would hardly ever be used.

I can’t see the world’s tax-men ignoring this for long.

While the frequent warnings about impending email taxes are usually variations on a long running hoax, it doesn’t mean that government bodies haven’t seriously considered it (especially in Europe). As recently as 1999 the UN proposed an email tax purely as a way of generating revenue (in this case for third world infrastructure development). I imagine it was mainly the lack of suitable infrastructure coupled with widespread suspicion of Government meddling in an emerging industry that eventually shelves these ideas.

Back in the mid-nineties the Canadian economist Arthur Cordell was proposing a “bit tax” of .000001 cents/bit. This might sound reasonable if you work out how much that is per email, but at the time I remember working out that (even if you were to discount the data used for routing and transmission control) the network delivery of a single MPEG-2 encoded 2-hour movie would accrue around $300 in tax. There’s clearly no direct correlation between bits and “value” – a single floppy disk’s worth of text can be more valuable than the bulk of Charlie Sheen’s filmography.

Emails are attractive as taxable electronic “items”. There’s still the potential for growth (especially in a spam-free environment), a fairly consistent idea of what a single email message is, and there’s usually some level of personal or commercial value in them that make sub-penny level taxes seem insignificant. And now, thanks to spam, tax proposals can now be dressed up as positive measures to benefit users.

When you introduce money into a system you’ll end up attempting to implement a solution that, as well as dealing with the primary problem of spam, also has to satisfy a host of conflicting secondary agendas. This is why I don’t think we’ll see currency based-charging in SMTP the resistance to change would be too great. And, I expect any proposed commercial replacement for SMTP/RFC-standard based email systems will incorporate charging from day one. And I don’t expect users to adopt them at anywhere near the penetration of current email.

But what of other “payment” schemes, ones that rely on non-currency based charging? Certainly, I think they’ve got more chance of adoption than money-based charges, but I’m not convinced yet. I’ll probably address these in a future submission.

Head of the Direct Marketing Association’s interactive media division, Robert Dirskovski, said its Email Marketing Council had been discussing the possibility of introducing a white list solution.

This would list those who are entitled to send email, and would be regulated by ISPs and/or a government agency.

Now obviously the juicy combination of “government agency” and “those who are entitled to send email” tends to set-off whatever the libertarian version of spider-sense is. But more likely, it’s going to be another piece of “industry self-regulation” designed to avoid government intervention.

Now, I don’t know what the Email Marketing Council have been discussing, but I’d speculate that most practical and likely approach is going to be running a public DNSDB. I imagine the plan would work like this:

• The DMA sets up their own whitelist zone, in a similar fashion
  to any DNSBL/RBL. But the zone lists approved IP addresses.
• DMA members who agree to a specific code-of-practice
  have their outgoing IP addresses added to this zone. In theory, you could use the domain of the envelope sender, but at the moment that approach invites forgeries.
• ISPs in the UK are persuaded to configure mail filtering (if such filtering exists) to use the zone as a whitelist. (I believe configuration for whitelist DNSDB is possible in most of the major MTA systems, at least the Unix ones, as well as some personal filtering software such as SpamAssassin.)
• Rather than being subject to instant fines as with the Bonded Sender system, they would likely be subjected to some DMA internal wrist-slapping procedure. Of course abusers would still be subject to the relevant government regulations, so hopefully it’ll still be in the best interests of the DMA to be seen to be keeping it’s own house clean.
• Remaining UK ISPs that continue to block “legitimate” mail from whitelisted IP addresses can be targeted by charm before they start making complaints (unfair restraint of trade?).

If this is what happens then I’d view it as a broadly positive move. Believe it or not, there are lists (commercial or not) who despite being careful in ensuring confirmed opt-in subscriptions still get accused of spamming by (usually) automated systems. While it doesn’t stop the non-stop spew of common-variety spam it does attempt to cover a major issue caused by spam: false-positive blocking of legitimate commercial email, and a provides stick-shaped carrot to deter legitimate organisations from adopting illegitimate marketing practices.

The main danger may come from putting to much control in the hands of those administrating the lists (a problem that has tarnished the reputations of blacklists when abuse of this power is perceived to have occurred). But, providing there’s no government-mandated use of the lists, the ability of ISPs to boycott the list, or use alternatives, should keep it useful.

At the very least, it might provide a catalyst for further DNSDB whitelist use. Shared whitelists are the the yang to the shared blacklist yin, in my opinion only a combination of the two can provide the right balance.

You can’t usually tell just by looking at an address if it is used for business, personal use, or both. Or if the usage has changed (a corporate address for an ex-employee forwarding to a personal account). I expect that UK spammers will initially make a “good faith” attempt at distinguishing between them – by just assuming that all addresses are used for business unless they’re specifically informed otherwise.

If so, this will probably lead to what anti-spam activists have been trying to avoid – a registry of UK personal e-mail addresses. In other words a TPS-style ”opt-out” system through the back door (essentially, a victory for the Direct Marketing agenda).

But why should private users be forced to disclose their private details? Wouldn’t it be easier to establish a registry of business email addresses?
Companies already have to register a postal address with Companies House. Each company would be forced to have at least one registered email address (businesses that have no access to email could make a declaration as such) and these would be considered “fair game” for unsolicited marketing.

This would get around the privacy/DPA issues of databases of personal email addresses. It also solves the problem of defining what a UK email address is (the physical location of the primary MX or the reader?).
It’s not an ideal solution – thousands of people will still be sorting the wheat from the chaff – but apparently when it comes to trade regulations, you can’t save everyone.

Also I note that the DTI definition of spam appears to have been modified from the normal definition to append a DMA appeasement:

Spam is unsolicited commercial e-mail sent without the consent of the addressee and without any attempt at targeting recipients who are likely to be interested in its contents.

This removes the notion of “bulk” mail and replaces it with something
that can be (and probably is) “bulk”. So if you receive unsolicited commercial e-mail where some attempt has be made to target you, it isn’t spam. Although I think it’s still covered by the regulations.