encyclo
msg:4168809 | 10:28 pm on Jul 12, 2010 (gmt 0) |
Have you seen this?
AOL SMTP Error Messages [postmaster.aol.com]
Also, do you have reverse DNS set up?
|
phranque
msg:4169035 | 7:15 am on Jul 13, 2010 (gmt 0) |
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
msg:4169048 | 7:40 am on Jul 13, 2010 (gmt 0) |
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
msg:4172587 | 2:52 am on Jul 19, 2010 (gmt 0) |
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
msg:4172591 | 3:02 am on Jul 19, 2010 (gmt 0) |
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
msg:4172594 | 3:14 am on Jul 19, 2010 (gmt 0) |
+1 to incrediBILL's thought, checks 81 blacklists. Visit [mxtoolbox.com ] to verify (click blacklists), checks 105 blacklists.
|
phranque
msg:4172639 | 7:15 am on Jul 19, 2010 (gmt 0) |
listed zero times.
unless it's in one of the lists that times out.
|
incrediBILL
msg:4172641 | 7:27 am on Jul 19, 2010 (gmt 0) |
What's listed zero times?
I didn't see any real mail server addresses in these posts.
|
phranque
msg:4173065 | 10:21 pm on Jul 19, 2010 (gmt 0) |
the IP address is "not listed" on any of the dnsbl lists and "listed zero times" on the mxtoolbox blacklist check.
|
Hoople
msg:4173114 | 12:06 am on Jul 20, 2010 (gmt 0) |
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
msg:4173133 | 1:01 am on Jul 20, 2010 (gmt 0) |
| 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.
|
|
