RevJL
asked on
Exchange 2000 SP3 on a W2K Server SP4 - Slow mail delivery and bounce backs too
Hello Exchange Experts,
We have noticed a decline in the speed that e-mails are being delivered out of our exchange server lately.
Sometimes up to 4 - 5 hours later to known good e-mail addresses that we use daily.
We have also had bounce backs from @yahoo.com e-mail addresses as well. (these come and go sometimes they work and sometimes they don't)
Each morning I "pause" the Virtual SMTP port on the Server for about 1 hour to purge the Delivery Queue.
Trying to free up some Server resources ( Dual 2.3 Ghz CPU's / 8GB Memory / RAID 5 with approx 45 GB HDD free space)
I have scanned the questions on these boards and have found similar issues but no absolute resolutions.
My situation is a single Exchange 2000 SP3 in a medium size company.
I have verified that RDNS is configured through DNSReports with the following issues on the "mail" tab from DNSReports
WARN Mail server host name in greeting WARNING: One or more of your mailservers is claiming to be a host other than what it really is (the SMTP greeting should be a 3-digit code, followed by a space or a dash, then the host name). If your mailserver sends out E-mail using this domain in its EHLO or HELO, your E-mail might get blocked by anti-spam software. This is also a technical violation of RFC821 4.3 (and RFC2821 4.3.1). Note that the hostname given in the SMTP greeting should have an A record pointing back to the same server. Note that this one test may use a cached DNS record.
mail.premiumware.com claims to be non-existent host exchange.TPE.PREMIUMWARE.C
PASS Acceptance of NULL <> sender OK: All of your mailservers accept mail from "<>". You are required (RFC1123 5.2.9) to receive this type of mail (which includes reject/bounce messages and return receipts).
PASS Open relay test OK: All of your mailservers appear to be closed to relaying. This is not a thorough check, you can get a thorough one here.
PASS Acceptance of postmaster address OK: All of your mailservers accept mail to postmaster@premiumware.com
PASS Acceptance of abuse address OK: All of your mailservers accept mail to abuse@premiumware.com.
mail.premiumware.com OK: 550 5.7.1 Unable to relay for Not.abuse.see.www.DNSreport.com.from.IP.70.250.236.209@DNSreport.com <br />
WARN SPF record Your domain does not have an SPF record. This means that spammers can easily send out E-mail that looks like it came from your domain, which can make your domain look bad (if the recipient thinks you really sent it), and can cost you money (when people complain to you, rather than the spammer). You may want to add an SPF record ASAP, as 01 Oct 2004 was the target date for domains to have SPF records in place (Hotmail, for example, started checking SPF records on 01 Oct 2004).
I have since setup the SPF record on our DNS Server.
Still e-mails are slow to be delivered we have also been experiencing some delays to the inetrnet connections across our network as well.
We use McAfee Groupshield on the Exchange Server and McAfee Virus Scan on the workstations and all are updated automatically and have current DATS and Engines installed.
Need more expertise / help to track this issue down before it starts to affect out client relationships.
Thanks in advance for your time and attention,
RevJL
We have noticed a decline in the speed that e-mails are being delivered out of our exchange server lately.
Sometimes up to 4 - 5 hours later to known good e-mail addresses that we use daily.
We have also had bounce backs from @yahoo.com e-mail addresses as well. (these come and go sometimes they work and sometimes they don't)
Each morning I "pause" the Virtual SMTP port on the Server for about 1 hour to purge the Delivery Queue.
Trying to free up some Server resources ( Dual 2.3 Ghz CPU's / 8GB Memory / RAID 5 with approx 45 GB HDD free space)
I have scanned the questions on these boards and have found similar issues but no absolute resolutions.
My situation is a single Exchange 2000 SP3 in a medium size company.
I have verified that RDNS is configured through DNSReports with the following issues on the "mail" tab from DNSReports
WARN Mail server host name in greeting WARNING: One or more of your mailservers is claiming to be a host other than what it really is (the SMTP greeting should be a 3-digit code, followed by a space or a dash, then the host name). If your mailserver sends out E-mail using this domain in its EHLO or HELO, your E-mail might get blocked by anti-spam software. This is also a technical violation of RFC821 4.3 (and RFC2821 4.3.1). Note that the hostname given in the SMTP greeting should have an A record pointing back to the same server. Note that this one test may use a cached DNS record.
mail.premiumware.com claims to be non-existent host exchange.TPE.PREMIUMWARE.C
PASS Acceptance of NULL <> sender OK: All of your mailservers accept mail from "<>". You are required (RFC1123 5.2.9) to receive this type of mail (which includes reject/bounce messages and return receipts).
PASS Open relay test OK: All of your mailservers appear to be closed to relaying. This is not a thorough check, you can get a thorough one here.
PASS Acceptance of postmaster address OK: All of your mailservers accept mail to postmaster@premiumware.com
PASS Acceptance of abuse address OK: All of your mailservers accept mail to abuse@premiumware.com.
mail.premiumware.com OK: 550 5.7.1 Unable to relay for Not.abuse.see.www.DNSreport.com.from.IP.70.250.236.209@DNSreport.com <br />
WARN SPF record Your domain does not have an SPF record. This means that spammers can easily send out E-mail that looks like it came from your domain, which can make your domain look bad (if the recipient thinks you really sent it), and can cost you money (when people complain to you, rather than the spammer). You may want to add an SPF record ASAP, as 01 Oct 2004 was the target date for domains to have SPF records in place (Hotmail, for example, started checking SPF records on 01 Oct 2004).
I have since setup the SPF record on our DNS Server.
Still e-mails are slow to be delivered we have also been experiencing some delays to the inetrnet connections across our network as well.
We use McAfee Groupshield on the Exchange Server and McAfee Virus Scan on the workstations and all are updated automatically and have current DATS and Engines installed.
Need more expertise / help to track this issue down before it starts to affect out client relationships.
Thanks in advance for your time and attention,
RevJL
ASKER
darkstar3d,
Thanks for your input ....... a couple of questions before I proceed.
1) Where in the DNS should the record for External IP be entered ?
a) Cached Lookups
b) Forward Lookup Zone
c) Reverse Lookup Zone
2) Where in the Exchange EMS - Delivery Tab - Advance Button
a) Masquerade Domain
b) FQDN - already has the entry of : ServerName.Domain.Com
c) Smart Host
Thanks again
Thanks for your input ....... a couple of questions before I proceed.
1) Where in the DNS should the record for External IP be entered ?
a) Cached Lookups
b) Forward Lookup Zone
c) Reverse Lookup Zone
2) Where in the Exchange EMS - Delivery Tab - Advance Button
a) Masquerade Domain
b) FQDN - already has the entry of : ServerName.Domain.Com
c) Smart Host
Thanks again
ASKER
darkstar3d,
As an after thought, we do have DNS records managed / maintained externally (at AT&T Data Center) that have
1) A - Record pointing to - mail.premiumware.com
2) MX - Record for our domain that also resolves to - mail.premiumware.com
3) MX - Record for our ISP relay - smtp-relay.swbell.net
or are you speaking about the DNS on my Domain Controller here in my office ?
Just trying clarify for my own purposes and knowledge.
Thanks
As an after thought, we do have DNS records managed / maintained externally (at AT&T Data Center) that have
1) A - Record pointing to - mail.premiumware.com
2) MX - Record for our domain that also resolves to - mail.premiumware.com
3) MX - Record for our ISP relay - smtp-relay.swbell.net
or are you speaking about the DNS on my Domain Controller here in my office ?
Just trying clarify for my own purposes and knowledge.
Thanks
DNS should be in the Reverse zone, but as AT&T manages that, make sure its pointed at your mail server's IP. If you have only one external IP, then make sure traffic to that host is routed to your mail server. That should satisfy the RDNS for that one.
So, based on what you posted, your DNS should be good, just set that FQDN to mail.premiumware.com and you should be good. Also check to see if the local (if any) DNS check on mail.premiumware.com is good by clicking the check button. Rerun the DNS check at DNSReports and see if you get all green.
So, based on what you posted, your DNS should be good, just set that FQDN to mail.premiumware.com and you should be good. Also check to see if the local (if any) DNS check on mail.premiumware.com is good by clicking the check button. Rerun the DNS check at DNSReports and see if you get all green.
ASKER
darkstar3d,
OK - the changing of the FQDN in Exchange EMS fixed the warning about mailserver claiiming to be a host ather than what it really is (SMTP greeting)
AT&T is pointing our mail.premiumware.com to our External IP address.
There is still a warning on the SPF Record.
I put a SPF entry into our / Forward Lookup Zone / Domain.com - entered as :
NAME COLUMN = (same as parent folder)
TYPE COLUMN = TXT
DATA COLUMN = v=spf1 mx ~all
I'm still not entirely clear on this entry ..... whether it needs to be on my Local DNS or at the External DNS at AT&T ....... do you know the answer to that ?
(This was on yesterdays report as well) - I also have a FAIL - Connect to Mail Server from DNSReports in the Mail Entry with the error message :
ERROR: I could not complete a connection to one or more of your mailservers:
smtp-relay.swbell.net: Timed out [Last data sent: [Did not connect]]
Don't know what this is about either
Although we still have mail coming into our server and out to workstations in the office.
Thanks
OK - the changing of the FQDN in Exchange EMS fixed the warning about mailserver claiiming to be a host ather than what it really is (SMTP greeting)
AT&T is pointing our mail.premiumware.com to our External IP address.
There is still a warning on the SPF Record.
I put a SPF entry into our / Forward Lookup Zone / Domain.com - entered as :
NAME COLUMN = (same as parent folder)
TYPE COLUMN = TXT
DATA COLUMN = v=spf1 mx ~all
I'm still not entirely clear on this entry ..... whether it needs to be on my Local DNS or at the External DNS at AT&T ....... do you know the answer to that ?
(This was on yesterdays report as well) - I also have a FAIL - Connect to Mail Server from DNSReports in the Mail Entry with the error message :
ERROR: I could not complete a connection to one or more of your mailservers:
smtp-relay.swbell.net: Timed out [Last data sent: [Did not connect]]
Don't know what this is about either
Although we still have mail coming into our server and out to workstations in the office.
Thanks
ASKER
darkstar3d,
I have the SPF Record information found out.
It is supposed to be entered into the External DNS for e-mail checking before delivery.
Still don't understand why DNSReports shows "Cannot Connect to Mail Server from DNSReports in the Mail Entry with the error message :
ERROR: I could not complete a connection to one or more of your mailservers:
smtp-relay.swbell.net: Timed out [Last data sent: [Did not connect]]
Any ideas what this is about or why it is occuring when mail is still being delivered ....... although slowly.
Thanks again for yuor input
I have the SPF Record information found out.
It is supposed to be entered into the External DNS for e-mail checking before delivery.
Still don't understand why DNSReports shows "Cannot Connect to Mail Server from DNSReports in the Mail Entry with the error message :
ERROR: I could not complete a connection to one or more of your mailservers:
smtp-relay.swbell.net: Timed out [Last data sent: [Did not connect]]
Any ideas what this is about or why it is occuring when mail is still being delivered ....... although slowly.
Thanks again for yuor input
That should have cleared up your outbound delivery. Are you having queue build up? If so, which queue are the messages in?
Most SMTP relay for internal stuff won't answer externally.
SPF is generally not in use. Good idea, poor rollout. Hopefully that will change sooner rather than latter.
Most SMTP relay for internal stuff won't answer externally.
SPF is generally not in use. Good idea, poor rollout. Hopefully that will change sooner rather than latter.
ASKER
Yes, we do have significant message build up in the queue.
The only SMTP that we use is the Default SMTP Virtual Server.
When I come in in the mornings there are a list of 20 - 30 IP addresses in the Current Session window.
I terminate all of them and then "pause" the SMTP Virtual Server for about 1 hour to empty the queue.
I ask about the SPF Record because we do experience some spoofing of our e-mail addresses where we receive e-mails from our own e-mail addresses that we didn't send an several others from unknown users@ourdomain.com.
After all of this, I tried sending an e-mail to an external yahoo address yesterday around 1:30pm and it still hadn't arrived until sometime in the night after I had left the office for the day when I checked that yahoo address this morning it was in the inbox.
Just don't know what else could be causing this nightmare.
The only SMTP that we use is the Default SMTP Virtual Server.
When I come in in the mornings there are a list of 20 - 30 IP addresses in the Current Session window.
I terminate all of them and then "pause" the SMTP Virtual Server for about 1 hour to empty the queue.
I ask about the SPF Record because we do experience some spoofing of our e-mail addresses where we receive e-mails from our own e-mail addresses that we didn't send an several others from unknown users@ourdomain.com.
After all of this, I tried sending an e-mail to an external yahoo address yesterday around 1:30pm and it still hadn't arrived until sometime in the night after I had left the office for the day when I checked that yahoo address this morning it was in the inbox.
Just don't know what else could be causing this nightmare.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The fix is:
1. Ensure a record exists in DNS for mail.premiumware.com that points to the external IP of the Exchange Server.
2. Open up EMS. in the Advanced Delivery box of the delivery tab of the virtual SMTP properties, enter the mail.premiumware.com.
After this, restart the SMTP service on the machine and do the test again. The DNS entry will take time to show up, so do that one first.