IPv6 isn't SMTP

Mailman List Mirror (Read Only)
1

Wow, what a lot of NANOG traffic about IPv6 readiness for SMTP!

Please explain my misunderstanding on the following:

1. IPv6 is a Routing Layer Protocol (with some associated helpers, like RA, ND, DHCP-PD, and the like).

2. SMTP is an Application Layer Protocol, supposedly independent of Routing and lower layers of the protocol stack. Various communities have added connection initiation requirements that sometimes impinge upon layer 3 by requiring name/address correlations in DNS and none of which depend directly on technical aspects of layer 3 addressing. [ignoring obsolescent MTA implementations]

3. Arguing about IPv6 in the context of requirements upon SMTP connections is playing that uncomfortable game with one’s own combat boots. And not particularly productive.

I look forward to furthering my education.

James R. Cutler
James.cutler@consultant.com
PGP keys at http://pgp.mit.edu

2

+1, very well put.

3

3. Arguing about IPv6 in the context of requirements upon SMTP connections is playing that uncomfortable game with
one�s own combat boots. And not particularly productive.

If you can figure out how to do effective spam filtering without
looking at the IP addresses from which mail arrives, you will be in a
position to make a whole lot of money.

But, as always, I'm not holding my breath.

R's,
John

PS: Note the word "effective".

4

You look at the IP, and verify forward and reverse DNS.

IPv6 doesn't make this any harder a problem than IPv4, it just means that we're going to *have* to reject mail that comes in from IPv6 addresses that don't have clean DNS.

5

Actually, with all the discussion about ipv6 not having rDNS, in most cases, would that not make things easier? So those that want to run email servers SHOULD be on ISP's that allow for rDNS configuration for IPv6. There should be some vetting in the process by the ISP, maybe, before allowing this. So in essence, if you are a legitimate email host, you will have rDNS configured on IPv6 for your server. Again, as others have stated, rDNS should NOT be the only deciding factor in whether or not an email is legit. No rDNS, or havinf rDNS, should have some weight assigned to it for the overall evaluation of the sender.

Robert

6

Several years ago now the IETF DNSOP WG worked on a document about
reverse mapping. The topic was so controversial that the final
version of the document, which said little more than, "There is a
reverse tree, and you might want to take that into consideration. Or
not. It's up to you," still couldn't get consensus. I think anything
that involves making rules about others' reverse maps is probably an
excellent way to attract ducks to nibble you to death.

A

7

If you can't get rDNS on a mail host from your ISP, I'd say you are on the wrong ISP if you want to run your own mail server.

This goes for IPv6 and IPv4 equally.

8

Daniel Taylor wrote the following on 3/26/2014 7:45 AM:

3. Arguing about IPv6 in the context of requirements upon SMTP connections is playing that uncomfortable game with
one�s own combat boots. And not particularly productive.

If you can figure out how to do effective spam filtering without
looking at the IP addresses from which mail arrives, you will be in a
position to make a whole lot of money.

But, as always, I'm not holding my breath.

R's,
John

PS: Note the word "effective".

You look at the IP, and verify forward and reverse DNS.

IPv6 doesn't make this any harder a problem than IPv4, it just means that we're going to *have* to reject mail that comes in from IPv6 addresses that don't have clean DNS.

With this in mind, how hard is it for a spamming operation to setup rDNS for their IPv6 ranges? Not very hard, just like their ability to use SPF or DKIM (they will do it if it improves their deliverability). This is separate from infected bots on residential connections, which is effectively dealt with today through the PBL or some basic rDNS checks since practically everyone has rDNS in IPv4.

Having rDNS doesn't automatically make you a good guy. SMTP operators will still have the need for reputation based services. Due to the design of the SMTP protocol (which provides little protection for abuse on its own), people chose to place additional checks at L3. I see this as a deficiency in SMTP that we were fortunate enough to solve in an IPv4 landscape (after a lot of initial concern about RBLs and their operators), but is going to be harder to to utilize the same tool as effectively in IPv6. The problem is with SMTP and is probably best addressed in the application layer through updates to SMTP or required bolt-ons (e.g SPF or similar); it was just simpler for most folks to address it on their own at L3 rather than trying to get everyone to agree on a new/better way to send email messages.

--Blake

9

With this in mind, how hard is it for a spamming operation to setup

rDNS for their IPv6 ranges? Not very hard, just like their ability to use
SPF or DKIM (they will do it if it improves their deliverability). This is
separate from infected bots on residential connections, which is
effectively dealt with today through the PBL or some basic rDNS checks
since practically everyone has rDNS in IPv4.

[snip]

There are plenty of residential connections, and enterprise non-mail server
connections, that PBL is no good for.

As far as i'm concerned.... if you can force the spammer to use their own
IP range, that they can setup RDNS for, then you have practically won,
for all intents and purposes, as it makes blacklisting feasible, once
again!

Spammers can jump through these hoops --- but spammers aren't going to
effectively scale up their spamming operation by using IP address ranges
they can setup RDNS on.

I would argue that less than 100% of spammers for sure would make the shift
from compromising as many IP addresses as possible and turning them into
mail servers.

Following that.... what's really left is: misconfigured mail servers
allowing open relays, and mail users that fall to phishing or pick easy to
guess passwords.

(Spammer intruding upon and co-oping mailboxes that are legitimate in the
first place.)

Having rDNS doesn't automatically make you a good guy. SMTP operators will
still have the need for reputation based services. Due to the design of the
SMTP protocol

Indeed it doesn't, but it's highly suggestive. *I would rather rDNS be
augmented with a registration of intent to run a mail server that can
verifiably be linked to whomever is authorized contact for the IP space.

(which provides little protection for abuse on its own), people chose to
place additional checks at L3. I see this as a deficiency in SMTP that we
were fortunate enough to solve in an IPv4 landscape (after a lot of initial
concern about RBLs and their operators), but is going to be harder to to
utilize the same tool as effectively in IPv6.

It will be immensly harder.

The problem is with SMTP and is probably best addressed in the application
layer through updates to SMTP or required bolt-ons (e.g SPF or similar); it
was just simpler

SPF is useful, but not a complete solution.

I'm curious what form you think these updates to SMTP would take?
What changes to SMTP protocol itself could really have a meaningful impact,

without frustrating, confusing, or terribly complicating the lives of
millions of mail users?

10

That is one of my two big take-aways from this conversation. The other is that operators of SMTP MTAs should implement RDNS for them, which I thought we already knew.

To my knowledge, there are three impacts that IPv6 implementation makes on an SMTP implementation. One is that the OS interface to get the address of the next MUA or MTA needs to use getaddrinfo() instead of gethostbyname() (and would do well to observe RFC 6555’s considerations). Another is that, whether on an incoming or an outbound connection, when the application gets its own address from the OS (binary or as a character string), it needs to allocate more storage for the data structure. The third is that it needs to be able to interpret user@2001:db8::1 as well as user@dns-name and user@192.0.2.1.

All things considered, that’s a pretty narrow change set.

Everyone here, no doubt, is clueful enough to implement RDNS for their MTAs. We know that there are people in the world that don’t implement it for IPv4. Yet, here we are, using SMTP/IPv4 to discuss this, and I don’t hear anyone saying that IPv4 isn’t ready for prime time as a result of the fact of some operators not implementing RDNS.

...

11

Fred Baker describes the requirements in a most satisfactory manner.

Thank you, Fred.

James R. Cutler
James.cutler@consultant.com
PGP keys at http://pgp.mit.edu

12

To my knowledge, there are three impacts that IPv6 implementation makes on an SMTP implementation. One is that the OS
interface to get the address of the next MUA or MTA needs to use getaddrinfo() instead of gethostbyname() (and would
do well to observe RFC 6555�s considerations).

In practice it's considerably more complex than that due to MX
handling. If you have multihomed hosts, or multiple MXes at the same
priority, you need to decide in what order to try them, and what to do
next if a connection attempt fails. If one MX has an A record and
another has AAAA, do you always prefer the one with the AAAA? If a
host has both an A and an AAAA, you probably try the AAAA first, so if
the AAAA connection fails, do you try the A or do you skip to the next
host? The RFC is deliberately unhelpful here, and a fair amount of
fiddling is required to come up with heuristics that work well.

There are also some odd things in the spec. For example, according to
RFC 5321 this is not a syntactically valid e-mail address:

mailbox@[IPv6:2001:12:34:56::78:ab:cd]

R's,
John

13

3. Arguing about IPv6 in the context of requirements upon SMTP connections is playing that uncomfortable game with one’s own combat boots. And not particularly productive.

That is one of my two big take-aways from this conversation. The other is that operators of SMTP MTAs should implement RDNS for them, which I thought we already knew.

It is in several industry recommendations cf for instance BCP at www.m3aawg.org

To my knowledge, there are three impacts that IPv6 implementation makes on an SMTP implementation. One is that the OS interface to get the address of the next MUA or MTA needs to use getaddrinfo() instead of gethostbyname() (and would do well to observe RFC 6555’s considerations). Another is that, whether on an incoming or an outbound connection, when the application gets its own address from the OS (binary or as a character string), it needs to allocate more storage for the data structure. The third is that it needs to be able to interpret user@2001:db8::1 as well as user@dns-name and user@192.0.2.1.

and user@2001:db8::1.25 with user@192.0.2.1:25. Who had the good idea to use : for IPv6 addresses while this is the separator for the port in IPv4? A few MTA are confused by it.

All things considered, that’s a pretty narrow change set.

Everyone here, no doubt, is clueful enough to implement RDNS for their MTAs. We know that there are people in the world that don’t implement it for IPv4. Yet, here we are, using SMTP/IPv4 to discuss this, and I don’t hear anyone saying that IPv4 isn’t ready for prime time as a result of the fact of some operators not implementing RDNS.

There is some confusion between MX selection and address selection, I tried to document it, and resolve the ambiguities in http://datatracker.ietf.org/doc/draft-martin-smtp-target-host-selection-ipv4-IPv6/ (comments at apps-discuss@ietf.org)

Remember 70 to 90% of email is spam, blacklists can drop as much as 75% of spam at connection time (an IPv6 blacklist has problems due to size and impact on DNS). If we mess up the transition of SMTP to IPv6, less than 1 out of 10 emails in your mailbox will be remotely interesting….

14

At the network level the IPv6 address is just a big number. No confusion there. At the plaintext level the naked IPv6 address should be wrapped in square brackets.

From:
http://tools.ietf.org/html/rfc3986#section-3.2.2

15

In article <5333970A.6070107@direcpath.com> you write:

and user@2001:db8::1.25 with user@192.0.2.1:25. Who had the good idea to use : for IPv6 addresses while this is the

separator for the port in IPv4? A few MTA are confused by it.
At the network level the IPv6 address is just a big number. No
confusion there. At the plaintext level the naked IPv6 address should
be wrapped in square brackets.

From:
RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax

It's messier than that. See RFC 5321 section 4.1.3. I have no idea
whether anyone has actually implemented IPv6 address literals and if
so, how closely they followed the somewhat peculiar spec.

R's,
John

16

I'm not sure why the SMTP RFC defines IPv6-addr so thoroughly and in an incompatible way with the other RFCs. It would make more sense to refer back to another RFC with authoritative definitions. They're completely missing the fun that's happening with Zone Identifiers in RFC6874 and the hacks to support them some have been doing with the IPvFuture definition.

I'm not saying John Klensin shouldn't have a say in how the IPv6 address is defined, but I do think it would be best for everyone to work it out in an official place somewhere so that email software isn't doing the complete opposite of everyone else.

17

I'm not saying John Klensin shouldn't have a say in how the IPv6 address is defined, but I do think it would be best for everyone to work it out in an official place somewhere so that email software isn't doing the complete opposite of everyone else.

Too late.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

18

Two errors, actually… As an RFC-821 address, it should be user@[IP]:port in both cases (user@[192.0.2.1]:25 and user@[2001:db8::1]:25).

Owen

19

indeed, but MTAs are know to accept any kind of non RFC compliant emails and trying to make some sense out of it… :stuck_out_tongue: see http://tools.ietf.org/html/rfc7103 which tries to address some of it in a more deterministic way.

20

Sure, but that doesn’t mean we should be sending random garbage deliberately.

Owen