Re: Exchange can't send email to one of the domains
From: Josh Fooks [MSFT] (jfooks_at_online.microsoft.com)
Date: 11/24/04
- Next message: Piratedking: "RE: Failure to deliver - Semaphore timeouts and others...."
- Previous message: Boris Lokhvitsky: "Re: Exchange can't send email to one of the domains"
- In reply to: Boris Lokhvitsky: "Re: Exchange can't send email to one of the domains"
- Next in thread: Boris Lokhvitsky: "Re: Exchange can't send email to one of the domains"
- Reply: Boris Lokhvitsky: "Re: Exchange can't send email to one of the domains"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 23 Nov 2004 16:49:19 -0800
Hi Boris,
Specifying the smarthost as the remote mail exchanger won't be considered
relaying...all this really does it remove the DNS lookup. So when Exchange
wants to send a mail to this domain, it will see there is an address space
available with the SMTP VS of your outbound server as the bridgehead.
Exchange will route the message to this BH server and deliver the message to
the server's IP specified in the smarthost setting. The only time a message
is considered "relaying" is if the message's ultimate destination is not the
server to which you're attached.
So if you want a message to go to "a.org" and you send the message to
"b.net" and expect "b.net" to deliver it to "a.org"...that would be relaying
the message. As long as the final delivery point is what is specified in
DNS, the messge should route properly. In short, adding the MX record as
the smarthost with the domain for "a.org" as the address space simply has
the effect of shortcutting past the NSLookup process we'd use to determine
that information anyways. The difference between using a host file vs. DNS.
You lose your dynamic capability in a long term implementation, but it's a
great short term test.
By testing with the EHLO manually, you're still losing out on some of the
verbs passed in an automated ESMTP conversation. The verb which is most
commonly filtered improperly is the BDAT command. This is advertised as
"chunking" in the ESMTP list of verbs. So often times chunking is still
advertised, but when the remote server attempts to send BDAT, the command is
filtered out and both servers end up waiting on the other and the connection
times out. It's not as common nowadays, but I have seen it on more than few
occasions. Most mail servers have no problem sending messages via SMTP
instead of ESMTP and again makes a great short term test. I would be
hesitant to dumb all of your servers down to this level since it does
provide some efficiency in sending larger volumes of mail.
I completely understand with regards to servers beyond your control...makes
things that much harder to track down. I'll be checking back here again if
you have more questions or want me to clarify anything :)
-Josh
"Boris Lokhvitsky" <msexpert@community.nospam> wrote in message
news:%23fcv3Ya0EHA.1392@tk2msftngp13.phx.gbl...
> Thanks a lot Josh,
>
> These both ideas had already come to my mind, too. I have suggested the
> idea
> of adding a connector for specified SMTP namespace. Unfortunately,
> Exchange
> servers I am asking about are not directly in my jurisdiction so I don't
> know yet if they checked this idea.
> One small question here - if I specify the MX servers from the domain in
> question as smart hosts for this connector, wouldn't they reject the
> messages as an SMTP relay attempt? I was going to use the "good" server as
> a
> smart host for the "bad" server, wouldn't that be better since they belong
> to the same org and SMTP namespace?
>
> As for Helo instead of Ehlo, I have tried both when sending mails from a
> Telnet SMTP session. Both worked fine. By the way, can I switch the
> Exchange
> virtual SMTP server to send Helo instead of Ehlo, rather than switching a
> connector? (Yes I understand this will be a global setting).
>
> Thanks for your help! Yes this IS odd. Unfortunately, as I said, I am not
> sitting directly on these Exchange servers... they actually belong to our
> client trying to send mail to our domain (the "domain in question" :)), -
> when they couldn't they actually started blaming us, so I'm trying to find
> an actual reason.
>
> Thanks again,
> Boris
>
>
> "Josh Fooks [MSFT]" <jfooks@online.microsoft.com> wrote in message
> news:evHPhsP0EHA.3408@tk2msftngp13.phx.gbl...
>> Hi Boris,
>>
>> <oops...lemme repost this in a cross-post so see it> :)
>>
>> Something easy you can to to track down the problem to being related to
> DNS
>> or not is to create an SMTP connector with the domain for that org on the
>> address space tab. Then on the general tab, use a smarthost with the
>> correct (and verified) primary MX record as the smarthost. This will
> allow
>> you to completely bypass the DNS lookup portion if you're suspecting a
>> lookup issue. If the mail is still sticking in the queue, then we can
> know
>> for certain whether or not it's SMTP or DNS.
>>
>> Another trick we can try if the messages are still sticking is to change
>> that test connector to send HELO instead of EHLO. If we're timing out on
> an
>> ESMTP verb that's passed and removed at one of the gateways, this will
> dumb
>> the conversation down enough to not send any ESMTP verbs any longer.
>>
>> ...but it IS odd that one server can and one server can't... <ponders>
>>
>> -Josh
>>
>> "Boris Lokhvitsky" <msexpert@community.nospam> wrote in message
>> news:OGt0phP0EHA.1392@TK2MSFTNGP14.phx.gbl...
>> > Thanks for answering Kevin,
>> >
>> > I get the same results on both servers. Correct MX entries.
>> >
>> > Exchange's SMTP, however, is performing DNS queries in a different
> manner
>> > (for example, it is always using TCP, not UDP, for DNS queries), so it
>> > cannot be a big argument... and I did not perform TCP based nslookup
>> > queries.
>> >
>> > http://support.microsoft.com/?id=263237
>> >
>> > Thanks,
>> > Boris
>> >
>> >
>> > "Kevin Longley" <kwlongley@cirtronics.com> wrote in message
>> > news:e8dBYRO0EHA.1188@tk2msftngp13.phx.gbl...
>> >> If you use Nslookup to verify the mx records of the domain in
>> >> question,
>> > from
>> >> each of the exchange servers, what do you get for results?
>> >>
>> >> "Boris Lokhvitsky" <msexpert@community.nospam> wrote in message
>> >> news:eVIhsLM0EHA.2572@tk2msftngp13.phx.gbl...
>> >> > Hello All,
>> >> >
>> >> > Here's a strange problem. There are two Exchange 2000 SP3 servers
>> >> > (on
>> >> > Windows 2000) hosting mailboxes, both belonging to the same
>> > organization,
>> >> > administrative group, and routing group. No SMTP or any other
>> >> > connectors
>> >> > configured. Virtual SMTP servers seem to be configured identically
>> >> > on
>> > both
>> >> > servers. Both servers use the same DNS servers for DNS resolution.
> Both
>> >> > servers (and DNS servers too) have private addresses and are behind
>> >> > a
>> >> > firewall/NAT. No SMTP proxies / gateways / smart hosts for the
> outgoing
>> >> > e-mail.
>> >> >
>> >> > Now the problem itself: _ONE_ of these servers can't send out e-mail
>> >> > messages to _ONE_ specific SMTP domain on the Internet. The mail
>> >> > just
>> > sits
>> >> > in the queue until its TTL expires. All other mail for other domains
>> > seems
>> >> > to work fine. Second Exchange server can send e-mail normally to all
>> >> > domains
>> >> > including the domain in question.
>> >> >
>> >> > On DNS server it can be seen that MX records for the domain in
> question
>> >> > appear in the cache when sending e-mail from the "good" server but
> not
>> >> > when
>> >> > sending e-mails from the "bad" server. Seems to be a DNS related
> issue
>> >> > (strange). However, messages sent to the same domain from the "bad"
>> > server
>> >> > using a command prompt Telnet session directly to SMTP, go through
> just
>> >> > fine. Hence - still an Exchange configuration issue?
>> >> >
>> >> > I'm out of ideas... any thoughts?
>> >> >
>> >> > Thanks a lot in advance,
>> >> > Boris
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>
- Next message: Piratedking: "RE: Failure to deliver - Semaphore timeouts and others...."
- Previous message: Boris Lokhvitsky: "Re: Exchange can't send email to one of the domains"
- In reply to: Boris Lokhvitsky: "Re: Exchange can't send email to one of the domains"
- Next in thread: Boris Lokhvitsky: "Re: Exchange can't send email to one of the domains"
- Reply: Boris Lokhvitsky: "Re: Exchange can't send email to one of the domains"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
