![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
kent at songbird.com wrote:
I think I could have been clearer with my message. It wasn't intended as either a criticism of the ietf list management (in fact, I use precisely the same anti-spam technique) or a request for help with configuration of my mailservers (I may not be the sharpest knife in the drawer, but usually I can figure these things out on my own).Instead, I was presenting what I thought was an interesting example of a subtle problem that can come up in ipv6 deployment.The mailserver in question uses a default redhat enterprise build (actually centos). ipv6 is either enabled by default, or just has a single check box, with no further information. The fact that ipv6 is enabled so trivially carries the implication that just enabling ipv6 won't actually damageanything.Now I know different. Just enabling ipv6 on an otherwise correctly configured and functioning ipv4 box *will* cause damage -- it will cause mail that would have been delivered to not be delivered. I could be wrong, butthis strikes me as a trap that lots of people could fall into.
that's one way to look at it. another way to look at it is that poorly chosen spam filtering criteria *will* cause damage, because conditions in the Internet change over time.
of course, IPv6 will often get blamed for the problem because it's something that the sender can control, whereas the spam filters are not accountable to anyone.
Keith _______________________________________________ Ietf mailing list Ietf at ietf.org https://www.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.