Administration of Active Directory does not have to be hard. Too often what should be a simple task is made more difficult than it needs to be.The solution? Hyena from SystemTools Software. With ease-of-use as well as powerful importing and bulk updating capabilities.
Mail not being received
SBS2008 + Exchange2007 External mail is being received perfectly normally. The only issue I have is with mail from an internal smtp program called Postie.exe. It stopped working a few months ago.
The Postie program is being used by our manufacturing database application. It sends emails to internal users to notify them about various issues within the database.
When look at the Exchange smtp receive log, I see something like this:
+,,
*,SMTPSubmit SMTPAcceptAnyRecipient SMTPAcceptAnySender SMTPAcceptAuthoritativeDom
>,"220 ourserver.ourdomain.co.uk Microsoft ESMTP MAIL Service ready at Fri, 21 Apr 2017 11:58:01 +0100",
<,EHLO aclient.ourdomain.local,
>,250-ourserver.ourdomain.
>,250-SIZE 20971520,
>,250-PIPELINING,
>,250-DSN,
>,250-ENHANCEDSTATUSCODES,
>,250-STARTTLS,
>,250-AUTH,
>,250-8BITMIME,
>,250-BINARYMIME,
>,250 CHUNKING,
<,MAIL FROM:<aclient@ourdomain.co
,*,08D488736BF69D73;2017-0
>,250 2.1.0 Sender OK,
<,"RCPT TO:<anothercient@ourdomain
>,250 2.1.5 Recipient OK,
<,DATA,
>,354 Start mail input; end with <CRLF>.<CRLF>,
>,250 2.6.0 <c120e33b-22a8-45c2-a2eb-4
<,QUIT,
>,221 2.0.0 Service closing transmission channel,
-,,Local
To me, that looks ok but email from the postie program never reaches it's destination these days. I don't know what changed. Can anyone help?
The Postie program is being used by our manufacturing database application. It sends emails to internal users to notify them about various issues within the database.
When look at the Exchange smtp receive log, I see something like this:
+,,
*,SMTPSubmit SMTPAcceptAnyRecipient SMTPAcceptAnySender SMTPAcceptAuthoritativeDom
>,"220 ourserver.ourdomain.co.uk Microsoft ESMTP MAIL Service ready at Fri, 21 Apr 2017 11:58:01 +0100",
<,EHLO aclient.ourdomain.local,
>,250-ourserver.ourdomain.
>,250-SIZE 20971520,
>,250-PIPELINING,
>,250-DSN,
>,250-ENHANCEDSTATUSCODES,
>,250-STARTTLS,
>,250-AUTH,
>,250-8BITMIME,
>,250-BINARYMIME,
>,250 CHUNKING,
<,MAIL FROM:<aclient@ourdomain.co
,*,08D488736BF69D73;2017-0
>,250 2.1.0 Sender OK,
<,"RCPT TO:<anothercient@ourdomain
>,250 2.1.5 Recipient OK,
<,DATA,
>,354 Start mail input; end with <CRLF>.<CRLF>,
>,250 2.6.0 <c120e33b-22a8-45c2-a2eb-4
<,QUIT,
>,221 2.0.0 Service closing transmission channel,
-,,Local
To me, that looks ok but email from the postie program never reaches it's destination these days. I don't know what changed. Can anyone help?
Who is Participating?
Experts Exchange Solution brought to you by
Enjoy your complimentary solution view.
Get every solution instantly with Premium.
Start your 7-day free trial.
I wear a lot of hats...
"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.
I have Receive Connector called "Internal Relay". It doesn't have a White List that I can configure. But in the log I posted above, it states the mail was queued for delivery. Does this statement not imply that the mail has passed all tests and has been accepted?
In Server Configuration -> Hub Transport the server has a white list. All the internal address space has always been white listed.
NOTIFY=DELAY,FAILURE
Shows there is a issue where it is not yet decided if the outcome will be a delay or a failure.
Since you don't get the mails, even with delay, we can conclude it ended in failure, question remaining is why.
What does Exchange Queue Viewer tells you?
Shows there is a issue where it is not yet decided if the outcome will be a delay or a failure.
Since you don't get the mails, even with delay, we can conclude it ended in failure, question remaining is why.
What does Exchange Queue Viewer tells you?
Are you sure about this? When I googled that statement, I found a page saying that this means that the sender is stating that he is prepared to be notified about delays or failures.
The last option is DELAY: you will be notified if there is an unusual delay in delivery, but the actual delivery's outcome (success or failure) is not yet decided. NEVER must be the only argument if it specified, the other three may appear in a list, delimited by a comma. SUCCESS and FAILURE make up for a pretty strong team together(!), telling you in (almost) any case what happened to your mail.
Source for this quote: https://www.lifewire.com/what-is-dsn-delivery-status-notification-for-smtp-email-3860942
OK. So I think we are in agreement on the meaning of the NOTIFY statement. At the point that it appears in the smtp log, the outcome has not been determined. But the smtp log goes on to state that the mail has bee queued for delivery. So I still need to know how to troubleshoot this further,
Thanks for your input so far by the way.
Thanks for your input so far by the way.
Ok, then I would initiate a telnet session from the server hosting this app and send a manual mail.
You can then track this mail via message tracking and see where it goes.
This is a good how to on doing it http://www.yuki-onna.co.uk/email/smtp.html
You can then track this mail via message tracking and see where it goes.
This is a good how to on doing it http://www.yuki-onna.co.uk/email/smtp.html
Is your windows 10 pic the machine where this app resides on?
Oh yes I can imagine ms left it disabled, not anybody needs it.
Run a command prompt as admin and run. dism /online /Enable-Feature /FeatureName:TelnetClient
In a few seconds telnet is enabled.
Oh yes I can imagine ms left it disabled, not anybody needs it.
Run a command prompt as admin and run. dism /online /Enable-Feature /FeatureName:TelnetClient
In a few seconds telnet is enabled.
OK, I stepped through that article and sent a message to myself. In the command prompt window it stated that the message had been queued for delivery. The smtp recieve log stated the same also, but I never received it.
Before i ran the telnet program I went into OrganisationConfiguration -> Hub Transport -> Anti Spam and disabled everything.
I've just noticed something in the smtp receive log..... At the end of the conversation there is the line:
250 2.6.0 <3c9afc57-33ba-4dd6-b656-0
When I look at other entries where the mail was received successfully, the 250 2.6.0 line contains the senders domain rather than our own. Is this relevant?
Before i ran the telnet program I went into OrganisationConfiguration -> Hub Transport -> Anti Spam and disabled everything.
I've just noticed something in the smtp receive log..... At the end of the conversation there is the line:
250 2.6.0 <3c9afc57-33ba-4dd6-b656-0
When I look at other entries where the mail was received successfully, the 250 2.6.0 line contains the senders domain rather than our own. Is this relevant?
Anti Spam and disabled everythingDid you restart the hub transport services after this?
Next, could there be another antivirus of malware program that is quarantining these mails?
Also, when use message tracking in EMC, you know the sender,receiving mailbox and the time, you should be able to find your mail. What is the result?
Experts Exchange Solution brought to you by
Your issues matter to us.
Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.
Start your 7-day free trial
OK I found the problem, and it is of my own creation..... You gave me the hint by suggesting I look at the server anti-virus.
Several months ago we were getting a lot of junk emails which spoofed someone from within our organisation as the sender address. So i created a transport rule to silently drop messages which came from outside of the organisation with one of our users as the sender. It turns out that emails received on the internal smtp connector are also being regarded as originating from outside the organisation. So I can fix this now.
Thank you very much for your help. It is much appreciated.
Ian
Several months ago we were getting a lot of junk emails which spoofed someone from within our organisation as the sender address. So i created a transport rule to silently drop messages which came from outside of the organisation with one of our users as the sender. It turns out that emails received on the internal smtp connector are also being regarded as originating from outside the organisation. So I can fix this now.
Thank you very much for your help. It is much appreciated.
Ian
Nice!! Thank you for the good explanation what went wrong and who is to blame :)
This will help future readers.
Cheers
This will help future readers.
Cheers
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Exchange
From novice to tech pro — start learning today.
-
Business CommunicationCertification: PMI ACP® Project Management Institute Agile Certified P… 340 lessons
-
Microsoft ApplicationsCertification: MOS Microsoft Office Specialist - Excel 2013 Part … 146 lessons
Experts Exchange Solution brought to you by
Enjoy your complimentary solution view.
Get every solution instantly with Premium.
Start your 7-day free trial.
Check your recieve and or relay connector, chances are the IP address from which the emails originate aren't white listed.
Cheers