Graph API ile E-posta İçeriği Artık O Kadar Esnek Değil: Neler Değişiyor, Kimler Dikkat Etmeli?
E-posta İmmutability’si: Gelen Kutusu Artık ‘Kutsal’ mı?
İnanın, Şimdi şöyle bir şey var… “E-postalar geldikten sonra, uygulamanın içeriği değiştirmesi doğru mu?” sorusuyla ilk kez 2011’de kafa yordum. O zamanlar bir Exchange Migration vardı; ekip compliance diye baş baş bağırıyor, IT denetimci de yanımda ter döküyor. Yıllar geçti – Graph API geldi, REST furyası aldı yürüdü – ama o temel soru hâlâ masada: Kullanıcının inbox’ına düşen mesajı keyfimize göre editlemek ne kadar doğru? Ben hâlâ biraz tedirgin yaklaşıyorum bu işe. Ve Microsoft son hamlesiyle “Bak burada çizgiyi çekiyorum” demeye başladı.
Artık Graph API ile e-postanın kritik alanlarında (konu, içerik, alıcılar) değişiklik yapmak neredeyse yasaklanacak gibi. Hâlâ ufak tefek arka kapılar var; tabiî eskisi kadar rahat değil…
Neden Bu Kadar Önemli? Gerçekten Bir Sorun mu Vardı?
Doğrusu, Bunu geçen sene bizzat yaşadım… 2019’da finans sektöründe bir phishing algılama add-in geliştiriyorduk. Add-in şüpheli mailleri bulunca subject kısmına “[POTANSİYEL TEHLİKE]” etiketi basıyordu. O dönemde tek gereken Mail.ReadWrite izniydi; işimiz gayet kolaydı. Düşünmedim bile bunun ilerde başımı ağrıtacağını… Sonra geçen ay başka bir müşteri için benzer entegrasyonu yapmaya çalışırken patladı durum: Adamların politikası net – gelen mail’in orijinal konusu asla bozulmaz! Baya şaşırdım açıkçası.
Eğer uygulamanız kullanıcının gelen kutusundaki mail içeriğini otomatik değiştiriyorsa – geçmiş olsun! Yeni Graph API update sonrası işler ciddi anlamda zorlaşacak.
Sensitive Properties Ne Demek? Tam Olarak Ne Değişiyor?
Konuya kısa ve öz giriyorum; artık “draft” olmayan e-postalarda, aşağıdaki alanları değiştirmek için ekstra karmaşık izinler gerekecek:
- Konu (subject)
- Mesaj gövdesi (body)
- Alıcılar (to/cc/bcc recipients)
- Daha başka can alıcı property’ler… (tam liste teknik olarak aşağıda)
Şahsen, Bunların dışında kalan küçük özellikleri (okundu/okunmadı flag’i, kategori ekleme vs.) zaten update edebiliyorsunuz, onlar aynı kalıyor.
Sensitive Alanlar Teknik Olarak Hangileri?
| Düzenlenebilir mi? | Taslakta | Taslak Olmayanda (“Inbox” vb.) |
|---|---|---|
| Konu (subject) | Evet (Mail.ReadWrite) |
Sadece advanced izinlerle (Mail-Advanced.ReadWrite) |
| Alıcılar (to/cc/bcc) | Evet | Sadece advanced izinlerle |
| Mesaj Gövdesi (body) | Evet | Sadece advanced izinlerle |
| Okundu bilgisi (isRead) | Evet | Evet – değişmiyor! |
| Kategori/bayrak v.b. | Evet | Evet – değişmiyor! |
Peki Hangi İzinler Gerekiyor? Tek Satırlık Kodla Olacak İş Bitiyor mu?
Açıkça söyleyeyim; sandığınızdan daha karışık hâle geldi olay. Şu üç izinden biri şart: Mart 2026 Azure SDK Güncellemeleri: Sürprizler, Detaylar ve Gerçek Hayat Yansımaları yazımızda bu konuya da değinmiştik.
Mail-Advanced.ReadWrite.AllMail-Advanced.ReadWrite.SharedMail-Advanced.ReadWrite
Bunların ortak noktası şu — her biri. Tenant admin onayıyla alınabiliyor! Normal kullanıcı ya da sıradan application permission yetmez; IT yöneticisinin devreye girmesi mecbur oluyor. Microsoft Entra’da Sonradan Görülen Tutarlılıkla Yaşamak: Hayal Kırıklığı mı, Gerçekçi Bir Mimarı mi? yazımızda bu konuya da değinmiştik. GitHub Copilot’ta Gemini 3 Pro Tarihe Karıştı: Ne Anlama Geliyor, Neler Değişiyor? yazımızda bu konuya da değinmiştik.
// Örnek izin talebi
{
"resourceAppId": "00000003-0000-0000-c000-000000000000",
"resourceAccess": [
{
"id": "...", // Mail-Advanced.ReadWrite GUID
"type": "Role"
}
]
}
Bunu yapmadan sensitive alanları draft dışındaki mesajlarda değiştirmek hayalden öteye geçmiyor.
Zaman Çizelgesi ve Kırılma Noktası — Dönüşüm Zorunlu mu?
Korkmanıza gerek yok — hemen yarın kimse kapınızı çalmayacak! Microsoft diyor ki:
Büyük kısıtlama için son tarih 31 Aralık 2026.
Kulağa uzak geliyor… Ama kurumsal dünyada panik havası çıkması an meselesidir. Mart ayında Logosoft’ta bir holding projesinde dashboard’a custom e-mail update mantığı eklemişlerdi; yeni policy gelince fonksiyon patlayınca arka planda kriz çıktı — bizzat şahit oldum.
Bir uyarı daha ekleyeyim… Eğer müşterilerinizde custom mail edit kullanıyorsanız uygulamanızı acilen kontrol edin.
Kodunuzda eski yetkilerle yapılan PATCH/PUT çağrılarını bulup advanced permission’a geçirin.
Client’larda tenant admin approval hazırlığını planlayın; süreci belgelemekte fayda var.
Kullanıcıya neden hata aldığını iyi anlatın — “Microsoft API değişti abi…” deyip geçmeyin.
Sertifika notlarını güncelleyin! AZ-305/AZ-500 hazırlık dökümanlarının bazılarını baştan yazmak zorunda kaldım…
- Müşteriniz varsa kodunuzu tarayın, yeni yetkilere uyumlu hâle getirin;
- Kullandığınız endpointleri test edin — advanced permission almadan kırılırsa şaşırmayın;
- Tenant admin approval prosedürünü erkenden dökümante edin;
- User-facing hata mesajını açıklamalı yazın (“Yetkiniz yok, IT yöneticisine başvurun!” tarzında);
- Sertifikalarınızı yenileyin ve sınav materyallerini gözden geçirin;
- Özetle elinizi çabuk tutarsanız kriz büyümeden çözülür!
Küçük Startup’tan Enterprise Seviyeye Etkiler — Herkes Aynı Derecede Mi Etkilenecek?
Küçük Takımlar & Startuplar İçin:
Dürüst olacağım şimdi; küçük SaaS ürünlerinin yüzde doksanı. İnbox’taki subject/body’ye dokunmuyordu bile! Ama mailbox otomasyonu yapan ekip varsa — ticketing sistemleri ya da workflow servisleri mesela — bu API güncellemesi sizi fena köşeye sıkıştırabilir. En büyük derdi genelde tenant admin erişimi çıkarıyor… Hele ki çoklu müşteri ile uğraşıyorsanız “her seferinde ayrı onay alma” kâbusu yaşayacaksınız.
Valla hiç abartmıyorum. Bu konuyla ilgili Veritabanına Akıllı Soru Sorabilen AI: Data API Builder MCP ile Güvenli Analiz Dönemi yazımıza da göz atmanızı tavsiye ederim.
Büyük Kurumlar ve Regülasyon Sektöründe:
Banka veya kamu sektörü işe tam tersine “compliance” nedeniyle yeni policy’ye dört elle sarılıyor… Geçen yıl bankada IRM temelli mail güvenlik işi yaptığımızda non-draft body’yi hashleyip dijital imza basmamız istenmişti — şimdi aynısını yapmak istesek en az üç farklı rol/layer admin approval gerekiyor. Proje takvimini iki hafta uzatma riski ortaya çıkıyor! Bu konuyla ilgili ABD Devletine Açılan Sır Kapısı: Azure Top Secret Bulutta Yapay Zekâ ve Verinin Yeni Çağı yazımıza da göz atmanızı tavsiye ederim.
Aşağıdaki tabloda farklı sektörlere göre potansiyel etki seviyesini özetledim:
| Sektör / Senaryo | Etkilenme Derecesi |
|---|---|
| Bilet/Ticketing yazılımları | Çok Yüksek |
| E-posta analiz/güvenlik çözümleri | Bayağı Yüksek |
| Bireysel/Küçük SaaS tool’ları | Düşük-Orta |
| Kamu/Banka Projeleri | Ciddi yüksek & Compliance zorunluluğu var! |
| Ofis eklentileri (signature manager vb.) | Düşük |
| Email forwarder/gateway hizmetleri | Dikkat edilmeli |
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder