Quack, I'm having a look at OVIRT-357 and found that IPv6 was disabled for Postfix as a workaround. It seems to me the IPv6 address should be added to the DNS RR (so that SPF would allow this address too) and Postfix could have IPv6 reactivated. I see no other problem with other services on the machine if we do so. Nevertheless, I found out this in the dns-maps: ; TASK0043529 - TASK0108580 overwriten ;linode01 IN AAAA 2600:3c01::f03c:91ff:fe93:4b0d Which means IPv6 RR were activated and then later disabled. I don't know how to have access to these TASKs (SNOW?) but I'd really like to know the reason for this before any action. Do any one know why this DNS RR was removed? or were I could find it? Regards. _______________________________________________ Infra mailing list Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

On 05/24 11:27, Eyal Edri wrote: > Misc,David?

I don't know, when was that done? =20 Maybe it's old enough so Quaid was involved back then? or dnary?

> On Tue, May 24, 2016 at 8:31 AM, Marc Dequ=E8nes (Duck) <duck(a)redhat.c=

> wrote: > >> Quack, >> >> I'm having a look at OVIRT-357 and found that IPv6 was disabled for >> Postfix as a workaround. >> >> It seems to me the IPv6 address should be added to the DNS RR (so tha=

>> SPF would allow this address too) and Postfix could have IPv6 >> reactivated. I see no other problem with other services on the machin=

>> if we do so. >> >> Nevertheless, I found out this in the dns-maps: >> ; TASK0043529 - TASK0108580 overwriten >> ;linode01 IN AAAA 2600:3c01::f03c:91ff:fe93:4b0d >> >> Which means IPv6 RR were activated and then later disabled. I don't k=

>> how to have access to these TASKs (SNOW?) but I'd really like to know=

>> the reason for this before any action. >> >> Do any one know why this DNS RR was removed? or were I could find it?=

>> >> Regards.

-----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJXRCEBAAoJEFXp+fesHEQ/kKAP+wcAvVuBVJgLHyUVRIE1Ap6D 3LuFjTBYQZ3BEkFDgIeuGNc32x+qHnntqDDlb47yVFZTyrQ7jjy6KlNq1Wtp2lcg kVab89rCGFu4gC4qX006sa3SsGiWZL+tn4MJq197ymp7IOwFnsiFVHktubE9d24W KNjNaVUZOuYuh2q9EydySpX6i4tCwM1Jo/tr3yoF2spbWU/yNe5RwzsxLjbRVXK7 wN4Vo8fveDdO5siaCP9OL6MQ+mLdEKK79fMNTx/fo02wgGoiig3AjRvQIYH0XKa9 LSKsiduqHoAiZfWHoLGlBqcGw47APUouMD937+cPjbncAvsp6NpLzpNs+MhRwm+9 +z3gYEqg6eod5fPXsxVJ38bbMPH98pqBZxfp9/qcx1IunISWRjYqGlze9HosIggB k4IPvfVnVCUlTzGznY/SMSAHJXOUKw/1yKwdi/L8AxQgKCOJLMcESOOVm8MYUhM3 CTeDxwpcSjtb+7FRokC7EZy+/F0XNCUPxRkuBSmre/9ZbhoVl7tA7SiQ36iIQzyj n/fg591LrT3Pl3eCq4GNQXhXjZBxx0dZTMq5BEOCunE1kDvdhhDTOpna2+cebYME 4Mn9suaQOHCEXFOBwKG7j2PMGR9iGqT6jOJYdd6/KY0zNqtp9YCrcsutHBKi3e1C vm7MiuME0AX3dNhgUMA7 =yOD5 -----END PGP SIGNATURE-----

Dave Neary, added. On Tue, May 24, 2016 at 12:38 PM, Marc Dequènes (Duck) <duck(a)redhat.com <mailto:duck@redhat.com>> wrote: Quack, On 05/24/2016 05:32 PM, David Caro wrote: > On 05/24 11:27, Eyal Edri wrote: >> Misc,David? Misc is on PTO > I don't know, when was that done? > > Maybe it's old enough so Quaid was involved back then? or dnary? Added Quaid, please help us. Who is dnary? Could not find this nick/mail-prefix/… Here is the original mail with the unsolved question: >> On Tue, May 24, 2016 at 8:31 AM, Marc Dequènes (Duck) <duck(a)redhat.com <mailto:duck@redhat.com>> >> wrote: >> >>> Quack, >>> >>> I'm having a look at OVIRT-357 and found that IPv6 was disabled for >>> Postfix as a workaround. >>> >>> It seems to me the IPv6 address should be added to the DNS RR (so that >>> SPF would allow this address too) and Postfix could have IPv6 >>> reactivated. I see no other problem with other services on the machine >>> if we do so. >>> >>> Nevertheless, I found out this in the dns-maps: >>> ; TASK0043529 - TASK0108580 overwriten >>> ;linode01 IN AAAA 2600:3c01::f03c:91ff:fe93:4b0d >>> >>> Which means IPv6 RR were activated and then later disabled. I don't know >>> how to have access to these TASKs (SNOW?) but I'd really like to know >>> the reason for this before any action. >>> >>> Do any one know why this DNS RR was removed? or were I could find it? >>> >>> Regards. -- Eyal Edri Associate Manager RHEV DevOps EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)

Maybe it's old enough so Quaid was involved back then?

-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAldEqmQACgkQ2ZIOBq0ODEF/1gCdGlAbok+hxemOK+WwXvFZ3p9/ AgAAn0FTmmYDdYiwocVO934JJvkav0Ui =tXyn -----END PGP SIGNATURE-----

Incident INC0093361: Neil Miao is requesting the following information to assist in completing your request: 2013-11-10 21:37:49 EST - Neil Miao Comments Hi there, Thanks Mike for going the extra mile to dig it out. The existing SPF record does look bad. Since lists.ovirt.org is actually a CNAME of linode01.ovirt.org. $ dig lists.ovirt.org ... ;; ANSWER SECTION: lists.ovirt.org.300INCNAMElinode01.ovirt.org. linode01.ovirt.org.300INA173.255.252.138 adding lists.ovirt.org to the SPF is a very obvious choice. :) - IN TXT "v=spf1 a:linode01.ovirt.org ~all" + IN TXT "v=spf1 a:linode01.ovirt.org a:lists.ovirt.org ~all" The change is pushed to the corp-dns. Let me know how it goes. Cheers Neil 2013-10-31 16:55:49 EDT - Dave Neary Comments Mail from the oVirt users mailing list is being marked as spam in gmail, and is not getting through to users. A colleague, Mike McLean, looked into the issue, and suspects it is related to our DNS config: See Mike's email to me below. Is this something IT services can help fix? Thanks, Dave. Mike wrote: I don't think it is users marking as spam, despite the google warning bar. The warning in the header suggests it is a networking problem. There is nothing in the headers about the ip address (which is ipv6) being on a blacklist. > On 10/31/2013 03:20 PM, Mike McLean wrote: >> Since I subscribed to the users list last week, I've had exactly zero >> messages from it in my gmail inbox. They're all in the spam folder. >> >> Each message shows a warning at the top "Be careful with this message. >> Many people marked similar messages as spam." >> >> I'm attaching a header example. One notable line is: >> >> Authentication-Results: mx.google.com; >> spf=softfail (google.com: domain of transitioning >> users-bounces(a)ovirt.org does not designate >> 2600:3c01::f03c:91ff:fe93:4b0d as permitted sender) >> smtp.mail=users-bounces(a)ovirt.org ^ This is the header warning I referred to >> It looks like ovirt.org only has an mx entry for linode01.ovirt.org. The >> host actually sending to google (lists.ovirt.org) doesn't show up in an >> mx entry. I'd push this up to IT. It appears that google doesn't trust this mail because ovirt.org explicitly says not to. From the headers, the mail is traversing from (sending user) -> linode01.ovirt.org -> lists.ovirt.org -> (google) The SPF record for ovirt.orig is: "v=spf1 a:linode01.ovirt.org ~all" (found via dig -t TXT ovirt.org) See: http://en.wikipedia.org/wiki/Sender_Policy_Framework This policy says that linode01.ovirt.org is allowed to send and all others (e.g. lists.ovirt.org) should "softfail". Who manages the ovirt.org servers? IT? Someone in IT will have more expertise in this than me, but I suspect that answer is one of 1) change the spf record for ovirt.org to allow lists.ovirt.org 2) reconfigure lists.ovirt.org to route its mail through linode01.ovirt.org State: Pending Customer Submitted Date: 2013-10-31 16:55:49 EDT Priority: 4 - Low Description: oVirt list email is being marked as spam by gmail To update your request and notify the person assigned to your request, simply reply to this email communication. You can view the status of your incident by selecting "Incidents" from the left navigation menu: LINK Ref:MSG1353267

On 05/24/2016 01:32 AM, David Caro wrote: > Maybe it's old enough so Quaid was involved back then? I don't recall for sure why IPv6 would be turned off, but iirc we had problems with SPF for a few years for gmail.com users, meaning it affected the end-users mailing lists the most. Is it possible SPF was turned off for IPv4 & IPv6, then the problem with SPF and GMail was fixed, and it was turned back on but only for IPv 4? How about experimenting and see what happens (SCIENCE!), maybe with a warning to the two main lists (devel, users) in case anything breaks? Best, - Karsten

How about experimenting and see what happens (SCIENCE!), maybe with a warning to the two main lists (devel, users) in case anything breaks?

-----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJXRV8fAAoJEFXp+fesHEQ/5B4QAJSP7R8VwwPEDEQwBQN+rYHJ v6eA26lQmAxNOmIyrcbmUKAQ9n8bTlOmAvY/vcpBErfIyR3AGtTScE/X8Jz+4Ltm u+rstw7T3XDMenKnXpcHRCK+aja5KGxM3V2VrrpJQWQ9+mkb+5oKqxVvJ0FbsVuG FBk7t7zFrrlgtP6WU3DTB/lU6gfI860dL92vO9M0P8J9PtRCu1jP9QvSKcJJ4EST MNRbf9k2HNelEcL4252eZgPg1B+1RtcDY/51Qc5QB1qJPUHdtZbY6JGqee3s50Cg KqiZQYI/euTGo7pL5qY7b80PDmo32eUv+UjaVjuq4ZxXnISEH5Ed0vLepHOQOFGU Xzi/QCfHv4zw0WbaqZ1tfpZa64LxhlmcvXrDyWgQsDK1jnEa3ji2qXGI0XtD4Nf/ hwWkEJNiT7+ElY/RNmENGEYAmXnVVyXIzxujVR3sEGkIAUvbJkCleYnxnwfPlFWK OTi6qWmh3ceoUyh3Spt1LpEFOWDz93pUA5L7vdv5U8muyA6+xgBFigf3MUXgcHSw +9ksiWr/YTJP9HbN69saCrDLzGeds94bszDzAngV6brVjRB9bRYQhNafnnkMNPf4 iy2rb1P9urZ2zCk5rvEAEZJ+kpiKtg4I/+T2CuL14UQzSPeug6VZ3ilN7z0Bcmfp wnL0hcheRrWuCfk5thYr =ibqf -----END PGP SIGNATURE-----

Based on the forwarded message and DNS checks I did everything should b=

fine. The only thing is that have CNAME for mail server may not be a good idea and it is better to make lists to be A and AAAA direct records, reverses are already fine. As I see that's the plan so looks good. When we change we can check headers of the nearest message after DSN propagation and google and see if it treats it as SPF pass.

-----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJXSAHBAAoJEFXp+fesHEQ/SHwP/i3Z7XzQKLYbvXH5DjnPfnVI F7aaVnXjdDO8GGuzJMKfUm9mwvDPGhSeAuPM+J3UkF4FuoK/eBbVvIS7r1dFnFjf j+xV99vGiO0L7RMPXzpR+oDTItHenRjFzuPTsScOP05TR/f2pofsxeqcKOhXav5f y/2f6JEgra1/gCaSrZip0R0SH2auL9/wKsrNuZym+9AfM7ARZECcH2IZAOkFgR9z 0VOvqQ+pW5B1+k4XzFfdYXT8AobGYQqNVO5dEQiFd3+CD4TUueyqNWFxZyL0BkPZ tqDpwSY/JlZw+DAq1BhccIibqRVdrPzrR0oYJgw5qSpdH+t1SQ4ZZGoUp/K2csLS re9/KXUeNqToyojcZsTSnrNo0QKJlXdA2NDs0N/3z8aCJsCaJ6NifZzpJrMXYYQN UDSrJCKWPMNzDSBh2zvYtrAq8TGjb/ChzG2U9eQQ7Fq9NOyMP23Fjhxik2owDVe6 XGmQgQ+OTjAtJYrPpdcE0aXsLAOsAyvTIYPoL9gysXLPuJ2plYS5/cdAGCPKLQaL O2NIKN5XjVvkSJa0PjpLiB6k8F5ttKxQVtTDIytW7rzPoGv7fV0HjfaOc/8nXaCI HNVl89+zcv69REItR9ROx9LmN0nfk+sCzXZ7l6JDbUQa6A0avCGnpnfTTFPYDNIO SM/DBaHEQRzUlwSF+5WJ =LwMj -----END PGP SIGNATURE-----