My Short Life As An Unintentional Porn Spammer

Freerange writes "Mike Masnick wrote up his experience getting slammed by a somewhat new kind of spam attack that doesn't get much hype (yet?). A spammer spoofed his personal email address as the 'reply-to' for a batch of spam, with interesting results for Mike: "I can now answer the questions 'who replies to spam?' and (should anyone ever wonder) 'what are the hundreds of variations on bounced messages?'" From Politech."

Comments

It's nothing new

[Anonymous Coward]

It's referred to as a "Joe Job" or that you've been "joe jobbed"

an article about it

Re:No way to contact spammer

[wobblie]

Some spams are purely for confirmation that your email address works. I repeatedly see spams which have 1x1 pixel gif's that link to a script to call the image and pass your email address off to that script. Biggest reason not to use HTML mail.

Re:Why?

[Neon Spiral Injector]

Hanging out on some anti-spam news groups I've seen this happen to people who go after spammers. In this case the spammer quite intentionally selects the FROM: address to make the bounces and irrate replies cause trouble for someone who has been causing trouble for the spammer. This is called a "Joe-job".

Re:Why?

[Fluffy the Cat]

In general, it's not a good idea to accept mail unless you think you can correctly generate a bounce message if you fail to deliver it. As a result, many mail servers will refuse to accept mail if the

MAIL FROM:

section of the SMTP exchange doesn't include a domain that exists. Some will go further and do some checks to see if the localpart exists, too. If the spammers want to get to as many addresses as possible, they have to use a real address rather than a made up one. In some cases, they'll pick the address of someone who's irritated them (anti-spammers, for instance).

New Mail RFC

[Ayanami Rei]

You mean like this?

RFC 2487: SMTP Service Extension for Secure SMTP over TLS.

SMTP [RFC-821] servers and clients normally communicate in the clear over the Internet.... Further, there is often a desire for two SMTP agents to be able to authenticate each others' identities. For example, a secure SMTP server might only allow communications from other SMTP agents it knows, or it might act differently for messages received from an agent it knows than from one it doesn't know.