[AusNOG] IPv6 reverse DNS and Mail ...

[David Miller]

On 5/20/2013 5:07 PM, Mark Smith wrote:
> 
> 
> 
> 
> ----- Original Message -----
>> From: David Miller <dmiller at tiggee.com>
>> To: ausnog at lists.ausnog.net
>> Cc: 
>> Sent: Tuesday, 21 May 2013 2:23 AM
>> Subject: Re: [AusNOG] IPv6 reverse DNS and Mail ...
>>
>> On 05/20/2013 10:38 AM, Shane Short wrote:
>>>  On 20/05/2013, at 6:04 PM, Noel Butler <noel.butler at ausics.net> 
>> wrote:
>>>
>>>>  On Mon, 2013-05-20 at 16:28 +1000, Reuben Farrelly wrote:
>>>>
>>>>
>>>>>  "They don't have a PTR record" isn't an 
>> explanation that will cut it to 
>>>>>  non IT people, generally, and after the blank look has subsided 
>> you'll 
>>>>  "Sorry,  but we see that X has failed one of our many anti spam 
>> measures so was rejected" - That's good enough. It's been good 
>> enough for past near 20 years, fail to see why WE should change, just to appease 
>> lazy system admins, if they can't do their job properly, maybe their 
>> employers should know, so they can be replaced by someone who will do the job 
>> properly.
>>>>
>>>  Not to call anyone out in particular, the general contempt some sysadmins 
>> show for their users is phenomenal-- sometimes I think people forget why we have 
>> these networks in place. We run these networks to service a customer or business 
>> need, not to give you toys to play with during the day.
>>
>> We do run these networks to satisfy business needs, and one of the
>> business requirements passed to 'us' from the 'users' is that 
>> they would
>> like less spam.
>>  
> 
> How is lack of PTR an absolute and unquestionable indicator that email from that source is spam?
> 

AFAIK, there are NO "absolute and unquestionable" indicators that email
from a source is spam, so it would be unrealistic to expect that reverse
DNS checks meet this standard.

If there are NO "absolute and unquestionable" indicators that email from
a source is spam, then by your standard no service provider can use any
anti-spam filters and MUST accept and deliver any and all messages?  Is
this the argument you are making or have I misunderstood?

>>>
>>>  If the customer isn't getting their mail, you're not doing your 
>> job. You can't dismiss the person with "oh the other end is doing 
>> something I don't like so I'm rejecting their email"
>>
>> You are looking at this from the wrong perspective.  If the commonly
>> accepted requirement for reverse DNS is a huge detriment to message
>> flow, then this is a business opportunity.  You should setup an email
>> service without this constraint and corner the market for email services.
>>  
> 
> I think you're looking at it from the wrong perspective. Unless the SMTP RFCs require PTRs (i.e. MUSTs), then dropping email because they don't exist is quite fragile, and placing too much "anti-spam" meaning on the absence or presence of PTRs. Common operational practice doesn't make it a mandatory requirement. You can choose to enforce such a local policy, at the cost of local consequences.


RFC 1912 (circa 1996)

2.1 Inconsistent, Missing, or Bad Data

   Every Internet-reachable host should have a name.  The consequences
   of this are becoming more and more obvious.  Many services available
   on the Internet will not talk to you if you aren't correctly
   registered in the DNS.

   Make sure your PTR and A records match.  For every IP address, there
   should be a matching PTR record in the in-addr.arpa domain.  If a
   host is multi-homed, (more than one IP address) make sure that all IP
   addresses have a corresponding PTR record (not just the first one).
   Failure to have matching PTR and A records can cause loss of Internet
   services similar to not being registered in the DNS at all.  Also,
   PTR records must point back to a valid A record, not a alias defined
   by a CNAME.

Yes, these are 'should' statements and not 'must' statements, but the
consequences of not complying with the 'should' are clearly set out as
"loss of Internet services".

> Dropping email because of lack of PTRs is violating Jon Postel's Robustness Principle, which has served the Internet well for decades.
> 
> "Be conservative in what you do, be liberal in what you accept from others"
> 

I disagree.

It is obvious that "be liberal in what you accept" is not the same as
"accept everything" and it was never intended to be.

RFC 1122 expanded on the Robustness Principle:

1.2.2  Robustness Principle
  <snip>...
  "A corollary of this is "watch out
   for misbehaving hosts"; host software should be prepared, not
   just to survive other misbehaving hosts, but also to cooperate
   to limit the amount of disruption such hosts can cause to the
   shared communication facility."



> 
>>>
>>>  So what if someone on the other end of the world haven't set up rDNS 
>> properly on a box? Google don't set up any rDNS on much of their network 
>> infrastructure, which bothers me, shall I blackhole their traffic? I bet 
>> that'd last a whole 30 seconds before someone bitches me out.
>>>
>>>  -Shane.
>>>
>> -DMM
>>
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>