Sign in with
Sign up | Sign in
Your question

Reverse DNS and mail server

Last response: in Windows 2000/NT
Share
Anonymous
May 24, 2005 9:43:22 PM

Archived from groups: microsoft.public.win2000.dns (More info?)

I guess I need some clarification here; my understanding was that properly
configured mail server should have as follow:
1. Static public IP address
2. MX record for it and
3. PTR added by ISP so IP address of mx record can be resolved to FQDN

A reverse DNS lookup takes the IP address that’s trying to make the
connection, and checks to see if there is a registered domain associated with
it.

For example, if an incoming message claims to be coming from the
66.160.177.11 IP address, an ISP would look up the domain to see if it
resolves to lyris.com. If it doesn’t, the message may be a forgery—or, the
hapless sender may not have a correct DNS entry. In either case, the message
will most likely be identified as spam.

And all it cares is domain name in this example lyris.com, even though PTR
returns mx1.lyris.com what counts is lyris.com. Yes? No?

Here is the reason why I’m asking for:

1. sender email us at joe.user@mycorpdomain.com
2. email goes out and looking in external DNS for MX record for
mycorpdomain.com which is resolved to public IP x.x.x.x
3. email is delivered to our domain
4. Joe User respond to sender – email goes out and is reaching mail server
which does reverse lookup, so
5. recipient mail server knows what IP address is trying to make connection
(in this example x.x.x.x ) and knows that sender claims to be from (in this
example) mycorpdomain.com
6. so recipient mail server takes connecting IP address and does reverse
lookup, as a result it gets mail1.mycorpdomain.com

Message is bounced back with following reason:

550 Requested actions not taken - SMTP sender domain
(exsvr1.mycorpdomain.com) not found in the DNS

Where exsvr1.mycorpdomain.com is our third party anti-virus/mail filtering
software between firewall and mail server, and the way is setup is that mx
record of mail1.mycorpdomain.com has public IP of x.x.x.x pointing to
external interface of the firewall which then is NATed and redirected to
internal exsvr1.mycordomian.com.

I kind of can see how do they get this name (exsvr1.mycorpdomain.com) in
returned NDR because if you lookup header of incoming messages you see
something similar to:

Received: from exsvr1.mycorpdomain.com ([x.x.x.x])
by their.mail.server.receipient_domain.com (SMSSMTP 4.1.4.30) with SMTP id
M2005052413322418434
for <user@receipient_domain.com>; Tue, 24 May 2005 13:32:24 -0500

x.x.x.x is my public IP which (as described above) can be resolved to
mail1.mycorpdomian.com but not exsvr1……

does this mean you need to have physical smtp/mail box named same as mx
record ?in my case I would either rename box or call ISP and change so
x.x.x.x has PTR resolved to exsvr1.mycorpdomain.com instead
mail1.mycorpdomain.com ???

was I all this time wrong about how it works? I always though DNS reverse
lookup takes IP and check registered domain in this case mycorpdomain.com

Can someone verify that?
Anonymous
May 25, 2005 2:26:20 AM

Archived from groups: microsoft.public.win2000.dns (More info?)

"Rafal W." <RafalW@discussions.microsoft.com> wrote in message
news:B7102DE5-417E-4F91-8F3E-7CEEB13F84E3@microsoft.com...
> I guess I need some clarification here; my understanding was that properly
> configured mail server should have as follow:
> 1. Static public IP address

> 2. MX record for it and

I know this is a good idea for the sender but it is actually
due to a misuse of the MX record by some who will (choose)
to drop mail based on this criteria -- I personally do not set
my receiving server to do this.

The reason: A legitimate email OUTBOUND server may not
also be an INBOUND receiver of email and that is the real
purpose of the MX record: identifying servers who can receive
mail for a domain.

> 3. PTR added by ISP so IP address of mx record can be resolved to FQDN

The pointer should definitely be registered and should agree with the
self-reported name (HELO xxx) of the sending server.

IF you can/do create the MX record then it should also be using this
name.

> A reverse DNS lookup takes the IP address that's trying to make the
> connection, and checks to see if there is a registered domain associated
with
> it.

True it checks for the registration of the servers host DNS name (which
is also a technically a domain name -- it does not check for a 'parent
domain' in these sense the word domain name is commonly used.)

> For example, if an incoming message claims to be coming from the
> 66.160.177.11 IP address

There is not 'claim' here - -in order to do SMTP on connection
oriented TCP the return address must actually work during the
entire conversation between sender and receiver.

>, an ISP would look up the domain to see if it
> resolves to lyris.com.

No to see that it resolves first to ANY NAME.

Then it would compare that name (if any) to the name reported
in the HELO message to determine if it is lying in the HELO.

> If it doesn't, the message may be a forgery-or, the

It is more likely to be a temporary or a forgery.

> hapless sender may not have a correct DNS entry. In either case, the
message
> will most likely be identified as spam.

By many servers.

> And all it cares is domain name in this example lyris.com, even though PTR
> returns mx1.lyris.com what counts is lyris.com. Yes? No?

Well, if the PTR says mx1.lyris.com then it expect an MX
(if it checks this) that says LYRIS (or whoever the email is
from has an MX of THATDOMAIN -> mx1.lyris.com).

But note it may be delivering mail for LyrisCustomer.com too
then it wouldn't be checking the LYRIS mx but the LyrisCustomer.com
MX (if it checks those.)

It may also be checking SPF records but it would foolish to
reject email solely based on the lack of such -- though sensible
to weight the message as less likely spam with a good SPF and
more likely spam without.

If however the SPF exists it would only accept the mail (a good
bet) if the SPF authorizes that the particular email server to send
email on it's behalf -- if the SPF exists and it doesn't authorize
this server then it is likely a forged record and may even be one
of those virus/trojans that forge other people's return address.

Also, very few DNS server actually have the SPF record type and
so most people use the TXT substitute.

SPF checking should use the SPF if present, but check for and use
the (alternative) TXT form of the SPF if the true SPF record does
not exist.

SPF is not however a mandatory standard so dropping solely on
due to not finding it is usually foolish -- but certainly anyone is
free to accept or reject any email they choose, except perhaps
on addressed to abuse@domain.com

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

> Here is the reason why I'm asking for:
>
> 1. sender email us at joe.user@mycorpdomain.com
> 2. email goes out and looking in external DNS for MX record for
> mycorpdomain.com which is resolved to public IP x.x.x.x
> 3. email is delivered to our domain
> 4. Joe User respond to sender - email goes out and is reaching mail server
> which does reverse lookup, so
> 5. recipient mail server knows what IP address is trying to make
connection
> (in this example x.x.x.x ) and knows that sender claims to be from (in
this
> example) mycorpdomain.com
> 6. so recipient mail server takes connecting IP address and does reverse
> lookup, as a result it gets mail1.mycorpdomain.com
>
> Message is bounced back with following reason:
>
> 550 Requested actions not taken - SMTP sender domain
> (exsvr1.mycorpdomain.com) not found in the DNS
>
> Where exsvr1.mycorpdomain.com is our third party anti-virus/mail filtering
> software between firewall and mail server, and the way is setup is that mx
> record of mail1.mycorpdomain.com has public IP of x.x.x.x pointing to
> external interface of the firewall which then is NATed and redirected to
> internal exsvr1.mycordomian.com.
>
> I kind of can see how do they get this name (exsvr1.mycorpdomain.com) in
> returned NDR because if you lookup header of incoming messages you see
> something similar to:
>
> Received: from exsvr1.mycorpdomain.com ([x.x.x.x])
> by their.mail.server.receipient_domain.com (SMSSMTP 4.1.4.30) with SMTP id
> M2005052413322418434
> for <user@receipient_domain.com>; Tue, 24 May 2005 13:32:24 -0500
>
> x.x.x.x is my public IP which (as described above) can be resolved to
> mail1.mycorpdomian.com but not exsvr1..
>
> does this mean you need to have physical smtp/mail box named same as mx
> record ?in my case I would either rename box or call ISP and change so
> x.x.x.x has PTR resolved to exsvr1.mycorpdomain.com instead
> mail1.mycorpdomain.com ???
>
> was I all this time wrong about how it works? I always though DNS reverse
> lookup takes IP and check registered domain in this case mycorpdomain.com
>
> Can someone verify that?
>
Anonymous
May 25, 2005 2:26:21 AM

Archived from groups: microsoft.public.win2000.dns (More info?)

Thanks for responding, just quick question if I'm understanding this part
correctly: when you saying:
> The pointer should definitely be registered and should agree with the
> self-reported name (HELO xxx) of the sending server.

I telnet to my mail1.mycorpdomain.com on port 25 then helo <whatever> server
is responding :
250 exsvr1.mycorpdomain.com Hello

So going back to my original question should my PTR for mx record (server
does both inbound and outbound) be exsvr1.mycorpdomain.com instead mail1…

Is this what you mean when saying self-reported name HELO xxx ? If this is
the case then in my case it’s not a big deal, because my AD domain name is
same as public registered domain name, I just need to change mx recor and
call ISP asking to modify PTR to be exsvr1... instead mail1 now, but what
about people who named their AD i.e domain.local ?? you telnet to their mail
server mx.domain.com 25 and get in respond server_name.internal_domain.local
, their ISP cannot create PTR on external NS for .local, can they?

"Herb Martin" wrote:

> "Rafal W." <RafalW@discussions.microsoft.com> wrote in message
> news:B7102DE5-417E-4F91-8F3E-7CEEB13F84E3@microsoft.com...
> > I guess I need some clarification here; my understanding was that properly
> > configured mail server should have as follow:
> > 1. Static public IP address
>
> > 2. MX record for it and
>
> I know this is a good idea for the sender but it is actually
> due to a misuse of the MX record by some who will (choose)
> to drop mail based on this criteria -- I personally do not set
> my receiving server to do this.
>
> The reason: A legitimate email OUTBOUND server may not
> also be an INBOUND receiver of email and that is the real
> purpose of the MX record: identifying servers who can receive
> mail for a domain.
>
> > 3. PTR added by ISP so IP address of mx record can be resolved to FQDN
>
> The pointer should definitely be registered and should agree with the
> self-reported name (HELO xxx) of the sending server.
>
> IF you can/do create the MX record then it should also be using this
> name.
>
> > A reverse DNS lookup takes the IP address that's trying to make the
> > connection, and checks to see if there is a registered domain associated
> with
> > it.
>
> True it checks for the registration of the servers host DNS name (which
> is also a technically a domain name -- it does not check for a 'parent
> domain' in these sense the word domain name is commonly used.)
>
> > For example, if an incoming message claims to be coming from the
> > 66.160.177.11 IP address
>
> There is not 'claim' here - -in order to do SMTP on connection
> oriented TCP the return address must actually work during the
> entire conversation between sender and receiver.
>
> >, an ISP would look up the domain to see if it
> > resolves to lyris.com.
>
> No to see that it resolves first to ANY NAME.
>
> Then it would compare that name (if any) to the name reported
> in the HELO message to determine if it is lying in the HELO.
>
> > If it doesn't, the message may be a forgery-or, the
>
> It is more likely to be a temporary or a forgery.
>
> > hapless sender may not have a correct DNS entry. In either case, the
> message
> > will most likely be identified as spam.
>
> By many servers.
>
> > And all it cares is domain name in this example lyris.com, even though PTR
> > returns mx1.lyris.com what counts is lyris.com. Yes? No?
>
> Well, if the PTR says mx1.lyris.com then it expect an MX
> (if it checks this) that says LYRIS (or whoever the email is
> from has an MX of THATDOMAIN -> mx1.lyris.com).
>
> But note it may be delivering mail for LyrisCustomer.com too
> then it wouldn't be checking the LYRIS mx but the LyrisCustomer.com
> MX (if it checks those.)
>
> It may also be checking SPF records but it would foolish to
> reject email solely based on the lack of such -- though sensible
> to weight the message as less likely spam with a good SPF and
> more likely spam without.
>
> If however the SPF exists it would only accept the mail (a good
> bet) if the SPF authorizes that the particular email server to send
> email on it's behalf -- if the SPF exists and it doesn't authorize
> this server then it is likely a forged record and may even be one
> of those virus/trojans that forge other people's return address.
>
> Also, very few DNS server actually have the SPF record type and
> so most people use the TXT substitute.
>
> SPF checking should use the SPF if present, but check for and use
> the (alternative) TXT form of the SPF if the true SPF record does
> not exist.
>
> SPF is not however a mandatory standard so dropping solely on
> due to not finding it is usually foolish -- but certainly anyone is
> free to accept or reject any email they choose, except perhaps
> on addressed to abuse@domain.com
>
> --
> Herb Martin, MCSE, MVP
> Accelerated MCSE
> http://www.LearnQuick.Com
> [phone number on web site]
>
> > Here is the reason why I'm asking for:
> >
> > 1. sender email us at joe.user@mycorpdomain.com
> > 2. email goes out and looking in external DNS for MX record for
> > mycorpdomain.com which is resolved to public IP x.x.x.x
> > 3. email is delivered to our domain
> > 4. Joe User respond to sender - email goes out and is reaching mail server
> > which does reverse lookup, so
> > 5. recipient mail server knows what IP address is trying to make
> connection
> > (in this example x.x.x.x ) and knows that sender claims to be from (in
> this
> > example) mycorpdomain.com
> > 6. so recipient mail server takes connecting IP address and does reverse
> > lookup, as a result it gets mail1.mycorpdomain.com
> >
> > Message is bounced back with following reason:
> >
> > 550 Requested actions not taken - SMTP sender domain
> > (exsvr1.mycorpdomain.com) not found in the DNS
> >
> > Where exsvr1.mycorpdomain.com is our third party anti-virus/mail filtering
> > software between firewall and mail server, and the way is setup is that mx
> > record of mail1.mycorpdomain.com has public IP of x.x.x.x pointing to
> > external interface of the firewall which then is NATed and redirected to
> > internal exsvr1.mycordomian.com.
> >
> > I kind of can see how do they get this name (exsvr1.mycorpdomain.com) in
> > returned NDR because if you lookup header of incoming messages you see
> > something similar to:
> >
> > Received: from exsvr1.mycorpdomain.com ([x.x.x.x])
> > by their.mail.server.receipient_domain.com (SMSSMTP 4.1.4.30) with SMTP id
> > M2005052413322418434
> > for <user@receipient_domain.com>; Tue, 24 May 2005 13:32:24 -0500
> >
> > x.x.x.x is my public IP which (as described above) can be resolved to
> > mail1.mycorpdomian.com but not exsvr1..
> >
> > does this mean you need to have physical smtp/mail box named same as mx
> > record ?in my case I would either rename box or call ISP and change so
> > x.x.x.x has PTR resolved to exsvr1.mycorpdomain.com instead
> > mail1.mycorpdomain.com ???
> >
> > was I all this time wrong about how it works? I always though DNS reverse
> > lookup takes IP and check registered domain in this case mycorpdomain.com
> >
> > Can someone verify that?
> >
>
>
>
Related resources
Anonymous
May 25, 2005 10:29:54 AM

Archived from groups: microsoft.public.win2000.dns (More info?)

"Rafal W." <RafalW@discussions.microsoft.com> wrote in message
news:7BACCF97-3AAA-405D-B8CD-FEBE1964D9F1@microsoft.com...
> Thanks for responding, just quick question if I'm understanding this part
> correctly: when you saying:
> > The pointer should definitely be registered and should agree with the
> > self-reported name (HELO xxx) of the sending server.
>
> I telnet to my mail1.mycorpdomain.com on port 25 then helo <whatever>
server
> is responding :
> 250 exsvr1.mycorpdomain.com Hello
>
> So going back to my original question should my PTR for mx record (server
> does both inbound and outbound) be exsvr1.mycorpdomain.com instead mail1.

The question needs to be answered the other way around, that is,
the PTR record sets the other name requirements since many times
the PTR record is not under your control.

Whatever the PTR record is, your SMTP server must report that
name -- and almost all SMTP servers will allow this to be configured
separately from the machines official name in the System control panel.

> Is this what you mean when saying self-reported name HELO xxx ? If this is
> the case then in my case it's not a big deal, because my AD domain name is
> same as public registered domain name,

I mean the name the SMTP server USES in the HELO. This is practically
always configurable even though it usually defaults to the System CP name.

> I just need to change mx recor and
> call ISP asking to modify PTR to be exsvr1... instead mail1 now, but what
> about people who named their AD i.e domain.local ?? you telnet to their
mail
> server mx.domain.com 25 and get in respond
server_name.internal_domain.local
> , their ISP cannot create PTR on external NS for .local, can they?

The key is the PTR is always going to be a public address and must map
back to the name the SMTP claims when IT (the SMTP) SENDS email.

Then, if you use the MX (and you should if you can) then it should be the
same name.

Note that Mail1.someotherdomain.com can be used as the MX for
the domain "mydomain.com" the key is that mail1.someotherdomain.com
must be in the PTR for the address it uses.

Then if possible, create the SPF records to authorize (all of) the servers
who are permitted to send on behalf of "mydomain.com" -- giving others
the information (by contrast) that any other server is bogus.


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

"Rafal W." <RafalW@discussions.microsoft.com> wrote in message
news:7BACCF97-3AAA-405D-B8CD-FEBE1964D9F1@microsoft.com...
> Thanks for responding, just quick question if I'm understanding this part
> correctly: when you saying:
> > The pointer should definitely be registered and should agree with the
> > self-reported name (HELO xxx) of the sending server.
>
> I telnet to my mail1.mycorpdomain.com on port 25 then helo <whatever>
server
> is responding :
> 250 exsvr1.mycorpdomain.com Hello
>
> So going back to my original question should my PTR for mx record (server
> does both inbound and outbound) be exsvr1.mycorpdomain.com instead mail1.
>
> Is this what you mean when saying self-reported name HELO xxx ? If this is
> the case then in my case it's not a big deal, because my AD domain name is
> same as public registered domain name, I just need to change mx recor and
> call ISP asking to modify PTR to be exsvr1... instead mail1 now, but what
> about people who named their AD i.e domain.local ?? you telnet to their
mail
> server mx.domain.com 25 and get in respond
server_name.internal_domain.local
> , their ISP cannot create PTR on external NS for .local, can they?
>
> "Herb Martin" wrote:
>
> > "Rafal W." <RafalW@discussions.microsoft.com> wrote in message
> > news:B7102DE5-417E-4F91-8F3E-7CEEB13F84E3@microsoft.com...
> > > I guess I need some clarification here; my understanding was that
properly
> > > configured mail server should have as follow:
> > > 1. Static public IP address
> >
> > > 2. MX record for it and
> >
> > I know this is a good idea for the sender but it is actually
> > due to a misuse of the MX record by some who will (choose)
> > to drop mail based on this criteria -- I personally do not set
> > my receiving server to do this.
> >
> > The reason: A legitimate email OUTBOUND server may not
> > also be an INBOUND receiver of email and that is the real
> > purpose of the MX record: identifying servers who can receive
> > mail for a domain.
> >
> > > 3. PTR added by ISP so IP address of mx record can be resolved to FQDN
> >
> > The pointer should definitely be registered and should agree with the
> > self-reported name (HELO xxx) of the sending server.
> >
> > IF you can/do create the MX record then it should also be using this
> > name.
> >
> > > A reverse DNS lookup takes the IP address that's trying to make the
> > > connection, and checks to see if there is a registered domain
associated
> > with
> > > it.
> >
> > True it checks for the registration of the servers host DNS name (which
> > is also a technically a domain name -- it does not check for a 'parent
> > domain' in these sense the word domain name is commonly used.)
> >
> > > For example, if an incoming message claims to be coming from the
> > > 66.160.177.11 IP address
> >
> > There is not 'claim' here - -in order to do SMTP on connection
> > oriented TCP the return address must actually work during the
> > entire conversation between sender and receiver.
> >
> > >, an ISP would look up the domain to see if it
> > > resolves to lyris.com.
> >
> > No to see that it resolves first to ANY NAME.
> >
> > Then it would compare that name (if any) to the name reported
> > in the HELO message to determine if it is lying in the HELO.
> >
> > > If it doesn't, the message may be a forgery-or, the
> >
> > It is more likely to be a temporary or a forgery.
> >
> > > hapless sender may not have a correct DNS entry. In either case, the
> > message
> > > will most likely be identified as spam.
> >
> > By many servers.
> >
> > > And all it cares is domain name in this example lyris.com, even though
PTR
> > > returns mx1.lyris.com what counts is lyris.com. Yes? No?
> >
> > Well, if the PTR says mx1.lyris.com then it expect an MX
> > (if it checks this) that says LYRIS (or whoever the email is
> > from has an MX of THATDOMAIN -> mx1.lyris.com).
> >
> > But note it may be delivering mail for LyrisCustomer.com too
> > then it wouldn't be checking the LYRIS mx but the LyrisCustomer.com
> > MX (if it checks those.)
> >
> > It may also be checking SPF records but it would foolish to
> > reject email solely based on the lack of such -- though sensible
> > to weight the message as less likely spam with a good SPF and
> > more likely spam without.
> >
> > If however the SPF exists it would only accept the mail (a good
> > bet) if the SPF authorizes that the particular email server to send
> > email on it's behalf -- if the SPF exists and it doesn't authorize
> > this server then it is likely a forged record and may even be one
> > of those virus/trojans that forge other people's return address.
> >
> > Also, very few DNS server actually have the SPF record type and
> > so most people use the TXT substitute.
> >
> > SPF checking should use the SPF if present, but check for and use
> > the (alternative) TXT form of the SPF if the true SPF record does
> > not exist.
> >
> > SPF is not however a mandatory standard so dropping solely on
> > due to not finding it is usually foolish -- but certainly anyone is
> > free to accept or reject any email they choose, except perhaps
> > on addressed to abuse@domain.com
> >
> > --
> > Herb Martin, MCSE, MVP
> > Accelerated MCSE
> > http://www.LearnQuick.Com
> > [phone number on web site]
> >
> > > Here is the reason why I'm asking for:
> > >
> > > 1. sender email us at joe.user@mycorpdomain.com
> > > 2. email goes out and looking in external DNS for MX record for
> > > mycorpdomain.com which is resolved to public IP x.x.x.x
> > > 3. email is delivered to our domain
> > > 4. Joe User respond to sender - email goes out and is reaching mail
server
> > > which does reverse lookup, so
> > > 5. recipient mail server knows what IP address is trying to make
> > connection
> > > (in this example x.x.x.x ) and knows that sender claims to be from (in
> > this
> > > example) mycorpdomain.com
> > > 6. so recipient mail server takes connecting IP address and does
reverse
> > > lookup, as a result it gets mail1.mycorpdomain.com
> > >
> > > Message is bounced back with following reason:
> > >
> > > 550 Requested actions not taken - SMTP sender domain
> > > (exsvr1.mycorpdomain.com) not found in the DNS
> > >
> > > Where exsvr1.mycorpdomain.com is our third party anti-virus/mail
filtering
> > > software between firewall and mail server, and the way is setup is
that mx
> > > record of mail1.mycorpdomain.com has public IP of x.x.x.x pointing to
> > > external interface of the firewall which then is NATed and redirected
to
> > > internal exsvr1.mycordomian.com.
> > >
> > > I kind of can see how do they get this name (exsvr1.mycorpdomain.com)
in
> > > returned NDR because if you lookup header of incoming messages you see
> > > something similar to:
> > >
> > > Received: from exsvr1.mycorpdomain.com ([x.x.x.x])
> > > by their.mail.server.receipient_domain.com (SMSSMTP 4.1.4.30) with
SMTP id
> > > M2005052413322418434
> > > for <user@receipient_domain.com>; Tue, 24 May 2005 13:32:24 -0500
> > >
> > > x.x.x.x is my public IP which (as described above) can be resolved to
> > > mail1.mycorpdomian.com but not exsvr1..
> > >
> > > does this mean you need to have physical smtp/mail box named same as
mx
> > > record ?in my case I would either rename box or call ISP and change so
> > > x.x.x.x has PTR resolved to exsvr1.mycorpdomain.com instead
> > > mail1.mycorpdomain.com ???
> > >
> > > was I all this time wrong about how it works? I always though DNS
reverse
> > > lookup takes IP and check registered domain in this case
mycorpdomain.com
> > >
> > > Can someone verify that?
> > >
> >
> >
> >
Anonymous
May 25, 2005 3:51:09 PM

Archived from groups: microsoft.public.win2000.dns (More info?)

You also might find some useful information in RFC 2505
(http://www.faqs.org/rfcs/rfc2505.html) that goes over many of the items you
are asking about.

Regards,
Ed Horley
Microsoft MVP Server - Networking

"Rafal W." <RafalW@discussions.microsoft.com> wrote in message
news:7BACCF97-3AAA-405D-B8CD-FEBE1964D9F1@microsoft.com...
> Thanks for responding, just quick question if I'm understanding this part
> correctly: when you saying:
>> The pointer should definitely be registered and should agree with the
>> self-reported name (HELO xxx) of the sending server.
>
> I telnet to my mail1.mycorpdomain.com on port 25 then helo <whatever>
> server
> is responding :
> 250 exsvr1.mycorpdomain.com Hello
>
> So going back to my original question should my PTR for mx record (server
> does both inbound and outbound) be exsvr1.mycorpdomain.com instead mail1.
>
> Is this what you mean when saying self-reported name HELO xxx ? If this is
> the case then in my case it's not a big deal, because my AD domain name is
> same as public registered domain name, I just need to change mx recor and
> call ISP asking to modify PTR to be exsvr1... instead mail1 now, but what
> about people who named their AD i.e domain.local ?? you telnet to their
> mail
> server mx.domain.com 25 and get in respond
> server_name.internal_domain.local
> , their ISP cannot create PTR on external NS for .local, can they?
>
> "Herb Martin" wrote:
>
>> "Rafal W." <RafalW@discussions.microsoft.com> wrote in message
>> news:B7102DE5-417E-4F91-8F3E-7CEEB13F84E3@microsoft.com...
>> > I guess I need some clarification here; my understanding was that
>> > properly
>> > configured mail server should have as follow:
>> > 1. Static public IP address
>>
>> > 2. MX record for it and
>>
>> I know this is a good idea for the sender but it is actually
>> due to a misuse of the MX record by some who will (choose)
>> to drop mail based on this criteria -- I personally do not set
>> my receiving server to do this.
>>
>> The reason: A legitimate email OUTBOUND server may not
>> also be an INBOUND receiver of email and that is the real
>> purpose of the MX record: identifying servers who can receive
>> mail for a domain.
>>
>> > 3. PTR added by ISP so IP address of mx record can be resolved to FQDN
>>
>> The pointer should definitely be registered and should agree with the
>> self-reported name (HELO xxx) of the sending server.
>>
>> IF you can/do create the MX record then it should also be using this
>> name.
>>
>> > A reverse DNS lookup takes the IP address that's trying to make the
>> > connection, and checks to see if there is a registered domain
>> > associated
>> with
>> > it.
>>
>> True it checks for the registration of the servers host DNS name (which
>> is also a technically a domain name -- it does not check for a 'parent
>> domain' in these sense the word domain name is commonly used.)
>>
>> > For example, if an incoming message claims to be coming from the
>> > 66.160.177.11 IP address
>>
>> There is not 'claim' here - -in order to do SMTP on connection
>> oriented TCP the return address must actually work during the
>> entire conversation between sender and receiver.
>>
>> >, an ISP would look up the domain to see if it
>> > resolves to lyris.com.
>>
>> No to see that it resolves first to ANY NAME.
>>
>> Then it would compare that name (if any) to the name reported
>> in the HELO message to determine if it is lying in the HELO.
>>
>> > If it doesn't, the message may be a forgery-or, the
>>
>> It is more likely to be a temporary or a forgery.
>>
>> > hapless sender may not have a correct DNS entry. In either case, the
>> message
>> > will most likely be identified as spam.
>>
>> By many servers.
>>
>> > And all it cares is domain name in this example lyris.com, even though
>> > PTR
>> > returns mx1.lyris.com what counts is lyris.com. Yes? No?
>>
>> Well, if the PTR says mx1.lyris.com then it expect an MX
>> (if it checks this) that says LYRIS (or whoever the email is
>> from has an MX of THATDOMAIN -> mx1.lyris.com).
>>
>> But note it may be delivering mail for LyrisCustomer.com too
>> then it wouldn't be checking the LYRIS mx but the LyrisCustomer.com
>> MX (if it checks those.)
>>
>> It may also be checking SPF records but it would foolish to
>> reject email solely based on the lack of such -- though sensible
>> to weight the message as less likely spam with a good SPF and
>> more likely spam without.
>>
>> If however the SPF exists it would only accept the mail (a good
>> bet) if the SPF authorizes that the particular email server to send
>> email on it's behalf -- if the SPF exists and it doesn't authorize
>> this server then it is likely a forged record and may even be one
>> of those virus/trojans that forge other people's return address.
>>
>> Also, very few DNS server actually have the SPF record type and
>> so most people use the TXT substitute.
>>
>> SPF checking should use the SPF if present, but check for and use
>> the (alternative) TXT form of the SPF if the true SPF record does
>> not exist.
>>
>> SPF is not however a mandatory standard so dropping solely on
>> due to not finding it is usually foolish -- but certainly anyone is
>> free to accept or reject any email they choose, except perhaps
>> on addressed to abuse@domain.com
>>
>> --
>> Herb Martin, MCSE, MVP
>> Accelerated MCSE
>> http://www.LearnQuick.Com
>> [phone number on web site]
>>
>> > Here is the reason why I'm asking for:
>> >
>> > 1. sender email us at joe.user@mycorpdomain.com
>> > 2. email goes out and looking in external DNS for MX record for
>> > mycorpdomain.com which is resolved to public IP x.x.x.x
>> > 3. email is delivered to our domain
>> > 4. Joe User respond to sender - email goes out and is reaching mail
>> > server
>> > which does reverse lookup, so
>> > 5. recipient mail server knows what IP address is trying to make
>> connection
>> > (in this example x.x.x.x ) and knows that sender claims to be from (in
>> this
>> > example) mycorpdomain.com
>> > 6. so recipient mail server takes connecting IP address and does
>> > reverse
>> > lookup, as a result it gets mail1.mycorpdomain.com
>> >
>> > Message is bounced back with following reason:
>> >
>> > 550 Requested actions not taken - SMTP sender domain
>> > (exsvr1.mycorpdomain.com) not found in the DNS
>> >
>> > Where exsvr1.mycorpdomain.com is our third party anti-virus/mail
>> > filtering
>> > software between firewall and mail server, and the way is setup is that
>> > mx
>> > record of mail1.mycorpdomain.com has public IP of x.x.x.x pointing to
>> > external interface of the firewall which then is NATed and redirected
>> > to
>> > internal exsvr1.mycordomian.com.
>> >
>> > I kind of can see how do they get this name (exsvr1.mycorpdomain.com)
>> > in
>> > returned NDR because if you lookup header of incoming messages you see
>> > something similar to:
>> >
>> > Received: from exsvr1.mycorpdomain.com ([x.x.x.x])
>> > by their.mail.server.receipient_domain.com (SMSSMTP 4.1.4.30) with SMTP
>> > id
>> > M2005052413322418434
>> > for <user@receipient_domain.com>; Tue, 24 May 2005 13:32:24 -0500
>> >
>> > x.x.x.x is my public IP which (as described above) can be resolved to
>> > mail1.mycorpdomian.com but not exsvr1..
>> >
>> > does this mean you need to have physical smtp/mail box named same as mx
>> > record ?in my case I would either rename box or call ISP and change so
>> > x.x.x.x has PTR resolved to exsvr1.mycorpdomain.com instead
>> > mail1.mycorpdomain.com ???
>> >
>> > was I all this time wrong about how it works? I always though DNS
>> > reverse
>> > lookup takes IP and check registered domain in this case
>> > mycorpdomain.com
>> >
>> > Can someone verify that?
>> >
>>
>>
>>
Anonymous
May 26, 2005 2:00:01 AM

Archived from groups: microsoft.public.win2000.dns (More info?)

well, although this all make sense this will cause problems with some of the
"smtp gateway" products which do mail filtering, I can name at least 2 I know
of... because they do not have any options to configure them in such way so
they can respond with name that you have specified as your PTR instead they
always will return "box name" ... and I will repeat myself here, but if box
where this product resides has name different then public domain name... you
stuck if you routing smtp traffic in/out thru this gateway... obviously you
can route incoming traffic thru gateway, but outgoing directly from mail
server to internet and configure mail server to claim same name as PTR, but
by not going out via smtp gateway you loosing some functionality and useful
futures of it, i.e. some of these products when email is routed out via them
are creating "white list" for your clients or people you dealing with... but
that's different story.

Thanks

"Herb Martin" wrote:

> "Rafal W." <RafalW@discussions.microsoft.com> wrote in message
> news:7BACCF97-3AAA-405D-B8CD-FEBE1964D9F1@microsoft.com...
> > Thanks for responding, just quick question if I'm understanding this part
> > correctly: when you saying:
> > > The pointer should definitely be registered and should agree with the
> > > self-reported name (HELO xxx) of the sending server.
> >
> > I telnet to my mail1.mycorpdomain.com on port 25 then helo <whatever>
> server
> > is responding :
> > 250 exsvr1.mycorpdomain.com Hello
> >
> > So going back to my original question should my PTR for mx record (server
> > does both inbound and outbound) be exsvr1.mycorpdomain.com instead mail1.
>
> The question needs to be answered the other way around, that is,
> the PTR record sets the other name requirements since many times
> the PTR record is not under your control.
>
> Whatever the PTR record is, your SMTP server must report that
> name -- and almost all SMTP servers will allow this to be configured
> separately from the machines official name in the System control panel.
>
> > Is this what you mean when saying self-reported name HELO xxx ? If this is
> > the case then in my case it's not a big deal, because my AD domain name is
> > same as public registered domain name,
>
> I mean the name the SMTP server USES in the HELO. This is practically
> always configurable even though it usually defaults to the System CP name.
>
> > I just need to change mx recor and
> > call ISP asking to modify PTR to be exsvr1... instead mail1 now, but what
> > about people who named their AD i.e domain.local ?? you telnet to their
> mail
> > server mx.domain.com 25 and get in respond
> server_name.internal_domain.local
> > , their ISP cannot create PTR on external NS for .local, can they?
>
> The key is the PTR is always going to be a public address and must map
> back to the name the SMTP claims when IT (the SMTP) SENDS email.
>
> Then, if you use the MX (and you should if you can) then it should be the
> same name.
>
> Note that Mail1.someotherdomain.com can be used as the MX for
> the domain "mydomain.com" the key is that mail1.someotherdomain.com
> must be in the PTR for the address it uses.
>
> Then if possible, create the SPF records to authorize (all of) the servers
> who are permitted to send on behalf of "mydomain.com" -- giving others
> the information (by contrast) that any other server is bogus.
>
>
> --
> Herb Martin, MCSE, MVP
> Accelerated MCSE
> http://www.LearnQuick.Com
> [phone number on web site]
>
> "Rafal W." <RafalW@discussions.microsoft.com> wrote in message
> news:7BACCF97-3AAA-405D-B8CD-FEBE1964D9F1@microsoft.com...
> > Thanks for responding, just quick question if I'm understanding this part
> > correctly: when you saying:
> > > The pointer should definitely be registered and should agree with the
> > > self-reported name (HELO xxx) of the sending server.
> >
> > I telnet to my mail1.mycorpdomain.com on port 25 then helo <whatever>
> server
> > is responding :
> > 250 exsvr1.mycorpdomain.com Hello
> >
> > So going back to my original question should my PTR for mx record (server
> > does both inbound and outbound) be exsvr1.mycorpdomain.com instead mail1.
> >
> > Is this what you mean when saying self-reported name HELO xxx ? If this is
> > the case then in my case it's not a big deal, because my AD domain name is
> > same as public registered domain name, I just need to change mx recor and
> > call ISP asking to modify PTR to be exsvr1... instead mail1 now, but what
> > about people who named their AD i.e domain.local ?? you telnet to their
> mail
> > server mx.domain.com 25 and get in respond
> server_name.internal_domain.local
> > , their ISP cannot create PTR on external NS for .local, can they?
> >
> > "Herb Martin" wrote:
> >
> > > "Rafal W." <RafalW@discussions.microsoft.com> wrote in message
> > > news:B7102DE5-417E-4F91-8F3E-7CEEB13F84E3@microsoft.com...
> > > > I guess I need some clarification here; my understanding was that
> properly
> > > > configured mail server should have as follow:
> > > > 1. Static public IP address
> > >
> > > > 2. MX record for it and
> > >
> > > I know this is a good idea for the sender but it is actually
> > > due to a misuse of the MX record by some who will (choose)
> > > to drop mail based on this criteria -- I personally do not set
> > > my receiving server to do this.
> > >
> > > The reason: A legitimate email OUTBOUND server may not
> > > also be an INBOUND receiver of email and that is the real
> > > purpose of the MX record: identifying servers who can receive
> > > mail for a domain.
> > >
> > > > 3. PTR added by ISP so IP address of mx record can be resolved to FQDN
> > >
> > > The pointer should definitely be registered and should agree with the
> > > self-reported name (HELO xxx) of the sending server.
> > >
> > > IF you can/do create the MX record then it should also be using this
> > > name.
> > >
> > > > A reverse DNS lookup takes the IP address that's trying to make the
> > > > connection, and checks to see if there is a registered domain
> associated
> > > with
> > > > it.
> > >
> > > True it checks for the registration of the servers host DNS name (which
> > > is also a technically a domain name -- it does not check for a 'parent
> > > domain' in these sense the word domain name is commonly used.)
> > >
> > > > For example, if an incoming message claims to be coming from the
> > > > 66.160.177.11 IP address
> > >
> > > There is not 'claim' here - -in order to do SMTP on connection
> > > oriented TCP the return address must actually work during the
> > > entire conversation between sender and receiver.
> > >
> > > >, an ISP would look up the domain to see if it
> > > > resolves to lyris.com.
> > >
> > > No to see that it resolves first to ANY NAME.
> > >
> > > Then it would compare that name (if any) to the name reported
> > > in the HELO message to determine if it is lying in the HELO.
> > >
> > > > If it doesn't, the message may be a forgery-or, the
> > >
> > > It is more likely to be a temporary or a forgery.
> > >
> > > > hapless sender may not have a correct DNS entry. In either case, the
> > > message
> > > > will most likely be identified as spam.
> > >
> > > By many servers.
> > >
> > > > And all it cares is domain name in this example lyris.com, even though
> PTR
> > > > returns mx1.lyris.com what counts is lyris.com. Yes? No?
> > >
> > > Well, if the PTR says mx1.lyris.com then it expect an MX
> > > (if it checks this) that says LYRIS (or whoever the email is
> > > from has an MX of THATDOMAIN -> mx1.lyris.com).
> > >
> > > But note it may be delivering mail for LyrisCustomer.com too
> > > then it wouldn't be checking the LYRIS mx but the LyrisCustomer.com
> > > MX (if it checks those.)
> > >
> > > It may also be checking SPF records but it would foolish to
> > > reject email solely based on the lack of such -- though sensible
> > > to weight the message as less likely spam with a good SPF and
> > > more likely spam without.
> > >
> > > If however the SPF exists it would only accept the mail (a good
> > > bet) if the SPF authorizes that the particular email server to send
> > > email on it's behalf -- if the SPF exists and it doesn't authorize
> > > this server then it is likely a forged record and may even be one
> > > of those virus/trojans that forge other people's return address.
> > >
> > > Also, very few DNS server actually have the SPF record type and
> > > so most people use the TXT substitute.
> > >
> > > SPF checking should use the SPF if present, but check for and use
> > > the (alternative) TXT form of the SPF if the true SPF record does
> > > not exist.
> > >
> > > SPF is not however a mandatory standard so dropping solely on
> > > due to not finding it is usually foolish -- but certainly anyone is
> > > free to accept or reject any email they choose, except perhaps
> > > on addressed to abuse@domain.com
> > >
> > > --
> > > Herb Martin, MCSE, MVP
> > > Accelerated MCSE
> > > http://www.LearnQuick.Com
> > > [phone number on web site]
> > >
> > > > Here is the reason why I'm asking for:
> > > >
> > > > 1. sender email us at joe.user@mycorpdomain.com
> > > > 2. email goes out and looking in external DNS for MX record for
> > > > mycorpdomain.com which is resolved to public IP x.x.x.x
> > > > 3. email is delivered to our domain
> > > > 4. Joe User respond to sender - email goes out and is reaching mail
> server
> > > > which does reverse lookup, so
> > > > 5. recipient mail server knows what IP address is trying to make
> > > connection
> > > > (in this example x.x.x.x ) and knows that sender claims to be from (in
> > > this
> > > > example) mycorpdomain.com
> > > > 6. so recipient mail server takes connecting IP address and does
> reverse
> > > > lookup, as a result it gets mail1.mycorpdomain.com
> > > >
> > > > Message is bounced back with following reason:
> > > >
> > > > 550 Requested actions not taken - SMTP sender domain
> > > > (exsvr1.mycorpdomain.com) not found in the DNS
> > > >
> > > > Where exsvr1.mycorpdomain.com is our third party anti-virus/mail
> filtering
> > > > software between firewall and mail server, and the way is setup is
> that mx
> > > > record of mail1.mycorpdomain.com has public IP of x.x.x.x pointing to
> > > > external interface of the firewall which then is NATed and redirected
> to
> > > > internal exsvr1.mycordomian.com.
> > > >
> > > > I kind of can see how do they get this name (exsvr1.mycorpdomain.com)
> in
> > > > returned NDR because if you lookup header of incoming messages you see
> > > > something similar to:
> > > >
> > > > Received: from exsvr1.mycorpdomain.com ([x.x.x.x])
> > > > by their.mail.server.receipient_domain.com (SMSSMTP 4.1.4.30) with
> SMTP id
> > > > M2005052413322418434
> > > > for <user@receipient_domain.com>; Tue, 24 May 2005 13:32:24 -0500
> > > >
> > > > x.x.x.x is my public IP which (as described above) can be resolved to
> > > > mail1.mycorpdomian.com but not exsvr1..
> > > >
> > > > does this mean you need to have physical smtp/mail box named same as
> mx
> > > > record ?in my case I would either rename box or call ISP and change so
> > > > x.x.x.x has PTR resolved to exsvr1.mycorpdomain.com instead
> > > > mail1.mycorpdomain.com ???
> > > >
> > > > was I all this time wrong about how it works? I always though DNS
> reverse
> > > > lookup takes IP and check registered domain in this case
> mycorpdomain.com
> > > >
> > > > Can someone verify that?
> > > >
> > >
> > >
> > >
>
>
>
Anonymous
May 26, 2005 2:12:02 AM

Archived from groups: microsoft.public.win2000.dns (More info?)

by the way... how about 1 mail server hosting many internet mail domians? you
can asign 1 public IP for each domian and create mx records for all of them
as well as PTR records associated with these IPs.... but smtp server will use
only 1 name.... ????

"Herb Martin" wrote:

> "Rafal W." <RafalW@discussions.microsoft.com> wrote in message
> news:7BACCF97-3AAA-405D-B8CD-FEBE1964D9F1@microsoft.com...
> > Thanks for responding, just quick question if I'm understanding this part
> > correctly: when you saying:
> > > The pointer should definitely be registered and should agree with the
> > > self-reported name (HELO xxx) of the sending server.
> >
> > I telnet to my mail1.mycorpdomain.com on port 25 then helo <whatever>
> server
> > is responding :
> > 250 exsvr1.mycorpdomain.com Hello
> >
> > So going back to my original question should my PTR for mx record (server
> > does both inbound and outbound) be exsvr1.mycorpdomain.com instead mail1.
>
> The question needs to be answered the other way around, that is,
> the PTR record sets the other name requirements since many times
> the PTR record is not under your control.
>
> Whatever the PTR record is, your SMTP server must report that
> name -- and almost all SMTP servers will allow this to be configured
> separately from the machines official name in the System control panel.
>
> > Is this what you mean when saying self-reported name HELO xxx ? If this is
> > the case then in my case it's not a big deal, because my AD domain name is
> > same as public registered domain name,
>
> I mean the name the SMTP server USES in the HELO. This is practically
> always configurable even though it usually defaults to the System CP name.
>
> > I just need to change mx recor and
> > call ISP asking to modify PTR to be exsvr1... instead mail1 now, but what
> > about people who named their AD i.e domain.local ?? you telnet to their
> mail
> > server mx.domain.com 25 and get in respond
> server_name.internal_domain.local
> > , their ISP cannot create PTR on external NS for .local, can they?
>
> The key is the PTR is always going to be a public address and must map
> back to the name the SMTP claims when IT (the SMTP) SENDS email.
>
> Then, if you use the MX (and you should if you can) then it should be the
> same name.
>
> Note that Mail1.someotherdomain.com can be used as the MX for
> the domain "mydomain.com" the key is that mail1.someotherdomain.com
> must be in the PTR for the address it uses.
>
> Then if possible, create the SPF records to authorize (all of) the servers
> who are permitted to send on behalf of "mydomain.com" -- giving others
> the information (by contrast) that any other server is bogus.
>
>
> --
> Herb Martin, MCSE, MVP
> Accelerated MCSE
> http://www.LearnQuick.Com
> [phone number on web site]
>
> "Rafal W." <RafalW@discussions.microsoft.com> wrote in message
> news:7BACCF97-3AAA-405D-B8CD-FEBE1964D9F1@microsoft.com...
> > Thanks for responding, just quick question if I'm understanding this part
> > correctly: when you saying:
> > > The pointer should definitely be registered and should agree with the
> > > self-reported name (HELO xxx) of the sending server.
> >
> > I telnet to my mail1.mycorpdomain.com on port 25 then helo <whatever>
> server
> > is responding :
> > 250 exsvr1.mycorpdomain.com Hello
> >
> > So going back to my original question should my PTR for mx record (server
> > does both inbound and outbound) be exsvr1.mycorpdomain.com instead mail1.
> >
> > Is this what you mean when saying self-reported name HELO xxx ? If this is
> > the case then in my case it's not a big deal, because my AD domain name is
> > same as public registered domain name, I just need to change mx recor and
> > call ISP asking to modify PTR to be exsvr1... instead mail1 now, but what
> > about people who named their AD i.e domain.local ?? you telnet to their
> mail
> > server mx.domain.com 25 and get in respond
> server_name.internal_domain.local
> > , their ISP cannot create PTR on external NS for .local, can they?
> >
> > "Herb Martin" wrote:
> >
> > > "Rafal W." <RafalW@discussions.microsoft.com> wrote in message
> > > news:B7102DE5-417E-4F91-8F3E-7CEEB13F84E3@microsoft.com...
> > > > I guess I need some clarification here; my understanding was that
> properly
> > > > configured mail server should have as follow:
> > > > 1. Static public IP address
> > >
> > > > 2. MX record for it and
> > >
> > > I know this is a good idea for the sender but it is actually
> > > due to a misuse of the MX record by some who will (choose)
> > > to drop mail based on this criteria -- I personally do not set
> > > my receiving server to do this.
> > >
> > > The reason: A legitimate email OUTBOUND server may not
> > > also be an INBOUND receiver of email and that is the real
> > > purpose of the MX record: identifying servers who can receive
> > > mail for a domain.
> > >
> > > > 3. PTR added by ISP so IP address of mx record can be resolved to FQDN
> > >
> > > The pointer should definitely be registered and should agree with the
> > > self-reported name (HELO xxx) of the sending server.
> > >
> > > IF you can/do create the MX record then it should also be using this
> > > name.
> > >
> > > > A reverse DNS lookup takes the IP address that's trying to make the
> > > > connection, and checks to see if there is a registered domain
> associated
> > > with
> > > > it.
> > >
> > > True it checks for the registration of the servers host DNS name (which
> > > is also a technically a domain name -- it does not check for a 'parent
> > > domain' in these sense the word domain name is commonly used.)
> > >
> > > > For example, if an incoming message claims to be coming from the
> > > > 66.160.177.11 IP address
> > >
> > > There is not 'claim' here - -in order to do SMTP on connection
> > > oriented TCP the return address must actually work during the
> > > entire conversation between sender and receiver.
> > >
> > > >, an ISP would look up the domain to see if it
> > > > resolves to lyris.com.
> > >
> > > No to see that it resolves first to ANY NAME.
> > >
> > > Then it would compare that name (if any) to the name reported
> > > in the HELO message to determine if it is lying in the HELO.
> > >
> > > > If it doesn't, the message may be a forgery-or, the
> > >
> > > It is more likely to be a temporary or a forgery.
> > >
> > > > hapless sender may not have a correct DNS entry. In either case, the
> > > message
> > > > will most likely be identified as spam.
> > >
> > > By many servers.
> > >
> > > > And all it cares is domain name in this example lyris.com, even though
> PTR
> > > > returns mx1.lyris.com what counts is lyris.com. Yes? No?
> > >
> > > Well, if the PTR says mx1.lyris.com then it expect an MX
> > > (if it checks this) that says LYRIS (or whoever the email is
> > > from has an MX of THATDOMAIN -> mx1.lyris.com).
> > >
> > > But note it may be delivering mail for LyrisCustomer.com too
> > > then it wouldn't be checking the LYRIS mx but the LyrisCustomer.com
> > > MX (if it checks those.)
> > >
> > > It may also be checking SPF records but it would foolish to
> > > reject email solely based on the lack of such -- though sensible
> > > to weight the message as less likely spam with a good SPF and
> > > more likely spam without.
> > >
> > > If however the SPF exists it would only accept the mail (a good
> > > bet) if the SPF authorizes that the particular email server to send
> > > email on it's behalf -- if the SPF exists and it doesn't authorize
> > > this server then it is likely a forged record and may even be one
> > > of those virus/trojans that forge other people's return address.
> > >
> > > Also, very few DNS server actually have the SPF record type and
> > > so most people use the TXT substitute.
> > >
> > > SPF checking should use the SPF if present, but check for and use
> > > the (alternative) TXT form of the SPF if the true SPF record does
> > > not exist.
> > >
> > > SPF is not however a mandatory standard so dropping solely on
> > > due to not finding it is usually foolish -- but certainly anyone is
> > > free to accept or reject any email they choose, except perhaps
> > > on addressed to abuse@domain.com
> > >
> > > --
> > > Herb Martin, MCSE, MVP
> > > Accelerated MCSE
> > > http://www.LearnQuick.Com
> > > [phone number on web site]
> > >
> > > > Here is the reason why I'm asking for:
> > > >
> > > > 1. sender email us at joe.user@mycorpdomain.com
> > > > 2. email goes out and looking in external DNS for MX record for
> > > > mycorpdomain.com which is resolved to public IP x.x.x.x
> > > > 3. email is delivered to our domain
> > > > 4. Joe User respond to sender - email goes out and is reaching mail
> server
> > > > which does reverse lookup, so
> > > > 5. recipient mail server knows what IP address is trying to make
> > > connection
> > > > (in this example x.x.x.x ) and knows that sender claims to be from (in
> > > this
> > > > example) mycorpdomain.com
> > > > 6. so recipient mail server takes connecting IP address and does
> reverse
> > > > lookup, as a result it gets mail1.mycorpdomain.com
> > > >
> > > > Message is bounced back with following reason:
> > > >
> > > > 550 Requested actions not taken - SMTP sender domain
> > > > (exsvr1.mycorpdomain.com) not found in the DNS
> > > >
> > > > Where exsvr1.mycorpdomain.com is our third party anti-virus/mail
> filtering
> > > > software between firewall and mail server, and the way is setup is
> that mx
> > > > record of mail1.mycorpdomain.com has public IP of x.x.x.x pointing to
> > > > external interface of the firewall which then is NATed and redirected
> to
> > > > internal exsvr1.mycordomian.com.
> > > >
> > > > I kind of can see how do they get this name (exsvr1.mycorpdomain.com)
> in
> > > > returned NDR because if you lookup header of incoming messages you see
> > > > something similar to:
> > > >
> > > > Received: from exsvr1.mycorpdomain.com ([x.x.x.x])
> > > > by their.mail.server.receipient_domain.com (SMSSMTP 4.1.4.30) with
> SMTP id
> > > > M2005052413322418434
> > > > for <user@receipient_domain.com>; Tue, 24 May 2005 13:32:24 -0500
> > > >
> > > > x.x.x.x is my public IP which (as described above) can be resolved to
> > > > mail1.mycorpdomian.com but not exsvr1..
> > > >
> > > > does this mean you need to have physical smtp/mail box named same as
> mx
> > > > record ?in my case I would either rename box or call ISP and change so
> > > > x.x.x.x has PTR resolved to exsvr1.mycorpdomain.com instead
> > > > mail1.mycorpdomain.com ???
> > > >
> > > > was I all this time wrong about how it works? I always though DNS
> reverse
> > > > lookup takes IP and check registered domain in this case
> mycorpdomain.com
> > > >
> > > > Can someone verify that?
> > > >
> > >
> > >
> > >
>
>
>
Anonymous
May 26, 2005 7:12:51 AM

Archived from groups: microsoft.public.win2000.dns (More info?)

In news:4EC54A5E-999D-49DD-9796-537945554532@microsoft.com,
Rafal W. <RafalW@discussions.microsoft.com> posted this:
> by the way... how about 1 mail server hosting many internet mail
> domians? you can asign 1 public IP for each domian and create mx
> records for all of them as well as PTR records associated with these
> IPs.... but smtp server will use only 1 name.... ????

All the MX records point to the same SMTP server name.
Examples:
mydomain.com MX 10 mail.mydomain.com
yourdomain.com MX 10 mail.mydomain.com

Some mail servers (Exchange, Imail for instance) have the capability to act
like multiple independent servers and can have multiple HELO names, but each
virtual server must use a different IP address.


--?
Best regards,
Kevin D4 Dad Goodknecht Sr. [MVP]
Hope This Helps
===================================
When responding to posts, please "Reply to Group"
via your newsreader so that others may learn and
benefit from your issue, to respond directly to
me remove the nospam. from my email address.
===================================
http://www.lonestaramerica.com/
===================================
Use Outlook Express?... Get OE_Quotefix:
It will strip signature out and more
http://home.in.tum.de/~jain/software/oe-quotefix/
===================================
Keep a back up of your OE settings and folders
with OEBackup:
http://www.oehelp.com/OEBackup/Default.aspx
===================================
Anonymous
May 26, 2005 1:04:08 PM

Archived from groups: microsoft.public.win2000.dns (More info?)

Kevin D. Goodknecht Sr. [MVP]" wrote:
> All the MX records point to the same SMTP server name.
> Examples:
> mydomain.com MX 10 mail.mydomain.com
> yourdomain.com MX 10 mail.mydomain.com

MX records are only used for incoming email, not outgoing... that's not the
case.

> Some mail servers (Exchange, Imail for instance) have the capability to act
> like multiple independent servers and can have multiple HELO names, but each
> virtual server must use a different IP address.

Now, we are going off the original topic.... basically I always though (and
sounds like I was wrong) that if some one does DNS reverse lookup on email as
long IP address of sending mail server has PTR associated with it which
matches MX record all is good but apparently it is not, since (thanks Herb
Martin) it has to be whatever is self-reported name (HELO) of the sending
server.

In this case all what I’m saying is that as long as you send emails out
directly to Internet from mail server (whatever type of server it is, most of
them can act as multiple virtual smtp server) you OK, but there are software
packages that act as smtp gateway that CANNOT do this, not only do multiple
virtual smtp servers but what most important they cannot even report
themselves as different name other then box name where they are install.

Tx All
Anonymous
May 26, 2005 2:35:48 PM

Archived from groups: microsoft.public.win2000.dns (More info?)

Rafal,
The basic rule of thumb is to have the FQDN / hostname, helo name and
reverse all match up. Really this isn't hard to do (well, beside some basic
planning ahead). All the other issues only really come up when you don't do
the above.

For domains that use a mail server that is isn't in their domain space - you
simply point your MX records to the correct FQDN of the SMTP server that
will host the mail as Kevin indicated. Remember that MX records only state
what servers are accepting smtp traffic for a domain, NOT who is permitted
to send it. That is what SPF records are for. So if you wish to publish
SPF record for a domain that does not run its own mail server you simply
publish the FQDN of the mail server that is allowed to send out on that
domain's behalf.

As a side note, most of the checks for reverse are done for the purpose of
SPF or domain keys at this point. If they are only doing reverse checks
they basically want to make sure the entry is there. Half the time they
don't even check to see that it matches the same domain never mind the FQDN.

If you do the first suggestion then none of this is an issue. I would also
suggest publishing SPF records if you can do so. See http://spf.pobox.com/
for more information.

Regards,
Ed Horley
Microsoft MVP Server - Networking

"Rafal W." <RafalW@discussions.microsoft.com> wrote in message
news:29043D64-382A-4BE6-9E15-312ED3B1C9FA@microsoft.com...
> Kevin D. Goodknecht Sr. [MVP]" wrote:
>> All the MX records point to the same SMTP server name.
>> Examples:
>> mydomain.com MX 10 mail.mydomain.com
>> yourdomain.com MX 10 mail.mydomain.com
>
> MX records are only used for incoming email, not outgoing... that's not
> the
> case.
>
>> Some mail servers (Exchange, Imail for instance) have the capability to
>> act
>> like multiple independent servers and can have multiple HELO names, but
>> each
>> virtual server must use a different IP address.
>
> Now, we are going off the original topic.... basically I always though
> (and
> sounds like I was wrong) that if some one does DNS reverse lookup on email
> as
> long IP address of sending mail server has PTR associated with it which
> matches MX record all is good but apparently it is not, since (thanks Herb
> Martin) it has to be whatever is self-reported name (HELO) of the sending
> server.
>
> In this case all what I'm saying is that as long as you send emails out
> directly to Internet from mail server (whatever type of server it is, most
> of
> them can act as multiple virtual smtp server) you OK, but there are
> software
> packages that act as smtp gateway that CANNOT do this, not only do
> multiple
> virtual smtp servers but what most important they cannot even report
> themselves as different name other then box name where they are install.
>
> Tx All
>
>
Anonymous
May 27, 2005 3:01:24 AM

Archived from groups: microsoft.public.win2000.dns (More info?)

In news:29043D64-382A-4BE6-9E15-312ED3B1C9FA@microsoft.com,
Rafal W. <RafalW@discussions.microsoft.com> posted this:
> Kevin D. Goodknecht Sr. [MVP]" wrote:
>> All the MX records point to the same SMTP server name.
>> Examples:
>> mydomain.com MX 10 mail.mydomain.com
>> yourdomain.com MX 10 mail.mydomain.com
>
> MX records are only used for incoming email, not outgoing... that's
> not the case.
Not always exactly, some mail servers check the MX record for incoming mail
domains to see if the server is authorized either by MX or SPF or both to
send/recieve mail for a domain.
The point I was making is that all MX records must point to the FQDN of the
SMTP server that accepts mail for the domain. You need one A record for the
SMTP server and one PTR record for the A record. The names should match the
HELO greeting of the SMTP server. One SMTP virtual server can have only one
HELO greeting.

So, your point:
"how about 1 mail server hosting many internet mail domians? you
can asign 1 public IP for each domian and create mx records for all of them
as well as PTR records associated with these IPs.... but smtp server will
use
only 1 name.... ???? "
Is an incorrect assumption, unless you set up separate SMTP virtual servers
for each domain. If you have only one SMTP virtual server, all MX records
should point to the same FQDN.





--?
Best regards,
Kevin D4 Dad Goodknecht Sr. [MVP]
Hope This Helps
===================================
When responding to posts, please "Reply to Group"
via your newsreader so that others may learn and
benefit from your issue, to respond directly to
me remove the nospam. from my email address.
===================================
http://www.lonestaramerica.com/
===================================
Use Outlook Express?... Get OE_Quotefix:
It will strip signature out and more
http://home.in.tum.de/~jain/software/oe-quotefix/
===================================
Keep a back up of your OE settings and folders
with OEBackup:
http://www.oehelp.com/OEBackup/Default.aspx
===================================
May 27, 2005 7:55:21 PM

Archived from groups: microsoft.public.win2000.dns (More info?)

<snippage>
> The reason: A legitimate email OUTBOUND server may not
> also be an INBOUND receiver of email and that is the real
> purpose of the MX record: identifying servers who can receive
> mail for a domain.

Well.. that's a job for the SPF records :-)

> The pointer should definitely be registered and should agree with the
> self-reported name (HELO xxx) of the sending server.

Seconded 100%; the mail server helo should match the name reported
by the reverse DNS query (an the "A" and "MX" names as well <g>)

> No to see that it resolves first to ANY NAME.
>
> Then it would compare that name (if any) to the name reported
> in the HELO message to determine if it is lying in the HELO.

Correct again, although I think this was exactly what the OP meant
the idea is to avoid connections from servers which are "spoofing"
themselves using different names/domains, so, if the HELO name
won't match the PTR one the whole mail transaction may be refused
by the destination server; btw, if the destination server is using SPF
that check must come *before* the PTR one and in case the given
host is allowed to send mail for the "HELO domain" then the receiver
should accept such a transaction

Regards

--

* ObiWan

Microsoft MVP: Windows Server - Networking
http://www.microsoft.com/communities/MVP/MVP.mspx
http://mvp.support.microsoft.com

DNS "fail-safe" for Windows clients.
http://www.ntcanuck.com

Newsgroups and forums
news://news.ntcanuck.com
http://forums.ntcanuck.com

408+ XP/2000 tweaks and tips
http://www.ntcanuck.com/tq/Tip_Quarry.htm
!