[RFCI-Discuss] is a reversename a must ?

[Rich Kulawiec]

On Tue, Jan 22, 2008 at 07:57:11AM +0100, Andreas Schulze wrote:
> Is there any RFC which requires a system *MUST* have any valid reverse name ?

Considerable debate has been expended on that point, with the answer
coming to down to "it depends on which RFCs you choose to include and
how you decide to interpret them".

Which is a good time to point out that there are really two kinds
of requirements for operating mail (and other) services: de jure
and de facto.  The de jure requirements are spelled out in the RFCs.
The de facto requirements aren't, but are nevertheless things that are
well-known to be best practices.

	[ If I'm recalling correctly, and I might not be, "de jure"
	means, literally, "of the law", and "de facto" means "of the facts".
	De jure requirements are things like RFCs and laws and regulations
	and other things that are formal documents.  De facto requirements
	are things that we've figured out but which aren't formalized. ]

An example of a de jure requirement is that per RFC 2821, local aliases
should never appear in SMTP transactions.  Which means that no mail server
should ever say "HELO fred", it should say "HELO fred.example.com".
An example of a de facto requirement is that (as far as I know) there is
no RFC which says "don't spew viruses from your mail server", but everyone
should know that's a bad idea and know why.

One of de jure requirements is that mail servers need to have DNS; a de facto
requirement is that they need to have rDNS.  (And a secondary one is that
those should agree.)  I consider it a best practice to reject/defer all mail
from hosts without rDNS -- it's a highly effective anti-spam tool.
And given that it's a matter of a single line of typing to set it up,
there really shouldn't be any mail servers without it.   I also, BTW,
reject on invalid HELO -- which also stops a lot of spam.  (Yes, it also
occasionally stops some non-spam, but I think that's fine: mail server
operators which can't get HELO right are proably getting lots of other
things wrong as well, so I don't really think I want to accept their
traffic until they start showing at least some signs of clue.)

If you're running a recent version of sendmail, then:

	FEATURE(require_rdns)dnl
	FEATURE(block_bad_helo)dnl

handle this nicely.  Similar features exist in other quality MTAs.

Incidentally, the network operator upstream from some of my servers
recently had a temporary issue with rDNS delegation, which in turn
caused those servers to lack rDNS for the better part of a day, which
in turn allowed me to get some idea of who else is doing this.  A number
of large ISPs -- including AOL -- will either defer or reject based on
missing rDNS, and I suspect that number is on its way up.

So in a practical sense, whatever we might decide from debate doesn't
matter: the world appears to have decided that rDNS is a requirement.

So my advice is:

1. Set up DNS

2. Set up matching rDNS

3. Make sure HELO matches -- unless there's a compelling
	reason to do otherwise

4. Make sure all of this is non-generic, e.g. something like

	ms-smtp-01.texas.rr.com
	mail5.example.com

instead of something like:

	175.42.196-77.rev.gaoland.net
	200-153-187-29.dsl.telesp.net.br

because there are any number of anti-spam projects busy cataloging
generic namespace and IP space occupied by hosts in generic namespaces,
and changes of getting mail accepted out of those aren't great.

---Rsk