Default SMTP Virtual Server & Smart Host
Ok, this may be a little confusing.
Company has 8 exchange servers throughout states. We have one LOCAL server called "MAIL" which has GFI Essentials installed on it. It also has IIS installed and running and under Default SMTP Virtual Server, it has "Mail - as local" + two other domains (as remote) Domain1 & Domain2 (it's just two variations of our domain name) as virtual servers.
Under "Mail" all that is set up is a DROP directory.
1st domain has allow incoming mail to be relayed to this domain & forward all mail to smart host (10.x.x.x)
2nd domain - same settings.
Now on our truly MAIN Exchange Server - Domain1, all the 8 Exchange servers are listed. Under Default SMTP Virtual Server there is no information entered there. And Domain1 IS the Smart Host.
We have a user who has been receiving the same email message over and over again, and so I contacted the dept of the company he's receiving from, and according to him, in his message tracking for that particular email message there is an error stating -> error transferring to "Mail" SMTP protocol returned permanent error.
All Queues have been checked, everything has been checked and none of us can figure out what's going on.
Any suggestions?
Company has 8 exchange servers throughout states. We have one LOCAL server called "MAIL" which has GFI Essentials installed on it. It also has IIS installed and running and under Default SMTP Virtual Server, it has "Mail - as local" + two other domains (as remote) Domain1 & Domain2 (it's just two variations of our domain name) as virtual servers.
Under "Mail" all that is set up is a DROP directory.
1st domain has allow incoming mail to be relayed to this domain & forward all mail to smart host (10.x.x.x)
2nd domain - same settings.
Now on our truly MAIN Exchange Server - Domain1, all the 8 Exchange servers are listed. Under Default SMTP Virtual Server there is no information entered there. And Domain1 IS the Smart Host.
We have a user who has been receiving the same email message over and over again, and so I contacted the dept of the company he's receiving from, and according to him, in his message tracking for that particular email message there is an error stating -> error transferring to "Mail" SMTP protocol returned permanent error.
All Queues have been checked, everything has been checked and none of us can figure out what's going on.
Any suggestions?
ASKER
I meant Outlook 2003.
That is usually caused by a firewall or other product interfering with the SMTP traffic. The Cisco PIX is notorious for doing this. Therefore the first to check is your firewall, to see whether it has any of kind of SMTP scanning facility enabled. If it does, turn it off.
Simon.
Simon.
ASKER
Cisco checked and there's no enabling (mail guard).
You have to then look at what else could be interfering with the SMTP traffic flow. Antivirus and antispam applications have also been known to cause these sorts of problems.
This is a pure SMTP problem - it isn't even getting to your Exchange servers.
Simon.
This is a pure SMTP problem - it isn't even getting to your Exchange servers.
Simon.
ASKER
OK, if it is an SMTP problem, then it must be occurring at the server which has our Spam filtering software installed - GFI. All emails run through this server before being passed onto our main exchange server; which then passes it to whatever state server it needs to be delivered.
I don't know where to begin. I've looked all throughout the GFI Essential GUI and can't find jack about anything. It appears as though there's hardly anything set up other than the black and whitelist, and passing through it then to our smarthost (Domain1). When I look through the GFI folders, the only folder that ever has any information is the queue folder where the .eml mails are being processed and I can see them disappearing one by one, but there are no logs here or anywhere on this server.
If I go to Domain1 and look into the log in the Exchsrvr folder, and open the text document, it's so jumbled it's hard for me to determine which line corresponds to what, for me to even see an event# of maybe 10 for delivered or 1015 for the NDR. Is there an easier way/program to open these log files in so I can read them more clearly? Excel?
I'm pretty sure these reports are tab-delimited? or is there a program available that will sort logs into the correct columns and rows?
Another thing that is odd is NDR reports has been disabled on all the servers, so the users don't receive the message their email was undelivered; these have been directed to an IT email address. But, somehow one of our internal users called the other day saying her received a rejected email from someone w/in our own domain. How could that be if that feature is turned off?
I know I can keep track of the NDR's and the one's which aren't marked as SPAM - feature setup w/in GFI, I can go into Message Tracking for the message Subject to find out the sender, b/c the NDR only states from Sys Admin, but that seems like it's the long way. Is there a shorter way?
And is there a way to have the NDR specify, who the sender of the email was?
Here's one in the IT emails:
From: System Administrator
Sent: Friday, April 07, 2006 4:06 PM
To: ithelpdesk@domain.com
Subject: Undeliverable:[domain.com #7261] New project directory
Your message did not reach some or all of the intended recipients.
Subject: [domain.com #7261] New project directory
Sent: 4/7/2006 4:06 PM
The following recipient(s) could not be reached:
ithelpdesk@domain.com on 4/7/2006 4:06 PM
The e-mail account does not exist at the organization this message was sent to. Check the e-mail address, or contact the recipient directly to find out the correct address.
<domain1.domain.com #5.1.1>
And actually the ithelpdesk email address does exist.
Lately when we've been having these issues, we go to Domain1 and stop and then restart the virtual server of the location, and that appears to resolve the problem.
What's going on, Sembee?
I don't know where to begin. I've looked all throughout the GFI Essential GUI and can't find jack about anything. It appears as though there's hardly anything set up other than the black and whitelist, and passing through it then to our smarthost (Domain1). When I look through the GFI folders, the only folder that ever has any information is the queue folder where the .eml mails are being processed and I can see them disappearing one by one, but there are no logs here or anywhere on this server.
If I go to Domain1 and look into the log in the Exchsrvr folder, and open the text document, it's so jumbled it's hard for me to determine which line corresponds to what, for me to even see an event# of maybe 10 for delivered or 1015 for the NDR. Is there an easier way/program to open these log files in so I can read them more clearly? Excel?
I'm pretty sure these reports are tab-delimited? or is there a program available that will sort logs into the correct columns and rows?
Another thing that is odd is NDR reports has been disabled on all the servers, so the users don't receive the message their email was undelivered; these have been directed to an IT email address. But, somehow one of our internal users called the other day saying her received a rejected email from someone w/in our own domain. How could that be if that feature is turned off?
I know I can keep track of the NDR's and the one's which aren't marked as SPAM - feature setup w/in GFI, I can go into Message Tracking for the message Subject to find out the sender, b/c the NDR only states from Sys Admin, but that seems like it's the long way. Is there a shorter way?
And is there a way to have the NDR specify, who the sender of the email was?
Here's one in the IT emails:
From: System Administrator
Sent: Friday, April 07, 2006 4:06 PM
To: ithelpdesk@domain.com
Subject: Undeliverable:[domain.com #7261] New project directory
Your message did not reach some or all of the intended recipients.
Subject: [domain.com #7261] New project directory
Sent: 4/7/2006 4:06 PM
The following recipient(s) could not be reached:
ithelpdesk@domain.com on 4/7/2006 4:06 PM
The e-mail account does not exist at the organization this message was sent to. Check the e-mail address, or contact the recipient directly to find out the correct address.
<domain1.domain.com #5.1.1>
And actually the ithelpdesk email address does exist.
Lately when we've been having these issues, we go to Domain1 and stop and then restart the virtual server of the location, and that appears to resolve the problem.
What's going on, Sembee?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I'm not in charge of the GFI or the settings of the NDRs, we have a "Security Admin" who has set certain features to his experience; whether they're right i have no idea, but he'll point out, he's got 6 certification titles behind his name.
Uninstalling GFI and reinstalling would cause a mass of SPAM to come in, so i'll have to pass this info on to my manager and let him know that some settings and configurations just aren't set to be beneficial to the company or IT dept.
Thanks for you input, I'll keep you posted.
Uninstalling GFI and reinstalling would cause a mass of SPAM to come in, so i'll have to pass this info on to my manager and let him know that some settings and configurations just aren't set to be beneficial to the company or IT dept.
Thanks for you input, I'll keep you posted.
ASKER
It's been so long since I checked this posting. I had done something one day to the exchange server and then the guy stopped receiving the emails.
Ok, i just looked. The only thing I did was to stop and restart the service on that exchange server, and the user stopped receiving the duplicate emails. I don't know whether that was what corrected the problem; whether it corrected itself, or whether it was a GFI error and it worked itself out.
So, far GFI has been nothing but a pain.
Then the Security Admin ran some updates on GFI and noone has had problems ever since.
Ok, i just looked. The only thing I did was to stop and restart the service on that exchange server, and the user stopped receiving the duplicate emails. I don't know whether that was what corrected the problem; whether it corrected itself, or whether it was a GFI error and it worked itself out.
So, far GFI has been nothing but a pain.
Then the Security Admin ran some updates on GFI and noone has had problems ever since.
ASKER