Re: Reverse DNS and mail server
- From: "Rafal W." <RafalW@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 24 May 2005 21:21:01 -0700
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@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:B7102DE5-417E-4F91-8F3E-7CEEB13F84E3@xxxxxxxxxxxxxxxx
> > 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@xxxxxxxxxx
>
> --
> 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@xxxxxxxxxxxxxxxx
> > 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@xxxxxxxxxxxxxxxxxxxxx>; 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?
> >
>
>
>
.
- Follow-Ups:
- Re: Reverse DNS and mail server
- From: Ed Horley
- Re: Reverse DNS and mail server
- From: Herb Martin
- Re: Reverse DNS and mail server
- References:
- Reverse DNS and mail server
- From: Rafal W.
- Re: Reverse DNS and mail server
- From: Herb Martin
- Reverse DNS and mail server
- Prev by Date: Re: dns
- Next by Date: Re: Secondary DNS: Depends on Primary?
- Previous by thread: Re: Reverse DNS and mail server
- Next by thread: Re: Reverse DNS and mail server
- Index(es):
Relevant Pages
|
