Most current efforts to start accepting email over IPv6 at scale appear to be stumbling on two irreducible problems:
- IPv4-dependence of current abuse-prevention techniques and the absence of a reliable way for a receiver to say “apologies, I can’t assess this message over IPv6, please retry over IPv4” means that most have been unwilling to even attempt accepting email over IPv6 generally.
- This requirement is sufficiently novel that merely using an existing SMTP response code or defining a suitable new one is likely to cause breakage (e.g. bounces) when encountered by senders unaware of the special meaning of the response code.
If these problems are the relevant ones and are truly irreducible then what is required to allow more early adopters to start is a way for a sender to affirmatively indicate its ability to interpret a “fallback to IPv4” response code, even before an AAAA record is returned when looking up the MX; if it doesn’t indicate its ability to do so then only an A record should be provided, meaning that delivery will only be attempted over IPv4. Proposed here is a means of doing so by specifying a new Service name for an SRV record (“MX6”) and the sequence of actions around a new response code.
A receiver NOT implementing MX6 might publish the following:
only4.example MX 0 mx.only4.example
mx.only4.example A 10.0.0.1
while a receiver implementing MX6 might publish the following:
with6.example MX 0 mx.with6.example
mx.with6.example A 10.0.0.2
_mx6._tcp.with6.example SRV 0 0 25 mx6.with6.example
mx6.with6.example A 10.0.0.2
mx6.with6.example AAAA 0:0:0:0:0:ffff:a00:2
This would support the following scenarios:
An MX6-unaware sender delivering to an MX6-aware receiver
- Looks up “MX with6.example”
- Gets mx.with6.example and then 10.0.0.2
- Connects via IPv4 to 10.0.0.2
- Proceeds as usual
An MX6-aware sender delivering to an MX6-unaware receiver
- Looks up “SRV _mx6._tcp.only4.example”
- Gets nothing
- Looks up “MX only4.example”
- Gets mx.only4.example and then 10.0.0.1
- Connects via IPv4 to 10.0.0.1
- Proceeds as usual
Both MX6-aware, receiver is willing to accept the message over IPv6
- Looks up “SRV _mx6._tcp.with6.example”
- Gets mx6.with6.example and then 10.0.0.2 and 0:0:0:0:0:ffff:a00:2
- Connects via IPv6 to 0:0:0:0:0:ffff:a00:2
- Proceeds as usual
Both MX6-aware, receiver is unwilling to accept the message over IPv6
- Looks up “SRV _mx6._tcp.with6.example”
- Gets mx6.with6.example and then 10.0.0.2 and 0:0:0:0:0:ffff:a00:2
- Connects via IPv6 to 0:0:0:0:0:ffff:a00:2
- After the DATA phase gets 550 5.5.XXX
- Connects via IPv4 to 10.0.0.2
- Proceeds as usual
Further thoughts:
- The use of the word “acceptance” in the title is intentional. Just about everything needed for senders to send over IPv6 is already in place, so this is not specifically about a delivery over IPv6. It’s addressing a receiver concern and therefore about receiving - and more importantly about acceptance - over IPv6.
- It is to be hoped that efforts to modify IPv4 reputation techniques to suit IPv6 are successful, however this is far from certain at this point.
- A very important characteristic of this proposal is that it makes no attempt at all to specify what reason a receiver might have for suggesting that a sender fallback to IPv4. There have been various proposals to specify in standards a set of authentication mechanisms or other practices a sender might be obliged to perform in order to be granted access via IPv6. The history of abuse-prevention techniques suggests that (a) any such specification is likely to be ignored by receivers anyway (b) even if they don’t, our odds of correctly guessing what to specify such that it gets implemented but not abused are about nil and (c) the approach used by receivers is likely to include elements largely outside the control or visibility of senders, like end-user addressbook matching. The only interoperability items required are the means for a receiver to suggest fallback and for a sender to indicate - even before receiving an address record - a willingness to fallback, so that’s all that’s specified here. The process of receivers working out what they need and senders implementing it will take time to unfold and need not be specified at this point.
- Other means of having a sender specify this willingness include:
- Entirely separate protocols that don’t require alteration to mail-server software (as is the case e.g. for Domain Owners for SPF, which helped accelerate rollout), but in light of the problem statement at the start of this proposal, this does not appear feasible.
- Large receivers or intermediaries operating registries of which servers are capable of what, which is pretty obviously a terrible idea and doesn’t solve the “before an AAAA record is provided” requirement (because of the use of shared resolvers) anyway.
- Altering DNS responses by the AS# of the network containing the DNS resolver as google did when rolling out IPv6 connectivity generally, however this is not workable as there isn’t the same identity between network location and implementation (MX6 awareness in this case, IPv6 peering in Google’s).
- The use of 550 5.5.X is loosely inspired by both RFC 5321’s 551 “User not local; please try <forward-path>” and by 452 “Requested action not taken: insufficient system storage” after RCPT TO (too many recipients for this transaction, retry this recipient and any subsequent ones in a later transaction). As this response code is not expected to be seen by non-MX6-aware senders the choice between 4xy and 5xy for this novel meaning is somewhat arbitrary, however choosing 5xy does mean that unaware senders who are mistakenly delivering over IPv6 will get an immediate fail (and thus an immediate bounce to the user), rather than be forced to wait their maximum retry time before doing so. The choice between X.5.X and X.7.X is somewhat arbitrary too; X.5.5 is almost exactly on point except that it does not connote “retry over IPv4”, so a new code is required anyway.
- The use of SRV records does open up the possibility of receivers specifying different ports for this SMTP-with-special-meaning (contrast submission over TCP/587), but this does not seem wise as it would invalidate widely implemented outbound TCP/25 control mechanisms. A better approach is to use TCP/25 at additional IPv6 addresses to separate the MX6 server(s) as such addresses are likely to be plentiful.
- While the basis upon which to decide when to suggest fallback to IPv4 is entirely up to the receiver, some useful things to include after the fall-back-to-IPv4 response code might include a multiple-line reply with:
- Authentication-Results: headers as would have been prepended to the message, to aid authentication problem diagnosis
- Where a reputation service that allows registration is in use (e.g. something like Spamhaus PBL but for IPv6) should such a thing prove useful, a URL for starting that process
- The name of the SRV Service is a little misleading (MX6 handles both IPv4 and IPv6, and MX continues to be able to handle both also), but is compact and appears to be about the right thing to call it (_mx6withfallbackto4 isn’t very catchy). Hopefully this is the last time there’s a need to introduce a non-backward compatible SMTP change that requires that a sender indicate awareness prior to receiving an address record; if so, then we won’t be propagating still more SRV Service names every time a new extension is proposed.
- One of the problems that led to this thinking was a particular problem for a large service provider whose customer wanted IPv6 receiving with no dependence upon a registration or other reputation service. This does solve that problem, albeit by creating a potentially more difficult one, which is the reason for the title.
Comments welcome.