I am working on mail-enabled folders on our SharePoint sites with SMTP addresses of the form id@host.domain.eduand with an SMTP server running on the SharePoint server to allow incoming emails to go to the folder associated with the email address. According to one article,http://social.technet.microsoft.com/Forums/en-US/exchangesvrgeneral/thread/c4cf3b74-62a4-4228-abd4-5b2b28d69509/all contacts should have themAPIRecipient attribute set to FALSE. There are3 observations:1. External email address contacts created with either E2K3 or E2K7 do not have themAPIRecipient attribute set2. Contacts that go to our SharePoint server (address format is ID@host.domain)and created with E2K3 have themAPIRecipient attribute set to FALSE and send correctly3.Contacts that go to our SharePoint server (address format is ID@host.domain)and created with E2K7 have themAPIRecipient attribute not set and bouncewith the sameerror codeas the regular external contacts did without the legacyExchangeDN.Differences between the contacts include:E2K3E2K7not setcountryCode=0mAPIRecipient=FALSEnot setmsExchALObjectVersion=21not setnot setmsExchRecipientDisplayType=6not setmsExchVersion=4535486012416So the questions would be:Should themAPIRecipient attribute be set to FALSE on all contacts (I believe that since this stops email from being sent in Rich Text, the answer would be yes)?What controls that setting to force that on all contacts created?Do any of the other attribute differences rather than themAPIRecipient create the bounces that I am seeing with E2K7 created contacts that go to SharePoint? SnoBoy

Hi,For Exchange 2003,it should be set to false. But for Exchange 2007,it will show as Not Set. mAPIRecipient might affect the message format when communicating with other mail system, if it is set to true, it will use Rich Text for the mail format. ms-Exch-MAPI-Recipient Attribute http://msdn.microsoft.com/en-us/library/ms981781(EXCHG.65).aspx Regards,Xiu

Ok, so back to the bottom line question: Do any of the other attribute differences rather than themAPIRecipient create the bounces that I am seeing with E2K7 created contacts that go to SharePoint?Or is there something else not related to the LDAP attributes that is causing SharePoint mail-enabled folder type contacts created in E2K7 to bounce, while those created in E2K3 to work correctly?NDR from E2K7 created address (obfuscated addresses in italics): Diagnostic information for administrators: Generating server: FQDN_domain testdoc@sharepoint_server.edu #550 5.1.4 RESOLVER.ADR.Ambiguous; ambiguous address ## <-- this is puzzling - works fine when created with E2K3 Original message headers: Received: from email2.domain.edu ([165.91.144.143]) by teesmail2 ([165.91.144.149]) with mapi; Wed, 21 Jan 2009 08:23:11 -0600 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: binary From: Bill Hobson <my email address> To: "'testdoc@moss.domain.edu'" <email address on MOSS2007> Date: Wed, 21 Jan 2009 08:23:09 -0600 Subject: Test Thread-Topic: Test Thread-Index: Acl708j3YxdznQUsSNG89TsV2mQB3Q== Message-ID: <D1F27CE6E55190438E944C4AAE2AC01501A70C6F37@email2> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: <D1F27CE6E55190438E944C4AAE2AC01501A70C6F37@email2> MIME-Version: 1.0 SnoBoy

Here is an interesting test result. After creating the contact in E2K7, I modified the mAPIRecipient from not set to FALSE, and guess what - it worked!So why do I get the NDR with it not set (see previous post - 5.1.4 error "ambiguous address") and it works correctly when that attribute is set to FALSE? SnoBoy

The real problem here is that Exchange 2007 makes the asumption that if the value is "Not Set" then it assume it must be True. Whether this is right or wrong is open to debate,but given that itdiffers from the previous version is of concern and cause a lot of problems for those who have created mail enabled users or contacts.At this stage there are two ways of working around this issue:1. Set each mail-enabled user or contact to false2. Set the Global setting to false. Organizational Configuration -> Hub Transport -> Remote DomainsRegardless I think MS needs to give this more thought given the fact that I create all my mail-enabled users and contacts through Powershell and yet the problem exists is of some concern.