[Mimedefang] Potential for Business mail servers tonot havereverse DNS

[Les Mikesell]

On Sat, 2006-09-23 at 00:30, John Rudd wrote:
> >
> > If a SHOULD could be interpreted as a requirement, there
> > wouldn't be any MUST's.
> >   
> 
> There is absolutely no logic to your statement.
> 
> 
> A MUST is _always_ a requirement.  Even if a SHOULD is sometimes treated 
> as a requirement for service (as that RFC clearly states) it does not 
> displace the need for MUSTS, because a SHOULD is _not_ _always_ a 
> requirement for service.

A SHOULD is _never_ a requirement.  That is why there is a MUST.
SHOULD's describe best practices, but by definition not strict
requirments for interoperation. 

> And, there is nothing in the definition of the RFC use of the term 
> "SHOULD" which says you MUST NOT treat a SHOULD as a requirement for 
> service.

You are, of course free to make any arbitrary choices about
what you want to accept for your own site or domain. You
can't however use an RFC SHOULD to justify it.  SHOULD
has a specific meaning, and it is not a strict requirement.

> The most you can say is that making a SHOULD a requirement for 
> service is as cautionary to those who choose deny service on a SHOULD as 
> it is cautionary to those who would choose to not adhere to the SHOULD.

No, you can say that is a misinterpretation.

> In this specific case, the SHOULD outlines the consequence of not 
> adhering to the SHOULD.  The purpose of a SHOULD is to allow deviation 
> but to caution those who would do so.  By making it a requirement for 
> service, the implementers of that policy are applying those 
> consequences.  They are not abusing the purpose of a SHOULD, confusing 
> it with a MUST, nor obsoleting the concept of a MUST.  To suggest so is 
> nonsense.

You are free to do whatever arbitrary things you want, but that's
not what the word means and you can't claim RFC compliance as
a reason for not interoperating in that circumstance.

-- 
  Les Mikesell
   lesmikesell at gmail.com