Mail PTR Records

[John Hinton]

Richard Frovarp wrote:
> mikea wrote:
>> On Mon, Mar 03, 2008 at 01:15:21PM -0600, Nathan Olson wrote:
>>  
>>> It's not RFC-compliant.
>>>     
>>
>> As has been mentioned elsethread, a number of techniques which are 
>> increasingly necessary for survival are not RFC-compliant.
>> Many RFCs were written when the Internet was kinder, gentler, and MUCH
>> less dangerous than it is now. They have not changed, though the 'Net
>> certainly has. Blind adherence to them in the face of evidence that 
>> that adherence opens windows of vulnerability is not necessarily dood
>> or wise.
>>
>>   
> The issue is you'll see people break the RFC's because they are upset 
> someone else broke another part of the RFC's. Becomes a bit hypocritical.
I think this thread is a dead horse. Do you reject any email to any 
address for which you should receive email? If so, what does that? 
Perhaps you may be running spamhaus.zen at the smtp level? This is not 
RFC compliant. Do you reject mail if it exceeds 100 GB? I know of no 
size limits allowed within the RFCs. Is there a RFC that allows one to 
change the subject line of incoming email, like adding SPAM to the front 
of it?

The bottom line is most of the huge ISPs, AOL, Comcast, Verizon, and on 
and on and on, all reject if there is no reverse DNS. Call it what you 
want, but if someone doesn't have a legit PTR, they have what amounts to 
being a broken email system by today's standards. Therefore, rejecting 
based on no PTR has become a standard. Just like having to receive html 
email due to Micro$oft has become a standard.

OK... I'm through beating this dead horse.

John Hinton