OT: Reverse Lookup Records for Mail Server

[Glenn Steen]

On 09/10/06, Billy A. Pumphrey <bpumphrey at woodmclaw.com> wrote:
> > -----Original Message-----
> > From: mailscanner-bounces at lists.mailscanner.info [mailto:mailscanner-
> > bounces at lists.mailscanner.info] On Behalf Of Glenn Steen
> > Sent: Monday, October 09, 2006 11:06 AM
> > To: MailScanner discussion
> > Subject: Re: OT: Reverse Lookup Records for Mail Server
> >
> > On 09/10/06, Billy A. Pumphrey <bpumphrey at woodmclaw.com> wrote:
> > > In the WIKI
> > > http://wiki.mailscanner.info/doku.php?id=best_practices&s=trusted
> > >
> > > The below is written.  I have known this to be a good practice for
> > > sometime, but DNS gets a little confusing for me sometimes.  I
> apologize
> > > for all of the OT that I do, but just searching the internet does
> not
> > > give suggestions.
> > >
> > > Have a reverse lookup that matches your HELO/EHLO.
> > > Many of these policies stem from the fact that spammers will forge
> > > addresses. When you send mail to a system that doesn't know you,
> you've
> > > become a potential spammer. You must show that you can be trusted
> before
> > > you will be trusted, and one way of doing that is to have a reverse
> > > lookup that matches what your system says it is. Unfortunately, this
> may
> > > be a problem in virtual hosting situations. At the very least make
> sure
> > > that your MX is listed in DNS as the name that will respond to the
> HELO.
> > > See RFC 2821 for more information on the SMTP command HELO.
> >
> > What this means is that if your host says it is host.example.net,
> > looking up the IP address you are connecting as should lead to that
> > name (and if that's not possible, for some unknowable reason... The MX
> > pointed to for example.net should be the hostnme you helo as...).
> >
> > > If the MailScanner machine is on the internal network, as in not in
> a
> > > DMZ, and host name ends not in the domain name, how does one set it
> up?
> > > Host names ends in host.domain.local.
> >
> > Thing is  that .local isn't a top level domain that you should
> > "spread" to the internet. If one were to try reach your host from the
> > internet, one would look up the MX for your domain, and go to that
> > address... What that host "thinks" it is named is pretty irrelevant,
> > as long as it answers in accordance to the _public_ DNS settings. So
> > in your case, you have a _private_ DNS setup that is geared toward a
> > (broken IMO) AD setup (the gospel according to M$... Sigh), and a
> > _public_ DNS entry for your MX gateway. This type of "split view" is
> > rather common. One might opt for not confusing oneself by not having
> > two separate naming spaces, but rather the same names, but different
> > views instead (much better:-).
> >
> > > Does the host name just need to be changed to host.domaain.com?
> That
> > > would seemingly cause problems communicating with the internal
> machines,
> > > or would it?
> >
> > Not really, no. It all depends on how you do things:-). As long as you
> > can find your way to MS-exchange.example.local (and the other way
> > around) and you have setup trusts etc, you should be fine.
> >
> > > So if the host name is mailscanner.domain.com, Then the reverse dns
> > > should be mailscanner.domain.com right?  Sounds right to me.
> > >
> > > What happens when the reverse DNS is mailscanner.domain.com but the
> > > actual host name is mailscanner.domain.local?
> >
> > As long as you set it up to accept for the domains involved, I see no
> > real problem. Handling a true split view DNS setup is rather more easy
> > than the .local idiocy... At least to my eyes:-).
> >
> > --
> > -- Glenn
> > email: glenn < dot > steen < at > gmail < dot > com
> > work: glenn < dot > steen < at > ap1 < dot > se
> > --
>
> Ok, thank you for the answer. One more thing and it will be clear to me
> I believe.  Is it best practice then to have all internal host that is
> behind the firewall to be something like:
> XPclient1.domain.com
> XPclient2.domain.com
> Etc.
>

Yes, that is exactlty what we have. Obviously, this is something one
has to set up when one creates (or recreates:-) the AD. Only thing you
need keep in mind after that are resources that have different
"presences" depending on if the view is from the outside (public DNS
for webserver(s), MX etc might lead to one set of (public) IP
addresses), or from the inside (private DNS leading to perheps other
addresses... or the same. Your choice is... well, not endless, but at
least up to you;-).
If the inside view of example.net (for example:-) use private
adresses, lets say 172.16.0.0/16 (mask 255.255.0.0), and your users
need be able to reach www.example.net (with a public address like
123.123.123.123), you'll just need keep an entry in example.net
(locally) to that effect (since the internal machines will be seeing
the local view of the example.net domain). For stuff that need differ
(for example local MX might not be exactly the same as the public
MX;-), you simply have different entries locally and publicly... And
for most things (that need a local, private view entry, but not a
public one) you only have them locally.
There just has to be loads written about this on the net... I'm just
too lazy to find it for you:-).

Anyway... That rather simple "problem" is what prompted a certain
company (that shall not be named, but has been know to figure as the
primary search result when googling for "more evil than satan
himself"...:-) to invent the .local idiocy. As if that would make it
any easier to live with?
Just another set of problems... and perhaps a bit more onerous to cope with.

Anyway, if your MX (MS) gateway is living in the DMZ, you likely have
already set a public address for it, and perhaps N(P)AT to that in the
firewall, so to solve your immediate problem (without rebuilding the
AD:) you could just make it handle the public domain by way of naming
(of the host), and the .local thing as an added domain (how to do this
differ somewhat between MTAs, but IIRC (Some real Sendmail guru will
correct this:-) you just need Cw for the relevant domain names...
If you feel up to it/can make it so (perhaps you have a smallish AD,
with friendly users:-), making it a normal sane split view thing would
probably be best though.

-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se