SMTP over IPv6 : gmail classifying nearly all IPv6 mail as spam since 20140818

[Matija Grabnar]

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 <list_ipv6-ops at bluerosetech.com> 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.
>