There is no way for a non-authorized requestor to find out the hosts of a
domain, but an anonymous requestor can look up a record. So, if you have
mail to [EMAIL PROTECTED], the MTAs will look for an MX
record at accounting.public.domain.tld, and if found, deliver as directed.
Failing that, they will try public.domain.tld, and if found, deliver as
directed. Failing that, they will try domain.tld, and if found, deliver as
directed. Failing that, they will report Unknown Host (although some MTAs
will try for an A record).

So, only if accounting.public.domain.tld needs to be a DIFFERENT MX than
public.domain.tld or domain.tld would you want any MX records other than
"@". This will be far less confusing. Your implementation (two MX, one for
"@" and one for "mail") will actually be faster if there are a lot of folks
using "mail." in the addresses, but it's certainly not a standard solution.
The more conventional the zone, the less confusing for everybody.

Just look at all the comments your thread has generated! If you can confuse
the users of this list, I bet you can confuse the sysadmins on lots of small
SMTP servers worldwide<g>.

Dan

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Imail Admin
Sent: Friday, July 01, 2005 7:31 PM
To: [email protected]
Subject: Re: [IMail Forum] OT: mx record is there, yet isn't


DNS Report shows success now because I added the root MX record, so that
zone now has both MX records (pointing to the same mail server).  As for why
we didn't just do that to begin with: we did what the client told us to do.
I viewed this (only having an MX record named "mail") as just fine, as long
as they were always careful to reference mail.salemradiology.com (in email
addressing, for example), rather than just using salemradiology.com.
However, the thing that keeps bothering me now is why DNS Report only
expects a root MX record, and not a named MX record.  If this is just a
matter of convention, as I always believed, then they should be able to
handle it both ways.  If, however, I'm just ignorant and the root record is
somehow special, then I need to be more aware of this to avoid future
problems.  So how much of this is Standards, and how much is just
convention?

Ben

----- Original Message -----
From: "Dan Barker" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, July 01, 2005 3:34 PM
Subject: RE: [IMail Forum] OT: mx record is there, yet isn't


> Maybe DNSReport had your old values cached. It's reporting success now.
Most
> MX records look like:
>
> @                       MX      5       mail.visioncomm.net.
>
> Your's evidentally looks like
>
> mail                    MX      5       smtpgw.slmdc.pnwtg.com.
>
>
> Unless there is ALSO an
>
> @                       MX      5       somewhereelse.domain.tld,
>
> why wouldn't you just put
>
> @                       MX      5       smtpgw.slmdc.pnwtg.com.
>
> in your zone file? It would be far less confusing.
>
> Although DNS Report is showing the records now happily, and dig certainly
> will dig (har har) them out, plain ole windoze nslookup doesn't show the
MX
> record unless you include the "mail.". Is this by design? IE: Mail to
> salemradiology.com is supposed to be undeliverable and mail to
> mail.salemradiology.com is supposed to work? I don't think so<g>. If not,
> then putting the MX record at the root (@ in DNSspeak) will work for both
of
> them. (If both exist):
>
>
> @                       MX      5       smtpgw.slmdc.pnwtg.com.
> mail                    CNAME           smtpgw.slmdc.pnwtg.com.
>
>   or
>
> @                       MX      5       smtpgw.slmdc.pnwtg.com.
> mail                    A               66.224.124.100
>
> Dan Barker
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Imail Admin
> Sent: Friday, July 01, 2005 6:02 PM
> To: [email protected]
> Subject: Re: [IMail Forum] OT: mx record is there, yet isn't
>
>
> Well, I think everyone's got the same point, but Sandy probably says it
> best.  We have a single MX record for the host "mail" in that zone.  We do
> not have an MX record for a root host (one that does not have a name) for
> the same zone.  So when we do a lookup on the mail MX record, we see it.
> However, apparently DNS Report only looks for the root record, which
doesn't
> exist in this case.  Sandy calls this a "restriction", I would call it a
> bug.
>
> I am not (not even close to being) a DNS expert, but some of the other
> replies posted do not fit with my understanding of the DNS setup.  The
host
> "mail" is not a subdomain, it's a host.  And the record that has 'no name'
> is a "root" host, but it's still a host, and not a subdomain.  There is
only
> one domain/zone, and that's salemradiology.com.  The rest are records for
> hosts within that domain.  At leat, I always considered hosts and
subdomains
> to be different animals.  So I expected that DNS Report would look through
> all the records in this zone, looking for any MX records, and identifying
> those as mail servers; instead, it only looked for a "root" host mail
> server.  It's kind of like assuming that a web site name must start with a
> "www."; that's the common usage, but it is not required.
>
> If I'm wrong in this understand, I'd love to hear it.  And thanks for all
of
> the replies; all let our clients know that the best way to fix this is to
> simply add that root MX record.
>
> Ben
>
> ----- Original Message -----
> From: "Sanford Whiteman" <[EMAIL PROTECTED]>
> To: "IMail Admin" <[email protected]>
> Sent: Friday, July 01, 2005 12:07 PM
> Subject: Re[2]: [IMail Forum] OT: mx record is there, yet isn't
>
>
> > > Why doesn't it see this mx record?
> >
> > It's  a  restriction  of  DNS  Report,  which only works on standalone
> > zones,  not  hosts  within those zones. The records are accessible via
> > dig, et al.
> >
> >
>
http://us.mirror.menandmice.com/cgi-bin/DoDig?host=4.2.2.1&domain=mail.salem
> radiology.com&type=MX&recur=on
> >
> > --Sandy
> >
> >
> > ------------------------------------
> > Sanford Whiteman, Chief Technologist
> > Broadleaf Systems, a division of
> > Cypress Integrated Systems, Inc.
> > e-mail: [EMAIL PROTECTED]
> >
> > SpamAssassin plugs into Declude!
> >
>
http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release
> /
> >
> > Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail
> Aliases!
> >
>
http://www.imprimia.com/products/software/freeutils/exchange2aliases/downloa
> d/release/
> >
>
http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/re
> lease/
> >
> >
> > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
> > List Archive:
http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
> > Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
> >
>
>
> To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
> List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
> Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
>
>
> To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
> List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
> Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
>


To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/


To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/

Reply via email to