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:
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.
// Ö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.
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!
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 |
Lafı dolandırmaya gerek yok; inbox’ın içeriğinin “dokunulmazlığı” kullanıcıya ciddi güven kazandırıyor bence.
Hele phishing vakalarının arttığı şu dönemde kimsenin mailinin gizlice manipüle edilmemesi birçok kurum açısından güzel gelişme diyebilirim.
Ama öbür tarafta can sıkan detaylar da çıktı – bugüne kadar yaygın kullanılan workflow’lardaki pratiklik ya ortadan kalkacak ya da ciddi zahmete dönüşecek.
Benim kişisel hayal kırıklığım işe şu öldü… Otomatik e-posta etiketleme sistemlerinde eski hız/pratiklik kayboldu – advanced permission almak bazı projelerde aylar sürüyor resmen!
Fena sayılmaz ama hâlâ yolun başında diyebilirim; özellikle tenant-admin onaylarının operasyon yükünü azaltacak ekstra geliştirme lazım.
Mantıklı Yol Haritası ve Pratik Tavsiyeler (Benden Deneme-Yanılma Notları)
- Panik yapmayın — kod dönüşümünü parça parça ve böl test ile ilerletin;
- User-facing hata mesajlarını net yazın (“Yetkiniz yok – lütfen IT yöneticisine danışın!” gibi); kafalar karışmasın;
- Mümkünse alternatif model olarak draft üzerinden klonlama metodunu deneyin;(Eski mail’i draft’a çekip orada güncelleyip tekrar göndermek bazen hayat kurtarabiliyor!)
- Dökümantasyonu müşteriye uygun dille hazırlayın — jargon kasmayın;
- Pilot projede proof-of-concept aşamasında mutlaka advanced permission sürecini test edip early-warning sistemi kurmayı ihmal etmeyin;
- Tarihlerin son dakika değişebileceğini unutmayın — breaking change olduğunda genelde gece-gündüz debug yapmak zorunda kalıyoruz!
- Müşteri education oturumları planlayın — Kasım’da iki şirkette şahsen denedim, insanlar sebep-sonuç ilişkisini öğrenince stres azaldı.
- Anlık sorunlara hızlı yanıt verecek mini FAQ rehberi hazırlayın…
- Büyük servis kırılım senaryolarıyla ilgili tecrübemi daha önce de paylaşmıştım; Mart 2026 Azure SDK Güncellemeleri yazısına bakabilirsiniz → buradan benzer panikleri önlemek mümkün!
- Aynı şekilde consistency/policy tabanlı konuları merak edenler için şuraya da link bırakıyorum:
Microsoft Entra’da Sonradan Görülen Tutarlılıkla Yaşamak yazımı okumanız tavsiye ederim →!Hazırlıklı olun!
Neyse… konuyu toparladım.
Sıkça Sorulan Sorular
Graph API’de e-posta subject/body’sını neden değiştiremiyorum?
Kritik mail içerikleri için Microsoft artık inbox’taki mesajlarda bazı property’lerin modifiye edilmesini yalnızca gelişmiş izinle mümkün kılıyor. Standart Mail.ReadWrite yeterli olmuyor artık — politika böyle öldü.
Taslak mesajlarda hâlâ istediğim alanları düzenleyebilir mıyım?
Evet, draft durumundaki mesajlarda eski Mail.ReadWrite izniyle her şeyi değiştirebilirsiniz. Kısıtlama sadece gönderilmiş veya alınmış maillerde devreye giriyor.
Zaten gelişmiş izin kullanan uygulamalar etkilenir mi?
Eğer uygulamanızda halihazırda Mail-Advanced.* role varsa hiçbir sorun yaşamazsınız. Fakat bu iznin tenant admin tarafından verilmesi gerektiğini akılda tutmak lazım!
Peki migration veya backup sırasında eski mailleri topluca güncellemek istersem ne yapmalıyım?
Anlık migration/backup işlerinde postaların çoğu taslak değilse ekstra advanced role almak mecburi oluyor. Sadece kopyalama yapıyorsanız problem çıkmaz ama içerik update gerekiyorsa mutlaka yeni yetkiye ihtiyaç olacak.
Kaynaklar ve İleri Okuma/hata çıktısı:) Tekrar başa döndüm ama link listesine devam ediyorum…
- Orijinal Duyuru Blog Yazısı (Microsoft )
- Update Message Dokümantasyonu (MS Graph)
- Graph API Permission Referansı – Mail Advanced Yetkileri Tablosu
- Mart 2026 Azure SDK Güncellemeleri Yazım (Benzer Servis Kırılım Senaryosu!)
- Consistency & Policy Tabanlı Değişimler Üzerine Kişisel Gözlem Yazım
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.
