Tag: email

Posted on
by

Following up on the PayPal anti-phishing discussion of a few weeks ago, I see that PayPal is promoting a service called Iconix. You install the program on your system, and it looks at your inbox for messages that claim to be from one of its customers. It tries to verify them “using industry-standard authentication technologies such as Sender ID and DomainKeys.” Messages that pass get a lock-and-checkbox icon attached to the sender’s name, and in some cases the name is replaced by the sender’s logo.

On the tech side, it’s similar to SpamAssassin’s whitelist_from_spf and whitelist_from_dkim features. Both allow you to specify a sender to whitelist, and it will only give a message special treatment if it can verify the sender.

On the user-interface side, it’s similar to EC certificates, in that it tries to highlight a “good” class of messages rather than flag or filter out a “bad” class.

It’s not a bad idea, actually, and now that I’m surprised I haven’t seen something similar in other email clients. It’s sort of like setting up custom rings or images for images on your cell phone address book

They seem to be focused on webmail and Outlook so far, and only on Windows, but it looks like the perfect candidate for a Thunderbird extension. They do have a sign-up form to notify you when they add support for various programs and OSes, and I was pleased to see not only Thunderbird and Mac OS listed, but Linux as well. Too often, Linux gets forgotten in the shuffle to ensure compatibility with every Windows variation.

Posted on
by

I found a 419 scam in the spamtraps that started, in typical fashion, with an all-caps name and address, then the line:

HIGHLY CONFIDENTIAL REQUESTING

What made this funny (aside from the bad grammar) was the fact that the To: line contained over 1,200 addresses!

Ah, this is obviously some strange use of the word confidential that I wasn’t previously aware of!

Posted on
by

Here’s a piece of friendly advice from a mail server admin to companies that interact with subscribers and customers via email:

Pick one domain name for your business. Just one. Don’t use any other domains in your emails, even if you want to keep order confirmations separate from promotions. If you contract out for some other company to send out a newsletter or survey to your customers, insist that they send it out using your own domain name. If you’re using DomainKeys or SPF, make sure they’re authorized or send it yourself. And don’t even think of making the links through redirection scripts, even if you really want to track which subscribers are clicking.

Why?

Two words: Spam and fraud. Continue reading →

Posted on
by

In the old days, we used to accept email sent to any local account. This meant that various system accounts would collect outside mail instead of bouncing it. No one was reading, say, rpm@example.com, or apache@example.com, but the mailboxes were there.

Enter the dictionary attacks. An awful lot of those standard accounts are three-letter names—rpm, gdm, bin, adm, etc. Spammers trying to guess addresses made up of three initials landed on these addresses, confirmed them, and added them to their lists. The system accounts began collecting spam.

Eventually we locked things down so that only “real” accounts would accept mail from outside. But here was this steady stream of 100% spam we could use to help train our filters.

The funny thing: these days, nearly all of it is for sex-related drugs or body part enlargements. Sent to software!

(Incidentally, if you can read this sentence, don’t send mail to ramblo@hyperborea.org.)

Posted on
by

A brief history:

  1. Spammers send mail directly to victims.
  2. Server admins block by source, victims complain and try to get spammers kicked off their networks.
  3. Spammers relay through third-party servers to disguise their origin.
  4. Server admins shut close relays, and block mail from open relays.
  5. Spammers relay through trojaned zombies straight to victims.
  6. Network admins block outgoing mail traffic except through their servers.
  7. Spammers relay through zombies’ ISPs’ mail servers.
  8. ????

We’re in the early stages of step 6, with broadband ISPs starting to block outgoing direct-to-MX mail traffic. The obvious response by spammers is, of course, Continue reading →