Have been searching quite a bit on this problem; had no problems when sending the mail by just manual typing the address but every time a user used the global address list mails did not arrive...
Seems there is a problem with some of the properties with the contact that was created in Active Directory when enabling the document library for incoming mail.
Found this article on technet:
If attachments are missing from e-mail messages that are sent to a Windows SharePoint Services 3.0 document library, it might be because you have associated the document library with an e-mail address. When you do this, Directory Management Service may not add the following two attributes:
• internet Encoding = 1310720
• mAPIRecipient = false
You must use Active Directory Service Interfaces (ADSI) to manually add these two missing attributes.
Add attributes by using the ADSI tool
1. Click Start, and then click Run.
2. In the Run dialog box, type Adsiedit.msc, and then click OK.
3. In the ADSI Edit window, expand ADSI Edit, expand Domain [DomainName], expand DC=DomainName, DC=com, and then expand CN=Users.
4. Right-click the user name to which you want to add the missing attributes, and then click Properties.
5. In the Properties dialog box, double-click internet Encoding on the Attribute Editor tab.
6. In the Integer Attribute Editor dialog box, type 1310720 in the Value box, and then click OK.
7. In the Properties dialog box, double-click mAPIRecipient on the Attribute Editor tab.
8. In the Boolean Attribute Editor dialog box, click False, and then click OK twice.
Also remember:
When you send mails to a mail enabled document library remember that your attachments can not have any illegal characters in their name (" # % & * : < > ? \ / { | } ~)! End-users are not always considering these restrictions...
More troubleshooting tips:
In order to verify that messages arrive at your SharePoint servers, stop the Windows SharePoint Services Timer service. Messages will pile up in the Drop folder because it is the Timer service that processes the messages and places file attachments in document libraries associated with the recipient e-mail addresses. If the messages do not arrive in the Drop folder, use the Queue Viewer on your Hub Transport server to see if Exchange routes the messages correctly. Then investigate network communication issues that might prevent the Hub Transport server from communicating with the SMTP service on the SharePoint server.
When you restart the Timer service, you should see the message items disappear from the Drop folder. However, if message attachments do not end up as documents in the destination libraries even though SharePoint indicates successful message processing in the Windows event log, it means that Exchange has sent the messages in Exchange RTF format. To investigate this problem, shut down the Timer service again, send another message with an attachment from your Outlook® client, and then open the message in Notepad after it arrives in the Drop folder. Now search for the string "winmail.dat." If you find it, Exchange Server is sending the messages in the wrong format.
SharePoint requires message attachments to be encoded in MIME or UUENCODE format. Also, SharePoint does not show any winmail.dat-related processing issues in the Windows event log. The file attachments simply won't appear in the document library. Use Notepad as a troubleshooting tool and eliminate the formatting issue by configuring a Remote Domain definition in Exchange Management Console for the SharePoint e-mail domain. On the Format of original message sent, as attachment to journal report tab, under Exchange rich-text format, select Never