OK, now I see that we come from fundamentally opposite viewpoints.
I'm arguing about what measures it makes sense to use to get good
protection while still enabling people to use their residential internet
for more than just consumption, while you are determined to block all
email originating from residential addresses, regardless of validity or
how well the servers are run.
Since our goals are exactly opposite, I don't think we'll ever see
eye-to-eye on what steps are appropriate.
On 11/03/2014 05:57 PM, Darren Pilgrim wrote:
On 11/3/2014 1:38 AM, Bjørn Mork wrote:
Darren Pilgrim <[email protected]> writes:
On 11/2/2014 12:38 PM, Matija Grabnar wrote:
And I've had similar problems ("we are not set up to delegate reverse
DNS for IPV6") with a hosting provider. I had a suggestion on the list
that I should simply rehost my machines, but alas it is not practical,
since the provider was chosen for a bunch of other parameters
(bandwidth
cost, hosting cost, etc), with IPv6 connectivity an afterthought.
I've had providers tell me that as well, then add that they can set
the reverse DNS upon request. If they can't do either, run away from
them very fast--they just made it very clear they don't have a good
design.
I am willing to agree as long as we're talking about hosting providers.
Yes, hosting providers. Specifically, those that provide VPSes.
But I have been following this thread with great interest from the
retail ISP point of view. I do hope we can all agree that "set reverse
DNS upon request" isn't a workable solution for any large scale retail
provider.
I want retail providers to drop reverse DNS entirely for their IPv4
and IPv6 access subnets.
Running a mail server on a retail access is just never going
to be a supported configuration. But some users will still do it, and
they should of course be allowed to do so.
If they want to be taken seriously as mail operators and interoperate
with the rest us, then they need to follow rules like "your MXes must
have FCRDNS" and "no MXes on retail access networks".
Scripted names provide absolutely zilch value over the
IPv6 address itself. And the fully automatic self-service will have a
few failure scenarios causing it to cost a bit of customer service.
Exactly. IME, it's cheaper to just have customers call or email for
their rDNS change requests.
So that's the conclusion for now at least, until there is some demand
for reverse DNS for IPv6. And I cannot imagine we're the only ISP
arriving there.
Lack of reverse DNS for IPv6 on retail access subnets has more value
than any programmatic rDNS option.
Are you
intentionally blocking mail servers runnning on retail access lines?
No rDNS results in a soft bounce. Repeated attempts hit a threshold
and generate a ticket. The false positive rate is amazingly low: in
six years, I have two permanent whitelist entries for legitimate hosts
with missing rDNS. I see more issues with hosts insisting on doing
opportunistic TLS, failing when I don't support broken crypto, and not
falling back to plaintext (AFAICT, it's older Ironport devices that do
this).
Do
you really believe it would help you in any way if you got a dummy
reverse name (of course with a matching forward too)?
Not at all. In fact, it would make my life as a mail admin easier if
everyone dropped reverse DNS for their retail access subnets.
