Wandering Thoughts archives


Why 'sender stores message' is easier for spammers than real mail servers

In my first entry on 'sender stores message' schemes for email, I asserted that spammers would have no problem making sure that their servers are not crushed under the load of everyone trying to read the spam email from them, yet in SenderStorageProblems I said that real mail senders would have such problems. The difference is that the two groups have very different problems, and the spammers can cheat. Let's look at what the two look like.

Real mail servers of any significant size will be dealing with tens of thousands of messages (or more) amounting to tens to hundreds of gigabytes in total size. Many of those messages will be read only a few times each, but they may be called for at random times, possibly quite a long time after they're sent. And the mail server must reliably store and serve these messages when asked, never confusing one for another.

(This does point out the tricky issue of when a 'sender stores message' mail server gets to delete the stored message, if ever.)

The mail servers of anyone sending bulk email have a very different usage pattern. They will likely be dealing with only a few hundred or a few thousand unique messages, quite possibly ones that can be synthesized on the fly from relatively compact information; the total unique storage needed is likely to be modest, and will probably fit in RAM on a decent server. These messages do not have to live very long, probably a few weeks at most, and it's not a tragedy if things are less than perfectly reliable.

Even if spammers serve static messages instead of creating them on the fly, the problem of serving a hundred or a thousand relatively small files to people is much different and rather easier than the problem of serving tens or hundreds of thousands of files, some of them quite big, to the same number of people. One hard bound is that reading random things from disk has an intrinsic speed limit; you get around 100 random IOs per second per disk that you have, and this is not increasing very fast (or cheaply).

spam/SenderStorageHelpsSpammers written at 02:52:29; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.