Mailing List Archive

On 8/22/2014 2:46 AM, Matija Grabnar wrote:
> So, much as I would LIKE to have reverse IPv6 DNS on my mail servers, in
> some cases it is just not possible.

Can you describe those cases? I can't think of any scenarios where
you'd run a correctly-configured public MX and not have reverse DNS.

On 2014-11-02 09:53, Darren Pilgrim wrote:
> On 8/22/2014 7:32 AM, Lorenzo Colitti wrote:
>> Note that from the text it sounds like SPF / DKIM is not strictly
>> required, but it looks like a PTR record is a hard requirement.
>
> PTRs are a hard requirement, yes. That's not a problem. All places
> where you can run a legitimate MX will have working reverse DNS and
> nearly all will facilitate FCRDNS.
>
> The problem is Google ignores the fact you must not hard fail on DNS.
> Even if the response is NXDOMAIN, the most you can do is soft bounce
> because you can not know why you didn't get an RR. Gmail hard bounces
> on such errors even though doing so accomplishes nothing you could
> consider an anti-spam countermeasure.
>
> I get relay failure to gmail at least once every day. It is always
> the same thing: gmail's server didn't get a response to the PTR lookup
> and 5xx'd the mail. I've even seen mail to the same server succeed
> mere seconds later. Google has an internal reliability problem and a
> policy that pushes the cost out to those with no power to fix it.
>
> "Please resend the email and let me know if it fails again" is not
> what my users want to hear, but it's the only answer that works.

At least that's an observation one can work with. If you have server
logs that show this problem I take them in private mail. Of course, if
the problem is actually on your DNS servers side it's not really a
reliability problem internal to Google.

Kind regards
Philipp Kern

On Nov 02, Darren Pilgrim <darren@bluerosetech.com> wrote:

> The problem is Google ignores the fact you must not hard fail on DNS. Even
> if the response is NXDOMAIN, the most you can do is soft bounce because you
> can not know why you didn't get an RR. Gmail hard bounces on such errors
No, not really. If the response is NXDOMAIN then there is no rDNS.

> I get relay failure to gmail at least once every day. It is always the same
> thing: gmail's server didn't get a response to the PTR lookup and 5xx'd the
> mail. I've even seen mail to the same server succeed mere seconds later.
> Google has an internal reliability problem and a policy that pushes the cost
> out to those with no power to fix it.
I think that you have a problem, not Google.

--
ciao,
Marco

On 11/02/2014 06:55 PM, Darren Pilgrim wrote:
> On 8/22/2014 2:46 AM, Matija Grabnar wrote:
>> So, much as I would LIKE to have reverse IPv6 DNS on my mail servers, in
>> some cases it is just not possible.
>
> Can you describe those cases? I can't think of any scenarios where
> you'd run a correctly-configured public MX and not have reverse DNS.
Bah - I have a correctly configured public MX on my home network (static
IPv4, static IPv6). It's correctly configured, but I have been as of now
unable to convince my provider to delegate reverse DNS (for IPv6) to my
DNS. They are simply not set up for that. Otherwise, the MX is
completely correctly configured. Under IPv4 it even has a PTR (for the
lone static IPv4 address).

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.

It is completely possible to have a "correctly configured public MX" and
not have a reverse DNS - unless your definition of "correctly configured
public MX" demands a reverse DNS, but I assume you wouldn't insult both
our intelligences with a "no true scotsman" fallacy of that sort.

On 11/2/2014 12:38 PM, Matija Grabnar wrote:
> On 11/02/2014 06:55 PM, Darren Pilgrim wrote:
>> On 8/22/2014 2:46 AM, Matija Grabnar wrote:
>>> So, much as I would LIKE to have reverse IPv6 DNS on my mail servers, in
>>> some cases it is just not possible.
>>
>> Can you describe those cases? I can't think of any scenarios where
>> you'd run a correctly-configured public MX and not have reverse DNS.
>
> Bah - I have a correctly configured public MX on my home network (static
> IPv4, static IPv6). It's correctly configured, but I have been as of now
> unable to convince my provider to delegate reverse DNS (for IPv6) to my
> DNS. They are simply not set up for that. Otherwise, the MX is
> completely correctly configured. Under IPv4 it even has a PTR (for the
> lone static IPv4 address).

Get a small VPS and have it act as MX and smarthost relay.

> 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.

If the provider won't or is unable to provide reverse for the IPv6
static address you have, it will be sub-optimal for you to continue to
advertise and/or use the IPv6 address for SMTP.

It's all part of the 'prove it's not a dynamic ip address' and part of
the 'proper reverse DNS provides some level of authority/delegation to
use that ip address for legit SMTP usage'.

Lyle Giese
LCR Computer Services, Inc.


On 11/02/14 14:38, Matija Grabnar wrote:
> On 11/02/2014 06:55 PM, Darren Pilgrim wrote:
>> On 8/22/2014 2:46 AM, Matija Grabnar wrote:
>>> So, much as I would LIKE to have reverse IPv6 DNS on my mail
>>> servers, in
>>> some cases it is just not possible.
>>
>> Can you describe those cases? I can't think of any scenarios where
>> you'd run a correctly-configured public MX and not have reverse DNS.
> Bah - I have a correctly configured public MX on my home network
> (static IPv4, static IPv6). It's correctly configured, but I have been
> as of now unable to convince my provider to delegate reverse DNS (for
> IPv6) to my DNS. They are simply not set up for that. Otherwise, the
> MX is completely correctly configured. Under IPv4 it even has a PTR
> (for the lone static IPv4 address).
>
> 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.
>
> It is completely possible to have a "correctly configured public MX"
> and not have a reverse DNS - unless your definition of "correctly
> configured public MX" demands a reverse DNS, but I assume you wouldn't
> insult both our intelligences with a "no true scotsman" fallacy of
> that sort.

Darren Pilgrim <list_ipv6-ops@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.

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. 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.

But if this is going to require reverse DNS, then we have a problem.
Because, after a bit back and forth discussing different reverse DNS
options like scripted dummies or fully automatic self-service, we
decided to drop reverse DNS for retail IPv6 accesses. It's just not
worth the effort. 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. And
also some development resources, and we have some really lazy
programmers ;-)

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.

Where does this leave anyone requiring reverse DNS? Are you
intentionally blocking mail servers runnning on retail access lines? 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)? Because
realistically, that is the only viable solution I see. Even with a self
service reverse DNS in place, there will be enough users not knowing how
to enable it but still setting up a mail server. So the scripted names
are necessary as a "backup solution".

It just seems so pointless. The dummy names will be longer than the
address and will contain the exact same information.



Bjørn

On 11/03/2014 01:52 AM, Lyle Giese wrote:
> If the provider won't or is unable to provide reverse for the IPv6
> static address you have, it will be sub-optimal for you to continue to
> advertise and/or use the IPv6 address for SMTP.
>
> It's all part of the 'prove it's not a dynamic ip address' and part of
> the 'proper reverse DNS provides some level of authority/delegation to
> use that ip address for legit SMTP usage'.
My SPF record does exactly that: it provides a level of authority for
that particular host to send mail for my domain.
In a much better, finer grained delegation, since a PTR maps to a single
domain, while a SPF specifies exactly *which* domains permit that
particular host to send mail.

The "need a PTR" requirement was created back when SPF was not even a
glint in anybody's eye. While I would prefer to have PTR records for all
my hosts, I don't agree having no PTR merits a clear rejection of a mail
with a valid SPF record for the host.

On 11/3/2014 3:51 AM, Matija Grabnar wrote:
> On 11/03/2014 01:52 AM, Lyle Giese wrote:
>> If the provider won't or is unable to provide reverse for the IPv6
>> static address you have, it will be sub-optimal for you to continue
>> to advertise and/or use the IPv6 address for SMTP.
>>
>> It's all part of the 'prove it's not a dynamic ip address' and part
>> of the 'proper reverse DNS provides some level of
>> authority/delegation to use that ip address for legit SMTP usage'.
> My SPF record does exactly that: it provides a level of authority for
> that particular host to send mail for my domain.
> In a much better, finer grained delegation, since a PTR maps to a
> single domain, while a SPF specifies exactly *which* domains permit
> that particular host to send mail.
>
> The "need a PTR" requirement was created back when SPF was not even a
> glint in anybody's eye. While I would prefer to have PTR records for
> all my hosts, I don't agree having no PTR merits a clear rejection of
> a mail with a valid SPF record for the host.

On the other hand, their server/their rules. You need to be aware of
their rules if you want to send email to them abide by them as best you can.

Old habits die hard as we all know in the email world.

Lyle Giese
LCR Computer Services, Inc.

On 11/3/2014 1:38 AM, Bjørn Mork wrote:
> Darren Pilgrim <list_ipv6-ops@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.

On 03/11/2014 22:38, Bjørn Mork wrote:
...
> It just seems so pointless. The dummy names will be longer than the
> address and will contain the exact same information.

Quite. It's idiotic. And if I was a paranoid mail operator, I would
put in some heuristic code to identify such dummy names and treat
them as if there was no PTR record, since they do nothing to actually
validate the source in any real way.

Brian

On 11/3/2014 11:27 AM, Brian E Carpenter wrote:
> On 03/11/2014 22:38, Bjørn Mork wrote:
>> It just seems so pointless. The dummy names will be longer than the
>> address and will contain the exact same information.
>
> Quite. It's idiotic. And if I was a paranoid mail operator, I would
> put in some heuristic code to identify such dummy names and treat
> them as if there was no PTR record, since they do nothing to actually
> validate the source in any real way.

Rulesets like fqrdns exist for exactly that purpose.

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@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.
>

On 11/4/14 1:43 AM, Matija Grabnar wrote:
> 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.

Right-o! :) You see, the problem is that even if a tiny percentage of
mail is originating from well-run servers in consumer space, the
overwhelming majority of it is spam, primarily from infected hosts. So
never mind rDNS (which is a very cheap and useful initial test to
perform), most ISPs publish indexes of their residential space to allow
the larger mail providers to blacklist that space up front.

> Since our goals are exactly opposite, I don't think we'll ever see
> eye-to-eye on what steps are appropriate.

It's fine for you not to agree, as long as you understand the landscape.
:) Several others have already given you the excellent advice to get a
cheap VPS and do your thing(s) on a network that is well supported for
those things. If you're interested I'm sure we can find you some solid
recommendations. Make sure that you find out in advance what address
space you'll be on. That way you can check the reputation lists in
advance. It would suck to get on a new system only to find that still
can't send mail.

Good luck,

Doug

On 11/04/2014 06:01 PM, Doug Barton wrote:
> On 11/4/14 1:43 AM, Matija Grabnar wrote:
>> 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.
>
> Right-o! :) You see, the problem is that even if a tiny percentage of
> mail is originating from well-run servers in consumer space, the
> overwhelming majority of it is spam, primarily from infected hosts. So
> never mind rDNS (which is a very cheap and useful initial test to
> perform), most ISPs publish indexes of their residential space to
> allow the larger mail providers to blacklist that space up front.

I remember, some years ago, people making *exactly* the same argument
for blocking all the mail from Asian countries. I found that a bad
argument then, I find it a bad argument now.
>> Since our goals are exactly opposite, I don't think we'll ever see
>> eye-to-eye on what steps are appropriate.
>
> It's fine for you not to agree, as long as you understand the
> landscape. :) Several others have already given you the excellent
> advice to get a cheap VPS and do your thing(s) on a network that is
> well supported for those things. If you're interested I'm sure we can
> find you some solid recommendations. Make sure that you find out in
> advance what address space you'll be on. That way you can check the
> reputation lists in advance. It would suck to get on a new system only
> to find that still can't send mail.

I remember the time when the Internet was the place where "the little
people" (as opposed to big corporations) could experiment and innovate.
IPv6, with it's no-need-for-dynamic addressing should make that easier,
not harder. (Provided their provider doesn't block incoming connections
on a network-wide level).

A person incapable of properly configuring SMTP on their home server
would be equally incapable of properly configuring a hired VPS server.
And vice versa, someone capable of properly configuring a VPS server is
equally capable of configuring a server in their home.

So I argue in favor of examining the mail itself and what can be
determined of the mail server, and giving less weight to just what
network it comes from.

Prejudice expends less energy, true, but it tends to false positives. So
I argue that prejudice, in general, is a bad policy.


>
> Good luck,
>
> Doug
>