Prev: Can't run Exchange Management Shell - type initializer excepti
Next: Can not Email 17mb file outside our SMTP connector
From: M on 28 May 2010 15:53
Ok. Let us know what happens. If you haven't done so, I would suggest that
you ask the recipient to put in a helpdesk ticket on his or her end and
request that it be routed to the group that manages the e-mail system. This
would obligate the recipient's sys admin to help you. If you haven't made
any recent server or network changes, then the issue could be on their end.
Either way, it would be helpful if they could check their server logs and
see why some of your messages got NDR'd.

--
Regards,
M
MCTS, MCSA
http://SysAdmin-E.com

"John" <a> wrote in message news:%231eYrop$KHA.5808(a)TK2MSFTNGP02.phx.gbl...
> Thank you for your explanation. Yes I can telnet from my mail server to
> their mail server IP address and issue all EHLO, MAIL FROM, RCPT TO, DATA
> commands without any problem. I just did a telnet test. It went through
> just fine with the last 2 messages shown below:
>
> 250 Backend Replied
> [4h3f0c4.0.235641.00-105.306933.pc062.theirdomain.com]: Ok (Mode: normal)
> 221 pc062.theirdomain.com Service closing transmission channel [235641.00]
>
> Here's what I found more:
> Since I posted my question, I've sent them multiple messages with Outlook
> 2007, only 1 got through. The rest bounces back to me.
>
> At this moment, I can only troubleshoot my own server. The next step is to
> contact their mail admin before making any changes to my mail server. I'm
> crossing my fingers that they want to help troubleshoot the problem
> instead of dismissing it as our server's fault.
>
>
> "M" <m(a)nowhere.com> wrote in message
> news:%23hnpK6o$KHA.3176(a)TK2MSFTNGP05.phx.gbl...
>> Hello:
>>
>> First, contact someone at the recipient domain and see if they made any
>> recent changes. They might have installed a new anti-spam system or
>> had some network/server issues.
>>
>> You should check the RECIPIENT'S domain with MXToolbox since the
>> NDR is stating that there was a communications problem between your
>> servers and the
>> recipient's.
>>
>> Can you telnet to port 25 of the IP addresses of the recipient's MX
>> records? Maybe there's a
>> network issue between you and the recipient. MXToolbox does the tests
>> from their servers
>> (their meaning MXToolbox) so they might not show any issues.
>>
>> If everything checks out, what you suggested as a cause is a possibility
>> (I don't think PTR is the right term,
>> but I know what you mean). I had what could be the same or similar issue,
>> but the NDR was different (see below). My issue was fixed when I changed
>> the
>> FQDN of my Exchange SMTP Virtual Server to match the external host name.
>>
>> There's some debate about what I did, but once I made the change, it
>> corrected my issue. This might not be related to your issue, but
>> sometimes
>> NDRs are not very clear on what exactly the issue is, so you'd need to
>> try a
>> few things.
>>
>> bob(a)abc.com on 3/9/2009 2:24 PM
>> You do not have permission to send to this recipient. For
>> assistance, contact your system administrator.
>> <ex01.mydomain.com #5.7.1 smtp;554 5.7.1 <ex01.mydomain.com>:
>> Helo command rejected: Host not found>
>>
>> Here are some notes that I made when I fixed my issue:
>> -----------------
>> Go to the SMTP VS properties --> Delivery tab --> Advanced button. The
>> FQDN
>> is what shows up in the message headers. It appears that some recipient
>> systems will reject messages if the FQDN of the sending SMTP server is
>> not a
>> valid server for the sending domain.
>>
>> This doesn't make a lot of sense as to why the recipient system would
>> bother
>> making sure that the sending server's hostname matches a reverse DNS
>> lookup.
>> As long as the IP address of the sending system matches what's in the MX
>> or
>> SPF records, that should overrule the hostname discrepancy. A hostname is
>> obviously much easier to spoof than an IP address. But apparently some
>> anti-spam systems check for this and won't accept mail if there's a
>> discrepancy between the sending hostname and the reverse DNS lookup of
>> its
>> IP address.
>>
>> Under "Myth 3b: Modifying The FQDN of the SMTP Virtual Server" on
>> http://msexchangeteam.com/archive/2005/02/25/380481.aspx, it advises
>> against
>> changing the FQDN of the default SMTP VS. If you do go ahead and change
>> the
>> FQDN, the SMTPSVC SPN must be updated for the server's AD object to
>> reflect
>> the change per
>> http://technet.microsoft.com/en-us/library/aa996905%28EXCHG.80%29.aspx.
>> Note
>> that the change can be made using ADSIEdit to edit the
>> servicePrincipalName
>> attribute (I've personally done this).
>>
>> The reply to this posting states that best practice is to the leave the
>> FQDN
>> as is. (Doing that would not resolve the NDR issue then, and I don't see
>> why
>> it should not be changed if the field is changeable. If best practice is
>> to
>> leave it alone, then why does MS even make the field changeable?):
>> http://forums.msexchange.org/m_1800493025/mpage_1/key_/tm.htm#1800493025
>> -----------------
>>
>> If you don't want to make any changes, then ask the recipient domain's
>> sys
>> admin to whitelist your mail servers and see if that corrects the issue.
>>
>> --
>> Regards,
>> M
>> MCTS, MCSA
>> http://SysAdmin-E.com
>>
>
>


From: Rich Matheisen [MVP] on 28 May 2010 17:11
On Fri, 28 May 2010 11:08:42 -0700, "John" <a> wrote:

>
>"Rich Matheisen [MVP]" <richnews(a)rmcons.com.NOSPAM.COM> wrote in message
>news:r2vvv5hvho69oi90jempdth1cfdbl0bn13(a)4ax.com...
>>
>> Only the admin at the receiving MTA knows why they send a 554 status.
>> There's no meaningful information in the text part of the status.
>
>Does the following SMTP log from my server help?

No, it just says the same thing you posted earlier. The only thing
that may be significant is that the DATA command is what's rejected.
That seems like it's related to the content of the message or the
reputation of the sending IP address, or both. IOW, your e-mail is
rejected as spam.

[ snip ]

>> Could it be that your server is incorrectly identifying itself? Sure.
>> Fix it and see it it makes the problem go away. If it doesn't, find
>> someone at the other domain and call them, or use a hotmail, yahoo,
>> aol, etc. account and e-mail them.
>
>Is this the correct location?
>ESM - Administrative Group - MyAdminGroup - Servers -
>my-exchange-internal-name - Protocols - SMTP - Default SMTP Virtual Server -
>(right click) Properties - Delivery (tab) - Advanced (button) -
>Fully-qualified domain name:

Yes.

>Currently showing: my-exchange-internal-name.mydomainname.com
>Is this the correct field to change so that my Exchange identifies itself as
>mail. blah blah (it matches the PTR record)?

It is. Once you make that change you should also add an "A" record to
your internal DNS with that name. With only one server it probably
doesn't matter, but if you have more than one strange things will
happen without that A record. Add it just to be safe. :-)
---
Rich Matheisen
MCSE+I, Exchange MVP
From: John on 28 May 2010 17:24
I'm waiting for a response from the recipient's mail administrator (if I can
get a hold of them) before making any changes to my server.

Thanks again for your help.

"Rich Matheisen [MVP]" <richnews(a)rmcons.com.NOSPAM.COM> wrote in message
news:81c006l85vu5965n0b37sc1pri5vt1m56i(a)4ax.com...
> On Fri, 28 May 2010 11:08:42 -0700, "John" <a> wrote:
>
>>
>>"Rich Matheisen [MVP]" <richnews(a)rmcons.com.NOSPAM.COM> wrote in message
>>news:r2vvv5hvho69oi90jempdth1cfdbl0bn13(a)4ax.com...
>>>
>>> Only the admin at the receiving MTA knows why they send a 554 status.
>>> There's no meaningful information in the text part of the status.
>>
>>Does the following SMTP log from my server help?
>
> No, it just says the same thing you posted earlier. The only thing
> that may be significant is that the DATA command is what's rejected.
> That seems like it's related to the content of the message or the
> reputation of the sending IP address, or both. IOW, your e-mail is
> rejected as spam.
>
> [ snip ]
>
>>> Could it be that your server is incorrectly identifying itself? Sure.
>>> Fix it and see it it makes the problem go away. If it doesn't, find
>>> someone at the other domain and call them, or use a hotmail, yahoo,
>>> aol, etc. account and e-mail them.
>>
>>Is this the correct location?
>>ESM - Administrative Group - MyAdminGroup - Servers -
>>my-exchange-internal-name - Protocols - SMTP - Default SMTP Virtual
>>Server -
>>(right click) Properties - Delivery (tab) - Advanced (button) -
>>Fully-qualified domain name:
>
> Yes.
>
>>Currently showing: my-exchange-internal-name.mydomainname.com
>>Is this the correct field to change so that my Exchange identifies itself
>>as
>>mail. blah blah (it matches the PTR record)?
>
> It is. Once you make that change you should also add an "A" record to
> your internal DNS with that name. With only one server it probably
> doesn't matter, but if you have more than one strange things will
> happen without that A record. Add it just to be safe. :-)
> ---
> Rich Matheisen
> MCSE+I, Exchange MVP


From: John on 28 May 2010 17:46
Btw, this makes sense.

"Rich Matheisen [MVP]" <richnews(a)rmcons.com.NOSPAM.COM> wrote in message
news:81c006l85vu5965n0b37sc1pri5vt1m56i(a)4ax.com...
>
> No, it just says the same thing you posted earlier. The only thing
> that may be significant is that the DATA command is what's rejected.
> That seems like it's related to the content of the message or the
> reputation of the sending IP address, or both. IOW, your e-mail is
> rejected as spam.


From: John on 1 Jun 2010 15:28
I have not heard anything from the recipient's mail administrator.

Going back to my original suspicion shown below:

Could this issue be related to the fact that my PTR record is
"mail.mydomainname.com" but my SMTP identifies itself as
"my-exchange-internal-name.mydomainname.com" in ehlo command? If that is
true, how can I correct this?

Instead of makes changes to my Exchange server settings, what if I change
the (publib) DNS settings from "mail" to "my-exchange-internal-name"? I
suppose that'll accomplish the same thing, won't it?

Thanks again.


"M" <m(a)nowhere.com> wrote in message
news:%23bYO29p$KHA.5808(a)TK2MSFTNGP02.phx.gbl...
> Ok. Let us know what happens. If you haven't done so, I would suggest that
> you ask the recipient to put in a helpdesk ticket on his or her end and
> request that it be routed to the group that manages the e-mail system.
> This would obligate the recipient's sys admin to help you. If you haven't
> made any recent server or network changes, then the issue could be on
> their end. Either way, it would be helpful if they could check their
> server logs and see why some of your messages got NDR'd.
>
> --
> Regards,
> M
> MCTS, MCSA
> http://SysAdmin-E.com
>
> "John" <a> wrote in message
> news:%231eYrop$KHA.5808(a)TK2MSFTNGP02.phx.gbl...
>> Thank you for your explanation. Yes I can telnet from my mail server to
>> their mail server IP address and issue all EHLO, MAIL FROM, RCPT TO, DATA
>> commands without any problem. I just did a telnet test. It went through
>> just fine with the last 2 messages shown below:
>>
>> 250 Backend Replied
>> [4h3f0c4.0.235641.00-105.306933.pc062.theirdomain.com]: Ok (Mode: normal)
>> 221 pc062.theirdomain.com Service closing transmission channel
>> [235641.00]
>>
>> Here's what I found more:
>> Since I posted my question, I've sent them multiple messages with Outlook
>> 2007, only 1 got through. The rest bounces back to me.
>>
>> At this moment, I can only troubleshoot my own server. The next step is
>> to contact their mail admin before making any changes to my mail server.
>> I'm crossing my fingers that they want to help troubleshoot the problem
>> instead of dismissing it as our server's fault.
>>
>>
>> "M" <m(a)nowhere.com> wrote in message
>> news:%23hnpK6o$KHA.3176(a)TK2MSFTNGP05.phx.gbl...
>>> Hello:
>>>
>>> First, contact someone at the recipient domain and see if they made any
>>> recent changes. They might have installed a new anti-spam system or
>>> had some network/server issues.
>>>
>>> You should check the RECIPIENT'S domain with MXToolbox since the
>>> NDR is stating that there was a communications problem between your
>>> servers and the
>>> recipient's.
>>>
>>> Can you telnet to port 25 of the IP addresses of the recipient's MX
>>> records? Maybe there's a
>>> network issue between you and the recipient. MXToolbox does the tests
>>> from their servers
>>> (their meaning MXToolbox) so they might not show any issues.
>>>
>>> If everything checks out, what you suggested as a cause is a possibility
>>> (I don't think PTR is the right term,
>>> but I know what you mean). I had what could be the same or similar
>>> issue,
>>> but the NDR was different (see below). My issue was fixed when I changed
>>> the
>>> FQDN of my Exchange SMTP Virtual Server to match the external host name.
>>>
>>> There's some debate about what I did, but once I made the change, it
>>> corrected my issue. This might not be related to your issue, but
>>> sometimes
>>> NDRs are not very clear on what exactly the issue is, so you'd need to
>>> try a
>>> few things.
>>>
>>> bob(a)abc.com on 3/9/2009 2:24 PM
>>> You do not have permission to send to this recipient. For
>>> assistance, contact your system administrator.
>>> <ex01.mydomain.com #5.7.1 smtp;554 5.7.1 <ex01.mydomain.com>:
>>> Helo command rejected: Host not found>
>>>
>>> Here are some notes that I made when I fixed my issue:
>>> -----------------
>>> Go to the SMTP VS properties --> Delivery tab --> Advanced button. The
>>> FQDN
>>> is what shows up in the message headers. It appears that some recipient
>>> systems will reject messages if the FQDN of the sending SMTP server is
>>> not a
>>> valid server for the sending domain.
>>>
>>> This doesn't make a lot of sense as to why the recipient system would
>>> bother
>>> making sure that the sending server's hostname matches a reverse DNS
>>> lookup.
>>> As long as the IP address of the sending system matches what's in the MX
>>> or
>>> SPF records, that should overrule the hostname discrepancy. A hostname
>>> is
>>> obviously much easier to spoof than an IP address. But apparently some
>>> anti-spam systems check for this and won't accept mail if there's a
>>> discrepancy between the sending hostname and the reverse DNS lookup of
>>> its
>>> IP address.
>>>
>>> Under "Myth 3b: Modifying The FQDN of the SMTP Virtual Server" on
>>> http://msexchangeteam.com/archive/2005/02/25/380481.aspx, it advises
>>> against
>>> changing the FQDN of the default SMTP VS. If you do go ahead and change
>>> the
>>> FQDN, the SMTPSVC SPN must be updated for the server's AD object to
>>> reflect
>>> the change per
>>> http://technet.microsoft.com/en-us/library/aa996905%28EXCHG.80%29.aspx.
>>> Note
>>> that the change can be made using ADSIEdit to edit the
>>> servicePrincipalName
>>> attribute (I've personally done this).
>>>
>>> The reply to this posting states that best practice is to the leave the
>>> FQDN
>>> as is. (Doing that would not resolve the NDR issue then, and I don't see
>>> why
>>> it should not be changed if the field is changeable. If best practice is
>>> to
>>> leave it alone, then why does MS even make the field changeable?):
>>> http://forums.msexchange.org/m_1800493025/mpage_1/key_/tm.htm#1800493025
>>> -----------------
>>>
>>> If you don't want to make any changes, then ask the recipient domain's
>>> sys
>>> admin to whitelist your mail servers and see if that corrects the issue.
>>>
>>> --
>>> Regards,
>>> M
>>> MCTS, MCSA
>>> http://SysAdmin-E.com
>>>
>>
>>
>
>


First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Can't run Exchange Management Shell - type initializer excepti
Next: Can not Email 17mb file outside our SMTP connector