Subject: [v6ops] IPv6-only SMTP delivery?

From: Ray Hunter <[email-masked]>
Date: Sat, 09 Jul 2011 08:41:38 +0200

Yes IPv6-only SMTP delivery should be discussed.

One current potential showstopper for enabling IPv6 SMTP is the lack of 
many operational IPv6 DNSxLs.
Only one I know of is http://virbl.bit.nl/index.php#ipv6 If you know of 
others, please yell.

Another problem in my view is that current DNSxLs generally rely on the 
scarcity of IPv4 addresses to encode return values including an implicit 
IPv4 /32 prefix length.

Section 2.4 of RFC5782 suggests encoding results for IPv6 queries in the 
same way as IPv4 results.

However, quoting RFC5782: "If a DNSxL is represented using traditional 
zone files and wildcards, there is no way to specify the length of the 
name that a wildcard matches, so wildcard names would indeed be 
ambiguous for DNSxLs served in that fashion."

Can anyone clarify how you'd encode a response for indicating use of a 
filter for an IPv6 /48 or larger, as opposed to a fixed IPv6 /64 prefix 
length filter assumed in the Virbl implementation?

If not, I think the current RFC 5782 mechanism perhaps needs expanding 
to include an explicit prefix length for encoding IPv6 related 
responses. IMHO an implicit IPv6 /128 or IPv6 /64 prefix length in IPv6 
response encoding is inadequate for long-term smooth operation of an 
IPv6 DNSxL, as many spamming machines will probably gain access to very 
large numbers of potential source addresses way beyond a single /64.

regards,
RayH

> Subject:
> [v6ops] IPv6-only SMTP delivery?
> From:
> Ted Lemon <[email-masked]>
> Date:
> Fri, 8 Jul 2011 17:02:04 -0400
>
> To:
> "[email-masked] Operations" <[email-masked]>
>
> Content-Transfer-Encoding:
> quoted-printable
> Precedence:
> list
> MIME-Version:
> 1.0 (Apple Message framework v1242)
> Message-ID:
> <[email-masked]>
> Content-Type:
> text/plain; charset="us-ascii"
> Message:
> 1
>
>
> Maybe this is a dumb question, but it occurred to me today to check to see if it's possible to receive mail from IPv6-enabled servers if your MX record points to a name with a valid AAAA but no A record.   Although I had no trouble delivering the mail to my mail server using a telnet session over IPv6, when I tried to send mail the usual way it bounced.   One MTA gave me this:
>
> <[email-masked]>: host other.example.com[10.20.30.40] said: 550 MX
>   record points to an invalid IP for domain:my.example.com - usmtp (in reply to
>   RCPT TO command)
>
> When I tried to send the mail from gmail, I got no bounce, but the mail hasn't arrived after several hours, so I think it's safe to assume it's not going to.
>
> I'd never thought to look into this issue before, so I suppose it's possible that I'm missing some RFC that says SMTP is only supported for now on dual-stack and v4-only devices, not on v6-only devices, but it seems unlikely to me.
>
> So what's going on here?   Are people disabling delivery over IPv6 for operational reasons, or are the implementations broken? Is this something we ought to be talking about?
>
>

---

From: Mark Andrews <[email-masked]>
Date: Sat, 09 Jul 2011 17:21:12 +1000

> large numbers of potential source addresses way beyond a single /64.

Well the simple way is to take advantage of the structure and that
NXDOMAIN does indicate that there are no children then start at the
/32 reverse and expand out a nibble at a time until you get data
or NXDOMAIN.

	x.x.x.x.x.x.x.x.bl.example.com  TXT "this isp is a spam haven"
	x.x.x.x.x.x.x.x.bl.example.com  A 127.0.0.2

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Erik Kline <[email-masked]>
Date: Sat, 9 Jul 2011 16:35:41 +0900

Maybe an APL RR could be included in the response (with a sanity check
that the IP address looked up must be within the APL RR).  The A
record could still hold the "return value", while the APL would
indicate how broadly it applies, as far as that DNSxL is concerned.

    http://tools.ietf.org/html/rfc3123

But I am not well versed in counter-spam techniques nor theories of
operation even.

---

From: Ray Hunter <[email-masked]>
Date: Sat, 09 Jul 2011 09:40:49 +0200

OK, AFAIK Section 2.4 of RFC 5782 suggests encoding IPv6 as RFC3596 
ip6.arpa, so each nibble in an IPv6 would be one octet.

So assuming your use case for DNSxL was you wanted to start at /128 as a 
max length prefix (deny one host) and /32 as a shortest length prefix 
(deny corporation), in the worst case that'd generate look ups for  /128 
/120 /112 /104 /96 /88 /72 /64 /56 /48 /40 /32 /24 at which point you'd 
get no response => 13 lookups.

If you assume something more reasonable like /64 as a max length and /32 
as a minimum (although that could be debatable depending on your use 
case) that'd still be 6 DNS lookups for one source.

Seems like a candidate for creating some sort of packet amplification 
attack to me.

Isn't there a better way of somehow including the prefix length into the 
encoding of the first reply, or sending two replies, one with old format 
and one new? At first read I like Eric's suggestion based on RFC3123 
better, although I certainly admit this is not my core competence area.

regards,
RayH

Mark Andrews wrote:
> In message<[email-masked]>, Ray Hunter writes:
>

---

From: Keith Moore <[email-masked]>
Date: Sat, 9 Jul 2011 08:05:20 -0400

On Jul 9, 2011, at 2:41 AM, Ray Hunter wrote:

> Another problem in my view is that current DNSxLs generally rely on the scarcity of IPv4 addresses to encode return values including an implicit IPv4 /32 prefix length.

More broadly, the ease with which a v6 host can be address agile means that a reputation based on an IPv6 address is of dubious value.  Spammers can be expected to change source addresses frequently.  

You could associate reputation with an address prefix of /64 or less length.  But that would no longer isolate a bad reputation to individual hosts.

Keith

---

From: Ray Hunter <[email-masked]>
Date: Sat, 09 Jul 2011 15:37:00 +0200

Thanks. I entirely agree with you that address based mechanisms could be 
of dubious value. Same same for existing IPv4 based DNSxl mechanisms, 
due to extensive use of NAT and with CGN on its way.

But putting that discussion aside for a moment, simple DNSxl tools save 
me processing well over 90%+ of incoming spam today as early as possible 
in the transfer (even before the DATA command), whilst applying other 
more resource-intensive techniques on the remainder.

So what other mechanisms exist to share/key information on reputation today?

And being pragmatic, if it turns out not to be dubious to filter based 
on IPv6 address block information (because ISPs do deploy decent ingress 
filtering in their IPv6 operations), what's the harm in ensuring that 
the existing reputation sharing mechanism is already updated and tested 
and able to efficiently handle variable length IPv6 prefixes long before 
that's really needed in production?

regards,
RayH

---

From: Keith Moore <[email-masked]>
Date: Sat, 9 Jul 2011 09:59:11 -0400

On Jul 9, 2011, at 9:37 AM, Ray Hunter wrote:

> Thanks. I entirely agree with you that address based mechanisms could be of dubious value. Same same for existing IPv4 based DNSxl mechanisms, due to extensive use of NAT and with CGN on its way.
> 
> But putting that discussion aside for a moment, simple DNSxl tools save me processing well over 90%+ of incoming spam today as early as possible in the transfer (even before the DATA command), whilst applying other more resource-intensive techniques on the remainder.

Saving 90% of CPU-intensive processing sounds impressive, though as you hint, that begs the question of how many of the messages blocked in that way were really spam.  I suggest that v6ops not go there.  There has been plenty of discussion already on spam-related groups and it's been going on, quite intensively, for many years, without any significant contribution to the problem IMO.

> So what other mechanisms exist to share/key information on reputation today?

Honestly I'm not sure that there is such a mechanism today.  Of all of the tokens that could be associated with a reputation, IP address (though quite dubious already and increasingly moreso) is by far the best - where "best" means "most reliably associated with a host or user and most difficult to forge or obtain an ephemeral token".  Of course, there isn't much IPv6 mail traffic today, so maybe it's not a problem yet.

I'm thinking that maybe what is needed is some sort of reputation identifier that's difficult to forge - maybe something based on a difficult computation.   Maybe there could be an SMTP extension to support it.   Again, it's not a topic for v6ops, but maybe the smtpext list.  Maybe IPv6 will be enough of an incentive to get people to want to do something new in this space.

> And being pragmatic, if it turns out not to be dubious to filter based on IPv6 address block information (because ISPs do deploy decent ingress filtering in their IPv6 operations), what's the harm in ensuring that the existing reputation sharing mechanism is already updated and tested and able to efficiently handle variable length IPv6 prefixes long before that's really needed in production?

The problem is collateral damage.  If you associate reputation with an address block, and a single host in that address block gets compromised, all of the mail from that address block falls on the floor at any MTA that trusts that DNSBL.

Keith

---

From: Philip Homburg <[email-masked]>
Date: Sat, 09 Jul 2011 23:25:46 +0200

In your letter dated Sat, 9 Jul 2011 08:05:20 -0400 you wrote:
>More broadly, the ease with which a v6 host can be address agile means that a 
>reputation based on an IPv6 address is of dubious value.  Spammers can be expe
>cted to change source addresses frequently.  
>
>You could associate reputation with an address prefix of /64 or less length.  
>But that would no longer isolate a bad reputation to individual hosts.

What could be done (but I requires experimenting to see if it works in
practice) is to query first for a /64 and then for the /128. 

By default put addresses in the /128 list. If the spammer is trying to
evade that list then add an entry to the /64 list.

There is also a proposal out somewhere to encode DNSBLs as some sort of
B-tree. Sounds a bit too complex to me, but maybe that is what will be
required eventually.

---

From: Erik Kline <[email-masked]>
Date: Sun, 10 Jul 2011 09:31:14 +0900

> B-tree. Sounds a bit too complex to me, but maybe that is what will be

    http://tools.ietf.org/html/draft-levine-iprangepub

---

From: Keith Moore <[email-masked]>
Date: Sat, 9 Jul 2011 22:03:02 -0400

> evade that list then add an entry to the /64 list.

Interesting idea.  I'm wondering if each contribution to the /128 list within a /64 should count slightly against the reputation of the /64.  So if there's a spammer or a compromised host using lots of addresses within a /64, the reputation of that /64 will quickly degrade.  But if there are only a small number of hosts within a /64 with a bad reputation, it won't affect the others.

Figuring out what the threshold should be would be an interesting exercise.  Problem is, some /64s will be denser than others.

Keith

---

From: Vishwas Manral <[email-masked]>
Date: Sat, 9 Jul 2011 19:30:42 -0700

Hi Kieth,

> Interesting idea.  I'm wondering if each contribution to the /128 list
within
> a /64 should count slightly against the reputation of the /64.  So if
there's
> a spammer or a compromised host using lots of addresses within a /64,
> the reputation of that /64 will quickly degrade.  But if there are only a
> small number of hosts within a /64 with a bad reputation, it won't affect
> the others.
>
> Figuring out what the threshold should be would be an interesting
> exercise.  Problem is, some /64s will be denser than others.
This is exactly what the virbl project does. If it finds more then 5 in the
same /64, the entire /64 is blacklisted.

-Vishwas

---

From: Roger Jørgensen <[email-masked]>
Date: Sun, 10 Jul 2011 11:24:04 +0200

On Sun, Jul 10, 2011 at 4:03 AM, Keith Moore <[email-masked]> wrote:
<snip>
> Figuring out what the threshold should be would be an interesting exercise.  Problem is, some /64s will be denser than others.

Blocking an entire /64 is probably not that harmful, what are the
chance that a real SMTP server will be in a /64 with a lot of other
clients/servers?

What I'm trying to say, we can assume a /64 is a LAN (most of the
time) and if you block it you will either
a.) block all SMTP server for an ISP, if they are sending out spam
then they have issues anyway.
b.) block a client LAN, this will hurt some real SMTP traffic but in
99,9% (my wild guess) this is not real traffic anyway.

And the next thing to block after a /64 should maybe be a /48 :]

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Sun, 10 Jul 2011 08:51:23 -0400

> chance that a real SMTP server will be in a /64 with a lot of other

To a large degree it depends on how hostile major MSPs and blacklists are to receiving mail that's originated by MTAs maintained by individuals and small businesses.   RIght now, if you want your mail to be delivered reliably, you pretty much have to use a professional mail service provider to originate your mail.  Individuals and small businesses typically don't have the resources needed to monitor blacklists and to appease them when they block mail (often for no good reason).  

I have this bizarre idea that the appropriate role for network operators is to be content-neutral.  I realize that's probably heresy here, and I also realize that operators have pragmatic needs to keep their customers happy when their customers blame the operators for spam that they receive.  But when people start assuming that users will (or should) use the IPv6 network in a certain way, and configure their networks to interfere with others' traffic based on those assumptions, I think that's crossing a line.

Keith