Re: is gmail strongly penalizing IPv6 senders?
On May 31, Lorenzo Colitti wrote: > I've asked internally, and in many cases this appears to be due to server > operators not properly configuring reverse DNS for their IPv6 addresses. Do > you know if that is the case here? This is not the case: rDNS is valid and (at least for my own servers) even matches the EHLO name. -- ciao, Marco
Re: is gmail strongly penalizing IPv6 senders?
On May 30, 2013, at 4:58 PM, Gert Doering wrote: > You might want to check the ones for the lists that you host that are not > @puck.nether.net, though - outages.org comes to mind, which has no > SPF record today. It looks fine :) - Jared
Re: is gmail strongly penalizing IPv6 senders?
Hi, On Thu, May 30, 2013 at 11:35:16AM -0400, Jared Mauch wrote: > On May 30, 2013, at 11:30 AM, m...@linux.it (Marco d'Itri) wrote: > > > For the time being let's just assume that I am not a moron. :-) > > As a likely moron on this topic, my mail seems to be working "OK". (e.g.: I > refuse to deploy DNSSEC for a few reasons, and breaking my domain is a major > contributor.. I only *think* i mostly get the other stuff like SPF right). > > If it broke over IPv6, I'm positive Gert would hunt me down. Uh, right now puck is whitelisted anyway... acl whitelist addr 2001:418:3f4::/48 ... so I won't even see whether milter-greylist thinks the SPF records are good or not. OTOH, to the semi-trained eye, the TXT record for puck looks good :-) You might want to check the ones for the lists that you host that are not @puck.nether.net, though - outages.org comes to mind, which has no SPF record today. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279
Re: Usage of fd00::/8 on the Interwebz - something with filters and uRPF
Jan, However: in fd00:3303::1, the 3303:: could of course be a random number, but doesn't look like it. A ULA prefix should always be assigned as defined in the RFC, so whoever configured that prefix seems to have skipped a few steps. Regards Brian Carpenter On 30/05/2013 18:50, Jan Boogman wrote: > This has been fixed now, thanks for the heads up. > > Jan > > Am 30.05.2013 um 08:27 schrieb Jan Boogman : > >> hmm, this is the ip of our ServiceApp6 SVI interface, which C told us has >> only local significance, apparently this is not the case. >> Time to renumber then. >> >> Cheers >> Jan >> >> Am 29.05.2013 um 21:59 schrieb Jeroen Massar : >> >>> ... >>> 4 2001:7f8:1::a500:3303:1 (2001:7f8:1::a500:3303:1) 20.755 ms 20.763 ms >>> 20.784 ms >>> 5 fd00:3303::1 (fd00:3303::1) 22.010 ms 21.984 ms 21.986 ms >>> 6 2a02:120c:1051:d010::1 (2a02:120c:1051:d010::1) 17.806 ms 17.889 ms >>> 17.842 ms >>> 7 2a02:120c:1051:d010::1 (2a02:120c:1051:d010::1) 18.720 ms 18.593 ms >>> 18.617 ms >>> ... >>> >>> H fd00::/8, that really should never ever be visible on the Internet, >>> being Unique *LOCAL* Addresses. >>> And it does not look like they applied the randomness bit for picking a >>> prefix either. >>> You would also almost think that a /28 is more than enough address space to >>> put a few router loopbacks in. >>> >>> It is apparently time for people to start checking their filters again >>> because it seems that these packets leak into other ASNs too... >>> >>> More generally, do recheck your network for BCP38 compliance, please do >>> apply it and require your peers to do the same! >>> >>> Greets, >>> Jeroen > > . >
6PE mapped addresses used for ICMPv6 responses - knob to fix that?
In relation to the fd00::/8 thread, it seems the bug with respect to 6PE is not resolved yet. That is, if you have 6PE (IPv4 LSP) in your network routers might send an ICMPv6 message from the IPv6-Mapped-IPv4 address. And as ::::0.0.0.0/96 should not be in anybody's BGP table, it will fail uRPF. Is anybody aware of a knob that can force for instance the loopback address to be used on these boxes? Greets, Jeroen
Re: is gmail strongly penalizing IPv6 senders?
2013/5/30 Patrick Tudor : > I noticed about two weeks ago peculiar problems with gmail delivery that were > immediately resolved by adding SPF records to a domain that had gone two > years without them, fwiw. I believe that reversed DNS may help also, and EHLO/HELO matching that rDNS. -- Pim van Pelt PBVP1-RIPE - http://www.ipng.nl/
Re: is gmail strongly penalizing IPv6 senders?
I noticed about two weeks ago peculiar problems with gmail delivery that were immediately resolved by adding SPF records to a domain that had gone two years without them, fwiw.
Re: Usage of fd00::/8 on the Interwebz - something with filters and uRPF
On 2013-05-30 08:10, Jared Mauch wrote: > > On May 30, 2013, at 2:23 AM, Jeroen Massar wrote: > >> Just showing that quite a few networks are not doing uRPF. > > Problem in many cases is that the vendors don't have working uRPF. > > CSCuh1350 I am unfortunately aware that even in 2013 the big boys do not play along with a BCP from 2000... ;( (and as mentioned, for transits, it can be tricky to turn on uRPF or do other kind of prefix-filters in some cases, though try they should) > Even if the providers wanted to do it (which many do), in IPv6 land > it's actually harder due to things like ULA, mapped-v4-in-v6 and other things. In the case of ULA (which started this thread) and mapped-v4-v6, does one really need to use these? One should have more than ample space in IPv6 to carve out things for special use and null-route those on the borders in case one does not want them reachable. And if one does not use ULA etc, one does not source it either. Greets, Jeroen
Re: is gmail strongly penalizing IPv6 senders?
On May 30, 2013, at 11:30 AM, m...@linux.it (Marco d'Itri) wrote: > For the time being let's just assume that I am not a moron. :-) As a likely moron on this topic, my mail seems to be working "OK". (e.g.: I refuse to deploy DNSSEC for a few reasons, and breaking my domain is a major contributor.. I only *think* i mostly get the other stuff like SPF right). If it broke over IPv6, I'm positive Gert would hunt me down. - Jared
Re: is gmail strongly penalizing IPv6 senders?
On May 30, Olivier MJ Crepin-Leblond wrote: > Gmail uses a number of things like SPF etc. to define if something's > Spam. At this time, technologies like SPF and DKIM are not easily applicable by default in the hosting market. > Did you check that this designates the IPv6 address as a permitted > sender? Do your SMTP servers have reverse IPv6 addresses? Do you use > DKIM? Just a few suggestions... For the time being let's just assume that I am not a moron. :-) -- ciao, Marco
Re: is gmail strongly penalizing IPv6 senders?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't know if it does - I've found our servers appear to have no problem. Gmail uses a number of things like SPF etc. to define if something's Spam. Did you check that this designates the IPv6 address as a permitted sender? Do your SMTP servers have reverse IPv6 addresses? Do you use DKIM? Just a few suggestions... Kind regards, Olivier On 30/05/2013 16:46, Marco d'Itri wrote: > I have noticed in the last few days that mail sent to gmail from a > significant number of our servers (both shared hosting / mail relays and > dedicated servers of our customers) with IPv6 connectivity is delivered > to the spam folder. > If there has been spamming activity (as a result of some security > incident, I am not an ESP) from some of these servers then it is not > recent. > The reputation problem is tied to the IP address, because after adding > a new one in the same /64 mail is delivered to the inbox. > > > (OTOH, recently I have received significant complaints from customers > about gmail rejecting connections or delivering to the spam folder even > long after a security incident, so this may be not specific to IPv6.) > - -- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRp28FAAoJENb2Jfn69hcjnMwH/0AP2BujLBXr+W2ybVZG0GF1 ocQC4Vd8zqVggDS17103Hdn8QjwTObgLPC+gJF9Bk0DUZWBvKqYZtyY7IGMi5zl4 EbXt3PocpZnVPxhELVD3cQkn+KV0umuYBWA9MsqEkhj1TJC39nI/65bns/XCiBR6 5ORoecyYdnY2M8wkA0kDDK8A7CENB4qQzMZjtwXuPCZudqTkqzHAtkpZgzbojOCt C8xR5BPMMrrP57vSF9IaBYuzih3mrmgE+B6dYD7InsKzCwzQXW7+gHtEJQIsgVVZ YeyBiGUILwW4hslhXiQ0GE1Mihqe2Vw8vFfQkOrLvk5KJqME7Ng11UFzqkSfCow= =7Ip1 -END PGP SIGNATURE-
RE: is gmail strongly penalizing IPv6 senders?
No problem here. However, lately almost all new sources sending to my gmail account have been going by default into the spam folder. I suspect gmail's threshold for spam has reached the point where almost all new email addresses/domains are being sent to the spam folder. Received: from smtp-gw01.ox.com (smtp-gw01.ox.com. [2620:0:2810:167::40]) by mx.google.com with ESMTPS id b6si3245411qcz.174.2013.05.30.08.15.14 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 30 May 2013 08:15:14 -0700 (PDT) Received-SPF: pass (google.com: domain of mh...@ox.com designates 2620:0:2810:167::40 as permitted sender) client-ip=2620:0:2810:167::40; Authentication-Results: mx.google.com; spf=pass (google.com: domain of mh...@ox.com designates 2620:0:2810:167::40 as permitted sender) smtp.mail=mh...@ox.com; dkim=pass header.i=@ox.com DomainKey-Signature: s=ota; d=ox.com; c=nofws; q=dns; h=Received:Received:From:To:Date:Subject:Thread-Topic: Thread-Index:Message-ID:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: Content-Type:Content-Transfer-Encoding:MIME-Version; b=pnqZ6FNYR202pXTN05Df2284sQdeRprIFWrmaqVP7RvaSd05Nf3JYqPl kwdRF9TKGlC4mAj8udbk1ea1Q1b//Yifp+E8hhlD2NvucWBvJ8Tk9L98E D0CF4xzbSILdoGVfXI07EvJGRCdLwhPZDSzuJv3FpddIX1+4j0ie00Y36 k=; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ox.com; i=@ox.com; q=dns/txt; s=ota; t=1369926914; x=1401462914; h=from:to:date:subject:message-id: content-transfer-encoding:mime-version; bh=tYPywKmEwl4+zNgImsFESvQKlPfc3DSfQTbxk3ovXVc=; b=vnd04BMqA5CVZe64xj2NZDbiSvUde/BwzOo5lMwTLxeGjRP9N2eb4TDC 8UOPsn52O9y4wTknCfBTO09Bd/7jJxEEE7QuQOqk2WH1eyonOD4axej8q dRto3nZBD4KNZ7jIFGGFIoT+DjGtLKNwAX4V+QW0o/C7a2n7ufNMErAdT w=; Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 > -Original Message- > From: ipv6-ops-bounces+mhuff=ox@lists.cluenet.de [mailto:ipv6-ops- > bounces+mhuff=ox@lists.cluenet.de] On Behalf Of staticsafe > Sent: Thursday, May 30, 2013 11:12 AM > To: ipv6-ops@lists.cluenet.de > Cc: ja...@puck.nether.net > Subject: Re: is gmail strongly penalizing IPv6 senders? > > On Thu, May 30, 2013 at 11:00:05AM -0400, Jared Mauch wrote: > > I've not observed a problem with the puck.nether.net lists and google. > > > > Then again, I don't know if stuff goes into Spam folder on the far side. > > > > This includes: > > > > gmail.com > > googlemail.com domains > > other domains hosted on google (aspmx.l.google.com) > > > > It's also possible I have a lot of volume so am well classified as "good". > > > > - jared > > > > On May 30, 2013, at 10:51 AM, staticsafe wrote: > > > > Interesting, just removed the ipv4 preference from Postfix, and sent a > test mail to Gmail, goes through fine. > > Received: from uriel.asininetech.com (uriel.asininetech.com. > [2607:5300:60:e3a::1]) > by mx.google.com with ESMTPS id > ow20si10750327veb.31.2013.05.30.08.09.13 > -- > staticsafe > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org > Please don't top post - http://goo.gl/YrmAb > Don't CC me! I'm subscribed to whatever list I just posted on.
Re: is gmail strongly penalizing IPv6 senders?
On Thu, May 30, 2013 at 11:00:05AM -0400, Jared Mauch wrote: > I've not observed a problem with the puck.nether.net lists and google. > > Then again, I don't know if stuff goes into Spam folder on the far side. > > This includes: > > gmail.com > googlemail.com domains > other domains hosted on google (aspmx.l.google.com) > > It's also possible I have a lot of volume so am well classified as "good". > > - jared > > On May 30, 2013, at 10:51 AM, staticsafe wrote: > Interesting, just removed the ipv4 preference from Postfix, and sent a test mail to Gmail, goes through fine. Received: from uriel.asininetech.com (uriel.asininetech.com. [2607:5300:60:e3a::1]) by mx.google.com with ESMTPS id ow20si10750327veb.31.2013.05.30.08.09.13 -- staticsafe O< ascii ribbon campaign - stop html mail - www.asciiribbon.org Please don't top post - http://goo.gl/YrmAb Don't CC me! I'm subscribed to whatever list I just posted on.
Re: Usage of fd00::/8 on the Interwebz - something with filters and uRPF
On May 30, 2013, at 2:23 AM, Jeroen Massar wrote: > Just showing that quite a few networks are not doing uRPF. Problem in many cases is that the vendors don't have working uRPF. CSCuh13508 Even if the providers wanted to do it (which many do), in IPv6 land it's actually harder due to things like ULA, mapped-v4-in-v6 and other things. - Jared
Re: is gmail strongly penalizing IPv6 senders?
I've not observed a problem with the puck.nether.net lists and google. Then again, I don't know if stuff goes into Spam folder on the far side. This includes: gmail.com googlemail.com domains other domains hosted on google (aspmx.l.google.com) It's also possible I have a lot of volume so am well classified as "good". - jared On May 30, 2013, at 10:51 AM, staticsafe wrote: > On Thu, May 30, 2013 at 04:46:02PM +0200, Marco d'Itri wrote: >> I have noticed in the last few days that mail sent to gmail from a >> significant number of our servers (both shared hosting / mail relays and >> dedicated servers of our customers) with IPv6 connectivity is delivered >> to the spam folder. >> If there has been spamming activity (as a result of some security >> incident, I am not an ESP) from some of these servers then it is not >> recent. >> The reputation problem is tied to the IP address, because after adding >> a new one in the same /64 mail is delivered to the inbox. >> >> >> (OTOH, recently I have received significant complaints from customers >> about gmail rejecting connections or delivering to the spam folder even >> long after a security incident, so this may be not specific to IPv6.) >> >> -- >> ciao, >> Marco > > Gmail is outright rejecting my MX over v6, something about "bulk mail" > which makes no sense as this is a personal e-mail server. I've worked > around the issue by telling Postfix to prefer ipv4 for sending. > -- > staticsafe > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org > Please don't top post - http://goo.gl/YrmAb > Don't CC me! I'm subscribed to whatever list I just posted on.
Re: is gmail strongly penalizing IPv6 senders?
On Thu, May 30, 2013 at 04:46:02PM +0200, Marco d'Itri wrote: > I have noticed in the last few days that mail sent to gmail from a > significant number of our servers (both shared hosting / mail relays and > dedicated servers of our customers) with IPv6 connectivity is delivered > to the spam folder. > If there has been spamming activity (as a result of some security > incident, I am not an ESP) from some of these servers then it is not > recent. > The reputation problem is tied to the IP address, because after adding > a new one in the same /64 mail is delivered to the inbox. > > > (OTOH, recently I have received significant complaints from customers > about gmail rejecting connections or delivering to the spam folder even > long after a security incident, so this may be not specific to IPv6.) > > -- > ciao, > Marco Gmail is outright rejecting my MX over v6, something about "bulk mail" which makes no sense as this is a personal e-mail server. I've worked around the issue by telling Postfix to prefer ipv4 for sending. -- staticsafe O< ascii ribbon campaign - stop html mail - www.asciiribbon.org Please don't top post - http://goo.gl/YrmAb Don't CC me! I'm subscribed to whatever list I just posted on.
Re: is gmail strongly penalizing IPv6 senders?
On 2013-05-30 07:46, Marco d'Itri wrote: > I have noticed in the last few days that mail sent to gmail from a > significant number of our servers (both shared hosting / mail relays and > dedicated servers of our customers) with IPv6 connectivity is delivered > to the spam folder. > If there has been spamming activity (as a result of some security > incident, I am not an ESP) from some of these servers then it is not > recent. > The reputation problem is tied to the IP address, because after adding > a new one in the same /64 mail is delivered to the inbox. > > > (OTOH, recently I have received significant complaints from customers > about gmail rejecting connections or delivering to the spam folder even > long after a security incident, so this may be not specific to IPv6.) Various people have been reporting related events: http://www.sixxs.net/forum/?msg=general-9241166 Seems something in the Big G classifies IPv6 as 'bad' quite quickly for some magic reason. Greets, Jeroen
is gmail strongly penalizing IPv6 senders?
I have noticed in the last few days that mail sent to gmail from a significant number of our servers (both shared hosting / mail relays and dedicated servers of our customers) with IPv6 connectivity is delivered to the spam folder. If there has been spamming activity (as a result of some security incident, I am not an ESP) from some of these servers then it is not recent. The reputation problem is tied to the IP address, because after adding a new one in the same /64 mail is delivered to the inbox. (OTOH, recently I have received significant complaints from customers about gmail rejecting connections or delivering to the spam folder even long after a security incident, so this may be not specific to IPv6.) -- ciao, Marco signature.asc Description: Digital signature
Re: Usage of fd00::/8 on the Interwebz - something with filters and uRPF
On 2013-05-29 23:27, Jan Boogman wrote: > hmm, this is the ip of our ServiceApp6 SVI interface, which C told us > has only local significance, apparently this is not the case. Time to > renumber then. Thanks for looking into it! ServiceApp6 is just a next-hop to get your packet into the code that handles the 6rd, thus in the case of traceroute or anything other packet the TTL will be decremented and will thus cause a ICMPv6 Hop Limit for that address to be sent out. Same goes for ServiceApp4 btw. The ServiceApp6 is also visible in a 'show route ipv6' btw. The bigger point with ServiceApp6 though is that it might and likely will originate a ICMPv6 PacketTooBig, this as everything behind it is tunneled and thus has a lower MTU, which is likely only 1280 unless otherwise configured. Thus using a invalid (eg ULA) ServiceApp6 address will just cause providers who do properly filter those addresses and will magically give all kinds of strange connectivity issues. The bigger question becomes why you would use a ULA prefix, when you got a huge block of address space to pick from, which is 'guaranteed' globally unique, in the first place. Next to not having proper filters for not causing such an address to leak of course, along with the upstreams in the path towards it that obviously just accept any kind of address without uRPF checks. The great thing about IPv6 is that typically as a (non-transit) provider one will have only one huge prefix, thus filtering that prefix and dropping anything else with a different source prefix should be extremely easy to do on the edge if it. And such a filter is completely stateless too, thus strange that this is not set up. And as the address is bogus one does not even have to send a response, as it won't go anyway to where it should go. Bottom-line: * enable uRPF everywhere * do source address checks as close to the source (useful if you "cannot" do uRPF on your core router) * Do not use ULA, just use a portion of the huge RIR-assigned prefix you have. Greets, Jeroen
Re: Usage of fd00::/8 on the Interwebz - something with filters and uRPF
On 2013-05-29 23:49, Tore Anderson wrote: > * Jeroen Massar > >> H fd00::/8, that really should never ever be visible on the >> Internet, being Unique *LOCAL* Addresses. > > FWIW this is not unique to ULAs. When tracerouting through AS174, for > example, you'll see IPv4-mapped IPv6 addresses, courtesy of 6PE. At > least that was the case a couple of years back. > > That said, if you go looking, I'll wager you'll find RFC1918 addresses > IPv4 traceroutes too. It is definitely not unique to ULA, hence my suggestion to turn on uRPF and the follow the other recommendations of BCP38. For IPv4 that game was lost years ago, but maybe with IPv6 there is still a chance to change that. And one would think that with the recent DNS Amplification attacks people would be at least a little bit aware of the fact that spoofed addresses causes quite a bit of pain out there and that uRPF is a good thing, in both IPv4 and IPv6. Greets, Jeroen
Re: Usage of fd00::/8 on the Interwebz - something with filters and uRPF
Tim, Hmm, you say till the day you receive a 100G of spoofed packets... and that is what they are as nobody is able to claim they "own" those prefixes. Would be interesting to see how much IPv6 traffic hits the DNS roots from link-local or ULA sources. Anyone have any info? DNS-OARC? https://www.dns-oarc.net/ I do not have access myself (if not I would give it a try), but I think there are some people in this list from the roots or the RIRs that could be able to get the data and perhaps a short report about it. Regards, as
Re: Usage of fd00::/8 on the Interwebz - something with filters and uRPF
Hi, On Thu, May 30, 2013 at 08:49:07AM +0200, Tore Anderson wrote: > That said, if you go looking, I'll wager you'll find RFC1918 addresses > IPv4 traceroutes too. Plenty. Even if you don't want to be looking. gert -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279
Re: Usage of fd00::/8 on the Interwebz - something with filters and uRPF
> > H fd00::/8, that really should never ever be visible on the > > Internet, being Unique *LOCAL* Addresses. > > FWIW this is not unique to ULAs. When tracerouting through AS174, for > example, you'll see IPv4-mapped IPv6 addresses, courtesy of 6PE. At > least that was the case a couple of years back. > > That said, if you go looking, I'll wager you'll find RFC1918 addresses > IPv4 traceroutes too. Absolutely. Unless you block these at your borders (we do). Steinar Haug, AS 2116
