Re: Beating the spam filter ...

Hi guys,

Thanks, I've changed the MX record to point from a CNAME to an A
record. And I've fixed the issue regarding the missing A record for the
DNS name server. And an A record for the englishteachingkorea.com zone
file.

I'm not too sure about the PTR records though. Should my PTR records
for 72.232.183.2 resolve to my mailing domain
'englishteachingkorea.com', or to my inert non-mailing domain
'eccindustries.info' ? If they resolve to my non-mailing domain, won't
I have trouble getting mail servers to accept my mails ?

Also, is it OK to have my MX records for my EnglishTeachingKorea.com
point to

IN MX 10 mail.eccindustries.info.

mail here btw has an A record now ...

mail IN A 72.232.183.2

Thanks again and appreciated,

David


Bill Cole wrote:
In article <e64af$44d6a623$d08d6db4$18651@xxxxxxxxxxxxxxx>,
"Taylor, Grant" <gtaylor@xxxxxxxxxxxxxxxxx> wrote:

On 08/06/06 20:49, Bill Cole wrote:
I don't run any systems where hostname takes a -f flag, but I suspect it
is probably akin to the POSIX uname -n. A nodename.

No, "-f / --fqdn / --long" will cause hostname to report the fqdn of a system.

More weird names for Linux-trained admins to give to Solaris machines...
:)

(FWIW, that would be the default for at least some BSD systems'
'hostname' whose only possible option is -s for stripping the domain
part. "Unix" is so much fun...)

DNS really doesn't enforce or even really encourage that concept, and
common practices have made it increasingly pointless to publish the
nodename of a host publicly in association with any specific service.
Maybe a MTA will banner and HELO with its nodename, but pointing MX
records at it is a bit restrictive.

Possibly, but I believe this is more your opinion.

Perhaps, but one of the reasons to use many names referring to a single
machine is to associate names with services or sets of services, rather
than with physical machines, and to support various forms of
virtualization. A name that is not a machine's internal identity is more
easily moved to refer to another machine, and that capability seems to
be driving a lot of the interesting novelty in IT these days.

Which is a far less problematic situation than the MX->alias one, which
actually will not be followed by some resolvers. Asymmetrical A/PTR
resolution is not a circumstance that causes anything to not work,
absent very unwise forms of paranoid configuration.

Unfortunately such "... very unwise forms of paranoid configuration. ..."
is becoming more and more common place in spam filtering.

MX records have absolutely nothing to do with outbound mail, so I'm not
sure of the relevance. The typical uses I'm aware of for using DNS
symmetry checking in spam filtering tend to start with the HELO argument
or reverse DNS from the connecting IP address, not a name from the RHS
of any MX. What sort of filtering are you thinking of?

I was referring to your earlier statement of "... Asymmetrical A/PTR
resolution is not a circumstance that causes anything to not work, absent
very unwise forms of paranoid configuration. ...". I have heard report of
mail servers not accepting mail from hosts if the A / PTR records were
asymmetric. I agree that this should not be the case, however I fear that
it will become more so as people become over zealous while trying to fight
spam.

Yes, but that's far more relevant to outbound mail than to how you set
up inbound MX records. If a mail service provider tells customers to
just set up their own MX's pointing at their own names with A records
pointing at an IP of the provider, the lack of symmetrical PTR records
for those is invisible when that mail server sends mail because it isn't
using the ad hoc customer names when it sends mail. No one sane resolves
an MX and then refuses to pass along mail simply because the A record of
the MX target doesn't have a matching PTR.

Oh, and http://www.rfc-ignorant.org/policy-bogusmx.php might be of
interest. I think using the RFC-I lists for spam control is properly
career-limiting for a mail admin, but people do use them, and the "bogus
MX" list is probably the least problematic.


Why do you care about the "real name" so much?

It is my belief / opinion that this is the name that should be used to
identify the system.

Okay, but it does not have much functional operational advantage that I
can see. Anyone who really needs to know the "real" name can log in and
run hostname (maybe -f...) or if they can't do that maybe just see what
the MTA says in its banner (although that's not always the same as the
"real" name either.)


Certainly any Unix-ish machine will have a nodename, but there's no
reason that it needs to be ANY of the names found through rDNS of any of
its public IP addresses, much less the IP's on which it happens to be
listening on port 25 because there are MX's leading there.

It is my belief / opinion that this is unclean and problematic at best.

Well, "unclean" has the sound of Leviticus to it... I'm more interested
in how it might be problematic.

As an example, I administer a machine that calls itself
asewp452.vwoa.na.vwg internally. That name carries a complex meaning to
me and about a dozen other people, and it is in DNS from the viewpoint
of tens of thousands of other machines. It is not visible in DNS from
the outside world, although that machine provides services to the world
at large. It's MTA, accessible to the world, does not banner with that
name. There are multiple other names that are visible to the world in
DNS which would get someone from the world to that machine, but nothing
readily seen from a distance that would identify all those names as
referring to to the same host. This has never caused any problems.

For over a decade, scconsult.com has had the same primary MX record
pointing at sc1.scconsult.com. There has never been a machine accepting
that mail with that nodename at the OS level, and that's been 3 distinct
machines using 7 different IP addresses for the name over the years.
This causes no trouble. It does mean I can make another machine into my
primary mail exchanger without changing any DNS records.

That will work, and obviously has. However, I suspect that this will
become more of an issue in the coming years with some of the spam fighting
techniques that I've witnessed / had clients victim to.

It never has yet, in part because for all that time there has been a PTR
from whatever IP sc1.scconsult.com resolves to pointing back at
sc1.scconsult.com. At present it is one of 4 PTR's for that address, all
equally valid.


[...]

Please reread and / or rerespond with the fact that I was discussing CNAMEs
in general and not just their (dis)use in MX records.

One general problem with CNAME records is that there isn't a solid
operational consensus in how strong the "canonical" nature is. Back in
the early days of name-based virtual web hosting, at least one browser
helpfully treated CNAME records as grounds to "correct" URL's (and Host
headers...) One could probably make an argument from RFC1034 and its
predecessors that this is not wrong behavior, although it certainly
causes problems.

On the other side, NOT pushing the real name back up into the
application layer to replace the alias also can lead to trouble when
using systems such as Kerberos where a client has to address the server
by the name it sees itself as.

The fact that it has been a deprecated practice for 20 years in RFC's is
secondary.

I do not recall reading any thing that suggests that CNAMEs are
depreciated. Will you please point such out?

I was speaking specifically of pointing MX recoprds and addresses that
have CNAME's.

--
Now where did I hide that website...

.

Relevant Pages

  • Re: Stub zone and phantom CNAME
    ... One of the entries on the peoples DNS is for www for that zone. ... An NSlookup indicates that the www.abc.com is pointing to the the IP ... If we delete the CNAME in the cache everything starts working again. ...
    (microsoft.public.windows.server.dns)
  • Re: TLD Resolving Woes
    ... > I've recently migrated from an ISP that handled my DNS services to one ... > get to a proper configuration. ... for the domain ending with trailing dot pointing ... You have it pointing to a CNAME which can cause a ...
    (comp.os.linux.networking)
  • Re: DNS & Windows 2003 Server
    ... In the gamerskeep.net zone, just make an A record called ... > www pointing to 64.202.163.124. ... Delete the CNAME record. ... >> 2) List of all Forward Lookup Zones in the DNS MMC ...
    (microsoft.public.windows.server.general)
  • Re: DNS & Windows 2003 Server
    ... In the gamerskeep.net zone, just make an A record called ... www pointing to 64.202.163.124. ... Delete the CNAME record. ... > 2) List of all Forward Lookup Zones in the DNS MMC ...
    (microsoft.public.windows.server.general)
  • Re: Beating the spam filter ...
    ... touch on the matter agree that pointing an MX at a name that has a CNAME ... of abstraction for the host name of mx.hosting-company.tld such that they ... to a pool with out the need to update all the client DNS zones. ... It is dead wrong to have multiple CNAME records for one name. ...
    (comp.mail.sendmail)