Reverse DNS and mail server

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?
11 answers Last reply
More about reverse mail server
  1. 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?
    >
  2. 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?
    > >
    >
    >
    >
  3. 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?
    > > >
    > >
    > >
    > >
  4. 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?
    >> >
    >>
    >>
    >>
  5. 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?
    > > > >
    > > >
    > > >
    > > >
    >
    >
    >
  6. 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?
    > > > >
    > > >
    > > >
    > > >
    >
    >
    >
  7. 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
    ===================================
  8. 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
  9. 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
    >
    >
  10. 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
    ===================================
  11. 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
Ask a new question

Read More

Internet Service Providers DNS Servers Windows Product