Teknik·
26 Mart 2026
E-posta istemcileri sunucudaki mesajlara erişmek için iki farklı protokolden birini kullanır: IMAP (Internet Message Access Protocol) veya POP3 (Post Office Protocol version 3). Hangisini seçtiğiniz; e-postalarınızın nerede saklandığını, birden fazla cihazdan nasıl erişileceğini ve bant genişliği tüketiminizi doğrudan etkiler. Kurumsal e-posta altyapısı tasarlarken ya da bir e-posta pazarlama platformu seçerken bu iki protokolün teknik ayrımlarını anlamak kritik önem taşır.
POP3, 1988 yılında Marshall Rose tarafından kaleme alınan RFC 1081 ile tanımlanmış; günümüzde geçerli olan sürüm ise 1996 tarihli RFC 1939'dur. Protokol son derece sade bir tasarıma sahiptir: sunucuya bağlan, kimlik doğrula, mesajları indir, bağlantıyı kes. Genişletilmiş komut seti RFC 2449 (POP3 Extension Mechanism) ile eklenmiştir.
IMAP ise 1986'da Mark Crispin tarafından Stanford Üniversitesi'nde geliştirilmiştir. Protokolün ilk yaygın sürümü IMAP4rev1, RFC 3501 (2003) ile standart hale gelmiş; 2021 yılında yayımlanan RFC 9051 bu standardı yerini alarak IMAP4rev2 adını almıştır. RFC 9051, TLS zorunluluğunu pekiştirmiş, bazı eski komutları kaldırmış ve OAuth 2.0 kimlik doğrulamasını birinci sınıf vatandaş konumuna taşımıştır.
Her iki protokol de TCP/IP üzerinde çalışır. POP3 varsayılan olarak 110 numaralı portu (TLS ile POP3S için 995), IMAP ise 143 numaralı portu (TLS ile IMAPS için 993) kullanır. STARTTLS mekanizması (RFC 2595) her iki protokol için de açık portlar üzerinde şifreli bağlantı kurulmasına olanak tanır.
İki protokol arasındaki en temel fark, mesajların nerede tutulduğudur.
POP3 modeli: İstemci sunucuya bağlanır, mesajları yerel diske indirir ve varsayılan ayarlarla sunucudaki kopyayı siler. RETR komutuyla mesaj alındıktan sonra DELE komutu işaretlenir ve oturum QUIT komutuyla kapatılırken silme işlemi kalıcı hale gelir. Mesaj sunucuda kalmaz; bu nedenle ikinci bir cihazdan aynı mesaja erişmek mümkün değildir.
IMAP modeli: Mesajlar sunucuda kalır. İstemci yalnızca başlıkları (envelope) indirebilir, gövdeyi isteğe bağlı getirebilir (FETCH BODY[]) ve sunucudaki klasör hiyerarşisini (LIST, LSUB komutları) yönetebilir. Okundu/okunmadı (\Seen), yanıtlandı (\Answered), silindi (\Deleted) gibi bayraklar (flags) sunucuda saklanır; böylece tüm cihazlar aynı durumu görür.
| Özellik | IMAP (RFC 9051) | POP3 (RFC 1939) |
|---|---|---|
| Mesaj saklama konumu | Sunucu | İstemci (yerel disk) |
| Varsayılan port (düz metin) | 143 | 110 |
| TLS portu | 993 (IMAPS) | 995 (POP3S) |
| Çok cihaz senkronizasyonu | Evet, bayraklar sunucuda tutulur | Hayır, mesaj indirildikten sonra silinir |
| Klasör/etiket desteği | Evet (CREATE, RENAME, DELETE) |
Hayır, tek kutu (INBOX) |
| Kısmi mesaj indirme | Evet (FETCH BODY[HEADER]) |
Sınırlı (TOP komutuyla sadece başlık) |
| Sunucu taraflı arama | Evet (SEARCH komutu) |
Hayır |
| IDLE / anlık bildirim | Evet (RFC 2177) | Hayır |
| Sunucu kaynak kullanımı | Yüksek (tüm mesajlar sunucuda) | Düşük (mesajlar istemciye aktarılır) |
| Bant genişliği (tekrar erişim) | Düşük (önbellekli başlıklar) | Yüksek (her cihaz tam mesajı indirir) |
| Kimlik doğrulama seçenekleri | PLAIN, LOGIN, CRAM-MD5, XOAUTH2, SASL | USER/PASS, APOP, AUTH (RFC 2449) |
| Çevrimdışı çalışma | İstemci önbelleğiyle mümkün | Doğal (mesajlar zaten yerelde) |
RFC 2177 ile tanımlanan IMAP IDLE uzantısı, istemcinin sunucuya IDLE komutu göndererek açık bir bağlantı tutmasına ve yeni mesaj geldiğinde sunucunun istemciyi anlık olarak bilgilendirmesine imkân tanır. Bu mekanizma, mobil uygulamaların "push e-posta" deneyimi sunmasının temelini oluşturur. POP3'te benzer bir mekanizma yoktur; istemci periyodik olarak yoklama (polling) yapmak zorundadır, bu da hem gecikmeye hem de gereksiz bant genişliği tüketimine yol açar.
Microsoft Exchange ortamlarında kullanılan MAPI protokolü ve ActiveSync, IMAP IDLE'ın sağladığı anlık bildirim işlevini benzer biçimde sunar. Ancak IMAP, açık standartlar üzerine kurulu olduğundan bağımsız istemci uyumluluğu açısından avantajlıdır.
Her iki protokol de başlangıçta kimlik bilgilerini düz metin olarak iletiyordu. Günümüzde bu kabul edilemez bir güvenlik riskidir. RFC 2595, POP3 ve IMAP için STARTTLS desteğini tanımlar; bu sayede 143 ve 110 numaralı portlar üzerinden şifreli oturum başlatılabilir.
IMAP4rev2 (RFC 9051) ile birlikte LOGINDISABLED yeteneği zorunlu hale getirilmiştir: sunucu TLS aktif değilse LOGIN komutunu reddetmelidir. Bu düzenleme, eski protokol sürümlerinde yaygın olan düz metin parola iletimini standart düzeyde engeller.
Google, Microsoft ve diğer büyük sağlayıcılar artık temel kullanıcı adı/parola kimlik doğrulaması yerine OAuth 2.0 XOAUTH2 (RFC 7628) mekanizmasını zorunlu kılmaktadır. Bu yöntemde erişim belirteçleri (access token) kullanılır; belirteçlerin ömrü kısıtlıdır ve belirli kapsamlar (scope) ile sınırlandırılabilir. POP3 için OAuth 2.0 desteği teknik olarak mümkün olsa da yaygın olarak desteklenmez; çünkü büyük sağlayıcılar POP3 erişimini giderek kısıtlamaktadır.
IMAP ve POP3 doğrudan e-posta gönderme protokolleri değildir; gönderim SMTP (RFC 5321) ile yapılır. Ancak bounce (geri dönen mesaj) işleme ve otomatik yanıt yönetimi için e-posta pazarlama sistemleri bir gelen kutusu hesabına bağlanmak zorundadır.
Bounce işleme akışı tipik olarak şöyle işler:
Return-Path başlığına bir bounce adresi atanır (örneğin bounce+kampanya123@domain.com).Bu süreçte IMAP'ın SEARCH ve FETCH BODY[HEADER] komutları, tüm mesajları indirmeden sadece ilgili mesajları işlemeye imkân tanıdığından POP3'e kıyasla çok daha verimlidir.
Türkiye'de e-posta iletişimi 6563 sayılı Elektronik Ticaretin Düzenlenmesi Hakkında Kanun (ETK) ve 6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK) kapsamında değerlendirilir. Her iki kanun da doğrudan protokol seçimini belirtmez; ancak veri güvenliği yükümlülükleri protokol yapılandırmasını etkiler.
KVKK'nın 12. maddesi, veri sorumlularının kişisel verilerin yetkisiz erişime karşı korunması için uygun teknik tedbirleri almasını zorunlu kılar. Bu kapsamda:
önlemler arasında sayılabilir. BTK'nın Elektronik Haberleşme Kanunu kapsamındaki ikincil düzenlemeleri ve Ticari Elektronik İleti Yönetim Sistemi (İYS) kuralları ise e-posta pazarlama gönderimlerinde onay yönetimini kapsar; bu onayların güvenli biçimde saklanması ve iletilmesi de IMAP altyapısındaki güvenlik yapılandırmasını ilgilendirir.
IMAP'ta mesajlar sunucuda saklanır ve tüm cihazlar aynı durumu (okundu/okunmadı, klasör yapısı) görür. POP3'te mesajlar istemciye indirilir; varsayılan ayarla sunucudaki kopya silinir. Bu nedenle IMAP çok cihazlı kullanım için tasarlanmışken POP3 tek cihaz senaryolarına uygundur.
IMAP düz metin için port 143, TLS (IMAPS) için port 993 kullanır. POP3 düz metin için port 110, TLS (POP3S) için port 995 kullanır. Ayrıca her iki protokol de RFC 2595 kapsamında STARTTLS mekanizmasıyla açık portlar üzerinde şifreli bağlantı başlatabilir.
RFC 2177 ile tanımlanan IMAP IDLE, istemcinin sunucuyla açık bir TCP bağlantısı tutmasına ve yeni mesaj geldiğinde anlık bildirim almasına olanak tanır. Mobil uygulamalardaki "gerçek zamanlı" e-posta bildirimleri bu mekanizmaya dayanır. POP3'te böyle bir özellik yoktur.
Hayır, zorunlu değildir. RFC 1939, mesajların DELE komutuyla işaretlenmediği sürece silinmeyeceğini belirtir. Birçok e-posta istemcisinde "sunucuda bir kopyasını bırak" seçeneği mevcuttur; ancak bu durumda çoklu istemciler aynı mesajı defalarca indirebilir ve senkronizasyon sorunları ortaya çıkabilir.
RFC 9051 (IMAP4rev2, 2021), RFC 3501'in (IMAP4rev1, 2003) yerini almıştır. Başlıca değişiklikler şunlardır: TLS zorunluluğunun pekiştirilmesi, IMAP4rev2 yeteneğinin eklenmesi, UTF-8 başlık desteği (RFC 6532 entegrasyonu), AUTHENTICATE komutunun ön plana çıkarılması ve bazı eski uzantıların çekirdek protokole dahil edilmesidir.
Exchange/ActiveSync ve MAPI, Microsoft ekosistemi içinde daha zengin özellikler (takvim, görev, kişi senkronizasyonu) sunar. Ancak IMAP açık standart olduğundan herhangi bir istemci ya da programlama dili ile entegre edilebilir. Bağımsız, çoklu sağlayıcı altyapılarında ve e-posta pazarlama sistemlerinin gelen kutusu entegrasyonlarında IMAP tercih edilir.
Bounce (geri dönen mesaj) işleme için e-posta pazarlama sistemleri, özel bir posta kutusuna IMAP ile bağlanır. SEARCH komutuyla belirli kriterlere uyan mesajları seçer, FETCH BODY[HEADER] ile başlıkları analiz eder ve hard bounce olan adresleri listeden kaldırır. Bu süreç POP3 ile de yapılabilir ancak IMAP'ın sunucu taraflı arama ve kısmi indirme özellikleri çok daha verimlidir.
Doğrudan protokol seçimini dikte eden bir KVKK maddesi yoktur; ancak 6698 sayılı KVKK'nın 12. maddesi kapsamında veri güvenliği tedbirleri alınması zorunludur. Bu, TLS şifreli bağlantı kullanımını, güçlü kimlik doğrulamayı ve yerel depolarda şifrelemeyi kapsar. POP3 ile indirilen mesajlar cihaz diskinde düz metin saklanıyorsa bu durum veri ihlali riski doğurabilir.
RFC 7628 (SASL OAuth 2.0 Framework) kapsamında XOAUTH2 mekanizması, geçerli bir erişim belirtecinin IMAP/POP3 kimlik doğrulama adımında kullanılmasına olanak tanır. Google ve Microsoft artık temel parola kimlik doğrulamasını desteklememektedir; entegrasyon yapan sistemlerin OAuth 2.0 akışını uygulaması zorunludur.
RFC 9051, aynı posta kutusuna birden fazla eşzamanlı IMAP oturumu açılmasına izin verir. Sunucular genellikle hesap başına bağlantı sayısını sınırlandırır (Gmail için hesap başına 15 eşzamanlı IMAP bağlantısı). Yüksek hacimli e-posta pazarlama sistemlerinde bu sınır göz önünde bulundurulmalı, bağlantı havuzu (connection pooling) uygulanmalıdır.
Reklamsız, KVKK uyumlu; kurulum ve geçiş ücretsiz, mailleri biz taşırız.