Mail PTR Records

[Matt Kettler]

John Hinton wrote:
> 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. 

Is it non compliant? There's nothing in the RFCs that prohibit blocking such 
email. Just because a RFC doesn't explicitly tell you you can, doesn't mean you 
MUST NOT.

I see nowhere that any RFC says you must always accept email for a valid 
recipient. I see nowhere that says you must not refuse email from hosts of your 
choosing.

RFC 2821 states:
"   From the Internet side, the gateway SHOULD accept all valid address
    formats in SMTP commands and in RFC 822 headers, and all valid RFC
    822 messages."

However, that's a SHOULD, not a MUST. It is not a standards violation to deviate 
from it.


> Do you reject mail if it exceeds 100 GB? I know of no 
> size limits allowed within the RFCs. 

I know of nowhere where such limits are disallowed. Therefore, by default, they 
are acceptable.

There's certainly examples in the RFC's of tempfailing mail due to lack of 
available storage. RFC 821 creates the 452 code explicitly for this purpose.

I see nowhere that would prohibit a system from enforcing a size limit on email, 
either by 4xx or 5xx error code. Can you find one?


> Is there a RFC that allows one to 
> change the subject line of incoming email, like adding SPAM to the front 
> of it?

RFC 2821 states that relay SMTP systems do not modify the message other than 
adding trace headers, however not all SMTP systems are relays. Gateways are 
allowed to modify. Normally gateways deal with clients, not server to server 
traffic.

However, RFC 2821 explicitly addresses firewalls that rewrite headers in server 
to server transfers and says these should be considered gateways.

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

Personally, I have yet to see anyone, anywhere point out how this violates an 
RFC. I've found one informational RFC that suggests this practice is common and 
should be expected. (RFC 1912)

> 
> OK... I'm through beating this dead horse.
> 
> John Hinton