Arnt Gulbrandsen wrote:
sm(_at_)resistor(_dot_)net writes:
Not necessarily. That host may apply a different policy for mail
coming through the other MX hosts. Otherwise, it would cause
backscatter. BTW, the problem may be applicable to IPv4 as well.
Oh wait, I misunderstood what you're saying. And you probably
misunderstood me.
jck.com doesn't have an IPv6 MX, so the only way to deliver mail to it
is to open an IPv4 SMTP connection.
Suppose I have only an IPv6 address and want to send John mail (sorry to
pick on you, John). I open an IPv6 connection to my ISP's smarthost and
send some mail from my address to a jck.com address. My ISP's smarthost
has an IPv4 address, so it opens an IPv4 connection to the best
reachable MX for jck.com. The connection from my ISP's smarthost to the
jck.com MX is what I pasted, and where the problem shows up.
Exactly. You SHOULD NOT expect IPv6 feedback behavior to be automatic or
reliable, especially from a IPv6 Only client to dual stack smarthost. It
will only work if replies are going back thru the same compatible host
routing which is generally not the case under a smarthost.
And the text I think should be there would be a sentence like this in
sections 4.1.1.2: "Note that the reverse-path may be reachable only via
IPv6, even if the SMTP connection uses IPv4", possibly with some
emphasis to point out that perfectly valid 2821 code/configurations
don't support this. 4.1.1.3 would need similar language for "forward-path".
Arnt
And this is why I was proposing the text that if a IPv6 aware client was
sending to mail out to a IPv4 client (because it used a IPv4 socket
connection), it SHOULD NOT make any presumption that the receiver would
be able to *communicate* back (in sending a bounce or user reply) using
IPv6. If it doesn't provide a compatible IPv4 layer, then its should
expect lost of mail.
Unless you have a middle man or proxie handling all the outbound and
inbound for you, you will need to have a dual stack smtp system for
direct contacts from IPv4 systems.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com