Microsoft Exchange mail delivery problems to AOL

[phranque]

i'm trying to help someone who just changed IT service providers and is now using their own Microsoft Exchange mailserver, whereas previously i believe they were going through the IT company's server.

they are now having issues sending email to AOL.
i am typically seeing either of the following messages reported by MS Exchange:

Delivery is delayed to these recipients or distribution lists:

Firstname Lastname

Subject: test

This message has not yet been delivered. Microsoft Exchange will continue to try delivering the message on your behalf.

Delivery of this message will be attempted until [date-and-time]. Microsoft Exchange will notify you if the message can't be delivered by that time.
Sent by Microsoft Exchange Server 2007
Reporting-MTA: dns; XXSRVR.xx.local Final-recipient: RFC822; [e-mail] Action: delayed Status: 5.4.0 X-Supplementary-Info: < #4.4.7 smtp;400 4.4.7 Message delayed> X-Display-Name: Firstname Lastname

or

Delivery has failed to these recipients or distribution lists:

Firstname Lastname
Microsoft Exchange has been trying to deliver this message without success and has stopped trying. Please try sending this message again, or provide the following diagnostic text to your system administrator.

_____
Sent by Microsoft Exchange Server 2007






Diagnostic information for administrators:

Generating server: XXSRVR.xx.local

[e-mail]
#550 4.4.7 QUEUE.Expired; message expired ##

Original message headers:
...

the email headers that i receive from this server typically include records that look like:
[some records from my end followed by]
Received: from XXSRVR.xx.local (remote.example.com [nnn.nnn.nnn.nnn])by spool.mail.myprovider.net (Postfix) with ESMTP id XXNXNNNXNXNfor <[e-mail]>; [date-and-time]
Received: from XXSRVR.xx.local ([fe80::nnnx:nxxn:nxxn:nnnn]) by XXSRVR.xx.local ([fe80::nxxn:nxxx:nxn:nxnx%10]) with mapi; [date-and-time]

where:
- nnn.nnn.nnn.nnn is the the IP address of the Exchange mail server
- XXNXNNNXNXN is a 9-digit hex id
- nnnx:nxxn:nxxn:nnnn & nxxn:nxxx:nxn:nxnx are both sets of 3- or 4-digit hex addresses separated by colons. (are these IPV6 addresses?)

so it appears the first jump is the server called XXSRVR.xx.local which appears to be the Exchange server.

they also send mail from the example.com web server.

currently the DNS zone file records include:
- a MX record:
Name:example.com Data:10 remote.example.com.
- an A record:
Name:mail Data:[the IP address of the Exchange mail server]
- an A record:
Name:remote Data:[the same IP address of the Exchange mail server]

in an attempt to solve the problem i added a SPF (actually a TXT) record and the most recent attempt looks like this:
Name:example.com Data:"v=spf1 a mx mx:mail.example.com ptr:example.com ~all"

this doesn't appear to have solved the problem.
any idea what i am missing?

[encyclo]

Have you seen this?

AOL SMTP Error Messages [postmaster.aol.com]

Also, do you have reverse DNS set up?

[phranque]

yes i've been to that page.
i'm not sure how to set up a PTR record in the zone file as that is not an option in this particular control panel.
it's not one of the standard control panels.
give me vi and i would be good to go.
i haven't found a workaround for this.
can this be done with a TXT record?

the reverse DNS test provided by AOL and linked from your resource works - if i enter the IP address for the Exchange server it returns remote.example.com.
but my question is this:
is AOL looking for the IPV4 address of remote.example.com or is it looking for the IPV6 address of XXSRVR.xx.local?
and if the latter, how would that .local domain name resolve in the global scheme of things.
is this a mail server configuration issue?

[lammert]

AOL will be primarily looking at the last email server which processed the message before it was delivered to AOL, which is the IPv4 address. But some anti-spam algorithms--but I don't know AOL is using such an algorithm--also check the addresses if intermediate servers to see if an open relay or other abusable server was used in the transit of that particular message.

Such an open-relay check may choke on an IPv6 address if the routine wasn't written with IPv6 in mind.

[Hoople]

There WAS a 'pre SP3' Microsoft Exchange 2007 specific hotfix to address this. What mostly triggers this is calendar meeting invites. Seems to have gone missing.

Primary alternative is to install Exchange 2007 Service Pack 3 (recently released).

Another option, for the brave is to edit the configuration files to effect a change to how retry behaves. Generally a manual configuration edit may have negative performance implications post SPx where x is an number one greater that the first service pack effecting the fix. Second hit (TechNet) for 'exchange 2007 glitch retry interval'

I've been an Exchange guys since 5.5, the SP is the safest choice (most regression testing).

[edited by: Hoople at 3:11 am (utc) on Jul 19, 2010]

[incrediBILL]

Before wasting too much time, check to see if the new IP of your email server is in a DNSBL (blacklist) [dnsbl.info] which AOL may be using to block spam.

[Hoople]

+1 to incrediBILL's thought, checks 81 blacklists. Visit [mxtoolbox.com ] to verify (click blacklists), checks 105 blacklists.

[phranque]

listed zero times.
unless it's in one of the lists that times out.

[incrediBILL]

listed zero times.

What's listed zero times?

I didn't see any real mail server addresses in these posts.

[phranque]

the IP address is "not listed" on any of the dnsbl lists and "listed zero times" on the mxtoolbox blacklist check.

[Hoople]

OK, your testing has proved your sending IP reputation is clean. Have you verified the IP you tested is the one outside domains see? Some firewalls NAT the DMZ IP that Exchange may be on, even if a public range! Said differently: sending IP = A record of highest priority MX record?

The next steps are to determine which part of the normal mailflow is triggering the error.

From the default console of the mail server establish a telnet session to the remote host and send a test message to a cooperative human at the affected domain. In the data segment you may have to add a date: as a few hosts may require it (some require more client added fields). See [support.microsoft.com ] Many times verbose errors seen here (in a telnet session) are summarized or otherwise morphed when returned via an email server to the sender. DNS configuration problems may be stated more verbosely here too. You might get lucky and get a policy URL giving you steps to unblock! If OK, move to next paragraph.

On a client PC within Outlook set the default message format to HTML. Create a test message to the domain. NO ATTACHMENTS! Does it go through? Some domains block HTML and want only plain text. If NOT OK, move to next paragraph.

If they reject the HTML message do the following. Add a Personal Address Book to Outlook and create and entry for the domain. In the test PAB entry Locate and check the option to send in plain text only. Restart Outlook and send a test message to the domain: open a blank message. Click the To: button and in the pulldown select the Personal Address Book. Click that domain's test PAB entry to add it to the message. DO NOT just retype the SMTP address in the To: box as Outlook will send the default (HTML) then.

If the message goes through you will have to either pursue getting whitelisted for HTML or include links to an external filesharing service. Some domains reject HTML messages created by application because they have no plain text part included (they insist on BOTH being present).

BTW if someone onsite at this customer suggests using a Outlook/AD Contact instead tell them that a contact has no plain text only option.

[incrediBILL]

the IP address is "not listed" on any of the dnsbl lists

haha - jokes on me - I forgot you were the OP!

I was scratching my head wondering how you knew this... then I scrolled up :)

Have you went to AOL's Postmaster page [postmaster.aol.com] and checked out everything there?

The troubleshooting page is quite extensive and informative.

I'd start there.