یک سری نقاط ضعف در این پروتکل وجود دارد که باعث افزایش پیچیدگی می شود مثلا دسترسی همزمان چند سرویس گیرنده به یک mail box که این کار توسط سرویس دهنده جانبی مانند ( maildir ، database ) صورت می گیرد و باعث رفع و تصحیح ضعف می شود . اما در این حالت لازم است که الگوریتم جستجو و ذخیره یک میل بر روی سرویس دهنده با دقت کافی صورت گیرد که سرویس گیرنده نهائی می تواند تعداد زیادی از منابع را در زمان جستجوی mail box معرفی کند . سرویس گیرنده imap برای دسترسی به محتوی پیام جدید می باید در خواستی را اعلام کنند که این کار باعث افزایش تاخیر در یک ارتباط کند مانند موبایل می شود، که برای رفع آن از طرحی به نام push imap را پیشنهاد شد که این طرح به طور کلی مورد تائید قرار نگرفت . بر خلاف بعضی از پروتکل های اختصاصی که عمل ارسال و بازیابی را به صورت ترکیبی انجام می دادند . ارسال یک پیام و ذخیره ای از کپی آن بر روی پوشه ای در سرویس دهنده های جانبی ( server – side ) باعث می شود که سرویس گیرنده برای انتقال محتوی پیام دو بار درخواست دهد اولی برای smtp ودومی را برای imap جهت ذ خیره و ارسال به پوشه میل است . که این مشکل با یک سری تنظیمات مورد تائید ietf lemonade در مورد قطعات موبایل ( urlauth ( rfc-۴۴۶۷ ) ، catenate ( rfc۴۴۶۹، در ( imap burl ( rfc۴۴۶۸ در smtp-submission رفع شده است . سرویس دهنده های pop۳ پوشه های سرویس دهندهای جانبی را حمایت نمی کنند پس بنابراین این سرویس گیرنده هاحق انتخاب ندارند اما می توانند موارد ارسال شده را بر روی سرویس گیرنده ذخیره کند . خیلی از سرویس گیرنده های imap می توانند پوشه های سرویس گیرنده جانبی را برای ذخیره میل های ارسال شده قالب بندی کنند . در آخر ( lemonade trio ) ماهواره مخابراتی سرویس گیرنده میل که کپی فایل های ارسال شده را در یک پوشه تحت نام out box ذخیره می کند .