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 bas bas 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 hala 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. Hala ufak tefek arka kapılar var; tabii 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)
- Alicilar (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.
💡 Bilgi: Sadece “draft” olan maillerde eski izinlerle güncelleme yapılabiliyor. Yani yeni taslak açıp her türlü oynama serbest.
Sensitive Alanlar Teknik Olarak Hangileri?
| Düzenlenebilir mi? | Taslakta | Taslak Olmayanda (“Inbox” vb.) |
|---|---|---|
| Konu (subject) | Evet (Mail.ReadWrite) |
Sadece advanced izinlerle (Mail-Advanced.ReadWrite) |
| Alicilar (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 hale geldi olay. Şu üç izinden biri şart: Mart 2026 Azure SDK Güncellemeleri: Sürprizler,… 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ıkl… yazımızda bu konuya da değinmiştik. GitHub Copilot’ta Gemini 3 Pro Tarihe Karıştı: … 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 hale 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ı. Inbox’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” kabusu yaşayacaksınız.
Valla hiç abartmıyorum. Bu konuyla ilgili api hakkındaki detaylı rehberimiz 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ü ise 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 Secr… 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 |
İçeriği paylaş:
İlgili Yazılar
Microsoft 365 E7: Yapay Zeka ve Güvenlik Bir Arada10 Mar 2026Microsoft Sovereign Cloud: İzolasyonda Güvenli Bulut9 Mar 2026Azure SDK Ekim 2025: Yapay Zekâdan Kimlik Yönetimine Dikkat Çeken Yenilikler18 Mar 2026.NET ve .NET Framework Mart 2026 Güncellemeleri: Gerçekten Güncelleme Yapmalı mıyız?21 Mar 2026
Yorum gönder