[146473] in cryptography@c2.net mail archive
Re: [Cryptography] IPv6 and IPSEC
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Thu Aug 29 19:20:13 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <CAGZkp18tkN8r4+T789qrgXOcjcST3OqYAbSaTeM6Q4gfNMt+Cg@mail.gmail.com>
Date: Thu, 29 Aug 2013 18:46:38 -0400
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Taral <taralx@gmail.com>
Cc: Lucky Green <shamrock@cypherpunks.to>,
Cryptography List <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============5308185576462349070==
Content-Type: multipart/alternative; boundary=089e013d1b9c02e4bc04e51de18f
--089e013d1b9c02e4bc04e51de18f
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Aug 29, 2013 at 4:53 PM, Taral <taralx@gmail.com> wrote:
> Oh, wait. I misread the requirement. This is a pretty normal
> requirement -- your reverse DNS has to be valid. So if you are
> 3ffe::2, and that reverses to abc.example.com, then abc.example.com
> better resolve to 3ffe::2.
>
> On Thu, Aug 29, 2013 at 1:38 PM, Phillip Hallam-Baker <hallam@gmail.com>
> wrote:
> >
> >
> >
> > On Thu, Aug 29, 2013 at 1:59 PM, Taral <taralx@gmail.com> wrote:
> >>
> >> On Wed, Aug 28, 2013 at 12:08 PM, Lucky Green <shamrock@cypherpunks.to>
> >> wrote:
> >> > "Additional guidelines for IPv6
> >> >
> >> > The sending IP must have a PTR record (i.e., a reverse DNS of the
> >> > sending IP) and it should match the IP obtained via the forward DNS
> >> > resolution of the hostname specified in the PTR record. Otherwise,
> mail will
> >> > be marked as spam or possibly rejected."
> >>
> >> Because under ipv6 your prefix is supposed to be stable (customer
> >> identifier) and the namespace delegated to you on request. Have you
> >> asked your provider for an ipv6 namespace delegation?
> >
> >
> > It is a stupid and incorrect requirement.
> >
> > The DNS has always allowed multiple A records to point to the same IP
> > address. In the general case a mail server will support hundreds,
> possibly
> > tens of thousands of receiving domains.
> >
> > A PTR record can only point to one domain.
> >
> > The reason that an MX record has a domain name as the target rather than
> an
> > IP address is to facilitate administration. Forcing the PTR and AAAA
> record
> > to match means that there has to be a one to one mapping and thus defeats
> > many commonly used load balancing strategies.
> >
> > Google is attempting to impose a criteria that is simply wrong.
>
>
So Lucky's problem seems to be that the ISPs providing IPv6 have decided on
a convention that they identify residential IPv6 ranges by not filling in
the reverse PTR info....
And the problem he has is that Google won't take email from a residential
IPv6.
--
Website: http://hallambaker.com/
--089e013d1b9c02e4bc04e51de18f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Thu, Aug 29, 2013 at 4:53 PM, Taral <span dir=3D"ltr"><<a hre=
f=3D"mailto:taralx@gmail.com" target=3D"_blank">taralx@gmail.com</a>></s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Oh, wait. I misread the requirement. This is=
a pretty normal<br>
requirement -- your reverse DNS has to be valid. So if you are<br>
3ffe::2, and that reverses to <a href=3D"http://abc.example.com" target=3D"=
_blank">abc.example.com</a>, then <a href=3D"http://abc.example.com" target=
=3D"_blank">abc.example.com</a><br>
better resolve to 3ffe::2.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On Thu, Aug 29, 2013 at 1:38 PM, Phillip Hallam-Baker <<a href=3D"mailto=
:hallam@gmail.com">hallam@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Thu, Aug 29, 2013 at 1:59 PM, Taral <<a href=3D"mailto:taralx@gm=
ail.com">taralx@gmail.com</a>> wrote:<br>
>><br>
>> On Wed, Aug 28, 2013 at 12:08 PM, Lucky Green <<a href=3D"mailt=
o:shamrock@cypherpunks.to">shamrock@cypherpunks.to</a>><br>
>> wrote:<br>
>> > "Additional guidelines for IPv6<br>
>> ><br>
>> > The sending IP must have a PTR record (i.e., a reverse DNS of=
the<br>
>> > sending IP) and it should match the IP obtained via the forwa=
rd DNS<br>
>> > resolution of the hostname specified in the PTR record. Other=
wise, mail will<br>
>> > be marked as spam or possibly rejected."<br>
>><br>
>> Because under ipv6 your prefix is supposed to be stable (customer<=
br>
>> identifier) and the namespace delegated to you on request. Have yo=
u<br>
>> asked your provider for an ipv6 namespace delegation?<br>
><br>
><br>
> It is a stupid and incorrect requirement.<br>
><br>
> The DNS has always allowed multiple A records to point to the same IP<=
br>
> address. In the general case a mail server will support hundreds, poss=
ibly<br>
> tens of thousands of receiving domains.<br>
><br>
> A PTR record can only point to one domain.<br>
><br>
> The reason that an MX record has a domain name as the target rather th=
an an<br>
> IP address is to facilitate administration. Forcing the PTR and AAAA r=
ecord<br>
> to match means that there has to be a one to one mapping and thus defe=
ats<br>
> many commonly used load balancing strategies.<br>
><br>
> Google is attempting to impose a criteria that is simply wrong.<br><br=
></div></div></blockquote><div><br></div><div>So Lucky's problem seems =
to be that the ISPs providing IPv6 have decided on a convention that they i=
dentify residential IPv6 ranges by not filling in the reverse PTR info....<=
br>
</div><div><br></div><div>And the problem he has is that Google won't t=
ake email from a residential IPv6.</div></div><div><br></div>-- <br>Website=
: <a href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>
--089e013d1b9c02e4bc04e51de18f--
--===============5308185576462349070==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============5308185576462349070==--
