Last week, I setup a new domain and Exchange Server 2007 SP1. I created new accounts and mailboxes for my 30 users and imported all mail from their old domain to this new server. It's a Hub Transport on a Windows 2003 Server R2 SP2. I don't have an Edge Transport Server. I setup the server as servername.mydomain.local and then added mydomain.com as the default accepted domain.
Internal email and most external mail is flowing just fine.
However, my users are getting "Delivery Delayed" messages when sending to a couple external addresses. In the Exchange Management Console "Queue Viewer", 2 recipient domains are rejecting email with similar notices:
451-4.4.0 Primary target IP address responded with: "554-p3pismtp01-027.prod.phx3.secureserver.net##451 4.4.0.554 Your access to this mail system has been rejected due to spam or virus content. If you believe that this failure is in error, please submit an u...
I believe they accepted mail in the past from the old Exchange server.
This morning, I added an SPF record with our domain registrar for the new server (there was none before for the old server). It doesn't seem to have helped.
I think the rejections might be related to a needed certificate on my server? I am getting an error 12014 in my Event Log.
Event Type: Error
Event Source: MSExchangeTransport
Event Category: TransportService
Event ID: 12014
Date: 10/28/2010
Time: 12:27:05 PM
User: N/A
Computer: SERVERNAME
Description:
Microsoft Exchange couldn't find a certificate that contains the domain name mail.mydomain.com in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector SMTP Send Connector with a FQDN parameter of mail.mydomain.com. If the connector's FQDN is not specified, the computer's FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Is this the same as the self-signed SSL Certificate? In the Exchange Shell, Get-ExchangeCertificate yields a thumbprint with Services listed as IP.WS and the Subject as CN=servername. I am thinking that I need to create a certificate for one or more of the following?
1. mail.mydomain.com (the FQDN used in my MX record)
2. servername.mydomain.com
3. servername.mydomain.local
and then use the Enable-ExchangeCertificate cmdlet as directed in the Event log error?
I need help figuring out which certificate to create and how to do that if it's not the same as the SSL certificate...
Also, I'm not sure if this might be related: I set my SMTP send connector to specify mail.mydomain.com as the FQDN response to HELO or EHLO. However, per the system Help recommendation, I left my Receive Connectors (Client and Default) as servername.mydomain.local (regarding HELO response).
Any help and guidance would be greatly appreciated! Thanks! -Dan
It's got nothing to do with the certificate. the clue is in the notification:
So you need to find out exactly what's triggering their Spam filter. You could try to contact the postmaster at the recipient domain.
BitCareTech hit the nail on the head (see above)
Short answer: I had to create an rDNS PTR record with my ISP and then go to unblock.secureserver.net (aka GoDaddy.com) and request that they unblock my IP address. See details above...
Just to clear up the certificate error, that's just a simple informational log entry. It's a bit like saying "Unable to find very expensive supercar on my driveway, I suppose I had better use that old Ford". That doesn't mean you can't drive to work...
Certificates are used to encrypt email in transit between two points and have nothing to do with sender reputation and won't make people more likely to accept email; if they believed you were sending them spam or virus output then installing a certificate will not make them say "Oh well, they're still sending out infected emails but at least they're offering to encrypt them en-route, so lets unblock them".