Subject: IPv6 email reflector

From: Bob Van Zant <[email-masked]>
Date: Tue, 13 Jul 2010 19:09:47 -0700

I setup a reflector a few weeks ago that helps email users identify
whether or not they're sending over IPv6 and also clues them in to
what their DNS looks like from the outside world.

To use it simply send an empty email to [email-masked]

It'll reply to the email showing you the Received headers as well as
dig -t mx output for your domain.

Nothing too terribly fancy. Feel free to provide feedback or
enhancement requests. Use it but please don't abuse it :-).

-Bob

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 14 Jul 2010 08:56:31 +0200

> enhancement requests. Use it but please don't abuse it :-).

Congratulations, you have just set up an automatic spammer for the
millions of spammers out there, they spam you, and you spam back the
spoofed email address.

You do realize that this email list is nicely indexed all around the
world I hope and that spammers can easily also read the above email address?

People who configure mail servers can check the log files of their mail
servers.

Others can when sending mail to another person, just ask that person to
cut&paste the headers back and hey, presto you know which parts went
over IPv6 or not.

Greets,
 Jeroen

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 14 Jul 2010 09:48:21 +0200 (CEST)

> millions of spammers out there, they spam you, and you spam back the 

Well, actually as far as I could see the email one gets back doesn't 
really contain any subject/body from the original email, so the use for 
spammers is limited (?).

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 14 Jul 2010 09:54:58 +0200

> really contain any subject/body from the original email, so the use for

It is another mail in your mailbox that should not be there in the first
place.

Same issue as with DSNs, mails should be rejected at DATA time so that
the sending SMTP server has the handle the issue, not by the receiving
SMTP server which then accepts it and then decided it doesn't want it.

Greets,
 Jeroen

---

From: Fred Baker <[email-masked]>
Date: Wed, 14 Jul 2010 07:13:55 -0400

I guess Jeroen's point is that you would do well to apply some form of policy to it, such as not responding to blacklisted addresses.

Although at this point I would guess that there are not a lot of IPv6 Bots (that will come, but is not status quo today); having this available would probably encourage their development :-)

> enhancement requests. Use it but please don't abuse it :-).

http://www.ipinc.net/IPv4.GIF

---

From: Fred Baker <[email-masked]>
Date: Wed, 14 Jul 2010 07:10:53 -0400

Well, I would agree, but there are issues. The receiver often cannot make that determination without having first received the email, in order to check its DKIM signature or apply content heuristics. It is possible to null route identified bots at the network layer, to reject their sending attempt by RST'ing the TCP connection that it opens, or to do the equivalent with their SMTP connection, but only before the email has been transferred. The only information that can be done on is the unverified email address of the sender (in SMTP) or the IP address of the device sending it. That's not a lot of information.

What Ironport and other spam management devices do is filter out spam in a trusted intermediary. That fails to leave the problem at the bot, but it does prevent the user from having to do it. The issue there is false positives and false negatives. Cisco tells me that upwards of 95% of email directed toward me is dropped by Ironport, meaning that I only deal with a daily average of about 60/day, the majority of which is dealt with by my Beysian filter. I can check for false positives or negatives there, but cannot in traffic dropped by Ironport.

What is it about this conversation that seems two layers higher than IPv6? :-)

---

From: Philip Homburg <[email-masked]>
Date: Wed, 14 Jul 2010 13:25:53 +0200

>SMTP server which then accepts it and then decided it doesn't want it.

I think it is better use of terminology to distinguish between spam and
back-scatter.

The reason is that spam is done on purpose, and back-scatter is incidental.
And that leads to a different security analysis.

So I can imagine that with some precautions, like rate limiting the output of
the reflector to prevent DoS attacks, and some requirements on the request
(to prevent back-scatter) the reflector may be quite safe to run.

---

From: Bob Van Zant <[email-masked]>
Date: Wed, 14 Jul 2010 08:45:22 -0700

Thanks for your feedback, Jeroen. There were 3 main security threats
that I tried to address when setting this up:

1. Someone overloading my MTA
2. Someone finding a way to turn it into an open relay
3. People getting blasted with backscatter

Realistically there's not a lot I can do to avoid someone overloading
my MTA. I have very stringent throttling in place on this machine but
a distributed attack would put those defenses to shame. In any case
this affects only me.

The box simply isn't an open relay. We've known for a long time how to
avoid creating an open relay and this simply isn't an open relay.

This leaves backscatter as the primary concern. As others have pointed
out no spammer is going to use this machine as the starting point for
a spam campaign. It completely throws away the original email leaving
nothing of value for the spammer. The most likely scenario is that the
reflector email address gets scraped from mailing list archives like
these ones and is then used as the recipient of a spam campaign.
Spammers rarely use their own email address in the mail from and so,
yes, that forged sender would receive backscatter. The defenses in
place here are numerous. The outermost MTA in this setup is an
IronPort appliance and for this particular address the settings are
dialed way down to prevent abuse. Both IP reputation and content-based
spam scanning (and virus scanning) are applied and any hint of spam is
simply discarded. Even people with good IP reputation are severely
limited in the number of tests they can run.

Add all of this to the fact that I'm continually monitoring the use of
the system to look for signs of abuse. It's my IP address' reputation
on the line and I even put my email address into the body of the reply
message.

At the end of the day I think it provides a valuable service for folks
trying to setup IPv6 email. I hope others will as well.

-Bob

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 14 Jul 2010 17:03:56 -0700

On 7/14/10 4:13 AM, Fred Baker wrote:
> I guess Jeroen's point is that you would do well to apply some form
> of policy to it, such as not responding to blacklisted addresses.
>
> Although at this point I would guess that there are not a lot of IPv6
> Bots (that will come, but is not status quo today); having this
> available would probably encourage their development :-)

we get plenty of spam over v6. windows machines with terredo or 6to4 are 
pretty flexible when it comes to protocol selection.

>> I setup a reflector a few weeks ago that helps email users
>> identify whether or not they're sending over IPv6 and also clues
>> them in to what their DNS looks like from the outside world.
>>
>> It'll reply to the email showing you the Received headers as well
>> as dig -t mx output for your domain.
>>