Mail PTR Records
mkettler at evi-inc.com
Mon Mar 3 22:30:21 GMT 2008
Richard Frovarp wrote:
> Peter Farrow wrote:
>> Matt Kettler 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.
>>> Well, that alone isn't a good reason to blindly toss RFC's aside.
>>> Some requirements of the RFCs are there for damn good reasons.
>>> However, in this case I suspect the activity isn't even a violation
>>> of an RFC, and not having a PTR record clearly violates their
>>> recommendations (albeit not their requirements).
>>> In general, it's really easy to claim something isn't complaint with
>>> the RFCs without any evidence to support it. We should all take such
>>> suggestions (including those generated by me) as unsubstantiated
>>> opinions until proven otherwise..
>> Its an RFC to have a matching forward and revserse DNS lookup, so not
>> having one or a mismatched one is a violation of RFC1912
>> To quote, verbatim,
>> "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
>> So you can legitimately bounce the email if the sending host has bad
>> forward/reverse DNS...
> What does "should" mean? should vs shall vs must isn't always the same
Agreed, should is not the same as must.
There's an RFC that specifies exactly how should and must are to be interpreted
in RFC documents. There is no RFC standard for "shall".
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
More information about the MailScanner