Mail PTR Records

[Peter Farrow]

Matt Kettler wrote:
> 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.
Ah yes but you can legitimately reject big messages

http://www.ietf.org/rfc/rfc1870.txt


>
> 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
>
You s