The real cost of spam

Spam costs a lot: to us regular users. A nice article about the cost we have to pay in order to defend against spam.

The cost vectors (according to the article):

– antispam technology

Most companies deploy additional servers to filter spam. Some also buy commercial software to perform spam filtering. It needs staff to manage it, and all of these costs money.

– lost productivity

Spam wastes your time. It needs some attention to handle it. Note that “deleting messages, however, turns out to be the most expensive spam strategy. The average employee at companies that delete spam messages loses an average of 7.3 minutes per week looking for lost legitimate messages.”

– wasted storage

A usual method is to move spam emails to a quarantine. It consumes disk space, so you need additional storage capacity, and enterprise grade storage still costs.

– intangible costs

“Spam has a broader economic impact as well, hitting many businesses and nations that are least able to bear the burden. Consider Nigeria, for example. Nucleus Research noted that while fraud and corruption have been rampant in Nigeria for some time, the country may be forever kept in the digital darkness because of the volume of deceptive email sent by local spammers. The research firm noted that most spam filters block any mail with “Nigeria” in the title or text, effectively keeping anyone communicating with, from, to or about Nigeria from doing it via email.”

Deploying CoreOS OVA on VMware

Deploy the vmware ova

Download the OVA image from Core OS website, and deploy it to VMware using vsphere client, etc.

When you boot the VM, you won’t be able to login, unless you provide coreos.autologin=tty1 as a kernel parameter to grub. If you do so, then you’ll be auto logged in as user core. Type sudo bash to get the root prompt necessary for the initial setup.


Configure networking

Create /etc/systemd/network/, add the following, and finally reboot:



Setup ssh acccess

Edit /usr/share/oem/cloud-config.yml, and add your ssh public key, eg.

- ssh-dss AAAAB3NzaC1kc3MAAAEBAOm5s8yJIl1ZnaqQU93f.....

Then validate the settings:

coreos-cloudinit --validate --from-file /usr/share/oem/cloud-config.yml

If everything goes right, then apply settings:

coreos-cloudinit --from-file /usr/share/oem/cloud-config.yml

Now you may ssh to the host using your private ssh key as user core, eg.

ssh -i /path/to/ssh.key -l core

You may want to setup etcd (version 2)

# generate a new token for each unique cluster from
# specify the initial size of your cluster with ?size=X

# multi-region and multi-cloud deployments need to use $public_ipv4
# listen on both the official ports and the legacy ports
# legacy ports can be omitted if your application doesn't depend on them

Recommended reading:

Cloud config docs
Using CoreOS

Pár érdekesség stub-okat használó email archívumból migrálás során

Chris McVeen írása Addressing Email Archive Shortcuts/Stubs when Migrating címmel, ami néhány váratlan meglepire készít fel, hogy ha migrálni akarsz egy olyan email archívumból, ami stub-okat (=pointerek a levélből kivágott és máshol található mellékletekre) használ.

A migráció során ezeket a stub-okat helyre kell állítani. Az egyik ilyen gotcha a művelet során az, hogy pl. a Microsoft Exchange egy új Message-ID-t fog generálni, ha letörlöd a stub-ot tartalmazó levelet, majd lecseréled a helyreállított levéllel. Az új Message-ID pedig gondot okozhat a levelezőklienseknél. Ennél jobb a stub rehidratálás, amelynek során nem törlöd az archivált levelet, hanem a stubbing során eltávolított adatokat helyreállítod. Ebben az esetben megmarad az eredeti Message-ID.