exchange 2003 bdat command sends internal fqdn

snowdog_2112
snowdog_2112 used Ask the Experts™
on
Exchange 2003 sp2.

The receiving mail server sees the *internal* fqdn in the DATA and BDAT command, rather than the *external* fqdn as defined in the SMTP virtual server-->delivery-->advanced tab.

I've checked on 2 different Exchange servers and see the same behavior.

Exch server #1 (this is in the recipient's smtp log files)
EHLO - +mail.external-domain-name.com 250
BDAT - +<7D435A70B4195B4AA2304D7C34BB5F3202167B@server03.internal-domain.local>
QUIT - mail.external-domain-name.com

Exch server #2 (in this case, the mail goes through a 3rd party filtering service before reaching the destination Exchange server)
EHLO - +barracuda2.3rd-party-provider.net
DATA - +<0FF89AA0A405354B84D76464033F84D186AA99@myserver.different-internal-fqdn.local>
QUIT - barracuda2.3rd-party-provider.net
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®

Commented:
You set this on the properties pages of the SMTP Virtual Server.  The pertinent KB article states it's for IIS, but of course it applies to Exchange 2000/2003.
http://support.microsoft.com/kb/303734

-tom

Commented:
Wow, I'm a bit of a dim bulb here, aren't I?  I just re-read for comprehension and realized that you're saying that you've DONE this, yet it's still showing the internal FQDN.  That's very curious, as that is exactly what must be done.  Have you restarted SMTP service?  
Expert of the Quarter 2009
Expert of the Year 2009
Commented:
Are you referring to this line:

0FF89AA0A405354B84D76464033F84D186AA99@myserver.different-internal-fqdn.local

If so, then that cannot be changed.
It is the message ID.

Here is a genuine one from Microsoft:
AFEFB9745C892042A264169B383E4F0806534E78@DF-MBX-61.exchange.corp.microsoft.com

Live with it, because there is nothing you can do about it. It makes no difference to spam filtering or anything like that.

Simon.

Author

Commented:
What strikes me as odd is that I've never noticed this before.  Couldn't it be a bit of a security risk to reveal internal naming schemes when the whole point of the FQDN in the SMTP virtual server is to present something *other than* the internal FQDN when talking to external hosts?
Expert of the Quarter 2009
Expert of the Year 2009

Commented:
"What strikes me as odd is that I've never noticed this before. Couldn't it be a bit of a security risk to reveal internal naming schemes when the whole point of the FQDN in the SMTP virtual server is to present something *other than* the internal FQDN when talking to external hosts?"

If someone gets to the position where that information is of use, then you have bigger problems to worry about.
When communicating with external SMTP hosts they do not see that information until after the session has been established and email is being delivered. It is part of the core email message, not the delivery section.

Simon.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial