MX Record Issue

[John]

Currently the company hosting our DNS has it configured something like the
following (I can't do a zone xfer and I'm trying to get a copy of it. This
may contain typos but I'm just attempting to show the records contained in
DNS currently) -

@ 86400 IN SOA ns.company.com.
root.company.com. (
3000
10800
604800
86400
)
IN NS ns.company.com.
IN NS ns2.company.com.
IN NS ns3.company.com.
IN NS ns4.company.com.

mail.company.com. IN A 123.123.123.123
www.company.com. IN A 234.234.234.234

company.com. IN MX 10 mail.company.com.

Our mail addresses are user...@mail.company.com. I'm not sure why, it was
setup before I arrived. This goes back years. We're now having a problem
with a particular company where they cannot send email to us because there
isn't an MX record for the 'sub-domain' mail.company.com. They are running
an SMTP server from Tumbleweed.com, and they are using RDNS lookups to cut
down on SPAM. Our Internet provider for some reason doesn't have any PTR's
defined, I'm guessing because no one here asked them to. (I've only been
here < 2 months).

I've modified our mail server so that each user has an aliased email address
of user...@company.com. If that email address is used, then the company
above doesn't have a problem. The error that they are getting from their
tumbleweed software, which apparently started rejecting sending mail to us
recently (~ 2wks ago), is that it can't find the MX record. I'm thinking
that they changed something, but I've been told they haven't.

So, to fix this on our end, I believe I need to have the DNS hosting company
(despite protests from their support staff that it's definately not req'd)
add another MX record something like this -

mail.company.com. IN MX 10 mail.company.com.

And I need to contact our ISP, and have them add a PTR record for our mail
server.

I'm going to be adding a 2nd mail server in the next couple of months, so at
that point, I'd have (2) more MX records and an additional A record added,
with a lower priority pointing (100) to that server.

Am I missing something obvious (outside of typo's that I may have made in
the above example)? Is the additional MX record required?

Thanks.

John

[p...@icke-reklam.ipsec.nu]

Yes. And remind your dns-hostinmg company that it's not their task
to protest, they should do what you tell them ( if you are correct)

> And I need to contact our ISP, and have them add a PTR record for our mail
> server.

Should have been done long tiem ago. Every address you publish with
an 'A' record should have exactly one PTR record.

> I'm going to be adding a 2nd mail server in the next couple of months, so at
> that point, I'd have (2) more MX records and an additional A record added,
> with a lower priority pointing (100) to that server.

Correct

> Am I missing something obvious (outside of typo's that I may have made in
> the above example)? Is the additional MX record required?

Yes, it's what makes your service redundant ( as far as Internet delivery needs)

> Thanks.

> John

--
Peter Håkanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.

[John]

Thank you for the reply. I just needed to check with someone else to get
another opinion to feel more confident about my plan of action.

John

<p...@icke-reklam.ipsec.nu> wrote in message
news:cmdug8$17b7$1...@sf1.isc.org...

[Jonathan de Boyne Pollard]

J> [...] they cannot send email to us [...]
J>
J> mail.company.com. IN MX 10 mail.company.com.
J>
J> Is the additional MX record required?

No. The "Tumbleweed" software that your correspondents are using is, if
it really requires this, broken. (And if it's sending mail to you it's
an SMTP *client*, not an SMTP *server*, by the way.) It is not obeying
the algorithms specified in RFC 2821 section 5 and in RFC 974, as it should.

Suggest to your correspondents that they buy software that operates
properly, and that they take the broken software that they have back to
the vendor for a refund.

J> [...] they are using RDNS lookups to cut down on SPAM [...]

This is irrelevant to the task at hand, which is *them* sending mail to
*you*, not the other way around. (The daft and useless reverse lookups
are done by SMTP Relay servers, not by SMTP Relay clients.)