e-posta trendleri

e-posta trendleri


Bu alandaki konular:

E-posta kimlik doğrulama yönergeleri

E-posta kimlik doğrulaması için SPF, DKIM ve DMARC protokollerinin yapılandırılmasına ilişkin yönergeler

BCC e-postalarına iyi bir alternatif

Postacı 'tek yönlü' listesi, haber bültenleri veya duyurular için özel bir yapılandırma

SMTP sunucuları için ters proxy

SMTP sunucunuzun güvenliğini, performansını ve ölçeklenebilirliğini nasıl iyileştirebilirsiniz?

E-posta adresleri nasıl çıkarılır?

İstediğiniz veriyi regex kullanarak elde edebilirsiniz

''NO-MAIL'' alan adlarını nasıl koruyabilirsiniz?

E-posta göndermeyen alan adlarını kötüye kullanımdan korumanın kolay bir yolu

İşletmeler neden SMS kullanıyor?

İşletmeler neden SMS mesajları kullanıyor?

Geri dönen e-postalarla nasıl başa çıkılır?

Zarar görmemek için geri dönen e-postalarla nasıl başa çıkılır?

SMTP'min güvenli olup olmadığını nasıl kontrol edebilirim?

SMTP sunucumun güvenli olup olmadığını nasıl kontrol edebilirim?

E-posta göndermek için DNS ayarları

E-posta göndermek için hangi alan adı DNS ayarları gereklidir?

E-posta listeleri nasıl yönetilir?

Posta listelerini öngörüyle nasıl yönetirsiniz?

Haber bültenleri nasıl gönderilir?

Liste düzenini koruyarak ve alıcıların ilgisini canlı tutarak nasıl haber bültenleri gönderilir?

Özel e-postalar nasıl gönderilir?

Gizli ve şifreli e-postalar nasıl gönderilir?

Gizli alıcı (BCC) e-postaları nasıl gönderilir ve sınırlandırılır?

Gizli alıcı (Bcc) e-postaları nasıl gönderilir ve sınırlandırılır: avantajları, dezavantajları ve sonuçları

E-POSTA PAZARLAMASINI ölçmek

E-posta pazarlama kampanyalarınızın performansını nasıl ölçersiniz?

SPAM olarak kabul edilen şey nedir?

Kullanıcılar ve posta sunucuları tarafından spam e-posta olarak nitelendirilen e-postalar nelerdir?

açık kaynak kodlu e-posta istemcileri

Hazır kullanıma uygun açık kaynaklı e-posta istemcileri kullanarak e-posta kontrolünü nasıl geri kazanabilirsiniz?

İş E-postası ve Gizlilik

Çalışan e-postaları: Okunabilirler mi? Yedeklenebilirler mi? Arşivlenebilirler mi?

E-postaları SPAM'den koruyun

İş e-postalarını istenmeyen e-postalardan nasıl koruyabilirsiniz?

DMARC nasıl çalışır - güncellendi

DMARC'ın Google Mail ve Office 365 ile nasıl çalıştığı - güncellendi

DMARC için DKIM alanı

DKIM etki alanı hizalamasının DMARC kimlik doğrulamasını nasıl etkilediği

en popüler E-POSTA SAĞLAYICILARI

2020 yılında en popüler e-posta sağlayıcıları hangileridir?

DMARC nasıl çalışır?

DMARC'ın Google Mail ve Office 365 ile nasıl çalıştığı

E-posta trendlerinin alt bölümleri

E-posta kimlik doğrulama yönergeleri

ACN (Ulusal Siber Güvenlik Ajansı) logosu

!! DİKKAT !! Bu belge İtalyancadan otomatik olarak çevrilmiştir

Yönergeler

Kimlik doğrulama için e-posta hizmetinin yapılandırılması

İtalyan Ulusal Siber Güvenlik Ajansı , ilgili tüm kuruluşlar için e-posta hizmetinin güvenilirliğini güçlendirmek ve genel güvenlik düzeyini artırmak amacıyla, kimlik doğrulama için e-posta hizmetinin yapılandırılmasına ilişkin kılavuzu yayınladı

Sürüm Kontrolü

VERSİYON YAYIN TARİHİ NOTLAR
1.0 Nisan 2026 İlk yayın.

DİZİN

1. Giriş 1
1.1. Önerme 1
1.2. Referans Yönetmelikleri 1
1.3. Referans Belgeleri 2
2. Düzenleyici Bağlam 3
3. E-posta Hizmeti Mimarisi 4
4. Tehditler 5
4.1. Gönderici Sahtekarlığı 5
4.2. Kimlik Avı 6
4.3. Mesajda Değişiklik Yapılması 6
5. Karşı Önlemler 8
5.1. Güneş Koruma Faktörü (SPF) 8
   5.1.1. SPF Kaydı 9
   5.1.2. Kimlik Doğrulama Süreci 11
5.2. DKIM 11
   5.2.1. DKIM İmzası 12
   5.2.2. DKIM Kaydı 13
   5.2.3. Kimlik Doğrulama Süreci 13
   5.2.4. Kriptografik Yönler 14
5.3. DMARC 14
   5.3.1. DMARC Kaydı 16
   5.3.2. DMARC Politikaları 16
   5.3.3. Politika Doğrulama ve Uygulama Süreci 17
6. Sonuçlar 18
Ek A: Güvenlik Önlemleri 20
Kaynakça 22

1. Giriş

1.1. Önerme

E-posta, günümüzde dijital bağlamda en kritik hizmetlerden birini temsil etmektedir; zira kuruluşlar ve kullanıcılar tarafından iletişim ve bilgi alışverişi için kullanılan başlıca kanallar arasındadır1.

E-posta hizmetinin işleyişi ve özellikle mesaj iletimi, gönderici kimlik doğrulaması ve mesajların gizliliğinin ve bütünlüğünün korunması için yeterli mekanizmaları doğal olarak içermeyen SMTP protokolüne dayanmaktadır. Bu güvenlik açıkları, onu kimlik avı, kurcalama ve iletim sırasında mesaj ele geçirme gibi saldırı risklerine maruz bırakmaktadır.

SMTP protokolünün zayıf yönlerini gidermek ve dolayısıyla yukarıda bahsedilen saldırılardan kaynaklanan riski azaltmak için zaman içinde SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) ve DMARC (Domain-based Message Authentication, Reporting and Conformance) gibi gönderici kimlik doğrulama ve mesaj bütünlüğünün korunmasına yönelik mekanizmalar geliştirilmiştir.

Bu yönergeler, özellikle 4. bölümde açıklanan tehditlere atıfta bulunarak, e-posta hizmetinin güvenilirliğini güçlendirmek ve genel güvenlik düzeyini artırmak amacıyla bu mekanizmaları açıklamaktadır.

E-posta mesajlarının gizliliğini korumak için gerekli olan önlemler ve protokoller (mesaj şifrelemesiyle ilgili S/MIME ve OpenPGP gibi) bu kılavuzların konusu değildir.

1.2. Referans Yönetmelikleri

DÜZENLEME TANIM
Ulusal Siber Güvenlik Çevresi (PSNC) 21 Eylül 2019 tarihli ve 105 sayılı Kanun Hükmünde Kararname. Ulusal siber güvenlik çemberi ve stratejik öneme sahip sektörlerdeki özel yetkilerin disiplini ile ilgili acil hükümler.
Kamu Yönetimi için Bulut Düzenlemesi ACN Yönetim Kurulu Kararı no. 21007/24, 27 Haziran 2024.
4 Eylül 2024 tarihli ve 138 sayılı Kanun Hükmünde Kararname 4 Eylül 2024 tarihli ve 138 sayılı Kanun Hükmünde Kararname. (AB) 2022/2555 sayılı Direktifin, Birlik genelinde yüksek ortak siber güvenlik düzeyi için tedbirlere ilişkin olarak, (AB) 910/2014 sayılı Yönetmeliği ve (AB) 2018/1972 sayılı Direktifi değiştiren ve (AB) 2016/1148 sayılı Direktifi yürürlükten kaldıran hükmünün aktarılması.

1.3. Referans Belgeleri

BAŞLIK VE YAYIN ADRESİ
NIST Teknik Notu 1945.
https://nvlpubs.nist.gov/nistpubs/TechnicalNotes/NIST.TN.1945.pdf
NIST SP 800-177 R1
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-177r1.pdf
ACN. E-posta Kimlik Doğrulama Çerçevesi.
https://www.acn.gov.it/portale/w/framework-di-autenticazione-per-la-posta-elettronica
RFC 5321 – Basit Posta Aktarım Protokolü
https://datatracker.ietf.org/doc/html/rfc5321
RFC 5322 – İnternet Mesaj Formatı
https://datatracker.ietf.org/doc/html/rfc5322
RFC 7208 – E-postada Alan Adlarının Kullanımını Yetkilendirmek için Gönderen Politikası Çerçevesi (SPF), Sürüm 1
https://datatracker.ietf.org/doc/html/rfc7208
RFC 6376 – Alan Adı Anahtarlarıyla Tanımlanmış E-posta (DKIM) İmzaları
https://datatracker.ietf.org/doc/html/rfc6376
RFC 7489 – Alan Adına Dayalı Mesaj Kimlik Doğrulama, Raporlama ve Uyumluluk (DMARC)
https://datatracker.ietf.org/doc/html/rfc7489

» başa dön

2. Düzenleyici Bağlam

Ülkenin dijital varlıklarını, e-posta hizmetlerini ve bunları barındıran altyapıları korumak için, mevcut mevzuattan türetilen ve sürekli olarak güncellenen geniş bir güvenlik önlemleri paketi uygulanmaktadır.

Ulusal güvenliğin korunmasıyla bağlantılı, ülkenin en kritik hizmetleri için en üst düzeyde koruma, 21 Eylül 2019 tarihli ve 105 sayılı Kanun Hükmünde Kararname ile kurulan ve 18 Kasım 2019 tarihli ve 133 sayılı Kanun ile değişikliklerle güncellenen Ulusal Siber Güvenlik Çevresi ile sağlanmaktadır. Bu, 14 Nisan 2021 tarihli ve 81 sayılı Başbakanlık Kararnamesinin B Ekinde ayrıntılı olarak belirtilen, özellikle yüksek düzeyde koruma sağlayan güvenlik önlemlerini içermektedir. Bu önlemler, devletin temel bir işlevinin yerine getirilmesi veya devletin çıkarları için temel olan sivil, sosyal veya ekonomik faaliyetlerin sürdürülmesi için gerekli bir hizmetin sağlanmasının bağlı olduğu kamu ve özel kuruluşların ağlarına, bilgi sistemlerine ve BT hizmetlerine uygulanır ve bunların tehlikeye atılması ulusal güvenliğe zarar verebilir.

Ayrıca, kamu yönetiminin tüm dijital hizmetleri gibi e-posta hizmetleri de, 18 Ekim 2012 tarihli ve 179 sayılı Kanun Hükmünde Kararnamenin 33-septies maddesi uyarınca kabul edilen ve Ulusal Siber Güvenlik Ajansı (ACN) tarafından 27 Haziran 2024 tarihli ve 21007 sayılı Direktörlük Kararnamesi ile güncellenen Bulut Yönetmeliği hükümlerine tabidir. Söz konusu Yönetmeliğe göre, tüm kamu idareleri, ACN tarafından hazırlanan modele göre dijital verilerini ve hizmetlerini sıradan, kritik veya stratejik olarak sınıflandırmakla yükümlüdür. Bu faaliyet, kamu yönetiminin dijital verilerinin ve hizmetlerinin, Yönetmelikte ayrıntılı olarak belirtilen ilgili sınıflandırma düzeyine uygun risklere yönelik güvenlik gereksinimleri de dahil olmak üzere, gereksinimleri karşılayan dijital altyapılar ve bulut hizmetleri aracılığıyla işlenmesini ve sunulmasını sağlamayı amaçlamaktadır.

4 Eylül 2024 tarihli ve 138 sayılı Kanun Hükmünde Kararname (bundan böyle NIS kararnamesi olarak anılacaktır), (AB) 2022/2555 sayılı Direktifi ulusal mevzuata aktarırken, ACN kararı 379907/2025'in Ek 1 ve 2'si aracılığıyla, NIS kararnamesinin 23 ve 24. maddeleri kapsamındaki yükümlülükler için temel ve önemli kuruluşların benimsemesi gereken temel güvenlik önlemlerini de belirlemiş ve e-posta hizmetleri de dahil olmak üzere ağ ve bilgi sistemlerinin korunmasını güçlendirmek için bir güvenlik çerçevesi tanımlamıştır.

» başa dön

3. E-posta Hizmeti Mimarisi

Giriş bölümünde belirtildiği gibi, e-posta hizmetinin işleyişi, göndericiden alıcıya e-posta mesajlarının iletimini düzenleyen SMTP protokolüne dayanmaktadır.

SMTP protokolü, başlangıçta 1982 yılında [1] bir depolama ve iletme protokolü olarak tanımlanmıştır ; bu protokolde gönderici, posta istemcisi (jargon adıyla Posta Kullanıcı Aracısı - MUA) aracılığıyla bir mesaj oluşturur ve bu mesajı göndericinin posta sunucusuna gönderir. Bu sunucu, Posta Aktarım Aracısı (MTA) adı verilen bir bileşen aracılığıyla mesajı, muhtemelen bir veya daha fazla ara MTA üzerinden de geçirerek, hedef posta sunucusunun MTA'sına iletir. Alıcı kullanıcı, mesajı posta istemcisi (MUA) [1] aracılığıyla erişir .

Dolayısıyla MTA, e-posta mesajlarının göndericiden alıcıya iletilmesini sağlayan e-posta hizmetinin bir bileşenidir. MTA bileşenleri gönderici ve alıcının posta sunucularında bulunur ve örneğin dağıtım listelerini yönetmek için ara MTA'lar da yapılandırılabilir.

E-posta hizmetinin üst düzey mimarisini gösteren diyagram

Şekil 1. E-posta hizmetinin üst düzey mimarisi.
Şekil, bu kılavuzlar için ilgi çekici olan bileşenleri göstermektedir.

MTA terimi e-posta sunucularının belirli bir bileşenini tanımlasa da³,bu belgenin amacı doğrultusunda e-posta sunucularına esas olarak MTA işlevleri bağlamında atıfta bulunulduğu için, herhangi bir belirsizlik olmadığı durumlarda, açıklama kolaylığı açısından daha spesifik olan MTA yerine genellikle e-posta sunucusu terimi kullanılacaktır.

Bu kılavuzda, posta sunucularının e-posta mesajlarının orijinalliğini ve bütünlüğünü doğrulamasına olanak tanıyan SPF, DKIM ve DMARC protokollerinin yapılandırmasına odaklanacağız.

» başa dön

4. Tehditler

Önceki bölümde tanıtılan SMTP protokolü, başlangıçta nispeten küçük bir akademik ağda çalışmak üzere tasarlanmıştı ve iletilen mesajların güvenliği veya gönderici kimlik doğrulamasıyla ilgili hususları dikkate almamıştı [1].

E-postanın giderek yaygınlaşması ve SMTP protokolünün doğasında var olan zayıflıklar, zaman içinde, aşağıdaki paragraflarda kısaca açıklanan başlıca saldırı türlerinin ortaya çıkmasına zemin hazırlamıştır.

4.1. Gönderici Sahtekarlığı

Sahtekarlık (spoofing) , bir mesajın göndericisinin adresini taklit ederek, mesajın güvenilir bir adresten (örneğin, bir meslektaşın, bir tanıdığın veya kişinin kendi banka kurumunun adresi gibi) geliyormuş gibi görünmesini sağlayan bir siber saldırı tekniğidir. Bu teknik, alıcıyı potansiyel olarak tehlikeli eylemler gerçekleştirmeye, örneğin e-posta ekini açmaya veya mesajda yer alan bağlantılara tıklamaya teşvik eder.

Bu tür bir saldırıyı gerçekleştirmek nispeten kolaydır, çünkü SMTP protokolü gönderici kimlik doğrulama mekanizmalarını içermez ve bu nedenle, e-posta istemcisi aracılığıyla mesaj oluşturulurken herhangi bir gönderici adresi yapılandırılabilir.

Gönderen e-posta adresi: envelope-from ve message-from

E-posta mesaj formatı, gönderenin e-posta adresini belirtmek için iki ayrı alan sağlar. Bu alanlar "envelope-from" ve "message-from": birincisi ( "return-path ), mesajı doğru şekilde yönlendirmek için kullanılan adrestir; ikincisi ise alıcının alınan mesaj başlığında görüntülediği adrestir.

Geleneksel posta yoluyla zarf içinde mektup göndermeyle bir benzetme yapacak olursak, zarftan gönderilen kısım, mektubun zarfında gösterilen gönderenin adresini temsil ederken, mesajdan gönderilen kısım mektubu kimin alıcıya yazdığını gösteren mektup başlığına karşılık gelir.

İki adresin aynı olmayabileceğini belirtmek önemlidir. Bu ayrım, örneğin üçüncü taraf hizmetlerinden gelen mesajların iletilmesi, posta listeleri aracılığıyla dağıtım veya otomatik e-posta yanıtları gibi durumların yönetilmesine olanak tanır.

Hem mesaj gönderen düzeyinde (alıcının aldığı mesaj başlığında görüntülenen gönderenin e-posta adresi) hem de zarf gönderen düzeyinde (mesaj iletimi için kullanılan gönderenin e-posta adresi) herhangi bir göndereni belirtmek gerçekten mümkündür

Bu tehditlere karşı koymak için, göndereni güvenilir bir şekilde doğrulamaya ve mesajı gönderen kişinin gerçekten bunu yapmaya yetkili olup olmadığını teyit etmeye olanak sağlayan mekanizmalar sunmak şarttır.

4.2. Kimlik Avı

Kimlik avı , genellikle güvenilir göndericilerden geliyormuş gibi görünen aldatıcı mesajlar göndererek bilgilerin (örneğin, giriş kimlik bilgileri, kredi kartı numaraları veya diğer hassas veriler gibi) hileli bir şekilde elde edilmesini amaçlayan bir siber saldırı tekniğidir³ .

kimlik taklit etme (spoofing), saldırganın gönderenin kimliğini taklit ederek mesajın meşru bir kullanıcıdan veya alan adından geliyormuş gibi görünmesini sağlamak için kullandığı başlıca tekniklerden biridir.

Alternatif olarak, alıcı tarafından tanınabilir bir gönderen adresi/alan adı kullanılabilir; örneğin, mesajın görünürdeki gerçekliğini güçlendirmek için sözde görünen ad 4 değiştirilebilir

Kimlik avı mesajları göndermek için, saldırgan tarafından daha önce ele geçirilmiş meşru hesaplar da kullanılabilir.

Kimlik avı mesajları genellikle alıcıda aciliyet, endişe veya ekonomik ilgi uyandırmak üzere tasarlanmış içeriklere sahiptir ve bu da alıcının dürtüsel olarak tepki vermesine ve kötü amaçlı ekleri açmak veya görünüşte meşru web sitelerine yönlendiren bağlantılara tıklamak gibi belirli eylemler gerçekleştirmesine yol açan durumlar yaratır; ancak bu siteler gerçekte saldırgan tarafından bilgi çalmak ve/veya kötü amaçlı yazılım yüklemek amacıyla oluşturulmuştur.

Genellikle, kimlik avı saldırıları, metni kurbanların özel profiline uyarlamadan, aynı e-posta mesajını çok sayıda kurbana göndererek gerçekleştirilir.

Kimlik avının bir varyantı olan hedefli kimlik avında, saldırgan kurbanın profilini bilir ve özellikle onu hedef alır.

Sıradan bir kimlik avı e-postasının aksine, hedefli kimlik avı mesajı, kullanıcının güvenilir bir göndericiyle etkileşimde bulunduğuna ikna etmek için daha hassas bağlamsal bilgiler kullanır [2].

4.3. Mesajda Değişiklik Yapılması

Uçtan uca şifreleme (E2EE) tekniklerini kullanmayan internet ağı üzerinden iletilen diğer tüm iletişimler gibi, bir e-posta mesajının içeriği de gönderici ve alıcı arasında iletim sırasında ele geçirilebilir ve değiştirilebilir (bu tür bir tehdit genellikle "ortadaki adam" saldırısı olarak adlandırılır).

Sonuç olarak, gizliliğin kaybına ek olarak, alınan mesaj gönderen tarafından başlangıçta yazılan mesajla aynı olmayabilir.

Örneğin, bir saldırgan mesaj içeriğini güvenilir bir göndericiden geliyormuş gibi gösterecek şekilde değiştirebilir, mesajdaki metni veya bağlantıları ve/veya ekleri değiştirebilir veya kötü amaçlı kod ekleyebilir.

Alıcı, mesajın görünürdeki gerçekliğine güvenerek, giriş bilgilerini paylaşmak, ödemeleri onaylamak veya kötü amaçlı dosyaları açmak gibi potansiyel olarak zararlı eylemlerde bulunmaya yönlendirilebilir.

Bu tehditlere karşı koymak için, mesajın bütünlüğünü ve orijinalliğini garanti eden, alınan içeriğin değiştirilmediğini ve gönderenin gerçekten iddia ettiği kişi olduğunu doğrulayan mekanizmaların benimsenmesi şarttır.

» başa dön

5. Karşı Önlemler

2. Bölümde, e-posta hizmetlerinin korunması için de güvenlik önlemleri öngören düzenlemeler hatırlatılmıştı. Bu belge, öncelikle, 4. Bölümde ele alınan tehditlerle ilişkili riskleri azaltmak amacıyla, söz konusu düzenlemelerde öngörülen ve Ek A'da belirtilen, e-posta hizmetlerinin yapılandırılması için de geçerli olan güvenlik önlemlerinin uygulanmasına ilişkin bir kılavuz sağlamayı amaçlamaktadır. Bununla birlikte, bu kılavuzda yer alan önerilerin, söz konusu düzenlemelere tabi olmayan taraflar için de tavsiye niteliğinde olduğu belirtilmelidir.

Söz konusu güvenlik önlemleri açıkça e-posta hizmetinin yapılandırmasına değil, – ele alınan düzenlemeye bağlı olarak – BT sistemlerinin ve endüstriyel kontrol sistemlerinin (PSNC ve Bulut Düzenlemesi) veya bilgi ve ağ sistemlerinin (NIS2) yapılandırmasına atıfta bulunmaktadır. Bu yönergelerin konusu olan e-posta hizmetleri, her iki sistem türüne de girmektedir.

Özellikle, e-posta hizmetinin genel güvenliğini ve özellikle gönderici kimlik doğrulamasını ve mesaj bütünlüğü kontrolünü güçlendirmek amacıyla tasarlanmış güvenlik mekanizmaları sağlayan SPF , DKIM ve DMARC protokolleri aşağıda gösterilmiştir

5.1. Güneş Koruma Faktörü (SPF)

SPF (Sender Policy Framework) , RFC 7208 ile resmileştirilmiş bir kimlik doğrulama protokolüdür ve bir alan adı sahibinin, kendi adına e-posta mesajı göndermeye yetkili IP adreslerini belirlemesine ve gönderenin e-posta adresinin bağlı olduğu alan adı 5 ile ilişkili IP adresi açıkça yetkilendirilmiş adresler arasında değilse alıcının uygulaması gereken politikaları oluşturmasına olanak tanır.

Yetkilendirilmiş IP adresleri, gönderen etki alanıyla ilgili bir DNS TXT kaydında (SPF kaydı olarak adlandırılır) listelenir ve bu paragrafın sonraki bölümünde açıklanmaktadır.

Bu şekilde, alıcının e-posta sunucusu6, belirli bir alandan gelen bir mesajı aldığında, ilgili SPF kaydını sorgulayabilir ve mesajın alındığı IP adresinin, alan adına mesaj göndermeye yetkili IP adresleri arasında yer aldığını doğrulayarak kaynağının kimliğini doğrulayabilir.

SPF seviyesinde doğrulanan alanın zarf-gönderen ile ilgili alan olduğunu gözlemlemek önemlidir; dolayısıyla SPF protokolünün tek başına benimsenmesi, sahtekarlığı önlemek için yeterli değildir, çünkü bu tür bir saldırı mesaj-gönderen seviyesinde gerçekleştirilebilir7.

Bir kuruluş, e-posta hizmetini tamamen veya kısmen üçüncü bir tarafa, örneğin bir bulut sağlayıcısına, dış kaynak olarak devrettiğinde, bu sağlayıcılar tarafından gönderilen mesajların SPF kontrollerinden geçmesini sağlamalıdır. Bu amaçla, kuruluş, sağlayıcıların kuruluşun alan adı adına e-posta gönderdiği IP adreslerini SPF kaydına eklemelidir.

Otomatik e-posta yönlendirme durumunda, mesajlar genellikle ara bir sunucu tarafından yeniden yönlendirildiğinden, son teslimatı yapan IP adresi artık gönderen alan adı tarafından başlangıçta yetkilendirilen IP adresiyle aynı olmaz. Bu durumlarda, SPF doğrulamasının başarısız olmaması için, ara yönlendirme sunucularının da yetkilendirilmesi veya özellikle çok sayıda ara yönlendirme sunucusunun bulunduğu durumlarda daha etkili olabilen SRS (Gönderici Yeniden Yazma Şeması) veya ARC (Kimliği Doğrulanmış Alınan Zinciri) gibi mekanizmalara başvurulması gerekir.

SPF'nin gerçekten etkili olabilmesi için, yalnızca gönderen tarafından değil, alıcı tarafından da doğru şekilde yapılandırılması gerektiğinin altını çizmek gerekir. Özellikle:

  • Gönderici , kendi adına e-posta göndermeye yetkili adresleri belirten SPF kaydını ilgili DNS sunucusunda yayınlamalıdır;
  • Alıcı , alınan mesajlarda SPF doğrulamasını gerçekleştirecek ve ortaya çıkan politikaları tutarlı bir şekilde uygulayacak şekilde kendi posta sunucusunu yapılandırmalıdır.
5.1.1. SPF Kaydı

SPF Kaydı, adı gönderen alan adına karşılık gelen ve içeriği, sürümü gösteren bölüm ve gönderen alan adının IP adresi ile bir yönerge arasında eşleşme olduğunda alıcının posta sunucusunun davranışını belirten bir dizi yönergeden oluşan TXT türünde bir DNS kaydıdır .

Yönergeler, bir niteleyiciyle başlayan bir mekanizma tarafından oluşturulur. SPF kayıtlarında kullanılan ana mekanizmalar şunlardır: [2]:

  • ip4, yetkilendirilmiş IPv4 adreslerini listeler;
  • ip6, yetkilendirilmiş IPv6 adreslerini listeler;
  • a, etki alanının A kaydında bulunan IP adreslerini yetkilendirir;
  • MX kaydı, alan adının MX kayıtlarıyla ilgili IP adreslerini yetkilendirir;
  • Dahil et seçeneği, başka bir alan adının SPF kaydında bulunan IP adreslerini yetkilendirir;
  • "all" ifadesi, diğer mekanizmalar aracılığıyla açıkça yetkilendirilmemiş tüm IP adreslerini temsil eder.

Özellikle, bu mekanizma, önceki mekanizmalar tarafından tanımlanmamış IP adreslerinden gelen mesajlar için politikalar oluşturulmasına olanak tanır.

Ayrıca, SPF mekanizmalarla ilişkilendirilebilecek aşağıdaki nitelikleri sunmaktadır:

  • + (pass) ifadesi, ilgili mekanizmayla eşleşen IP adreslerinin yetkilendirildiğini gösterir. Başka bir niteleyici belirtilmediyse varsayılan niteleyicidir;
  • - (başarısız) ifadesi, ilgili mekanizmayla eşleşen IP adreslerinin yetkilendirilmediğini gösterir;
  • ~ (softfail), ilgili mekanizmayla eşleşen IP adreslerinin muhtemelen yetkilendirilmediğini gösterir. Bu, bir öncekine göre daha belirsiz bir bildirimdir. Bu durumlarda mesaj kabul edilmeli ancak daha derinlemesine analiz için işaretlenmelidir; örneğin hata ayıklama durumlarında veya SPF doğrulamasının başarılı olmayabileceği öngörüldüğünde kullanılır;
  • ? (nötr) ifadesi, ilgili mekanizmayla eşleşen IP adresleri için herhangi bir gösterge verilmediğini belirtir. Varsayılan davranış, mesajı kabul etmektir.

Uygulamada, SPF kaydının yetkilendirilmiş IP adreslerini belirtmek için oluşturulduğunu ve ardından -all (bu konuda lütfen aşağıdaki örneklere bakın). Bu, yetkilendirilmiş IP adreslerini açıkça belirtmeye ve diğerlerini hariç tutmaya olanak sağladığı için önerilen yapılandırmayı temsil eder.

Her durumda, +all (veya eşdeğeri all ) yönergesini asla kullanmamanız önerilir, çünkü bu tüm IP adreslerinin yetkilendirilmesi anlamına gelir.

SPF kayıtlarına örnekler

Belirli bir IP adresini yetkilendirin

v=spf1 ip4:203.0.113.0 -all

Yukarıda gösterilen SPF kaydı, SPF sürüm 1'i kullanır ve ip4 mekanizması aracılığıyla 203.0.113.0 IP adresini yetkilendirir (aslında, ip4 mekanizması için herhangi bir niteleyici belirtilmediğinden , varsayılan + örtük olarak kullanılır). all mekanizması ve - (fail) niteleyicisi tarafından oluşturulan -all yönergesi , diğer tüm adreslerin yetkilendirilmediğini belirtir.

Belirli bir IP adresi alanını yetkilendirin

v=spf1 ip4:203.0.113.0/24 -all

Yukarıda gösterilen SPF kaydı, bir öncekine benzerdir ancak 203.0.113.0/24 adres aralığındaki tüm IP adreslerine yetki verir.

Birden fazla IP adresini yetkilendirin

v=spf1 ip4:203.0.113.22 ip4:203.0.113.44 -tümü

Yukarıda gösterilen SPF kaydı, yalnızca 203.0.113.22 ve 203.0.113.44 IPv4 adreslerine erişim izni vermektedir .

MX kayıt adreslerini ve belirli bir etki alanını yetkilendirin

v=spf1 mx include:spf.emailprovider.it -all

Yukarıda gösterilen SPF kaydı, yalnızca SPF kaydıyla aynı etki alanına sahip MX kayıtlarının IP adreslerini ve spf.emailprovider.it (örneğin, bir e-posta servis sağlayıcısının etki alanı) yetkilendirdiği IP adreslerini yetkilendirir.

5.1.2. Kimlik Doğrulama Süreci

SPF doğrulaması yapmak üzere doğru şekilde yapılandırılmışsa, alıcının posta sunucusu yeni bir e-posta mesajı aldığında, zarfın gönderen alanında bildirilen adresten yola çıkarak, gönderen alan adının kayıtlarını içeren DNS sunucusunu sorgulayarak gönderen alan adının SPF kaydını alır. Örneğin, zarfın gönderen alanında bildirilen adres alice@example.com, alıcının posta sunucusu example.com.

SPF doğrulama sürecini gösteren diyagram

Şekil 2. SPF doğrulamasının çalışma mekanizması.

Alıcının posta sunucusu daha sonra SPF doğrulamasını gerçekleştirir ve mesajı aldığı IP adresinin example.com alan adı için e-posta gönderme yetkisine sahip olup olmadığını belirlemek için SPF kaydını analiz eder. E-posta mesajı SPF doğrulamasından geçerse, alıcıya iletilir.

Örneğin, example.com alan v=spf1 ip4:203.0.113.22 -all , doğrulama yalnızca gönderen sunucunun IP adresi 203.0.113.22, diğer tüm adresler için başarısız olurdu.

» başa dön

5.2. DKIM

DKIM – DomainKeys Identified Mail , RFC 6376 ile resmileştirilmiş bir kimlik doğrulama protokolüdür ve bir alan adı sahibinin, posta sunucusu tarafından kamuya açık şifreleme algoritmaları kullanılarak oluşturulan ve iletilecek mesajın başlıklarına eklenen dijital bir imza (DKIM imzası) ekleyerek gönderilen e-posta mesajlarının orijinalliğini garanti etmesini sağlar.

Alıcının mesajın iletim sırasında değiştirilmediğini doğrulayabilmesi için, DKIM imzasıyla ilişkili genel anahtar, gönderen alan adının genel DNS'sinde DKIM kaydı adı verilen bir TXT kaydında saklanır ve bu kayıt, mesaj alındığında alıcı posta sunucusu tarafından sorgulanır.

Bu paragrafın sonraki bölümlerinde DKIM imzası ve kaydı gösterilmektedir.

SPF'de olduğu gibi, DKIM de gönderici ve alıcı tarafından doğru şekilde yapılandırılmalıdır ve özellikle şu hususlara dikkat edilmelidir:

  • Gönderici, posta sunucusunu DKIM imzaları oluşturacak ve DKIM kaydını ilgili DNS sunucusunda yayınlayacak şekilde yapılandırmalıdır;
  • Alıcının, gelen mesajlarda DKIM doğrulaması yapacak şekilde posta sunucusunu yapılandırması gerekir.
5.2.1. DKIM İmzası

DKIM imzası, mesaj gövdesinin ve başlıklarının belirlenmiş öğelerinden yola çıkarak oluşturulur ve aşağıdaki öğeleri belirten bir dizi anahtar-değer çiftinden oluşur:

  • v: protokol sürüm10;
  • a: kullanılan şifreleme algoritması11;
  • d: Mesajın orijinalliğini beyan eden imzalama alanı12;
  • s: DNS kaydında hangi DKIM genel anahtarının aranacağını belirten seçici13;
  • h: imzaya dahil edilen e-posta başlıklarının listesi14;
  • bh: mesaj gövdesinin base64 formatında kodlanmış özeti15;
  • b: Özel anahtarla oluşturulan ve base64 formatında kodlanan gerçek dijital imza16;
  • x: İmzanın geçerlilik tarihi;
  • c: kanonikleştirme türü.

Kanonikleştirme, dijital olarak imzalanmadan önce mesaj öğelerinin normalleştirilmesi işlemidir; bu işlem, iletim sırasında meydana gelebilecek küçük değişikliklerin (örneğin tekrarlanan boşluklar veya satır sonları) etkisini azaltmayı amaçlar. İki tür kanonikleştirme vardır: Basit, orijinal mesaj ile alınan mesaj arasında tam bir eşleşme gerektirir; gevşekkanonikleştirme ise boşlukların kaldırılması, başlıklardaki büyük harflerin küçük harflere dönüştürülmesi ve mesaj gövdesindeki ardışık boş satırların azaltılması gibi normalleştirmeler uygular.

5.2.2. DKIM Kaydı

DKIM kaydı, adı selector._domainkey.domain yapısına sahip bir TXT türünde DNS kaydında saklanır; burada _domainkey, DNS kaydının gerçekten bir DKIM kaydı olduğunu belirtmek için kullanılan bir etikettir. DKIM kaydının içeriği, aşağıdakiler de dahil olmak üzere öğeleri belirten bir dizi anahtar-değer çiftinden oluşur:

  • v: protokol sürümü;
  • k: anahtar türü, varsayılan olarak RSA'dır;
  • p: Base64 formatında kodlanmış açık anahtar.
DKIM kaydı örneği

Adı: s1._domainkey.example.com
Değeri: v=DKIM1; k=rsa; p=Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h...

Örnek DKIM kaydı, example.com alan adının s1 seçicisiyle ilişkilidir , 1. sürümü kullanır ve base64 formatında kodlanmış RSA genel anahtarını içerir ( Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h... ).

5.2.3. Kimlik Doğrulama Süreci

Hem gönderenin hem de alıcının posta sunucularında DKIM protokolü doğru şekilde yapılandırılmışsa, DKIM kimlik doğrulama ve onaylama sürecinin işleyişi, gönderen posta sunucusunun 5.2.1 paragrafında açıklandığı gibi mesajın DKIM imzasını oluşturmasını ve bu imzanın mesajın kendisine eklenmesini sağlar. Özellikle, DKIM imzası d alanında imzalama alanını 17 ve b alanında imzalama alanının özel anahtarıyla oluşturulan mesajın dijital imzasını içerir.

DKIM doğrulama mekanizmasını gösteren şema

Şekil 3. DKIM doğrulamasının çalışma mekanizması.

Mesaj alındığında, alıcı posta sunucusu, imzalayan alan adının DKIM kaydını ( DKIM imzasının d alanı) o alan adının kayıtlarını içeren DNS sunucusundan alır. Ardından, DKIM kaydında bulunan genel anahtarı kullanarak DKIM imzasında bulunan dijital imzayı ( b alanı) doğrular. Doğrulama başarılı olursa, mesaj alıcıya iletilir.

5.2.4. Kriptografik Yönler

Kriptografik cephede, DKIM tarihsel olarak RSA algoritmasını, özellikle de 2007'den beri standart olarak kabul edilen rsa-sha256 varyantını kullanmıştır. RFC 8463 ile tanıtılan yeni alternatif ise, daha yüksek verimlilik ve çok daha kompakt anahtarlar sağlayan, eliptik eğrilere dayalı modern bir dijital imza biçimi olan Ed25519-SHA256'dır .

Teknik düzeyde, 2048 bit anahtar uzunluğuna sahip RSA, evrensel standart olmaya devam ediyor, ancak anahtarlar uzun ve imzalar nispeten büyükken, Ed25519, RSA 2048'e kıyasla dokuz kat daha kısa anahtarlar ve dört kat daha küçük imzalar sunarken, imzalama performansı otuz kata kadar daha üstün. Bu avantajlara rağmen, gerçek dünya desteği sınırlı: 2026 yılında Ed25519 yalnızca birkaç sağlayıcı tarafından doğrulanmış durumda, bazı büyük operatörler ise imzalama veya doğrulama konusunda güvenilir bir destek sunmuyor, bu da onu üretimde tek çözüm olarak uygunsuz hale getiriyor.

Bu nedenle, teknik olarak üstün olmasına rağmen, bu belgenin yazıldığı sırada, Ed25519'un kullanımı, deneysel bir bakış açısıyla ve gelecekteki uyumluluk önlemi olarak, çift imza yoluyla RSA ile birlikte kullanılması dışında önerilmemektedir . Büyük sağlayıcılar doğrulamasını tam olarak uygulamaya koyana kadar, RSA, maksimum mesaj teslim güvencesini sağlamak için vazgeçilmez olmaya devam etmektedir.

Uzun vadeli güvenlik açısından, ne RSA'nın ne de Ed25519'un gelecekteki kuantum bilgisayarların saldırılarına karşı dirençli olmadığını hatırlamak önemlidir [3] ve kuantum sonrası algoritmalara geçiş, şu anda mevcut olmayan yeni DKIM standartlarını gerektirecektir; bu nedenle yeni nesil kriptografi gelişmelerini ve bu alandaki gelecekteki ACN önerilerini izlemek çok önemlidir.

Kriptografik anahtar yönetimi hususlarında, DKIM özel anahtarı, yetkisiz erişimi veya güvenlik ihlallerini önlemek için, yalnızca yetkili hizmetlerin erişebileceği izole sistemlerde tutularak, kısıtlayıcı izinler benimsenerek, periyodik olarak değiştirilerek ve sürekli olarak izlenerek, sıkı güvenlik önlemleriyle korunmalıdır.

» başa dön

5.3. DMARC

DMARC – Alan Adı Tabanlı Mesaj Kimlik Doğrulaması, Raporlama ve Uyumluluk, RFC 7489, SPF ve DKIM mekanizmalarını entegre edenadı sahibinin, o alan adından iletilen mesajların alıcılarına, SPF ve DKIM doğrulamalarından geçemeyen mesajları yönetme politikalarını belirtmesine olanak tanıyan bir kimlik doğrulama protokolüdür.

Özellikle DMARC, SPF ve DKIM tarafından doğrulanan alanlar ile alınan mesajın "message-from " alanıyla ilgili alan arasındaki uyumu doğrulayan bir doğrulama mekanizması (hizalama olarak adlandırılır) sunar. "Mesajdan gelen" alanı ile SPF/DKIM alanı arasındaki hizalama kontrolünün, ilgili SPF/DKIM doğrulaması başarısız olursa her durumda başarısız olacağını unutmayın (Şekil 4'e bakınız)

DMARC doğrulama mekanizmasını gösteren şema

Şekil 4. DMARC doğrulama mekanizması.

Hizalama, katı modda doğrulanabilir ; bu modda SPF/DKIM tarafından kimliği doğrulanan alan adları ile mesajdan gelen alan adıyla ilgili alan adı arasında tam bir eşleşme gereklidir. Gevşek modda ise alt alan adları farklı olsa bile birincil alan adlarının eşleşmesi yeterlidir.

Örneğin, gevşek modda sub1.example.com ve sub2.example.com alan adları için DMARC doğrulama amacıyla bir eşleşme bulunur (çünkü birincil alan adı olan example.com aynıdır). Ancak katı modda, alan adları arasında tam bir eşleşme olmadığı için DMARC eşleşme kontrolü başarısız olur.

Hizalama doğrulaması sayesinde, bir saldırgan SPF ve/veya DKIM kontrollerini, SPF ve/veya kimliği doğrulanmış imza alanından farklı bir zarf göndericisinden farklı bir mesaj göndericisi kullanarak geçmeyi başarsa bile , DMARC yine de tutarsızlığı tespit ederek gönderenin kimliğinin tutarlı ve güvenilir bir şekilde doğrulanmasını sağlar [2] .

DMARC doğrulamasında başarısız olan mesajların yönetimine ilişkin politikalar, gönderen etki alanının göreceli DNS sunucusunun DMARC kaydı adı verilen bir TXT kaydında belirtilir ve bu paragrafın sonraki bölümünde açıklanır.

DMARC ayrıca, alıcılara, o alan adından kaynaklandığı iddia edilen mesajlarla ilgili olarak gönderen alan adı sahiplerine rapor göndermelerini belirtme olanağı da sunar. Bu sayede, alan adı sahibi, alan adının yetkisiz bir şekilde kullanılıp kullanılmadığını ve ne ölçüde kullanıldığını doğrulayabilir; örneğin, toplam kaynak iddiasında bulunan mesajlar arasından kaç mesajın gerçekten kendilerine ait olduğunu analiz edebilir.

SPF ve DKIM'de olduğu gibi, DMARC'ın da gönderici ve alıcı tarafından doğru şekilde yapılandırılması gerekir ve özellikle şu hususlara dikkat edilmelidir:

  • Gönderici, DMARC doğrulamasından geçemeyen mesajların nasıl yönetileceğine dair politikaları belirten DMARC kaydını DNS'inde yayınlamalıdır;
  • Alıcının, aldığı mesajlarda DMARC doğrulamasını gerçekleştirecek şekilde posta sunucusunu yapılandırması gerekir.
5.3.1. DMARC Kaydı

DMARC kaydı adı, _dmarc.domain yapısına sahiptir ; burada _dmarc, DNS kaydının bir DMARC kaydı olduğunu belirtmek için kullanılan bir etikettir ve domain ise politikanın atıfta bulunduğu etki alanıdır.

DMARC kaydı, aşağıdakiler de dahil olmak üzere çeşitli öğeleri belirten bir dizi anahtar-değer çiftinden oluşur:

  • v: DMARC protokolü sürüm20;
  • p : DMARC doğrulamasında başarısız olan mesajlara uygulanacak politika; none , quarantine , reject değerlerinden birini alabilir .
  • aspf: SPF kontrolüne uygulanacak hizalama modu ( relaxed, default value veya strict);
  • adkim : DKIM kontrolüne uygulanacak hizalama modu ( gevşek , varsayılan değer veya katı olabilir );
  • rua: Gönderen alan adından alınan mesajlara ilişkin istatistiksel ve özet bilgiler içeren toplu raporların gönderileceği e-posta adresleri;
  • ruf: DMARC doğrulamasından geçemeyen gönderen alan adından alınan bireysel mesajlar hakkında ayrıntılı raporların gönderileceği e-posta adresleri.
DMARC kaydına örnek

Adı:
_dmarc.example.com
Değer:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; adkim=s; aspf=s

Örnek DMARC kaydı example.com alan adıyla ilişkilidir , sürüm 1'i kullanır ve DMARC doğrulamasında başarısız olan mesajlar için reddetme politikasını belirtir; SPF ve DKIM alan adlarının uyumunun doğrulanması için katı mod ( ) talep eder ve toplu raporları dmarc-reports@example.com adresine , başarısızlık raporlarını ise dmarc-fail@example.com adresine iletir .

5.3.2. DMARC Politikaları

Önceki paragrafta açıklandığı gibi, DMARC kaydı, alıcı posta sunucusunun DMARC doğrulamasından geçemeyen mesajlar için uygulaması gereken politikayı belirtir. Olası politikalar şunlardır:

  • Hiçbiri: Gönderen alan adı, DMARC doğrulamasında başarısız olan mesajların teslimiyle ilgili herhangi bir bilgi vermez;
  • Karantina: Gönderen alan adı, DMARC doğrulamasından geçemeyen mesajların şüpheli olarak değerlendirilmesi gerektiğini belirtir (örneğin, daha fazla incelemeye tabi tutulmalı, spam olarak ele alınmalı veya şüpheli olarak etiketlenmelidir);
  • Reddet: Gönderen alan adı, DMARC doğrulamasından geçemeyen mesajların reddedilmesi gerektiğini belirtir.
5.3.3. Politika Doğrulama ve Uygulama Süreci

Hem gönderenin hem de alıcının posta sunucularında DMARC protokolü doğru şekilde yapılandırılmışsa, mesaj alındığında alıcı posta sunucusu ilgili doğrulamaları gerçekleştirmek için SPF ve DKIM kayıtlarını ve ayrıca DMARC kaydını (5.2.4 paragrafının başında ayrıntılı olarak açıklanmıştır) alır. Mesaj DMARC doğrulamasından geçemezse, DMARC kaydında belirtilen politika (yok, karantinaya al veya reddet) uygulanır.

DMARC doğrulama ve politika uygulama sürecini gösteren şema

Şekil 5. DMARC politikalarının doğrulama ve uygulama süreci.

Her posta sunucusunun, SPF, DKIM ve DMARC doğrulamalarının sonuçlarını da dikkate alarak, bir mesajın teslim edilip edilmeyeceğine karar vermek için yerel sezgisel yöntemler ve politikalar benimseyebileceğini unutmayın. Bu nedenle, genellikle yukarıda belirtilen doğrulamaların ardından ek bir karar verme süreci ("Şekil 5'teki "Standart filtre") vardır ve bu süreç, örneğin spam önleme ve kötü amaçlı yazılım önleme filtreleri gibi daha fazla kontrol içerebilir.

Ayrıca, alıcı posta sunucusu şunları iletebilir:

  • DMARC kaydının rua alanında belirtilen adreslere , gönderen alan adından alınan mesajlara ilişkin istatistiksel ve özet bilgiler içeren toplu raporlar gönderilir;
  • DMARC kaydının ruf alanında belirtilen adreslere , DMARC doğrulamasından geçemeyen gönderen alan adından alınan bireysel mesajlara ilişkin ayrıntılı raporlar gönderilir

» başa dön

6. Sonuçlar

Önceki bölümde tartışıldığı gibi, gönderici alan adı taklitine bağlı tehditlerle en iyi şekilde mücadele etmek için incelenen üç protokolün de birlikte uygulanması ve özellikle de şu hususların dikkate alınması gerekmektedir: [3]:

  • Gönderen alan adı, DNS'te SPF, DKIM ve DMARC kayıtlarını doğru şekilde yayınlar;
  • Gönderenin posta sunucusu, mesajları DKIM ile imzalamak üzere yapılandırılmıştır;
  • Alıcının posta sunucusu, SPF ve DKIM doğrulamalarını gerçekleştirmek ve DMARC politikalarını uygulamak üzere yapılandırılmıştır.

Protokolün uygulanmasına ilişkin olarak, aşağıdaki öneriler de formüle edilmiştir [2]:

  • Alan adı adına e-posta göndermeye yetkili IP adreslerini belirterek SPF'yi yapılandırın; e-posta iletimi için kullanılmayan alan adları için, örneğin yalnızca web siteleri için tasarlanmış olanlar için, o alan adı için geçerli e-posta göndericisinin olmadığını açıkça belirtmek üzere bir SPF kaydı oluşturulmalıdır;
  • Bu belgenin yazıldığı tarih itibariyle DKIM anahtarları için güvenli kabul edilen en gelişmiş şifreleme protokolleri ve algoritmaları kullanılmalıdır; 2048 bit RSA önerilmektedir;
  • Posta sunucusunda saklanan DKIM özel anahtarını yeterli şekilde koruyun, kısıtlayıcı erişim izinleri benimseyin ve yalnızca posta sunucusu yazılımının anahtara okuma ayrıcalığına sahip olmasını sağlayın;
  • Olası bir özel anahtar güvenliğinin ihlalinin etkisini azaltmak için her posta sunucusunu benzersiz bir anahtar çifti ve seçici ile yapılandırın;
  • Özel anahtarı hem kaz accidental ifşadan hem de bir saldırgan tarafından erişim veya değiştirme girişimlerinden koruyun;
  • Posta listeleriyle ilgili yazılımın gelen mesajlardaki DKIM imzalarını doğrulamasını ve giden mesajlara yeni DKIM imzaları eklemesini sağlayın;
  • Kuruluş adına e-posta gönderen her üçüncü taraf için benzersiz DKIM anahtar çiftleri kullanın;
  • Olası bir güvenlik ihlalinin etkisini azaltmak için DKIM anahtar çiftlerini periyodik olarak (en az altı ayda bir) değiştirin;
  • Güvenlik ihlalinden şüphelenilmesi durumunda anahtarları derhal geri alın;
  • DMARC raporlarını izleyerek yapılandırma hatalarını veya kötüye kullanım girişimlerini tespit edin.

Daha ayrıntılı bilgi için, Referans Belgelerinde listelenen kaynaklara bakınız .

E-posta güvenliğini yeterince korumak için, burada incelenen kimlik doğrulama protokollerine ek olarak, bu kılavuzların konusu olmayan başka protokoller de olduğu gözlemlenmiştir; örneğin, iletim kanalı şifrelemesini garanti eden TLS (Transport Layer Security) ve uçtan uca şifreleme ve mesaj kimlik doğrulamasıyla ilgili olan SMIME ve OpenPGP gibi

Ayrıca, kesin anlamda bir e-posta güvenlik protokolü olmasa da, e-posta hizmeti güvenliği amacıyla DNSSEC'in (Alan Adı Sistemi Güvenlik Uzantıları) uygulanmasının önerildiği belirtilmektedir. DNSSEC, DNS sorgularının bütünlüğünü ve orijinalliğini garanti altına almak için DNS kayıtlarına kriptografik imzalar ekleyen bir DNS protokol uzantısıdır. Örneğin, DNSSEC sayesinde SPF, DKIM ve DMARC kayıtlarıyla ilgili bilgiler iletim sırasında korunarak, değiştirilme riski azaltılır ve dolayısıyla e-posta hizmeti güvenliği artırılır.

» başa dön

Ek A: Güvenlik Önlemleri

Ulusal Siber Güvenlik Çevresi (PSNC)

PR.IP-1: Güvenlik ilkelerini (örneğin, en az işlevsellik ilkesi) içeren BT sistemlerinin ve endüstriyel kontrol sistemlerinin yapılandırılması için referans uygulamalar (temel standartlar olarak adlandırılır) tanımlanır ve yönetilir.

  1. Kategori ID.AM ile ilgili olarak da en azından şu hususları belirten ayrıntılı ve güncellenmiş bir belge bulunmaktadır:
    • a) BT ve endüstriyel kontrol sistemlerinin yapılandırmalarının geliştirilmesi ve yalnızca benimsenen yapılandırmaların devreye alınması için benimsenen güvenlik politikaları;
    • b) Kullanılan BT ve endüstriyel kontrol sistemi konfigürasyonlarının listesi ve ilgili referans uygulamalarına atıf;
    • c) Güvenlik politikalarına uyumluluğa katkıda bulunan süreçler, metodolojiler ve teknolojiler.

Bulut Bilişim Düzenlemesi – Kamu Yönetimi için Dijital Altyapılar ve Hizmetler

PR.IP-01: Güvenlik ilkelerini (örneğin, en az işlevsellik ilkesi) içeren BT sistemlerinin ve endüstriyel kontrol sistemlerinin yapılandırılması için referans uygulamalar (temel standartlar olarak adlandırılır) tanımlanır ve yönetilir.

  1. Uygulama güvenliğiyle ilgili politikalar ve prosedürler, uygulama güvenliği özelliklerinin planlanması, gerçekleştirilmesi ve sürdürülmesi için yeterli desteği sağlamak amacıyla tanımlanır ve en az yılda bir kez gözden geçirilip güncellenmelidir.
  2. Kategori ID.AM ile ilgili olarak da en azından şu hususları belirten ayrıntılı ve güncellenmiş bir belge bulunmaktadır:
    • a) BT ve endüstriyel kontrol sistemlerinin yapılandırmalarının geliştirilmesi ve yalnızca benimsenen yapılandırmaların devreye alınması için benimsenen güvenlik politikaları;
    • b) Kullanılan BT ve endüstriyel kontrol sistemi konfigürasyonlarının listesi ve ilgili referans uygulamalarına atıf;
    • c) Güvenlik politikalarına uyumluluğa katkıda bulunan süreçler, metodolojiler ve teknolojiler.
  3. Çeşitli uygulamaların güvenliğine ilişkin temel gereksinimler tanımlanmış ve belgelenmiştir.
  4. Tanımlanmış güvenlik gereksinimlerine ve uyumluluk yükümlülüklerine uyma düzeyini izlemek için yararlı olan teknik nitelikteki ölçütler tanımlanır ve uygulanır.
  5. Uygulama güvenliği için, mümkün olduğunda düzeltmeyi otomatikleştiren, uygulama güvenlik açıklarının azaltılması ve giderilmesine yönelik bir süreç mevcuttur.
  6. Cihazın işletim sistemleri ve uygulamalarla uyumluluğunu doğrulamak için bir süreç mevcuttur.
  7. İşletim sistemi, yama ve/veya uygulamalar açısından bir varyasyon yönetim sistemi mevcuttur.
Bulut Düzenlemesi – Kamu Yönetimi için Bulut Hizmetleri

PR.IP-01: Güvenlik ilkelerini (örneğin, en az işlevsellik ilkesi) içeren BT sistemlerinin ve endüstriyel kontrol sistemlerinin yapılandırılması için referans uygulamalar (temel standartlar olarak adlandırılır) tanımlanır ve yönetilir.

  1. Uygulama güvenliği ile ilgili politikalar ve prosedürler, uygulama güvenliği özelliklerinin planlanması, gerçekleştirilmesi ve sürdürülmesi için yeterli desteği sağlamak amacıyla tanımlanır ve en az yılda bir kez gözden geçirilip güncellenmelidir [IaaS, SaaS].
  2. Kategori ID.AM ile ilgili olarak da en azından şu hususları belirten ayrıntılı ve güncellenmiş bir belge bulunmaktadır:
    • a) BT ve endüstriyel kontrol sistemlerinin yapılandırmalarının geliştirilmesi ve yalnızca benimsenen yapılandırmaların devreye alınması için benimsenen güvenlik politikaları;
    • b) Kullanılan BT ve endüstriyel kontrol sistemi konfigürasyonlarının listesi ve ilgili referans uygulamalarına atıf;
    • c) [SaaS] güvenlik politikalarına uyumluluğa katkıda bulunan kullanılan süreçler, metodolojiler ve teknolojiler.
  3. Çeşitli uygulamaların güvenliğine ilişkin temel gereksinimler tanımlanmış ve belgelenmiştir.
  4. Tanımlanmış güvenlik gereksinimlerine ve uyumluluk yükümlülüklerine uyma düzeyini izlemek için yararlı olan teknik nitelikteki ölçütler tanımlanır ve uygulanır. 5. Uygulama güvenliği için uygulama güvenlik açığı azaltma ve kurtarma süreci vardır ve mümkün olduğunda düzeltme otomatikleştirilir.
  5. İşletim sistemleri ve uygulamalarla [PaaS, SaaS] cihaz uyumluluğunu doğrulamak için bir süreç vardır.
  6. İşletim sistemi, yama ve/veya uygulamalar [PaaS, SaaS] açısından bir varyasyon yönetim sistemi mevcuttur.
2 NIS

PR.PS-01: Yapılandırma yönetimi uygulamaları oluşturulur ve uygulanır.

  1. En azından ilgili bilgi ve ağ sistemleri için, güvenli temel yapılandırmaları (güçlendirilmiş) tanımlanmış ve güncellenmiş bir listede belgelenmiştir.
  2. GV.PO-01 numaralı önlemde belirtilen politikalara uygun olarak, 1. maddeyle ilgili prosedürler benimsenmiş ve belgelendirilmiştir.

» başa dön

Kaynakça

[1] NIST, «Teknik Not 1945».
[2] NIST, «NIST Özel Yayın 800-177 Revizyon 1»
[3] Ulusal Siber Güvenlik Ajansı, «Kuantum sonrası ve kuantum kriptografi - Kuantum tehdidine hazırlık».
[4] Ulusal Siber Güvenlik Ajansı, «E-posta kimlik doğrulama çerçevesi».

» başa dön


  1. Eurostat Verileri 2026, https://ec.europa.eu/eurostat/databrowser/view/tin00094/default/table?lang=en&category=f_isoc_t_isoc_i_t_isoc_iu ↩︎

  2. RFC 821 daha sonra 2008 tarihli RFC 5321 ile güncellenmiştir. ↩︎

  3. Aslında genel olarak, e-posta sunucuları, MTA'nın görevlerinin dışında, örneğin mesajların yerel olarak depolanması ve istemcilerin e-posta kutularına erişimi gibi görevleri yerine getiren ek modüller içerir. ↩︎ ↩︎

  4. Görüntülenen ad, gönderenin e-posta adresiyle ilişkili olan ve e-posta istemcisi tarafından mesaj başlığında alıcıya gösterilen metin alanıdır. E-posta adresinden farklıdır ve göndereni okunabilir ve tanınabilir bir şekilde tanımlamaya yarar. ↩︎

  5. Bir e-posta adresi, yerel-bölüm@alan-bölümü şeklinde bir yapıya sahiptir; burada yerel-bölüm, alan-bölümü ile ilişkili e-posta sistemi veya sunucu içindeki belirli kullanıcıyı tanımlar ; alan-bölümü ise yerel-bölüm tarafından tanımlanan kullanıcının hesabını barındıran sistemin veya hizmetin alan adına karşılık gelir [2] . ↩︎

  6. Metin akıcılığı açısından ve herhangi bir belirsizliğe yol açmamak için, göndericiden alıcıya mesajların aktarımını sağlayan e-posta sunucusunun bileşeni olan MTA yerine "e-posta sunucusu" ifadesi kullanılacaktır. ↩︎

  7. "Zarf-gönderen" ve "mesaj-gönderen" arasındaki fark için lütfen 4.1. paragraftaki " Gönderen e-posta adresi: zarf-gönderen ve mesaj-gönderen" başlıklı ayrıntılı bilgi kutusuna bakın. ↩︎

  8. Ek bilgi belirten, kurallara istisna getiren ve varsayılan değerlerden sapmaları gösteren "değiştiriciler" de bulunabilir. ↩︎

  9. Şu anda protokolün yalnızca bir sürümü mevcut (v=spf1). ↩︎

  10. Şu anda protokolün yalnızca bir sürümü (v=1) mevcuttur. ↩︎

  11. Varsayılan algoritma rsa-sha256'dır. ↩︎

  12. İmzalama alanı, dijital imza yoluyla mesajın orijinalliğini garanti eden ve alıcıların DNS'den DKIM genel anahtarını almak ve imzayı doğrulamak için başvurduğu alandır. Mesajın gönderdiği ve/veya zarfın gönderdiği alanla mutlaka aynı olması gerekmez, ancak DMARC politikaları bunların bunlarla uyumlu olmasını gerektirebilir (bu konuda lütfen DMARC paragrafına bakın). ↩︎

  13. Seçici, imzayı oluşturmak için kullanılan kriptografik anahtar çiftini benzersiz bir şekilde tanımlamaya olanak tanır. Belirli bir etki alanı için, aynı etki alanındaki MTA'ların farklı anahtarlar kullanmasına veya etkili bir periyodik anahtar rotasyonuna izin vermek üzere birden fazla anahtar çifti oluşturulabilir. ↩︎

  14. Özellikle, mesaj iletimi sırasında değiştirilmeyen belirli mesaj başlıkları (örneğin Kimden, Kime, Konu, Tarih) imzalanır. ↩︎

  15. Mesaj özeti genellikle mesajın tüm gövdesi üzerinden hesaplanır. Örneğin, altbilgi veya sorumluluk reddi beyanları gibi öğeler eklenerek mesajın iletim sırasında değiştirildiği senaryoları yönetmek için (posta listesi hizmetlerini veya otomatik yönlendirmeyi düşünün), imza amacıyla mesajın yalnızca bir bölümünü dikkate almak mümkündür. Ancak bu uygulama, alınan mesajın tam bütünlüğünü garanti etmediği için riskler içerir. ↩︎

  16. Dijital imza, h'de listelenen başlıklardan ve bh'deki mesaj gövdesi özetinden yola çıkarak elde edilir . ↩︎

  17. Daha önce 5.2.1 paragrafında belirtildiği gibi, genel olarak imzalama etki alanı, mesajdan gelen ve/veya zarftan gelen etki alanıyla örtüşmeyebilir, ancak DMARC politikaları bunun uyumlu olmasını gerektirebilir (bu, DMARC paragrafında açıklanacaktır). ↩︎

  18. DMARC'ın işlev görmesi için SPF ve DKIM'den en az birinin uygulanması gerekir. Bu kılavuzda, 5. bölümde belirtildiği gibi, üç protokolün de birlikte uygulanması önerilmektedir. ↩︎

  19. DMARC doğrulamasından geçmek için iki hizalamadan (SPF veya DKIM) en az birinin geçerli olması gerekir. ↩︎

  20. Şu anda protokolün yalnızca bir sürümü mevcut (v=DMARC1). ↩︎

BCC e-postalarına iyi bir alternatif

GNU Mailman

Önceki bir yazımızda, gizli alıcı (bcc) e-postalarının kullanımının avantajlarını ve dezavantajlarını açıklamıştık,
bkz: "Gizli Alıcı E-postaları Nasıl Gönderilir ve Sınırlandırılır".

Sonuç bölümünde, diğer cümlelerin yanı sıra şunları belirttik:

Toplu e-posta gönderimi için özel uygulamalar kullanın. Profesyonel sistemler, onay iş akışına ve adım adım kontrole sahiptir; hataları önlemek için tasarlanmıştır.

Bu makalenin özeti:

Nasıl çalışır?

E-posta pazarlama platformlarını öğrenmek ve (müşterilerinize sunmanız durumunda) desteklemek zor olabilir.

Burada anlattığımız şey, toplu e-postalarınızı göndermek için açık kaynaklı yazılım "GNU Mailman"ı kullanma fikridir.
copymail uygulaması "nı sunma deneyimimizden kaynaklanmaktadır .

Mailman'da "tek yönlü" liste,
yalnızca yetkili moderatörlerin gönderi yapabildiği ve üyelerin listeye yanıt veremediği haber bültenleri veya duyurular için bir yapılandırmadır.

İşte çalışma şekli:

  1. Kullanıcı, mesajı e-posta istemcisinden veya web posta üzerinden listenin e-posta adresine gönderir.
    Ardından, mesajın sunucu tarafında tüm abonelere dağıtılması için teslimatı onaylaması gerekir.

  2. Sistem, geri dönen e-postaları (bounce emails) otomatik olarak işler ve istenirse abonelikleri iptal eder.
    Aboneliklerin manuel olarak kaydedilmesi gerekir.

  3. Bu hizmet son derece güvenilirdir ve binlerce adresi sorunsuz bir şekilde işleyebilir.
    Gönderme işlemi RealSender'ın veya diğer SMTP sunucularının kullanımına bağlıdır.

başa dön


GNU Mailman "tek yönlü" liste

GNU Mailman, çoğu İnternet Servis Sağlayıcısının sunduğu yaygın olarak kullanılan bir yazılımdır.
İnternette, toplu e-posta gönderimi için nasıl yapılandırılacağı ve kullanılacağına dair birkaç kılavuz bulunmaktadır:

  • Üyeler, web sitenizdeki bir formu doldurarak (ve onay e-postasına yanıt vererek) katılırlar
  • Onlara listeye nasıl gönderi yapılacağına dair bilgi içermeyen bir hoş geldin mesajı gönderilecek
  • Onlara, abonelikten çıkmak için basit talimatlar içeren bir alt bilgi bölümüyle birlikte haber bültenleriniz gönderilecektir
  • Listeye yalnızca yetkili kişiler mesaj gönderebilir (bülten gönderebilir)

Ana referans, Barry Warsaw'ın mailman-users listesine yazdığı iki gönderiden alınan bu belgedir:
Nasıl bir haber bülteni/duyuru/tek yönlü liste oluşturabilirim?

Metin, ana noktaları ayrıntılı olarak açıklamaktadır:

  • Listeye nasıl gönderi yapılacağından bahsetmeden özelleştirilmiş bir karşılama mesajı ve liste bilgisi sayfası nasıl oluşturulur?
  • Bu tür listelerde sıkça karşılaşılan parola sorunlarını ve abonelik iptali problemlerini nasıl en aza indirebilirsiniz?
  • Listeyi nasıl kısıtlayarak yalnızca yetkili kişilerin paylaşım yapabilmesini sağlayabilirim?
  • Bir duyuru listesinin belirli bir iletişim adresine yanıt vermesini nasıl ayarlayabilirim?
  • Duyuru listesine nasıl gönderi yapılır?

Stanford Üniversitesi'nden bir başka makale, Mailman'ın
yalnızca duyuru amaçlı bir liste oluşturmak için nasıl kullanılabileceğini açıklıyor:
Yalnızca duyuru veya haber bülteni içeren 'tek yönlü' bir liste nasıl oluşturulur - Bilgi makalesi KB00010792

başa dön


GNU Mailman hakkında bazı tarihsel bilgiler

E-posta listeleri tartışmaya dayalı veya duyuruya dayalı olabilir. Mailman yazılımı Python dilinde yazılmıştır; piyasaya sürülmesinden önce Python topluluğu, Perl tabanlı bir e-posta listesi yöneticisi olan Majordomo'yu kullanıyordu.

Şu anda Mark Sapiro istikrarlı 2.1 dalını sürdürürken,
Barry Warsaw yeni 3.X sürümüne odaklanıyor.

Mailman'ın süregelen başarısı için kritik öneme sahip iki temel ilke:

  • Hiçbir mesaj kaybolmamalı
  • Hiçbir mesaj birden fazla kez iletilmemelidir

Mailman 2'de geliştiriciler, bu iki ilkenin her zaman en önemli öncelik olmasını sağlamak için mesaj işleme sistemini yeniden tasarladılar. Sistemin bu kısmı en az on yıldır istikrarlı durumda ve Mailman'ın bugün olduğu kadar yaygın olmasının temel nedenlerinden biri de bu.

başa dön


VERP sıçrama yönetimi

VERP, Değişken Zarf Geri Dönüş Yolu anlamına gelir . E-posta listelerinin, geri dönen alıcı adreslerini kesin olarak belirlemek için kullandığı iyi bilinen bir tekniktir. E-posta listesi geri dönen adresi aldığında, geri dönen adresi devre dışı bırakmak veya listeden çıkarmak gibi yararlı bir işlem yapabilir.

Geri dönen e-postalar için teslimat durumu bildirimleri adı verilen standart bir format vardır . Mailman, yirmi yıllık varlığı boyunca gerçek dünyada görülen düzinelerce geri dönme formatı sezgisel yöntemini içeren bir kütüphane kullanır.

VERP, SMTP protokolünün temel gereksinimi olan, hata mesajlarını zarf göndericisine geri göndererek, net bir şekilde hata tespiti sağlama özelliğini kullanır. Bu, "From:" alanı değil, aslında "MAIL FROM" değeridir. Bu değer, teslimat yolu boyunca korunur ve standartlara göre, nihai alıcı posta sunucusunun hata mesajlarını bu adrese göndermesi gerekir.

Mailman sunucusu mylist@example.org ise, anne@example.com adresine gönderilen bir posta listesi gönderisi için VERP kodlu zarf gönderici adresi şu şekilde olacaktır: mylist-bounce+anne=example.com@example.org . Geri dönen e-postalar, VERP kodlu alıcı adresine gönderilir. Mailman daha sonra "To:" başlığını ayrıştırarak orijinal alıcıyı anne@example.com olarak çözebilir

VERP kullanmak, Mailman'in her alıcıya mesajın yalnızca bir kopyasını göndermesini gerektirir. VERP, her alıcı için benzersiz bir MAIL FROM ve bunu yapmanın tek yolu mesajın benzersiz bir kopyasını göndermektir. Bu yaklaşım ayrıca mesajın spam olarak tanımlanmasını önlemeye de yardımcı olur.

başa dön


"Gönderen" ve "Posta Gönderen" adreslerinin hizalanması

Deneme süresi boyunca, varsayılan “ copymail uygulaması ” yapılandırması, geri dönen e-postaların gönderildiği adres olan, tarafımızdan sağlanan bir alan adını Gönderen adresi (geri dönüş/iade yolu/zarf adresi olarak da bilinir) olarak kullanır. Bu Gönderen alan adı, Gönderen adres alan adından (alıcılara görünen gönderen adresi) farklıdır

Üretime geçmeden önce, "Gönderen" alan adıyla gönderilen mesajların kimlik doğrulaması için DNS'te bazı değişiklikler yapılmalıdır . En yeni e-posta standartları, "Gönderen" adresi olarak temel alan adını (örneğin, info@youremaildomain.com ) kullanmaya devam ederken, "Gönderen" adresi olarak bir alt alan adı (örneğin, email.youremaildomain.com ) kullanarak kimlik doğrulamalı e-postalar göndermenize olanak tanır . Daha fazla ayrıntı için e-posta kimlik doğrulama gelişmiş sayfasına bakabilirsiniz .

Aynı durum diğer ortamlarda da meydana gelebilir. Bunu internet servis sağlayıcınızla doğrulamanızı öneririz.

başa dön

SMTP sunucuları için ters proxy

Ters proxy, istemci isteklerini işlemek için bir veya daha fazla web sunucusunun önünde yer alan ve
güvenliği, performansı ve ölçeklenebilirliği artıran bir sunucudur.

ters proxy diyagramı

İstemciler sunucularla doğrudan iletişim kurmak yerine,
isteklerini ters proxy'ye gönderirler;
tek ve güvenli bir erişim noktası görevi görerek
uygun sunuculara yönlendirir

Başlıca Faydaları:

  • Güvenlik açısından, kötü amaçlı istekleri engelleyebilir, trafiği şifreleyebilir
    ve arka uç sunucularını doğrudan saldırılardan koruyabilir.
  • Performans: Gelen trafiği birden fazla sunucuya dağıtarak
    tek bir sunucunun aşırı yüklenmesini önler ve daha yüksek kullanılabilirlik sağlar.
  • Ölçeklenebilirlik: Hizmet kesintisi olmadan arka uç sunucuları eklemenize veya kaldırmanıza olanak tanıyarak
    artan trafiği yönetme yeteneği sunar.

Yalnızca HTTP kullanan ters proxy (Katman 7)

İnternette çeşitli araçlar mevcut; araştırmalarımız sonucunda, öncelikle yalnızca HTTP protokolünü (Katman 7) destekleyenleri eledik:

Apache'ye Hayır!
“Eyvah. Kullandığınız teknolojiler hakkında biraz bilgi edinin. E-posta SMTP kullanır. Apache HTTP kullanır. Apache'nin SMTP hakkında hiçbir bilgisi yok. E-posta mesajlarıyla çalışmak istiyorsanız, SMTP konuşan bir teknolojiye ihtiyacınız olacak.” – EEAA, 18 Ağustos 2016, 02:49'da yorum yaptı

Caddy'ye Hayır!
“Caddy TCP'yi vekil sunucu olarak kullanamaz, yalnızca TCP üzerinden HTTP'yi vekil sunucu olarak kullanabilir. Traefik, Nginx veya haproxy gibi TCP'yi vekil sunucu olarak kullanabilen bir ters proxy kullanın veya bu deneysel eklentiyi kullanın.” – ElevenNotes Yorumu, 24 Eylül 2024


Ardından yorumlarda önerilen üç seçeneğe odaklandık: "Traefik, NginX veya HAProxy" ve bunları tek tek kurup test ettik.

Traefik ilk tercihti.

Çoğu eğitim videosu Docker ile başlıyordu; ben ise bu platformdan kaçınmak ve Fedora ve CentOS gibi RPM tabanlı dağıtımlar için YUM veya Ubuntu ve Debian gibi Debian tabanlı dağıtımlarda kullanılan APT (Advanced Package Tool) gibi Linux paket yöneticilerinden birine dayalı daha basit bir çözüm tercih etmek istedim.

Uzun bir aramanın ardından, aradığımız kurulum türünü açıklayan bu yeni makaleyi bulduk: Traefik'i systemd Servisi Olarak Kurma.

Bir not: SELinux ayarlarını "Zorlayıcı"dan "İzin Verici"ye değiştirmeniz gerekiyor

Yine, Udemy'de iki kurs denedikten sonra, bu mükemmel kursu bulduk: Traefik Hızlı Başlangıç ​​Kursu (Docker Olmadan). Sağlanan örnekleri yeniden üreterek çalışır hale getirmeyi başardık. Videonun sonuna doğru, mükemmel eğitmen bu araca tamamen karşı olduğunu ifade etti: Traefik Hızlı Başlangıç ​​Kursu - 53:50 Özet.
Bu, daha fazla test yapmaktan bizi caydırdı ve başka bir şey denememize yol açtı.

Nginx ikinci tercihti

Bu durumda kurulum daha basitti, kısaca YUM kullanılarak yapıldı:
yum install epel-release nginx nginx-mod-stream nginx-mod-mail
Bir not: SELinux'ta röleyi etkinleştirmeniz gerekiyor:
setsebool -P httpd_can_network_relay 1

Eğitim için, önceki kurstaki eğitmenle aynı eğitmeni seçerek işi garantiye aldık: Nginx Hızlı Kursu (ilk bölüm yaklaşık bir saat yirmi dakika sonra bitiyor). Eğitmen de bu uygulamaya, özellikle hem web sunucusu hem de ters proxy görevi görmesine ikna olmamış durumda: Nginx Hızlı Kursu - 1:20:10 Özet.
Rapor "Nginx yerine HAProxy'yi tercih ederim" şeklinde bitiyor, bu yüzden biz de HAProxy'yi denemeye karar verdik.

Son olarak, HAProxy'yi de denedik.

Kurulumu son derece kolay oldu, çünkü çok yaygın bir uygulama ve tüm Linux paket yöneticilerinde mevcut, örneğin: yum install haproxy

Ayrıca güvendiğimiz eğitmenimiz HAProxy Crash Course'a da danıştık .

Çalışıyor, ancak maalesef SMTP kimlik doğrulaması için uygun değil:
"haProxy'yi bu şekilde yapılandırmak mümkün değil, çünkü haproxy SMTP'yi hiç desteklemiyor."
– lukastribus, 17 Ağustos 2023 tarihinde yorum yaptı.


Ters proxy olarak çalışan standart bir SMTP sunucusu

İki haftalık test sürecinin ardından,
diğer SMTP sunucuları için ters proxy olarak standart bir SMTP sunucusu kullanmanın daha iyi olduğunu fark ettik.

Görevini yerine getiriyor, yalnızca SMTP protokolünü kullanıyor, bağlantıları doğru bir şekilde doğruluyor
ve "smarhost" işlevi aracılığıyla istekleri diğer SMTP sunucularına iletebiliyor.

Postfix'te, main.cf dosyasında,
relayhost = [smarthost_address]:port

Sendmail'de, sendmail.mc dosyasında,
`SMART_HOST',`mail.example.com'` şeklinde bir tanım bulunur.


başa dön

E-posta adresleri nasıl çıkarılır?

Bazen web sitenizden veya işletme yazılımınızdan
sipariş bilgileri veya müşteri detayları içeren verileri dışa aktarmış olabilirsiniz.
Sadece e-posta adresine ve sipariş tarihine ihtiyacınız olmuş olabilir.

Bir yöntem, tüm verileri Excel'e aktarmak, istenmeyen sütunları silmek
ve kalanları dışa aktarmaktır.

Eğer e-posta alanı aynı zamanda e-posta adresi açıklamasını da içeriyorsa, örneğin: "Dave Martin",
bu yöntem iyi sonuç vermeyebilir.

Bir görevi birden fazla kez tekrarlamanız
veya tüm adımları başka birine açıklamanız gerekiyorsa, bu zahmetli olabilir.


İstenilen verileri "regex" kullanarak çıkarın

Düzenli ifade (kısaltılmış haliyle “regex” veya “regexp”),
metinde eşleşen bir deseni belirten bir karakter dizisidir.

Çok basit bir örnek olarak, bir metin düzenleyicide iki farklı şekilde yazılmış bir kelimeyi bulmak verilebilir;
seriali[sz]e düzenli ifadesi hem "serialise" hem de "serialize" kelimeleriyle eşleşir.

Daha karmaşık bir durum ise metin içinde tanımlama için kullanılan sözdizimidir


Düzenli İfadeler (Regex) Eğitimi

Önerilen YouTube videosu:
“38 dakika harika geçti, kesinlikle değdi” :

Herhangi Bir Metin Kalıbını Nasıl Eşleştirebilirsiniz
(25. dakikadan itibaren e-posta adreslerini ayıklama sözdizimi açıklanmaktadır)

Düzenli ifadelerin kullanımı için kısa özet


RegExr çevrimiçi aracı

Düzenli ifadeler, Notepad++ veya Atom gibi gelişmiş metin düzenleyicilerinde
genellikle kabul görmektedir

Ücretsiz çevrimiçi araçlar da mevcuttur; bunlardan biri de
https://regexr.com Bu çevrimiçi hizmet, düzenli ifadeleri öğrenmek, oluşturmak ve test etmek için kullanılır.

Web arayüzü açıklaması:
“İfade” alanı, düzenli ifade sözdizimini içerir.
“Metin”, analiz etmek istediğiniz içeriktir.
“Araçlar > Liste” seçeneği, çıkarma işleminin sonuçlarını gösterecektir.


Örnek 1: Yalnızca e-posta adresini ayıklamak

İfade:
[a-zA-Z0-9._-]+@[a-zA-Z0-9._-]+\.[a-zA-Z0-9_-]+

Metin:

Dave Martin 615-555-7164 173 Main St., Springfield RI 55924 davemartin@bogusemail.com Charles Harris 800-555-5669 969 High St., Atlantis VA 34075 charlesharris@bogusemail.com Eric Williams 560-555-5153 806 1st St., Faketown AK 86847 laurawilliams@bogusemail.com

Araçlar > Liste:
$&\n

Sonuç:

davemartin@bogusemail.com charlesharris@bogusemail.com laurawilliams@bogusemail.com

Örnek 2: E-posta adresini ve tarihi çıkarmak

İfade:
","(.*?)([a-zA-Z0-9._-]+@[a-zA-Z0-9._-]+\.[a-zA-Z0-9_-]+)(.*?)",".*",(\d{2}\.\d{2}\.\d{4})

Metin:

"lorem ipsum dolor sit amet", "Robert Farrell"<rmfarrell@bogusemail.com> ","",02.01.2024, ,5379, "elit yapıların inşası""""Mesa, Rene<rmesa@bogusemail.com> "",",04.01.2024, ,20826, "sed do eiusmod tempor incididunt",Antonio Bugan<antonio@bogusemail.com> ","",04.01.2024, ,2856, "ut emek ve dolore magna aliqua","Crawley Down Tenis Kulübü<hello@bogusemail.com> ","",05.01.2024, ,4453,

Araçlar > Liste:
$2,$4\n

Sonuç:

rmfarrell@bogusemail.com, 02.01.2024 rmesa@bogusemail.com, 04.01.2024 antonio@bogusemail.com, 04.01.2024 hello@bogusemail.com, 05.01.2024

Düzenli ifadelerin kullanımı için kısa özet
. - Yeni Satır Hariç Herhangi Bir Karakter \d - Rakam (0-9) \D - Rakam Olmayan (0-9) \w - Kelime Karakteri (az, AZ, 0-9, _) \W - Kelime Karakteri Olmayan \s - Boşluk (boşluk, sekme, yeni satır) \S - Boşluk Olmayan (boşluk, sekme, yeni satır) \b - Kelime Sınırı \B - Kelime Sınırı Olmayan ^ - Dizinin Başlangıcı $ - Dizinin Sonu [] - Köşeli Parantez İçindeki Karakterlerle Eşleşir [^ ] - Köşeli Parantez İçinde Olmayan Karakterlerle Eşleşir | - Ya da ( ) - Grup Belirleyiciler: * - 0 veya Daha Fazlası + - 1 veya Daha Fazlası ? - 0 veya Bir {3} - Tam Sayı {3,4} - Sayı Aralığı (Minimum, Maksimum)

Kaynak: GitHub kod parçacıkları


başa dön

''NO-MAIL'' alan adlarını nasıl koruyabilirsiniz?

Çoğu şirket ve kamu kurumu birden fazla alan adı kaydeder.
İşletmeler genellikle kullanıcı hatalarına karşı korunmak ve markalarını güvence altına almak için birden fazla alan adı satın alırlar.
Bazen de özel görünürlüğü hak eden etkinlikleri veya projeleri tanıtmak için.

Bu sayılar, tek bir faaliyet için birkaç düzine alan adından birkaç yüze kadar değişebilir.
Büyük bir şehrin belediyesinde yaklaşık iki yüz alan adından, Ferrari ve Goldman Sachs gibi şirketlerde binlerce alan adına kadar uzanabilir .

Verisign'ın iddiasına göre, 2022 yılının sonunda 350 milyon alan adına
kayıtlı alan adlarının toplam sayısını saydığınızda, bu rakam şaşırtıcı seviyelere ulaşıyor

Bu alan adlarının çoğu "vitrin" olarak kullanılıyor. Web sitesinde e-posta adresleri listelenmiyor.
İletişim talepleri genellikle doldurulması gereken formlara veya sosyal medya kanallarına yönlendiriliyor.

NO-MAIL alan adı

Gerekli kimlik doğrulama yöntemleriyle (SPF, DKIM, DMARC, ...) e-posta gönderimlerinin yönetimi giderek daha karmaşık hale geliyor.
Bu nedenle, genellikle resmi dış iletişim için e-posta yoluyla yalnızca bir alan adı kullanılır.

Ancak, çevrimiçi varlığını koruma fikri iki ucu keskin bir kılıç olabilir.
Yanlış yapılandırılmış "tanıtım amaçlı alan adları" kötü niyetli kişiler tarafından kolayca istismar edilebilir.

Sıklıkla gönderenin tanınmış adını kötüye kullanarak alıcıların güvenini kazanır ve
gizli bilgileri veya bağlantıları ve ekleri ifşa eden eylemler talep ederler.

Alıcılar, sistemlerinin güvenliğinin tehlikeye girmesi ve
dijital suçlu çetelerinin dışarıdan erişim sağlaması riskiyle karşı karşıya kalabilirler.

dmarc logosu

Yukarıda bahsedilen karmaşık kimlik doğrulama sistemlerinin de olumlu yönleri vardır.
yetkisiz kişilerin veya kuruluşların göndericilerimizle e-posta göndermesini engellemek için
sahte e-postalara karşı işlem yapmak üzere tasarlanmıştır

Hızlı bir kurulumla, belirli bir alan adının kullanımda olmadığını belirtebilir ve
alıcıları bu alan adından gelen e-postaları reddetmeleri konusunda uyarabilirsiniz. Bunun için
alan adı DNS'sine bu belirtiyi içeren bir kayıt (tek satır) eklemeniz yeterlidir:

_dmarc.yourdomain.com. TXT "v=DMARC1; p=reject"

geri dönen posta

Bu kuralın uygulanıp uygulanmayacağı, mesajları alan sisteme bağlıdır.
Mart 2015'ten beri onaylanmış bir IETF standardıdır.
Çoğu çevrimiçi e-posta hizmeti, kullanıcılarını korumak için bunu uygulamaktadır.

“NO-MAIL” alan adlarından gelen mesajlar otomatik olarak geri çevrilecektir.

Bu sayede, şirketinizin kötüye kullanımdan korunmasının yanı sıra,
artık gönderme yetkisi olmayan veya kimliği doğrulanmamış "eski" alan adlarının yanlışlıkla kullanılmasını da önlemiş olursunuz.

İşletmeler neden SMS kullanıyor?

Sorun: okunmamış e-postalar, cevapsız telefon görüşmeleri.

E-posta gelen kutusu, tüketicinin dikkatini çekmek için yapılan yoğun rekabetle dolu;
bu da işletmelerin müşterileri ve potansiyel müşterileri tarafından fark edilmesini çok daha zorlaştırıyor.

Birine önemli bir e-postayı okutmak (hatta telefonla görüşmeye ikna etmek)
giderek daha zor hale geliyor.

Müşterileriniz neden artık e-postalarınızı okumuyor?

Tüketicilerin %48'inin gelen kutusunda 50'den fazla okunmamış mesaj bulunuyor.
Çoğu tüketici okunmamış mesajları ayıklamaktan kaçınıyor, bu nedenle e-postalar birikmeye devam ediyor.
– Kaynak: ZipWhip Müşterileriniz Artık E-postalarınızı Neden Okumuyor (pdf 15 MB)

Bazı güncellemeler acil ve kritik olabilir. Bunları e-posta yoluyla iletmek,
mesajın okunmaması veya spam klasörüne düşmesi riskini beraberinde getirir.

"Kaç tane e-posta hesabınız var?" sorusuna katılımcıların %77'si "iki veya daha fazla" yanıtını verdi.
Genellikle akıllı telefonda yalnızca bir tanesi yapılandırılmış durumda.

Müşterileriniz neden artık telefonlara cevap vermiyor?

Müşterileri arayıp cevap alamamak
veya çağrının telesekretere yönlendirilmesi
giderek daha yaygın bir durum haline geliyor.

Tüketicilerin %97'si işletmelerden ve bilinmeyen numaralardan gelen aramaları görmezden geldiklerini itiraf ediyor.
– Kaynak: ZipWhip Müşterileriniz Artık Neden Telefonlarına Cevap Vermiyor? (pdf 15 MB)

Çözüm: bana mesaj at.

Covid-19, elektronik cihaz kullanımını artırdı;
görüşülen kişilerin %64'ü "Telefonumda daha fazla zaman geçiriyorum" dedi.

2021'de mesajlaşmanın durumu

Tüketicilerin %58'i, işletmelerin kendilerine hızlı bir şekilde ulaşmasının en etkili yolunun kısa mesaj olduğunu söylüyor.
– Kaynak: ZipWhip Kısa Mesajlaşma Durumu 2021 (pdf 21 MB)

Kayıt için genellikle e-posta adresinin gerekli olduğu e-ticaret sektöründe bile,
Amazon da dahil olmak üzere bazı büyük şirketler cep telefonu numarasıyla kayıt olma imkanı sunmaktadır.

Açıklama: Mesajlaşmanın beş iyi nedeni
  1. Anında iletişim sağlar.
    Kısa mesajlar neredeyse her zaman, genellikle alındıktan saniyeler sonra okunur.
    Açılma oranları %95 eşiğini aşmaktadır (bu %95'in %90'ı, mesaj gönderildikten sonraki üç dakika içinde gerçekleşir).
    SMS mesajları kısa ve özlüdür, iletişim esastır ve anında gerçekleşir.

  2. Çok basit.
    Alıcılarına ulaşmak için internet bağlantısına ihtiyaç duymuyorlar.
    Markanızın teknolojiye aşina olmayan demografik gruplara ulaşmasını sağlıyor.
    Kullanımı video içeriğine benziyor (hızlı, anlık, 160 karakterle ifade edilebilir).

  3. Her yerde bulunan
    SMS, yeni uygulama yüklemeye gerek kalmadan gezegendeki her cep telefonuyla uyumludur.
    Akıllı telefon (veya eski nesil cep telefonu) tıpkı cüzdan ve ev anahtarları gibi her zaman sahibinin yanındadır.
    Müşteriyle nerede olursa olsun, güvenilir bir kanal aracılığıyla etkileşim kurma imkanı sağlar.

  4. Ucuz
    SMS mesajlarının gönderim maliyeti düşüktür.
    Gönderilen mesajların ortalama uzunluğu 155 karakteri geçmez (tek bir mesaj için sınır 160 karakterdir).
    Telefon görüşmeleri veya e-postalarla birlikte SMS kullanmak, müşterilerle iletişim kurarken zamandan tasarruf sağlayabilir.

  5. Etkileşimli bir iletişim biçimidir.
    İletişim, "zorlama" veya "stres" içermeyen, "yükten arındırılmış" bir kanal üzerinden gerçekleşir.
    SMS'ler daha yüksek öneme sahiptir, açılma ve okunma olasılığı daha yüksektir. Ayrıca yanıtlanma olasılıkları da daha yüksektir.
    Kısa mesaj dili basittir ve etkileşimi teşvik eder. Yanıt oranları %45'e kadar çıkmaktadır.

Geri dönen e-postalarla nasıl başa çıkılır?

"Geri dönen e-postalar" veya kısaca "geri dönen e-postalar" , bir posta aktarım aracısı (MTA) tarafından gönderene otomatik olarak gönderilen ve
mesajın alıcı tarafından doğru şekilde alınmadığını bildiren
e-postalardır.

Konu genellikle "İade edilen posta: ayrıntılar için transkripte bakın" şeklindedir.
Açıklayıcı hata bilgileri, yani bir kod ve açıklaması, içerikte bulunabilir.

"Durum kodu", iadeye neden olan hata türünü açıkça belirtmelidir,
ancak genellikle her e-posta servis sağlayıcısının kullandığı kodlar ve açıklamalar,
iadeyi doğru şekilde sınıflandırmak için analiz edilmeli ve yorumlanmalıdır.


Geri dönen e-postaların riskleri nelerdir?

Yanlış/aktif olmayan alıcılara e-posta göndermek "spam gönderen davranışı" olarak kabul edilir.

Onları görmezden gelemezsiniz

Listenizin geri kalanına ulaşmak istiyorsanız, listenin "kötü" kısmına göndermeyi bırakmanız en iyisidir.
Bazen buna "liste hijyeni" denir.

Onların anlamını anlamalısınız

Teslimat Durumu Bildirimi (DSN) üç türdedir: Başarılı - E-posta teslim edildi (bildirim yalnızca gönderen tarafından talep edilirse gönderilir)
Kalıcı Hata - Kalıcı bir hata oluştu
Geçici Hata - Geçici bir hata oluştu

Kalıcı (durum kodu 5.XXX.XXX): E-posta adresi
"550 5.1.1 … Kullanıcı bilinmiyor" veya "5.1.2 … Sunucu bilinmiyor" gibi
. Kalıcı bir hata, o alıcıya bir daha asla e-posta göndermemeniz gerektiğini gösterir.
Tek bir geri dönen mesaj, e-posta adresinin engellenmesini tetiklemelidir.

Geçici hata (durum kodu 4.XXX.XXX): E-posta adresi
"452 4.2.2 … Posta kutusu dolu" gibi
. Geçici bir hata, gelecekte teslimatı tekrar deneyebileceğinizi gösterir.
Birbirinden birkaç gün içinde en az üç geri dönen mesaj, e-posta adresinin engellenmesini tetiklemelidir.

Sıçrama işleme mekanizmasının nasıl çalıştığını (ve nasıl ince ayar yapılacağını) bilmelisiniz
  • Geri dönen tüm mesajlar bir uygulama tarafından indirilir ve
    uygulama arayüzü veya JSON dosyası aracılığıyla insan incelemesine sunulur.

    sert sıçrama
  • Sınıflandırma, düzenlenebilen bazı kurallara tabidir

    sert sıçrama kategorileri
  • Seçenekler, yumuşak sekme hareketlerinin ne zaman sert sekme hareketine "yükseltileceğini" tanımlar

    sıçrama seçenekleri

» başa dön


Sıçrama sayısını kontrol edin

Bazen hem gönderici hem de alıcı tarafındaki bir yapılandırma hatası,
geçici veya kalıcı bir geri dönüşe neden olabilir.

İyi bir alışkanlık, geçen haftadaki geri dönen mesaj sayısını kontrol ederek
değerlerin öncekiyle aynı olup olmadığını veya herhangi bir anormallik olup olmadığını görmektir.
Bir sorun varsa, bunu hemen fark edersiniz. Geri dönen mesajların ayrıntılarını okumak, sorunun nedenini bulmanıza yardımcı olacaktır.

Bazı sistemler, bir abonenin yanıt vermeme bilgilerinin silineceği
gün sayısını (örneğin 180) belirlemenize olanak tanır
Bu şekilde, SMTP sunucusu söz konusu alıcıyla tekrar iletişime geçmeyi deneyecektir.

Yanlışlıkla etkinleştirilen bloklar otomatik olarak temizlenecektir,
ancak SMTP sunucusunun itibarı zarar görebilir.

» başa dön


Tek cümleyle özetlemek gerekirse: önlem almak tedavi etmekten daha iyidir.

e-posta gönderme süreci

SMTP sunucularının itibarının zedelenmesini önlemek için,
giderek daha fazla E-posta Servis Sağlayıcısı (ESP), bir " e-posta engelleme listesi "
mesajlar alıcının posta kutusuna ulaşmadan önce devreye giren kullanmaktadır .

Herhangi bir müşteri, kalıcı bir geri dönüşe neden olan bir e-posta gönderdiğinde,
geri dönüşe neden olan e-posta adresi engelleme listesine eklenir.

Engelleme listesi tüm müşteriler için geçerlidir. Başka bir deyişle,
farklı bir müşteri engelleme listesinde bulunan bir adrese e-posta göndermeye çalışırsa,
SMTP sunucusu e-postayı göndermez çünkü e-posta adresi engellenmiştir.

Özel IP adresine sahip SMTP sunucuları kullanmak, itibar paylaşımıyla ilgili bazı sorunlardan kaçınmanızı sağlayabilir.
Örneğin, "e-posta engelleme listesi" yalnızca sizin IP adresinizle sınırlı olabilir;
böylece başka bir müşteri SMTP sunucusunun kara listeye alınmasına ve ilgili geri dönüşlere neden olsa bile,
e-postalarınız etkilenmez.

» başa dön


Geri dönen mesajların durum kodları

Kalıcı ve geçici geri dönüşleri tanımlamak için kullanılan durum kodlarının sözdizimi şu şekildedir:
durum-kodu = sınıf “.” konu “.” detay

Durum kodları, "." ile ayrılmış üç sayısal alandan oluşur

  • İlk alt kod (sınıf), dağıtım girişiminin başarılı olup olmadığını gösterir
  • İkinci alt kod (konu), herhangi bir teslimat anormalliğinin muhtemel kaynağını gösterir
  • Üçüncü alt kod (detay), belirli bir hata durumunu gösterir

Alt kod (sınıf), durumun genel bir sınıflandırmasını sağlar.
Her sınıf için listelenen değerler, RFC 3463 ve RFC 6522'de:

2.XXX.XXX Başarılı (Gönderici tarafından talep edilmedikçe gönderilmez) Başarılı, DSN'nin olumlu bir teslimat eylemi bildirdiğini belirtir. Ayrıntı alt kodları, teslimat için gerekli dönüşümler hakkında bildirim sağlayabilir. 4.XXX.XXX Kalıcı Geçici Hata Kalıcı geçici hata, gönderilen mesajın geçerli olduğu, ancak bazı geçici koşulların devam etmesinin mesajı gönderme girişimlerinin terk edilmesine veya gecikmesine neden olduğu bir hatadır. Bu kod bir teslimat hatası raporuna eşlik ediyorsa, gelecekteki gönderimler başarılı olabilir. 5.XXX.XXX Kalıcı Hata Kalıcı hata, mesajın mevcut haliyle yeniden gönderilmesiyle çözülmesi muhtemel olmayan bir hatadır. Başarılı teslimat için mesajda veya hedefte bazı değişiklikler yapılmalıdır.

İşte bazı kod ve açıklama örnekleri:

2.0.0: Gönderildi (Mesaj teslim için kabul edildi) 4.2.2: Kota aşıldı 4.4.5: Yetersiz disk alanı 5.0.0: Geçersiz alan adı 5.1.1: Kullanıcı bilinmiyor 5.7.1: Mesaj içeriği reddedildi

» başa dön

SMTP'min güvenli olup olmadığını nasıl kontrol edebilirim?

2020'lerde fidye yazılımı saldırılarının artmasıyla birlikte
, internetteki ana iletişim kanalımız olan e-posta güvenli mi?

SMTP sunucuları özellikle hassas bir altyapıdır.
Bizim adımıza e-posta mesajlarını yayabilirler ve
gönderen sunucu tarafından doğru şekilde kimlik doğrulamasından geçtikleri için bu mesajları
güvenilir göndericilerden gelmiş gibi kabul ederler

SMTP sunucuları özellikle hassas bir altyapıdır.
Bizim adımıza e-posta mesajlarını yayarlar ve karşı taraflar bu mesajları,
gönderenin SMTP sunucusu tarafından doğru şekilde kimlik doğrulamasından geçirilmiş oldukları için
güvenilir göndericilerden geldiğini kabul ederler

Başka biri SMTP sunucunuzu kullanırsa ne olur?
SMTP sunucumun güvenli olup olmadığını nasıl kontrol edebilirim?


İnternette hassas altyapıların kullanımı,
kötüye kullanımı önlemek için yüksek düzeyde koruma gerektirir.

Kritik güvenlik uyarısı

smtp.gmail.com üzerinden mesaj göndermeye çalışırsanız
engelleneceksiniz ve şu "Kritik güvenlik uyarısı"nı alacaksınız:

Daha az güvenli uygulama engellendi. Google, kullanmaya çalıştığınız uygulamayı güvenlik standartlarımızı karşılamadığı için engelledi. [...]

Tek alternatif, parola verilerini paylaşmayan
, bunun yerine kimliği doğrulamak için yetkilendirme belirteçleri kullanan bir protokol olan OAuth2'yi kullanmaktır.


İnternette en çok kullanılan e-posta sunucuları (Ağustos 2021 verileri):
Exim (%58), Postfix (%35), Sendmail (%4)

Siber saldırılara karşı riski azaltarak
kendi posta sunucunuzu kullanmaya devam etmek için kontrol etmeniz gereken minimum gereksinimler şunlardır:

  1. Yalnızca güvenli kimlik doğrulama kabul edilir;
    kullanıcı adı ve parola güvenli bağlantılar üzerinden iletilmelidir,
    genellikle port 587+TLS veya port 25+TLS veya port 465+SSL
    düz metin hassas veri iletişimi devre dışı bırakılır.

  2. "Gönderen" adresinde (posta gönderen) bir kontrol olması gerekiyor;
    yalnızca yetkilendirdiğiniz kişiler geçebilecek.

  3. Fail2ban'ı , koruma önlemlerinizi zorlamaya yönelik
    tüm dış saldırıları engelleyecek şekilde yapılandırın
    Özellikle Fail2ban, tekrarlanan tüm saldırı girişimlerini engellemelidir:

  • yanlış kullanıcı adı veya şifreyle giriş yapmak
  • yetkisiz bir göndericiyle e-posta göndermek
  • Kimlik doğrulama işlemi sırasında SMTP bağlantısını kesmek
    (birden fazla bağlantının kesilmesi, SMTP hizmetini meşru kullanıcılar için kullanılamaz hale getirir)

Engelleme genellikle üç ila on deneme arasında gerçekleşir
ve kaynak IP adresini üç ila yirmi dört saat süreyle engeller.

Bu noktaları test etmek ve SMTP altyapınızın güvenlik yükseltmesine ihtiyaç duyup
duymadığına karar vermek oldukça kolaydır


Fail2ban, sunucunuzu BruteForce/DDOS saldırılarına karşı korur.
Tıpkı bir yabancının kapıyı çalması gibi çalışır;
belirli sayıda vuruştan sonra kapı kaybolur.

Fail2ban logosu

Hacker News'ten bir tanıklık :

Birkaç yıldır kendi posta sunucumu yönetiyorum ve sanırım buradaki birçok kişi Mail-in-a-box, mailcow, Mailu vb. çözümler kullanıyor. Korona'ya kadar posta sunucumla ilgili büyük sorunlarım yoktu, ancak son haftalarda çok büyük bir gelen trafik aldım - bu sunucum için çok fazlaydı ve her seferinde manuel olarak yeniden başlatmak zorunda kaldım... [...] Düzenleme: Fail2ban ayarlarımı değiştirdim ve öncelikle kaba kuvvet saldırılarının hedefi olduğumu fark ettim, bunlara karşı fail2ban gibi araçlarla korunabileceğimi anladım

Fail2ban , otomatik bir saldırının belirtilerini aramak için
sistem günlüklerini izleyen bir günlük ayrıştırma uygulamasıdır

Bir saldırı girişimi tespit edildiğinde, tanımlanmış parametreler kullanılarak Fail2ban,
saldırganın IP adresini belirli bir süre veya kalıcı olarak engellemek için
güvenlik duvarına (iptables veya firewalld) yeni bir kural ekler
Fail2ban ayrıca, bir saldırı gerçekleştiği konusunda sizi e-posta yoluyla da uyarabilir.

Fail2ban öncelikle SSH saldırılarına odaklanmıştır, ancak log dosyaları kullanan ve güvenlik açığına maruz kalabilecek herhangi bir hizmet için de çalışacak şekilde
yapılandırılabilir

Yaygın olarak kullanılmaktadır. Google'da arama yaparak,
posta sunucularını korumaya yönelik yapılandırma örneklerini bulmak kolaydır.

E-posta göndermek için DNS ayarları

E-posta göndermek için hangi alan adı DNS ayarları gereklidir?

E-posta servis sağlayıcıları genellikle SMTP sunucularını kullanmadan önce
gönderenin alan adını doğrulamanızı ister . Bunun iki nedeni vardır:

  1. alan adı sahipliğini kanıtlayın
    ; bu, gönderenin alan adını kontrol ettiğinizi ve
    başkasının alan adını kullanmadığınızı (sahtekarlık yapmadığınızı)

  2. SPF ve DKIM kimlik doğrulamasını ayarlayarak kimliği doğrulanmış e-postalar gönderdiğinizde
    alan adınız ve SMTP sağlayıcınız iyi bir itibara sahipse,
    mesajlarınız
    alıcılar tarafından "gerçek" bir göndericiden geliyormuş gibi algılanır ve
    mesajlar alıcıların gelen kutusuna ulaşır.

Özet:

E-posta servis sağlayıcıları: Doğrulanmış göndericiler için gereksinimler

Aşağıda, alfabetik sırayla kontrol ettiğimiz başlıca sağlayıcılardan bazıları yer almaktadır.
Temmuz 2021 sonunda, e-posta göndermeye başlamak için gereken temel ayarları test ettik.
Doğrulanan alan adı “emailperfect.com” idi. 2012 yılında tescil edilmişti ve daha önce hiç e-posta göndermek için kullanılmamıştı.

Sağlayıcı adı DKIM “From”
etki alanı hizalaması
SPF “Mail-From”
alan adı hizalaması
Notlar
Amazon SES evet (3 CNAME kaydı) HAYIR (@amazonses.com)
Posta tabancası evet (TXT kaydı) evet (TXT kaydı) Hotmail ve Yahoo teslimat kontrolü*
Posta uçağı evet (TXT kaydı) HAYIR (@mailjet.com) Hotmail ve Yahoo teslimat kontrolü*
RealSender Evet (2 CNAME kaydı) evet (TXT kaydı) özel IP adresi
Sendgrid Evet (2 CNAME kaydı) evet (CNAME kaydı) Hotmail teslimat kontrolü*
Sendinblue HAYIR (sendinblue.com) HAYIR (@aa.d.sender-sib.com) Gönderici doğrulaması gerekmiyor
Smtp2go evet (1 CNAME kaydı) evet (CNAME kaydı)

* = Aşağıdaki posta kutularının her birine bir mesaj gönderdik ve tekrar kontrol etmemizi gerektiren bir şey olup olmadığını not ettik:
Gmail, Hotmail, Yahoo, Gmx, Aruba, Tiscali, Exchange Online

Doğrulanmış bir gönderici neden bu kadar önemli?

2021 yılında, gönderenin alan adının doğrulanmasını zorunlu görüyoruz;
böylece alıcı, gönderenin e-posta adresinin sahte olmadığını anlayabilir.
Önleyici kimlik doğrulama kontrolü, gönderim sistemlerinin kötüye kullanılma riskini de büyük ölçüde azaltır.

Bu nedenle listeden bir sağlayıcıyı "sildik":
Mesaj göndermelerine izin vermeden önce alan adı doğrulamasını gerektirmiyor.

Alan hizalaması nedir?

Mesaj gönderirken iki alanla ilgileniyoruz:

  1. Gönderenin "Gönderen" adresinde, alıcılar tarafından görülebilen bilgi yer almaktadır
  2. Gönderen adresi (aynı zamanda "zarf gönderen" veya "geri dönüş yolu" olarak da adlandırılır)
    gizlidir ve geri dönen e-postaları almak için doğrudan ESP tarafından yönetilir.

“Alan adı uyumu” gerekliliği şu cümlede özetlenmiştir:
“Gönderici, e-postasını SPF ve/veya DKIM kullanarak doğruladığında,
alan adlarından en az birinin gönderen alan adıyla uyumlu olması gerekir.”

CNAME kaydı mı yoksa TXT kaydı mı daha iyi?

DKIM kimlik doğrulaması için CNAME kaydı uygulamak daha kolaydır.
Aynı sonuç 2048 bitlik bir TXT kaydı eklenerek de elde edilebilir, ancak bu daha karmaşıktır.
Ayrıca, DKIM kaydının CNAME aracılığıyla devredilmesi, sağlayıcınızın
güvenlik nedenleriyle gerektiğinde anahtarını değiştirmesine olanak tanır.

CNAME kaydı kullanarak SPF kimlik doğrulaması yapmak, Mail-From adresinin
e-posta servis sağlayıcınız tarafından yönetilen bir alt alan adı olacağı anlamına gelir; örneğin: bounce.your-company-name.org.
Sağlayıcı hem SPF kimlik doğrulamasını hem de geri dönen mesajları ele alacaktır.

Zimbra veya Exchange gibi,
her göndericinin geri dönen mesajları doğrudan aldığı e-posta sunucularında SPF kimlik doğrulaması için TXT kaydı en iyi seçenektir.
Alan adı kimlik doğrulaması için yalnızca bir TXT kaydı bulunur ve
birden fazla SMTP sunucusu yönetiyorsanız bunu sürdürmek zor olabilir.

Özel IP adresi nedir?

"İnternet Protokol adresi" veya "IP adresi",
ev telefonunuzdaki veya mobil cihazınızdaki telefon numarasına benzer.

Çoğu SMTP hizmeti, müşterilerine "paylaşımlı" IP adresleri sağlar.
Her e-posta gönderildiğinde farklı bir IP adresi atanır.

“Özel IP adresi”, e-posta gönderdiğiniz IP adresinin zaman içinde değişmeyeceği anlamına gelir.
Bu, gönderenin itibarını başkalarının kullanımıyla zarar görmeyecek şekilde kontrol etme olanağı sağlar.

Şirketin alan adı DNS ayarlarını doğrudan biz mi yönetmeliyiz?

Mutlaka öyle değil, çünkü bazı teknik beceriler gerektiriyor.

Şirket yönetimi, DNS ayarlarında yapılacak birkaç değişikliğin
aşağıdaki gibi ciddi sonuçlara yol açabileceğinin farkında olmalıdır:

  • web sitesi ziyaretçilerini başka bir web sunucusuna yönlendirmek
  • Gelen mesajları farklı bir posta sunucusuna yönlendirin
  • E-posta kimlik doğrulamasını bozarak mesajların spam olarak algılanmasına veya reddedilmesine neden olun

» başa dön

E-posta listeleri nasıl yönetilir?

Posta listelerini öngörüyle nasıl yönetirsiniz?

  1. Öncelikle: neden bir e-posta listesi yöneticisi kullanmalısınız?
    CRM sistemleri (Salesforce ve Microsoft CRM gibi)
    ve kurumsal e-postalar (Office 365 ve Google Apps Gmail gibi)
    toplu e-posta gönderimi için uygun değildir.
    Bunlar bire bir iletişim için oluşturulmuştur.
    Genellikle kötüye kullanımı önlemek için günlük gönderim limitleri koyarlar.
    Birçok şirket, iletişim kurduğu kişilerin çoğuna veya belirli gruplara e-posta göndermek zorundadır.
    büyük miktarda mesajı işleyebilen ve otomatik abonelik iptali yapabilen
    özel sistemlerle yönetilmelidir


  2. İkinci adım: Bu çözümleri nerede arayacağız?

    Kolay cevap, "SaaS" - Hizmet Olarak Yazılım - tekliflerine bakmaktır
    (Mailchimp en ünlü sistemdir, Inxmail daha az bilinir ve büyük şirketler tarafından kullanılır).

    Yerel kurulum ile bulut hizmetleri arasında her zaman önemli bir seçim vardır.
    Bizim görüşümüz, yerel seçeneğin "e-posta kontrolünü yeniden kazanmaya" yardımcı olduğudur ki bunu savunuyoruz.

    Bulutta kendi kendine barındırılan bir uygulama kullanmaya karar verseniz bile,
    bu, aynı çözümü korurken tedarikçiyi kolayca değiştirmenize olanak tanır.

  3. Bahsetmeye değer üç çözüm şunlardır:

  • Sendy olgunlaşmış ancak "kapalı kaynak kodlu" ve ücretli bir yazılımdır.

  • Listmonk açık kaynaklı bir projedir. 1. sürümü 2021 yılında yayınlanmıştır. Go dilinde geliştirilmiştir,
    bağımsız bir ikili dosya olarak gelir ve tek bağımlılığı Postgres veritabanıdır. GitHub'da 5.4k yıldıza sahiptir.

  • Mailtrain de açık kaynaklıdır. İlk sürümü 2016'da, 2. sürümü ise 2021'de yayınlandı.
    MySQL veritabanı kullanıyor. GitHub'da 4.800 yıldızı var.

Temiz bir arayüz, liste odaklı bir çözüm, bakımı kolay ve sorun olması durumunda kolayca geri yüklenebilen bir araç arayışındaydık ve
Listmonk'u en iyi seçenek olarak değerlendirdik.

Listmonk, kendi sunucunuzda barındırabileceğiniz, yüksek performanslı bir e-posta listesi ve haber bülteni yöneticisidir. Bağımsız bir ikili dosya olarak gelir ve tek bağımlılığı Postgres veritabanıdır.

listmonk kontrol paneli


Başvuru sürecinin ilk adımları

Bu, Hacker News'te yayınlanan orijinal duyurudur:

knadh, 12 Temmuz 2019 [–] Yazar burada. Listmonk'un neden geliştirildiğine dair biraz bağlam vermek gerekirse, iş yerinde (düzenlenmiş bir finans şirketi) 1,5 milyondan fazla müşteriye düzenli olarak e-posta, çoğunlukla önemli güncellemeler göndermemiz gerekiyor. Uzun süre phpList kullandık, ardından MailTrain ve Sendy'yi denedik ve sonunda bir dizi sorunla karşılaştıktan sonra tekerleği yeniden icat etmeye karar verdik. Bunlardan birkaç önemli olanı aşağıda belirtilmiştir: - Performans. E-posta göndermek için makul olmayan derecede uzun süreler gerekiyordu. phpList, bir kampanyayı işlemek için birkaç gün sürecek kadar kötüleşti. Listmonk, N adet goroutine (~iş parçacığı) oluşturabilir ve e-postaları birden fazla SMTP sunucusuna gönderebilir. Sıradan bir EC2 örneğinde, birkaç saat içinde 1,5 milyondan fazla e-posta gönderebiliyoruz. - Abone içe aktarma işlemleri son derece yavaştı. Aboneleri harici CRM'lerle senkronize tutmak için doğrudan entegrasyon zahmetliydi. Karmaşık tablo yapıları nedeniyle doğrudan veritabanına veri ekleme işlemleri zordu. listmonk, saniyede 10.000 kaydı sıradan bir EC2 örneğindeki Postgres veritabanına aktarıyor. - Bölümleme. Genellikle, kullanıcıları özel özniteliklere ve koşullara göre hızlı bir şekilde bölümlendirmemiz ve onlara bir güncelleme iletmemiz gerekiyor. listmonk, rastgele JSON haritaları olarak tanımlanan özniteliklerine göre kullanıcıları bölümlendirmek için SQL ifadelerini destekliyor (Postgres JSONB türü sayesinde). - Dinamik şablonların bulunmaması. listmonk şablonları Go şablon ifadelerini desteklediğinden, mesajlarda mantık yazarak onları dinamik hale getirmek mümkün.

Kailash Nadh, FOSS (Özgür ve Açık Kaynak Yazılım) alanında oldukça aktif bir geliştiricidir.
Hindistan'ın en büyük borsa aracı kurumu olan Zerodha'da çalışmaktadır
Zerodha'nın teknik personelinin blogu zerodha.tech adresinde yayınlanmaktadır .


Ayrıntılar

Listmonk, standart kullanım (web arayüzü aracılığıyla) ve geliştiriciler (API aracılığıyla) için iyi bir şekilde belgelendirilmiştir

listmonk Belgelemesi

Bu çözüm, büyük listeler (milyonlarca aboneye kadar) ve küçük gruplar için de uygundur.
Abone sorgulama ve segmentasyon özelliği sayesinde ,
abonelerin profillerine ve özelliklerine göre bir seçimi sorgulayabilir ve dışa aktarabilirsiniz.
Çıkarılan veriler, yeni bir hedefli e-posta listesine kolayca aktarılabilir.

E-posta geri dönüş işlemleri gibi bazı önemli özelliklerden yoksun.
Ancak bir sonraki büyük sürümde mevcut olması bekleniyor:
Geri dönüş işlemleri #166
Geri dönüş işlemleri ekran görüntüsü önizlemesi


Teknik hususlar

Daha önce başka bir Go uygulaması kullanmıştık: RealSender - DMARC RAPORLARI.
Kaynak: dmarc-report-converter. Hiçbir sorun yaşanmadan hemen çalıştı.

"Yirmi yılı aşkın bir geliştirme geçmişine sahip PostgreSQL veritabanı yönetim sistemi, şu anda dünyanın herhangi bir yerinde bulunan en gelişmiş açık kaynaklı veritabanıdır." -- PostgreSQL'in Kısa Tarihi - https://www.postgresql.org/docs/9.3/history.html

Geçmişte Inxmail Professional sunucu kurulumuyla çalışırken bu konuda biraz deneyimimiz oldu.
2017'de Inxmail GmbH, diğer tüm veritabanlarını bırakarak yalnızca PostgreSQL'i destekleyeceğini duyurdu:

1 Ocak 2019'dan itibaren, en uygun teknik altyapıya odaklanacağız ve Windows sunucuları ile MySQL, Oracle ve MS SQL Server veritabanlarına desteği sonlandıracağız. Bu, yalnızca Linux sunucuları ve PostgreSQL tabanlı Inxmail Professional için destek sunacağımız anlamına gelir. -- Inxmail Professional lisans çözümü: Sistem desteğimizdeki değişiklikler https://www.inxmail.de/files/files/de/downloads/Inxmail-Professional-licence-solution-EN.pdf

Yeni başlayanlar için kesinlikle iyi bir seçim ve değerli bilgiye yapılan bir yatırım.
Udemy çevrimiçi kursları, PostgreSQL'in ilk kurulumu ve bakımı konusunda yardımcı olabilir.

Açık kaynak yazılımın riskleri var: 2019'da başlatılan yeni bir proje gelecekte de sürdürülecek mi?
Kimse bilmiyor, belki en kötü ihtimalle başka bir geliştirici ilgilenir, ama:

  • Özellikleri itibariyle temel bir unsur gibi görünüyor; çok karmaşık olursa bakımı zorlaşır
  • Listmonk için bir hata raporu gönderdik ve geliştiriciden iki saat içinde yanıt aldık.
  • Yazar, bu yazılımı şirket içinde kullanan büyük bir şirkette çalışmaktadır

E-posta teslim edilebilirliği

E-posta Teslim Edilebilirliği, Soru ve Cevap:

hemancuso 12 Temmuz 2019'da şunları yazdı: [–] Bu tür projeler harika bir fikir gibi görünüyor, ancak teslim edilebilirlik, yeterli deneyime sahip olmadığınız sürece ölçülmesi zor olan büyük bir endişe kaynağı gibi görünüyor. Bu tür bir proje kullanacaksanız ve makul bir teslim edilebilirlik sağlamak istiyorsanız, bir ESP kullanmak/seçmek için en iyi uygulamalar nelerdir? knadh 12 Temmuz 2019'da şunları yazdı: [–] Yazar olarak şunu söyleyebilirim: Şirketimizde (düzenlemeye tabi finansal işletme) 6 aydan fazla bir süredir düzenleyici olanlar da dahil olmak üzere e-posta güncellemeleri göndermek için Listmonk'u üretim ortamında kullanıyoruz. EC2 örneklerinde Postal kullanarak kendi SMTP örneklerimizi barındırıyoruz ve teslim edilebilirlik konusunda hiçbir sorun yaşamadık. Eğer meşru bir e-posta ise, bunun büyük bir sorun olduğunu düşünmüyorum.

Müşterilere beklenen iletişimlerin gönderilmesinin çoğu teslimat sorununu önlemeye yardımcı olacağı konusunda hemfikiriz.
Deneyimlerimize göre, sayı ne kadar büyük olursa, sorunların ortaya çıkma olasılığı da o kadar artar.
AWS EC2 sunucuları genellikle Gmail'de kara listeye alınır; gönderilen tüm mesajlar Spam klasörüne gider.

RealSender , özel IP SMTP sunucuları sunmaktadır
güvenilir ve sürekli olarak izlenen bir ortamda çalışan


İsim hakkında

liste keşişi logosu

goberoi 13 Temmuz 2019'da [–] Tamamen alakasız bir soru: ismi nasıl seçtiniz? knadh 13 Temmuz 2019'da [–] Tam olarak hatırlayamıyorum ama sanırım düşünce süreci "sorunsuz, huzurlu liste yönetimi" şeklindeydi.

Deneyelim

Docker imajını kullanarak dakikalar içinde çalışan bir demo kurulumu elde edebilirsiniz .
Alternatif olarak, RealSender'dan bir listmonk demo hesabı isteyebilirsiniz .

» başa dön

Haber bültenleri nasıl gönderilir?

Kara listeye alındıktan sonra, büyük bir spam önleme hizmetinin müşteri desteği genellikle şu yanıtı verir:
"Lütfen alıcıların e-postalarınıza ilgi duymasını sağlamak için listenizin temizliğini denetleyin."

“Liste hijyeni” ve “alıcıların ilgisi” birçok yönü olan kavramlardır:

A - MAKİNE tarafında - "hijyen listesi"

  1. İyi yönetilen abonelik ve abonelik iptallerinde,
    abonenin e-posta adresini doğrulaması (çift onaylı kayıt) gerekir;
    alıcılar kolayca ve güvenle abonelikten çıkabilmelidir (aboneliği iptal etme).

  2. Yalnızca "aktif" ve tamamen etkileşimli alıcılara gönderin,
    geçersiz/posta kutusu dolu alıcılara tekrar tekrar göndermeyin
    , etkileşimde bulunmayan alıcılara göndermeyi bırakın; bu, ilgilerinin olmadığına dair açık bir sinyaldir.

  3. İçerik, birden fazla cihazda okunabilir olması için iyi bir şekilde sayfalandırılmalı (tek bir resim olmamalı) ve "duyarlı" olmalıdır;
    aksi takdirde, spam filtreleri mesaj alıcının gelen kutusuna ulaşmadan önce engelleyebilir.

  4. Makinelerin
    e-postayı kimin gönderdiğini tanımasını sağlayın. Kimlik doğrulama, hedef posta sunucularının mesajların güvenilir göndericiler tarafından gönderildiğini belirlemesine olanak tanır.

B - İNSAN tarafında - "alıcının çıkarı"

  1. Aboneler aldıkları içeriği beklemeli,
    alıcılar ise mesajınızı dört gözle beklemeli ve takdir etmelidir.

  2. Kullanıcı yanıtları yönetilmelidir;
    bazen bir şeyler ters gider veya bazı alıcılar sizinle iletişim kurmak isteyebilir,
    belki de sadece artık mesaj almak istemediğini söylemek isteyebilir, abonelikten çıkma bağlantısı olsa bile.


MAKİNE tarafı - “hijyen listesi”

Yukarıda listelenen noktalar, birkaç yüz alıcı içeren küçük listeler için kolayca yönetilebilir.
Genellikle gönderen kişi, alıcıları bireysel olarak tanır, çünkü bunlar müşterileri veya bir derneğin üyeleridir.

Liste büyüdükçe, binlerce alıcı olduğunda
ve posta gönderimi üzerinde çalışan daha fazla kişi olduğunda işler karmaşıklaşır.
Bu durumda profesyonel araçlar kullanmak zorunludur.

İnternette e-posta pazarlaması için birçok profesyonel çözüm bulunmaktadır;
uluslararası alanda en bilineni MailChimp'tir
MailChimp alternatiflerini de listelemektedir .

EmailTrends'in misyonu "e-posta kontrolünü geri almak"tır;
bu nedenle alternatif bir yol öneriyoruz.

W3Techs'e göre, WordPress internetteki tüm web sitelerinin %40'ına güç veriyor
ve açık kaynak kodlu teknolojiler arasında internetteki en popüler teknoloji konumunda

WordPress MailPoet

200.000'den fazla aktif kurulumuyla Mailpoet
e-posta bültenleri için en çok kullanılan WordPress eklentilerinden biridir .

MailPoet açık kaynaklı bir yazılımdır ve 2020 yılının sonundan itibaren
Wordpress'in ana şirketi olan Automattic'e bağlı şirketler grubunun bir parçasıdır

Bazı ekran görüntüleri, çeşitli noktaların nasıl karşılandığı konusunda size bir fikir verebilir:

abonelikler ve abonelik iptalleri

Kayıt Onayı

tamamen ilgili alıcılar

Aktif olmayan abonelere gönderimi durdurun

Abone durumunu "Geri Döndürüldü" olarak değiştir

Sıçrama Kontrolü

duyarlı e-posta şablonları

Bülten Önizlemesi

Mailpoet'in "freemium" kar modeli vardır; bu modelde "Sadece Premium'u istiyorum, gönderim yapmak istemiyorum"
seçeneğini tercih edebilirsiniz

RealSender'ın özel SMTP sunucusu, "Şununla Gönder... > Diğer" seçeneği aracılığıyla yapılandırılabilir.
RealSender tarafından sağlanan bülten posta kutuları ile birlikte "Bounce Handler MailPoet" eklentisi,
gönderilen e-posta mesajlarının doğru şekilde kimlik doğrulamasını garanti edecektir.

» başa dön


İNSANİ taraf - “alıcının çıkarları”

İnsan faktörü elde edilmesi daha zor olan bir unsurdur ve
teknik yönetim mükemmel olmadığında
fark yaratan nokta da budur

yin yang

"İLGİLİ OLUN"
birkaç yıl önce e-posta pazarlamasında kullanılan bir slogandı.

Uzun süre konuştuğunuz ve yakından tanıdığınız
kişilere değerli bilgiler gönderdiğinizde
veya mesajın spam klasörüne gitmesi
önemli değildir

Teknik hataları her zaman hoş görecekler,
e-postalarınızı bekleyecek, okuyacak
ve gerekirse "spam değil" düğmesine tıklayacaklar.

» başa dön

Özel e-postalar nasıl gönderilir?

Gizli ve şifreli e-postalar nasıl gönderilir?

E-posta gizli veya güvenli değildir.
Gizlilik veya güvenlik düşünülerek tasarlanmamıştır.

İletim sırasında e-postalarınızı işleyen herkes , internet servis sağlayıcınız, bir bilgisayar korsanı veya NSA (ABD Ulusal Güvenlik Ajansı) dahil olmak üzere
, e-postalarınızı okuyabilir

Özet:

bugün neler oluyor

gözetim kurumları e-postaları okuyor

“Herhangi bir bilginin değeri, ancak onu gelecekte ortaya çıkacak başka bir şeyle
ilişkilendirebildiğinizde bilinir
Sahip olmadığınız noktaları birleştiremediğiniz için, bu bizi temelde
her şeyi toplamaya ve sonsuza dek saklamaya çalışmaya itiyor.”

“Bunun sadece meta veri olduğunu, sadece meta veri olduğunu söylediler, […]
kiminle konuştuğunuz, ne zaman konuştuğunuz, nereye seyahat ettiğiniz.
Bunların hepsi meta veri olayları.
PRISM içerikle ilgili. […] Şifrelenmemiş olduğu için hepsi görebiliyor.”

Birinin izleniyor olabileceğini bildiğinde
sergilediği davranışların çok daha uyumlu ve itaatkar olduğunu
kanıtlayan düzinelerce psikolojik çalışma var
[…] Kitlesel gözetim zihinde bir hapishane yaratır […]

“yasadışı” tarafta

Dolandırıcılar ayrıca kötü amaçlı yazılımlar kullanarak bir şirketin bilgisayar ağına sızabilir
ve finansal konularla ilgili e-posta yazışmalarına erişebilirler.

İş e-postası ele geçirme (BEC) - e-posta hesabı ele geçirme (EAC) olarak da bilinir -
en büyük mali zararı veren çevrimiçi suçlardan biridir.
Bir BEC dolandırıcılığında, suçlular bilinen bir kaynaktan geliyormuş gibi görünen ve meşru bir talepte bulunan bir e-posta mesajı gönderirler
[…]

başa dön

zorluklar

Anonimlik ve Gizlilik

Anonimlik gizlilikten farklıdır
[…] mesajları şifreliyoruz,
böylece insanlar bir mesaj gönderdiğimizi görseler bile
içeriğini okuyamazlar,
ancak bazen insanların bir mesaj gönderdiğimizi görmelerini bile istemeyiz.

İnternette anonim kalmak zordur.
Kullanmayı seçtiğiniz araçlar hakkında derin bir bilgi gerektirir.

Bu kılavuz size karmaşıklığı hakkında bir fikir verebilir:
Özel E-posta Sağlayıcıları


Gizliliğe ulaşmak daha kolaydır.

Gizleyecek hiçbir şeyiniz olmasa bile, şifreleme kullanmak
iletişim kurduğunuz kişilerin gizliliğini korumaya yardımcı olur
ve toplu gözetim sistemlerinin işini zorlaştırır.

Eğer saklamak istediğiniz önemli bir şey varsa, yalnız değilsiniz;
, insan hakları ihlallerini, yolsuzluğu ve diğer suçları ortaya çıkarırken
kimliklerini korumak için ihbarcıların kullandığı araçların aynısıdır

Öncelikle atılacak en önemli adım, kendinizi korumak
ve iletişiminizin gözetlenmesini olabildiğince zorlaştırmaktır.

Uçtan Uca Şifreleme

E-postalar için uçtan uca (e2ee) şifreleme, yalnızca mesajın göndericisinin ve alıcılarının içeriğini okuyabilmesini
sağlamak için kullanılabilir

Bu koruma olmadan, ağ yöneticilerinin, e-posta sağlayıcılarının ve devlet kurumlarının mesajlarınızı okuması
kolaylaşır

Uçtan uca şifreleme (e2ee) elde etmek, hem gönderici hem de alıcı tarafından dikkatli olmayı gerektirir.
İlgili taraflardan herhangi birinin yapacağı tek bir hata, e2ee güvenliğini kırmaya yetebilir.

Gönderen e-postası, alıcı e-postası, tarih ve saat gibi e-posta meta verileri uçtan uca şifreleme (e2ee) kullanılarak korunamaz.
E2ee kullanıldığında bile e-postanın konusu korunmasız ve kolayca okunabilir kalabilir.

başa dön

çözümler

Şifrelenmiş e-postaları okumak imkansızdır

< teknik > Oldukça İyi Gizlilik - PGP olarak da bilinir

PGP yazılımı, veri şifreleme ve şifre çözme için OpenPGP şifreleme standardını
(RFC 4880) takip eder.

PGP, e-postanızın içeriğini yalnızca yetkili kişilerin okuyabileceği
bir koda şifreler

PGP hemen hemen her bilgisayar veya akıllı telefonda çalışır.
Ücretsiz lisanslıdır ve hiçbir ücret talep etmez.

Her kullanıcının, rastgele sayı dizilerinden oluşan
benzersiz bir açık anahtarı ve özel anahtarı vardır

Herkese açık anahtarınız fiziksel bir anahtar gibi değildir, çünkü insanların indirebileceği çevrimiçi bir dizinde bulunur.
İnsanlar, size gönderdikleri e-postaları şifrelemek için herkese açık anahtarınızı PGP ile birlikte kullanırlar.

Özel anahtarınız, kendinizde (bilgisayarınızda) sakladığınız için fiziksel bir anahtara daha çok benzer.
Başkalarının size gönderdiği şifreli e-postaları çözmek için PGP'yi ve özel anahtarınızı kullanırsınız.

PGP ile şifrelenmiş bir e-posta yanlış ellere geçerse, anlamsız görünür.
Gerçek alıcının özel anahtarı olmadan, onu okumak neredeyse imkansızdır.

Kendimizi gözetimden korumak için, PGP'yi ne zaman kullanmamız gerektiğini öğrenmeli
ve e-posta adreslerimizi paylaştığımız her durumda genel anahtarlarımızı da paylaşmaya başlamalıyız.

< teknik > PGP şifrelemesi nasıl kullanılır

PGP kullanmak için bir genel anahtar ve bir özel anahtara (birlikte anahtar çifti olarak bilinir) ihtiyacınız olacak.
Her biri, size özel, rastgele oluşturulmuş uzun bir sayı ve harf dizisidir.
Genel ve özel anahtarlarınız özel bir matematiksel fonksiyonla birbirine bağlanır.

Mesajların şifrelenmesini/şifresinin çözülmesini ve anahtarların yönetimini sağlayan bir uygulamaya ihtiyaç duyulmaktadır;
işte en popüler olanlarından bazıları:

< easy > PGP şifrelemesine alternatifler

PGP, halihazırda kullanan bir ortakla güvenli iletişim için en iyi çözümdür.
Karşı tarafınızdan PGP kullanmaya başlamasını istemek zor olabilir.

Sırrı yalnızca bir kez paylaşmanıza olanak tanıyan hizmetler bir alternatiftir.

Bir şeyi yalnızca bir kez gönderirken,
yalnızca bir kez görüntülenebilecek bilgileri girmenize olanak tanıyan açık kaynaklı web uygulamaları mevcuttur.

Alıcı sayfayı açtıktan sonra bilgiler silinir
ve sohbet kayıtlarınızda veya e-postanızda kalan tek şey bozuk bir bağlantı olur.

PGP'yi tüm ekibinizin kullanması kadar sağlam olmasa da, kurulumu ve açıklaması çok daha kolay.
Bunu, teknik bilgisi oldukça az olan kişilere giriş bilgilerini göndermek için kullandık ve onlar da kullanımı kolay buldular.

Örnek (şifre eklemeden):

Diyelim ki bir şifreniz var. Bunu iş arkadaşınız Jane ile paylaşmak istiyorsunuz. Ona e-posta ile gönderebilirsiniz, ancak bu durumda şifre onun e-postasına girer ve bu e-posta yedeklenmiş olabilir, hatta büyük olasılıkla NSA tarafından kontrol edilen bir depolama cihazında da bulunur. Eğer Jane şifreye ait bir bağlantı alır ve ona hiç bakmazsa, şifre kaybolur. Eğer NSA bu bağlantıyı ele geçirir ve şifreye bakarsa... işte o zaman şifreye sahip olurlar. Ayrıca, Jane şifreye ulaşamaz, ancak artık birilerinin sadece e-postasına bakmakla kalmayıp, bağlantılara tıkladığını da bilir.

Tamamı ücretsiz ve açık kaynaklı olan bu hizmetlerden bazıları aşağıda listelenmiştir.
Ayrıca kendi web sunucunuzda bir örnek barındırmayı da tercih edebilirsiniz.

PrivateBin (PasteBin'in güvenli bir versiyonu gibi) PHP ile geliştirilmiştir.
PrivateBin kodu Github'da yayınlanmıştır - 3100 yıldız.
PrivateBin kullanım kılavuzu farklı bir web sitesinde mevcuttur.

OneTimeSecret, Ruby dilinde geliştirilmiştir.
OneTimeSecret kodu ve talimatları Github'da yayınlanmıştır - 1200 yıldız.

SnapPass, Python dilinde yazılmıştır. Aslen Pinterest tarafından geliştirilmiştir.

SnapPass kodu ve talimatları Github'da yayınlandı - 600 yıldız

başa dön

Gizli alıcı (BCC) e-postaları nasıl gönderilir ve sınırlandırılır?

Gizli alıcı (Bcc) e-postaları nasıl gönderilir ve sınırlandırılır?

"Cc", (eski) anlamıyla
daktiloda karbon kağıdı kullanarak kopya çıkarmak anlamına gelen "Karbon Kopya" demektir.

E-postalardaki “Bcc:” alanı (burada “Bcc”, “Gizli Karbon Kopya” anlamına gelir),
mesajın diğer alıcılarına açıklanmaması gereken
alıcıların adreslerini içerir
– IETF rfc 2822 “İnternet Mesaj Formatı”

Bcc ve Cc arasındaki fark, alıcının gizliliğinde yatmaktadır.
Cc özelliğini kullandığınızda, Cc alanındaki e-posta adresleri
e-postanın tüm alıcıları tarafından görülebilir.

Gizli alıcı (Bcc) olarak eklenen kişi, doğrudan alıcıyı (Kime:) görebilir,
ancak e-postada başka kimlerin gizli alıcı olarak eklendiğini göremez.

Bcc, genellikle kullanımı kolay bir toplu e-posta dağıtım sistemi olarak görülür.
Bcc kullanmanın avantajları ve dezavantajlarının kısa bir analizi yer almaktadır
Sayfanın sonunda ise bazı önerilerle birlikte sonuçlar bulunmaktadır

AVANTAJLAR

Çok kolay: herkes kullanabilir.

  • Birden fazla e-posta alıcısıyla iletişim kurmanın kolay bir yoludur
  • E-posta istemcisi olan herkes bunu kullanabilir
  • Doğru kullanıldığında, alıcıların e-posta adreslerini ifşa etmeyerek gizliliklerine saygı gösterir

başa dön

DEZAVANTAJLAR

E-posta, önceden kontrol yapılmadan gönderilen bir e-posta geçididir.
Gizli kopya (Bcc) özelliği, yüzlerce veya binlerce kişiye ulaşmasını sağlar.

Bcc, yüksek riskli ve potansiyel olarak tehlikeli bir iletişim aracı
olarak değerlendirilmelidir

  • Hata yapmaya yatkın bir süreçtir, riskler şunlardır:
    • Yanlışlıkla CC alanına Bcc alıcıları eklemek
      genellikle ciddi marka hasarına neden olur;
      bu durumdan kurtulmanın en yaygın yolu yeni bir özür mesajı göndermektir.
      » Tüm alıcıların isimleri kamuya açık hale gelir.
      Kontrolsüz e-posta zincirleri oluşturan
      "tümüne yanıtla" özelliğinin istem dışı (ve bazen kasıtlı) kullanımı.
      aynı kategoriye ait kişileri (örneğin hastalık, cinsel yönelim veya inançlar)
      tanımlıyorsa,
      GDPR açısından bir gizlilik ihlali söz konusu olabilir.
    • Birini yanlışlıkla ana (görünür) alıcı olarak eklemek
    • Birini eklemeyi unuttunuz veya mesajı almaması gereken birini eklediniz

  • Spam olarak sınıflandırılma olasılığı yüksektir
    • Sorun şu ki, çoğu spam gönderici Bcc kullanarak e-posta gönderiyor ve
      hedef posta sunucuları Bcc mesajlarını kabul etme konusunda temkinli davranıyor.
    • Eğer size gizli alıcı (Bcc) kullanarak bir mesaj gönderirsem,
      size hitaben gönderilmemiş bir e-posta alırsınız;
      bu da spam değerlendirmesi yapılırken mesajın aleyhine bir puan olarak sayılır.
    • Aynı mesaj, aynı alan adına ait "birkaç" e-posta adresine aynı anda gönderilecek
      ; bunları saymak ve engellemek kolay.

  • Yanlış adresler üzerinde herhangi bir kontrol bulunmamaktadır
    • Aynı alıcıda birden fazla e-posta adresi olabilir;
      bu durum, adreslerden bir veya daha fazlası doğru olsa bile, o alıcıya gönderimi etkiler.
    • Sözdizimsel olarak hatalı adresler , örneğin @ sembolü eksikse veya boşluk varsa,
      uyarı verilmeden kabul edilir

  • Kişiselleştirme yok / düşük etki / çok az veya hiç tepki yok
    • Mesaj zorunlu olarak standart ve "anonim" olacak,
      bireysel iletişim mümkün olmayacak, Sayın Bay/Bayan... şeklinde bir hitap şekli kullanılmayacak.
    • Gizli alıcı olarak eklediğiniz kişiler , dikkat etme veya tepki verme olasılıkları düşük olan
      başka birine yönlendirilmiş bir mesaj alacaklardır.

  • Teknik sorunların çıkması çok muhtemel
    • Spam gönderenler veya bilgisayar korsanları tarafından gerçekleştirilen her türlü kötüye kullanım eylemi, birçok alıcıyı hızla etkileyebilir ve
      SMTP sunucusunun itibarını zedeleyebilir (örneğin sunucu kara listeye alınabilir).
    • Gönderenin posta kutusu, "kullanıcı bilinmiyor", "posta kutusu dolu" gibi hatalarla dolup taşabilir;
      bu hataların sayısı gönderilen e-postaların %5 ile %20'si arasında değişebilir.
    • Gönderim işlemi, e-posta dağıtım sistemlerini (SMTP sunucuları) olumsuz etkileyebilir; örneğin:
      çok sayıda "daha sonra tekrar deneyin" yanıtı, posta kuyruğunda çok sayıda mesaj, sistem çökmesi.

başa dön

SONUÇLAR

  1. Sınırları Belirleyin
  • E-posta sağlayıcınızın izin verdiği alıcı sayısını kontrol edin
    , %100 emin olmak için kendiniz deneyin.

    RealSender, test için 300 adet @bogusemail.net adresinden oluşan bir liste paylaşıyor;
    mesajlar bir "kara delik" posta sunucusuna ulaşacak:
    bogusemail-test.txt

  • Tek bir mesajdaki alıcı sayısını 20 gibi küçük bir sayıyla sınırlandırmak,
    bunları küçük gruplara bölerek binlerce e-posta adresine
    kolayca mesaj göndermeyi mümkün kılar
  1. Profesyonel Olun
  • yalnızca farklı kanallar aracılığıyla toplu e-posta gönderimine izin ver

  • Örneğin,
    çok sayıda mesaj gönderirken farklı bir Gönderen adresi kullanın,
    Bu adrese yalnızca yetkili kişiler erişebilecek
    ve daha dikkatli bir şekilde işlem yapacaklardır.

  • Yapılandırılmış ofislerde, birçok kişinin e-posta ile çalıştığı ortamlarda,
    toplu e-posta göndermek için özel uygulamalar kullanılır;
    profesyonel sistemlerde onay iş akışı
    ve adım adım kontrol bulunur, hataları önlemek için tasarlanmıştır.

başa dön

E-POSTA PAZARLAMASINI ölçmek

E-posta pazarlama kampanyalarınızın performansını nasıl ölçersiniz?
, Inxmail e-posta pazarlama platformuyla ilgili
on beş yıllık deneyimimizden elde edilmiştir

"E-posta pazarlama kampanyaları" nedir?
Bunlar izin tabanlı kitlesel e-postalardır
genellikle alıcının ilgi alanlarına göre içeriği özelleştirilmiş,
gönderenin alıcıların davranışlarına dayalı geri bildirim verileri elde edebildiği,

Yanıtlar veya "geri bildirim verileri",
e-posta pazarlama kampanyalarının performansına ilişkin raporların ölçümlerinin temelini oluşturur.
Bunların neler olduğunu ve nasıl ölçüldüğünü özetleyelim:

En iyi teknik araçlar, mesajlar alıcının gelen kutusuna ulaşmadığı sürece işe yaramaz.
İşte burada "e-posta teslim edilebilirliği" devreye giriyor:

e-posta pazarlama kampanyaları

izin tabanlı pazarlama

"İzin tabanlı pazarlama" veya "diyalog pazarlama" olarak da adlandırılan
bu kavram, Seth Godin tarafından 1999 yılında çok satan kitabı "İzinli Pazarlama"da ortaya atılmıştır.

Kitapta, bu yöntem,
televizyon ve gazeteler gibi geleneksel kitle iletişim araçlarında genellikle kullanılan "kesintili pazarlama"nın tam tersi olarak tanımlanmaktadır.

Amaç , iki taraf arasında
kişisel ve doğrudan bir iletişim, bir ilişki kurmak
her iki taraf için de yararlı ve zenginleştirici bir deneyim sunan "insani" bir diyaloğu etkinleştirmektir.

başa dön

kullanıcı tepkilerini takip etmek

Gönderici, alınan gizlilik izinlerine bağlı olarak şunları kaydedebilir:

  • toplu veriler
  • Tek bir kullanıcının verileri (örneğin e-postayı kim açtı, kim tıkladı)

Toplu verilerle
küresel geri bildirim ve genel eğilimler hakkında bilgi sağlarlar
(örneğin, e-postayı kaç kişi açtı, kaç kişi tıkladı).

Tek kullanıcı verileri,
kişisel verileri toplayarak ve ardından
önceki etkileşimlere ve kullanıcı davranışına dayalı olarak
bireysel bilgilere ulaşmayı mümkün kılar

başa dön

kullanıcı takibi nasıl çalışır

Bağlantı izleme, web sitesinin son URL'sini hayali bir adresle değiştirme işlemidir
; bu işlem ziyareti kaydeder ve kullanıcıyı hedef sayfaya yönlendirir.

E-posta mesajlarında yalnızca bağlantılara yapılan tıklamalar izlenebilir.
E-posta istemcisinin indirmeden önce onay istediği harici resimler de
e-posta açılma oranını öğrenmek için
yalnızca harici resim URL'sini izlemeniz yeterlidir

Takip sistemi genellikle yalnızca gönderilen postanın benzersiz tanımlayıcısı olan
"posta kimliğini" kaydeder

Kişiselleştirilmiş izleme, ziyaret edilen sayfalara
yazılım tarafından oluşturulan bir veya daha fazla parametre eklenerek gerçekleştirilir;
örneğin: example.com/test.html?id=54725788327466628654 burada
"id" parametresi belirli bir kullanıcıyı ve mesajdaki belirli bir bağlantıyı ifade eder.

Elde edilen bilgiler,
e-posta pazarlama uygulamasındaki alıcının verilerini otomatik olarak güncelleyebilir
veya tıklamanın kaynağına ilişkin ayrıntıları web analiz platformuna iletebilir.

Örneğin: bir seyahat acentesi , kullanıcının deniz veya dağ haberlerine kaç kez tıkladığını
ölçebilir
zaman içinde belirli bir sayacı artırabilir.
Toplanan veriler, alıcının tercih ettiği destinasyonu gösterecektir.

başa dön

Açılma oranı ölçümünün nasıl çalıştığı

Açılma oranları, takip edilen bağlantılara yapılan tıklamalar ve indirilen takip edilen görseller tarafından oluşturulan "gizli tıklamalar"dan elde edilen
verilerin birleştirilmesiyle ölçülür

Eğer bir mesaj e-posta istemcisinde önizleme modunda açılırsa,
resimler indirilmeden veya herhangi bir bağlantıya tıklanmadan
mesajın açıldığını anlamak mümkün değildir.

2003 yılından itibaren, önce Outlook, ardından da çoğu e-posta istemcisi,
kullanıcılarının gizliliğini korumak amacıyla,
aksi takdirde her okunan e-posta için takip edilecek olan
resimlerin otomatik olarak indirilmesini engellemeye başladı

2013'ten beri Gmail'deki resimler varsayılan olarak otomatik olarak görüntüleniyor.
İndirme işlemi,
kullanıcının terminalini gizleyen ancak e-posta pazarlama operatörlerinin
resmin indirildiğini ve mesajın açıldığını bilmesini sağlayan "proxy" adı verilen üçüncü bir sunucu tarafından gerçekleştiriliyor.
Daha fazla bilgi için buraya bakabilirsiniz:
Yeni Gmail resim proxy'si nasıl çalışıyor ve bu sizin için ne anlama geliyor?

Açılış oranlarının kaydedilmesi doğru sonuç vermez,
gerçek açılışlardan daha düşük bir değer verir.
farklı kampanyaların sonuçlarını karşılaştırmak için bile olsa
, bunu ölçmek iyi bir fikirdir

başa dön

e-posta teslim edilebilirliği

tohum e-postaları

Öncelikle, e-postaların
listenizde bulunan başlıca ücretsiz e-posta alan adlarının
Google Apps ve Office 365'in
gelen kutularına ulaşıp ulaşmadığını kontrol etmek gerekir

İçerik tabanlı spam filtreleri genellikle URL'lerde (http…) bulunan alan adları tarafından tetiklenir;
iyi bir ipucu, mesajlarınızın bağlantılarında yalnızca bir alan adı kullanmaktır.
Alan adı, gönderen adresinde kullanılan alan adıyla aynı olmalıdır;
buna "alan adı uyumu" denir ve kimlik avı filtreleriyle ilgili riski azaltır.
gönderen adresinde kullanılan alan adının
bir alt alan adını kullanmalıdırlar

Gerçek testler, her e-posta sağlayıcısı için bir "çekirdek" posta kutusu etkinleştirerek ve ardından mesajların e-posta adresinize yönlendirilmesini etkinleştirerek
kolayca yapılabilir
ve "Test Mesajı" içeriği ile birlikte alan adınızın bağlantısını içeren
bir mesaj gönderin
Mesaj spam filtrelerinden geçerse, gelen kutunuzda almanız gerekir.

başa dön

hemen çıkma oranları

Geri dönen e-postalar almak normaldir.
Bunun nedeni, terk edilmiş adreslerin varlığı,
dolu posta kutuları veya diğer teknik sorunlar olabilir.

Listenizin "temizliğine" bağlı olarak,
hemen çıkma oranı %5 ile %20 arasında değişebilir.

Sayılar arttıkça, geri dönen e-postaları manuel olarak yönetmek imkansız hale gelir.
reddedilen mesajları otomatik olarak indiren,
analiz eden ve içeriklerine göre sınıflandıran
"geri dönen e-posta işleyici" adı verilen bir özellik entegre eder

Hedef e-posta adresi
, "kalıcı hata" (kullanıcı bilinmiyor, sunucuya ulaşılamıyor gibi kalıcı hatalar)
veya "geçici hata" (posta kutusu dolu gibi geçici hatalar) sayısının daha fazla olması durumunda otomatik olarak devre dışı bırakılır.

"Geri dönme oranları" (reddedilen mesajlar) veya tamamlayıcı "teslimat oranları" (kabul edilen mesajlar) izlenmesi önemlidir
. Bunların toplamı %100'ü verir.
Değerlerindeki bir değişiklik, araştırılması gereken bir belirtidir.

başa dön

e-posta pazarlama kıyaslama ölçütleri

En büyük e-posta pazarlama platformları,
tüm müşterilerinden topladıkları verilere dayalı kıyaslama rakamları yayınlıyor.

Raporlarda kullanılan teknik terimler:

  • Açılışlar: İzlenen bağlantılardan en az birine
    tıklayan veya izlenen görsellerden en az birini açan alıcı sayısı.
  • Açılma Oranı: Açılan e-postalar / Alıcı sayısı (geri dönen e-postalar hariç)
  • Benzersiz Tıklamalar: Bir bağlantıya en az bir kez tıklayan alıcı sayısı
  • Tıklama Oranı (CTR): Benzersiz tıklamalar / Alıcı sayısı (geri dönen kayıtlar hariç)
  • Tıklama Açma Oranı (CTOR): Benzersiz tıklamalar / Açılışlar

İşte kısa bir liste, bunların çoğu ABD'ye atıfta bulunuyor:

başa dön

SPAM olarak kabul edilen şey nedir?

Hangi kullanıcılar ve posta sunucuları spam e-posta olarak nitelendirilir?

RealSender ile olan deneyimimizden yola çıkarak ,
gelen kutusuna teslimatı etkileyebilecek temel noktaları özetlemeye çalıştık.


Mesajlar alıcıları tarafından beklenmiyorsa/istenmiyorsa,
diğer noktaları değerlendirmenin hiçbir faydası yoktur

KULLANICI tepkileri

Gönderen, alıcının yerine kendini koymalı ve e-posta mesajının nasıl ele alınacağını anlamaya çalışmalıdır.
Kullanıcı şikayetleri, tüm SMTP sunucusunun veya alan adının kara listeye alınmasına yol açabilir ve bu da gelecekteki tüm mesajların teslimatını etkileyebilir.

  • Kullanıcılar genellikle* gelen kutularını yönetebilirler: her kullanıcının spam olarak değerlendirdiği şey "spam"dir.
    * = birçok ücretsiz e-posta sağlayıcısı "dahili reklamlarından" vazgeçme seçeneği sunmaz.
  • Kullanıcı, Gmail'de "Spam Bildir" düğmesine
    veya Outlook/Hotmail'de "Önemsiz" düğmesine tıklayarak tercihini belirtir.
  • Modern e-posta sunucularının spam filtreleri tamamen kullanıcı şikayetlerine bağlıdır; "Spam Olarak Bildir" seçeneğine belirli sayıda tıklandıktan sonra,
    benzer içerikteki tüm mesajlar doğrudan spam klasörüne gönderilir.

E-posta mesajlarının kabul edilmesi için temel teknik ayarlar gereklidir.

IP adresi ve IP sınıfı itibarı

  • SMTP sunucu IP adreslerinin kara listeye alınmasıyla ilgili birçok aracı Google'da "kara liste kontrolü" şeklinde aratarak bulabilirsiniz
  • SMTP sunucu IP sınıfı itibarı hakkında daha fazla bilgi için blog yazımıza göz atın: SMTP IP İTİBARI ÖNEMLİDİR
  • Eğer mesajlar kişisel bir bilgisayardan gönderiliyorsa, internet bağlantısının genel IP adresinin itibarı da kontrol edilmelidir
    (bazı SMTP sunucu sağlayıcıları internet bağlantısının IP adresini maskeler, böylece alıcının sistemi yalnızca kendi IP adresini görür).

doğru SMTP sunucu kurulumu

  • Ters DNS,
    posta sunucunuzun IP adresinin, posta göndermek için kullandığınız alan adına işaret ettiğinden emin olmak anlamına gelir.
  • E-postaları yönlendiren ve teslim eden uygulama olan posta aktarım aracısı,
    IETF tarafından yayınlanan en son RFC'ye uygun şekilde yapılandırılmalıdır
    (örneğin: Postfix'i RFC Uyumlu Hale Getirme).

Doğru e-posta kimlik doğrulaması

E-postalarınızın ve alan adınızın birbirine ait olduğunu kanıtlamak için SPF ve DKIM gibi e-posta kimlik doğrulama yöntemlerini kullanın.
Bunun güzel bir yan etkisi de, e-posta alan adınızın taklit edilmesini önlemeye yardımcı olmanızdır.

  • SPF, e-posta alıcılarının, gönderenin DNS TXT kayıtlarında yayınladığı bilgilere dayanarak gönderenin giden MTA'sının IP adresini değerlendirerek, gönderenin mesaj başlığındaki alan adlarını kullanma yetkisine sahip olup olmadığını belirlemesine olanak tanıyan, yol tabanlı bir e-posta kimlik doğrulama protokolüdür. SPF, IETF RFC 4408'de tanımlanmıştır.
  • DKIM, göndericinin giden e-postaları alıcı tarafından doğrulanabilecek şekilde imzalamak için açık anahtarlı şifrelemeyi kullanmasını sağlayan bir e-posta kimlik doğrulama protokolüdür. DKIM, IETF RFC 4871'de tanımlanmıştır. DKIM standardı, Gmail ve diğer büyük şirketler tarafından internet postalarından kimlik avı ve sahtekarlığı tamamen ortadan kaldırmak için benimsenmiştir.
  • DMARC, e-posta kimlik doğrulaması için yerleşik SPF ve DKIM standartlarına dayanır. Hedef posta sunucuları, gönderenin "dmarc politikasına" göre kimliği doğrulanmamış postalar üzerinde işlem yapar ve sonucu gönderene bildirir. DMARC, İnternet Mühendisliği Görev Gücü'nün yayınladığı RFC 7489 belgesinde tanımlanmıştır.

SPAMASSASSIN kontrolü

  • SpamAssassin, e-posta spam filtrelemesi için kullanılan sunucu tarafı bir yazılımdır. Çeşitli spam tespit teknikleri kullanır.
    Her testin bir puan değeri vardır. Puanlar pozitif veya negatif olabilir; pozitif değerler "spam", negatif değerler ise "ham" (spam olmayan) anlamına gelir.
    Alıcı için varsayılan puan eşiği "5.0"dır. Bir e-postanın puanı eşikten yüksekse, spam olarak işaretlenir.
    O kadar yaygın olarak kullanılır ki, e-posta mesajları göndermeden önce puan kontrolünün zorunlu olarak yapılması gerektiği düşünülebilir.
  • SpamAssassin puanınızı kontrol etmenize yardımcı olabilecek iki çevrimiçi araç şunlardır: spam değil Ve posta test cihazı
    1. Mesajı verilen e-posta adresine göndermeniz gerekiyor
    2. Birkaç saniye sonra "raporunuzu görüntüleyin" veya "sonrasında puanınızı kontrol edin" düğmelerine

Bir e-postanın spam olarak sınıflandırılıp sınıflandırılmadığını anlamanın tek kesin yolu...
onu göndermek ve karşı tarafta nasıl göründüğüne bakmaktır.

Deneyin ve neler olacağını görün

  • Eğer reddedilen bir mesaj alırsanız, bu çok yardımcı olabilir çünkü son birkaç satır genellikle reddedilmeye neden olan sorunu açıklar.
    Açıklama anlaşılmazsa, "Test mesajı" konu ve içeriğiyle bir mesaj göndermeyi deneyin ve kabul edilip edilmediğini kontrol edin.
    Bu durumda, spam filtresini hangi bölümün etkinleştirdiğini belirleyene kadar aynı mesajı birkaç kez gönderip içeriği kademeli olarak azaltmalısınız.
  • Ayrıntılı bir gönderim günlüğüne sahip olmak, mesajların kabul edilip edilmediğini veya reddedilip reddedilmediğini doğrulamanıza yardımcı olabilir;
    günlükte bulunan bilgilere
  • Bazı (nadir) durumlarda bir tür "beyaz liste" gereklidir.
    Bazı spam sistemleri, kullanıcıların aldıkları mesajlarla ne yaptıklarından öğrenir.
    Eğer alıcı, aldığı e-postayı bir kez "spam DEĞİL" olarak işaretlerse,
    sistem bunların geçerli mesajlar olduğunu öğrenir ve bunları "Önemsiz" klasörü yerine "Gelen Kutusu" klasörüne teslim etmeye başlar.
    Alternatif olarak, gönderenin alıcının adres defterinde olması veya daha önce onunla e-posta alışverişinde bulunmuş olması gerekir.

açık kaynak kodlu e-posta istemcileri

Hazır kullanıma uygun açık kaynaklı e-posta istemcileri kullanarak e-posta kontrolünü nasıl geri kazanabilirim?

Son on yılda, kurumsal e-posta kutularında , şirket içi posta sunucularından Exchange Online (Office 365) veya Gmail for Business (Google Apps) gibi bulut hizmetlerine doğru
neredeyse tamamen bir değişim gördük

Bunun başlıca nedenleri şunlardır:

  • Mobil ve web arayüzlerinden e-postalara erişme ihtiyacı
  • posta kutularını istenmeyen e-postalardan ve kötü amaçlı yazılımlardan koruma ihtiyacı

Bu sayede, e-posta altyapısının yönetim sorumluluğu "büyük teknoloji şirketlerine"
devredilerek, bilişim uzmanlarının hayatı kolaylaştırılmıştır

Temel e-posta becerilerini terk etme riski, Microsoft ve Google'ın bunu halletmesi nedeniyle
e-postanın sihirli bir şekilde çalıştığını düşünmemize yol açabilir

Mesajlaşma bileşenlerini parçalara ayırıp ayrı ayrı yöneterek e-posta üzerindeki kontrolü yeniden ele geçirebiliriz:

  • gelen posta sunucusu
  • e-posta istemcisi
  • giden posta sunucusu

Bu, hizmet izolasyonu ve bölümlendirmesi oluşturarak güvenliğe büyük fayda sağlar.
Dolayısıyla, izolasyon/bölümlendirme yoluyla saldırı yüzeyini azaltmak en iyi uygulama olarak kabul edilir.
Ayrıca, ölçeklenebilirliği ve istikrarı da artırır.


E-posta istemcileri, posta kutularının birincil arayüzüdür. Kullanıcılarla etkileşim kuran karmaşık bir yazılım parçasıdır.

Piyasada birçok çözüm mevcut, biz bunları iki gereksinime göre seçtik:

  • çok platformlu, aktif olarak yönetilen ve açık kaynaklı projeler
  • Kullanıma hazır oldukları için sistem yöneticileri bunları kolayca yönetebilirler

İki seçenek belirledik:

  1. Mozilla Thunderbird Mozilla Thunderbird , kişisel bilgisayarlar için açık kaynaklı, platformlar arası bir e-posta istemcisidir. Mozilla Vakfı tarafından geliştirilmiştir.
    Hem IMAP hem de POP'u (internet bağlantısı olmadan erişilebilmesi için e-postaları yerel olarak sabit diskinizde saklama) destekler.
    Mükemmel e-posta filtreleme yeteneklerine ve yönetimine sahiptir.

    Thunderbird, otomatik imza özellikleri de dahil olmak üzere birden fazla hesap ve kimlik kullanımını güçlü bir şekilde destekler.
    Windows, Mac OS ve Linux için kurulumu hazır sürümleri mevcuttur. Uzaktan erişim sağlamak için kullanıcıların öncelikle bilgisayarlarına bağlanmaları gerekir.

  2. Yeni Rainloop çatalı Yeni Rainloop çatalı, basit, modern, hafif ve hızlı bir web tabanlı e-posta istemcisidir.
    Herhangi bir veritabanı bağlantısına ihtiyaç duymadan çok sayıda e-posta hesabını yönetebilir.
    SMTP ve IMAP protokollerini destekleyerek e-postaları sorunsuz bir şekilde gönderip almayı kolaylaştırır.

    2020 yılında SnappyMail Github projesi yayınlandı.
    Bu, RainLoop Webmail Community sürümünün önemli ölçüde geliştirilmiş ve güvenli hale getirilmiş bir çatalıdır.
    İşte SnappyMail e-posta istemcisi demosu. Yönetici arayüzünü denemek isterseniz bizimle iletişime geçin.

İş E-postası ve Gizlilik

Uyarı: Bu konu ciddi hukuki sonuçlar doğurabilir. Düzenlemeleri ve uygulamalarını doğrulamak için yetkili danışmanlarla iletişime geçin.

İş e-postası,
etkileyici miktarda işle ilgili bilgi içeren bir iş aracıdır.

Şirketler, iş aracı olan
e-postayla istediklerini yapabilirler
Çalışanlar e-postaları okuyabiliyor mu? Yedekleyebiliyorlar mı? Arşivleyebiliyorlar mı?

Özet:

Genel iş e-posta adresleri, herhangi bir kısıtlama yok

İşyeri e-posta kutusu ikili bir niteliğe sahiptir;
işverene ait bir araçtır ancak çalışan tarafından kullanılır.

İki farklı türde işletme e-posta adresini birbirinden ayırmamız gerekiyor:

  • Kişisel şirket e-posta adresi, örneğin ad.soyad@şirketadı.com
  • Şirket genelinde kullanılan e-posta kutuları; örneğin bilgi, destek, satış, pazarlama, faturalama vb.
    yani tek bir kişiye ait olmayan tüm e-postalar.

Şirketlere ait genel posta kutuları hiç sorun teşkil etmiyor,
şirket bunları kontrol ediyor, tüm mesajları okuyor, hiçbir kısıtlama yok.

şirket araçlarındaki kişisel şirket posta kutusu gibi

İsim.soyad@şirketadı.com gibi kişisel e-posta kutuları ,
işverenin korumakla yükümlü olduğu çalışanın kişisel verilerini içerebilir.

Bu tür bir e-posta kutusu kullanmayı tercih edersek,
verileri yeterli şekilde işleyebilmek için
hangi teknik standartları benimsememiz ve hangi araçları kullanmamız gerektiğini bilmemiz gerekir

Posta kutusu, şirket arabasına benzetilebilir;
çalışanın iş görevleri kapsamında kullanması için tahsis edilmiştir.

Örneğin, işveren, çalışanın
bu iş aracını kişisel amaçlar için kötüye kullanmadığını doğrulamak amacıyla kilometre bilgilerini kontrol edebilir.

Ancak işveren, çalışanın şirket aracı içinde ne yaptığını
sistematik olarak ve belirli bir neden olmaksızın izleyemez

Posta kutusu, şirket arabasının eşdeğeridir; şirkete ait,
çalışana işini yapmak ve görevlerini yerine getirmek için verilen bir çalışma aracıdır.

Çalışanın mesai saatleri içinde bile gönderdiği ve aldığı şeyler,
şirket arabasının kokpitinde olup bitenlere benziyor ve özel yazışma olarak değerlendiriliyor.

başa dön

yalnızca belirli koşullar altında okunabilir

Şirket, e-posta mesajlarında yazılanları okuyamaz;
bu, sistematik olarak ve belirli bir sebep olmaksızın yapılamaz.
Belirli bir gerekçe olsa bile, ancak belirli koşullar altında yapılabilir.

Dengelenmesi gereken üç farklı çıkar söz konusudur:

  • İşverenin bu içeriğe erişme konusundaki menfaati,
    organizasyonel/üretimsel, iş güvenliği veya diğer nedenlerden kaynaklanmaktadır.

  • Bu içeriği gizli olarak değerlendiren
    çalışanların meşru beklentisi

  • Söz konusu şirket adına yazan üçüncü şahısların beklentisi,
    yazışmalarının içeriğinin gizli ve özel OLMADIĞININ farkında olmayabilecekleridir.
    (E-posta mesajlarının altındaki standart uyarı genellikle içeriğin başkaları tarafından okunabileceği konusunda uyarıda bulunur.)

çalışanı bilgilendirin

Çalışana, e-posta mesajlarının yalnızca iş ilişkisiyle ilgili amaçlar için kullanılabileceği, örneğin kişisel kullanımın yasaklanması yoluyla
, yeterli yazılı iletişimle bildirilmelidir

Belgede,
e-posta kutusu da dahil olmak üzere şirket araçlarının nasıl kullanılacağına dair bilgiler yer almalı ve gizlilik düzenlemelerine uygun olarak şu hususlar bildirilmelidir:

  • Yasa gereği ve şirket varlıklarını korumak amacıyla e-posta mesajları arşivlenecektir
  • Şirket, bazı durumlarda, çalışanın posta kutusunun içeriğini kontrol edebilir

Büyük çaplı çekler yasaktır

Çalışanların posta kutusunun içeriğinin sistematik olarak okunması gibi
"kitlesel kontroller" yasaklanmıştır

İşveren kontrolündeki sınırlamalar üç temel ilkeye dayanmaktadır:

  • Birincisi iyi niyet ilkesidir ; bu da işverenin,
    örneğin şirket varlıklarının virüs nedeniyle tehlikeye girebileceği veya risk altında kalabileceği durumlarda korunması veya
    çalışanın sadakatsizliğinden şüphelenilmesi halinde savunma amaçlı kontroller yapılması
    haklı bir neden varsa, çalışanın şirket e-posta kutusunu kontrol etme olanağıdır

  • Diğerleri ise kontrolde orantılılık , zaman ve araştırma nesnesinde sınırlamadır.

başa dön

e-posta mesajlarını arşivleme yükümlülüğü

Kurallar, işverenin
yeterli ve etkili güvenlik önlemleri aldığını
; örneğin, kurumsal e-posta arşivleme gibi.

çalışanı bilgilendirme yükümlülüğü

Şirket hakkında detaylı bilgi bulunmadığı durumlarda
işveren tarafından verilere erişim :

  • Bu durum çok ciddi bir ihlal teşkil etmektedir;

    hassas veriler, örneğin çalışanın kişisel alanında bulunabilir ve
    bu veriler siyasi, dini, cinsel veya sendikal eğilimlere ilişkin olabilir;
    bu tür bilgilerin gizliliği en üst düzeyde güvence altına alınmalıdır.

  • Bu bir suçtur ve
    herhangi bir yasal süreçte kullanılamaz hale gelme
    riski de vardır.

e-posta mesajlarını silme yükümlülüğü

İş yazışmaları genellikle en fazla on yıl saklanmalıdır. Bu,
şirketin varlıklarını korumak ve olası dava durumlarında kendini savunabilmek içindir.

Kişisel verilerin saklanması ve işlenmesi yalnızca belirli bir amaç için izinlidir.
Bu amaç belirli bir süre sonra, örneğin on yıl sonra, ortadan kalkarsa, bu veriler silinmelidir.

posta kutularını devre dışı bırakma yükümlülüğü

Çalışanın işten çıkarılması veya istifa etmesi durumunda,
ad.soyad e-posta kutusu kısa bir süre içinde devre dışı bırakılmalıdır.

Şirket, gönderene hesabın devre dışı bırakıldığını bildiren ve
başka bir dahili e-posta adresine yazmasını isteyen otomatik bir yanıt etkinleştirebilir.

İşten çıkarılan çalışanların şirket içi mesajlarının tarihi arşivi,
ancak çalışana mesajlarının saklandığı bilgisi verilmişse muhafaza edilebilir.

başa dön

E-postaları SPAM'den koruyun

İş e-postalarını istenmeyen e-postalardan nasıl koruyabilirim?

E-posta denince akla hemen istenmeyen e-postalar (spam) gelir.
Mevcut durumu ve izlenebilecek stratejileri özetlemeye çalıştık:


E-posta trafiğinin ne kadarı istenmeyen e-posta (spam) olarak geçiyor?

Güvenilir bir kaynak olan ve şu anda Talos olarak adlandırılan SenderBase'in verilerine
göre, Eylül 2020'de kaydedilen e-posta trafiğinin
yaklaşık %85'i spam , %15'i ise meşru e-postadır

Bu oran son on iki ayda çok az değişiklik göstererek istikrarlı kaldı.

Eylül 2020 e-posta spam trafiği

Kaynak: E-posta ve Spam Verileri - Toplam küresel e-posta ve spam hacmi.

başa dön


Spam'in maliyetleri nelerdir?

Bazen istenmeyen e-postalar sadece tanıtım amaçlıdır ve gönderen kişi
yalnızca işletmesi için daha fazla müşteri kazanmaya çalışır;
bu da dikkat dağıtıcı unsurlara ve zaman kaybına neden olur. Gelen kutunuzu o kadar doldurabilir
ki, önemli e-postaları bulmak zorlaşır.

Tüm spam e-postalar dostane tanıtım e-postaları değildir.
Birçok durumda amaç kötü niyetlidir ve kullanıcı sistemlerine zarar vermek veya onları ele geçirmektir.
Dünya çapında en yaygın kötü amaçlı spam türleri arasında truva atları, casus yazılımlar ve fidye yazılımları bulunur.

başa dön


En yeni spam önleme teknikleri nelerdir?

Şirketinizin e-posta kutularını evinizin kapısı olarak düşünün:
Kimin içeri girebileceğine ve kimin dışarıda kalacağına karar vermeniz gerekiyor.

Hiçbir teknik, spam sorununa tam bir çözüm değildir.
Her birinin, meşru e-postaları yanlışlıkla reddetme (yanlış pozitifler)
ile spam'i reddetmeme (yanlış negatifler)
ve bununla ilişkili zaman, emek ve maliyet açısından dezavantajları vardır; bu maliyetler, iyi niyetli e-postaların yanlışlıkla engellenmesinden kaynaklanır.

Spam önleme teknikleri iki ana başlığa ayrılabilir: önleme ve tedavi.

Spam önleme (oluşmadan önce)

İstenmeyen e-posta alma olasılığını azaltmak amacıyla e-posta adreslerinizin erişilebilirliğini kısıtlayın.

  • Gizlilik ilkesine dikkat edin;

    e-posta adresinizi herkese vermeyin
    , ne kadar az kişi bilirse o kadar az istenmeyen e-posta alırsınız.
    Mümkün olduğunca, çevrimiçi kayıtlar için farklı bir e-posta adresi kullanın.

  • İletişim formları

    e-posta adresinizi çevrimiçi olarak yayınlamaz,
    herkes görebilir; "spam botları" bunları sürekli olarak yakalar
    ve çevrimiçi olarak iletişime geçmek için kullanır. Güvenli* web formları/iletişim formları kullanın (
    * = otomatik olarak dolduran robotlar tarafından korunmaktadır).

Spam'i (oluştuğu sırada) ortadan kaldırın

Spam gönderenler e-posta adresinizi ele geçirdikten sonra, mücadele posta sunucunuza ve gelen kutunuza taşınır.

  • SpamAssassin benzeri puanlama sistemleri,
    (genellikle Gerçek Zamanlı Kara Liste, DNSBL veya RBL olarak adlandırılır), metin analizi ve Bayes filtrelemesi
    dahil olmak üzere çeşitli spam tespit teknikleri kullanır
    Her testin bir puan değeri vardır. Puanlar pozitif veya negatif olabilir; pozitif değerler "spam", negatif değerler ise "ham" (spam olmayan) anlamına gelir.
    Alıcı için varsayılan puan eşiği "5.0"dır. Bir e-postanın puanı eşikten yüksekse, spam olarak işaretlenir.
    spam gönderenlerin mesajlarını göndermeden önce kontrol etmelerini sağlayan
    birçok "SpamAssassin Testi" mevcuttur


  • Kullanıcılar tarafından desteklenen

    bu sistemlerin kullanıcıları, gelen e-postaları meşru veya spam olarak işaretleyebilir ve bu işaretlemeler merkezi bir veritabanına kaydedilir.
    Belirli sayıda kullanıcı belirli bir e-postayı spam olarak işaretledikten sonra, filtre otomatik olarak bu e-postanın topluluğun geri kalanının gelen kutularına ulaşmasını engeller.

    Bazen kullanıcı geri bildirimleri, mesaj içeriğiyle etkileşim sayısı,
    bağlantılara tıklama sayısı ve indirilen resimler veya aynı mesajın birden fazla posta kutusunda görünme sayısı gibi otomatik kontrollerle entegre edilir.

    İşbirlikçi bir içerik filtreleme sistemi büyük ve aktif bir kullanıcı tabanını içerdiğinde,
    spam saldırısını bazen birkaç dakika içinde hızla engelleyebilir.

    Bu tür bir filtrenin spam gönderenler tarafından aşılması oldukça zordur.

  • E-posta kimlik doğrulaması için kullanılan
    SPF, DKIM ve DMARC teknikleri, gönderen adresinin gerçekten iddia ettiği kişi olup olmadığını anlamanıza olanak tanır.
    2020 yılında yaygın olarak kullanılan bu teknikler, güvenilir göndericileri belirlemek için iyi bir kaynaktır.
    E-postaların tam olarak hangi alan adından geldiğini önceden bilmek önemlidir,
    aksi takdirde basit bir harf değişikliğiyle kolayca yanıltılabilirsiniz.
    , mesajlarının "meşru göndericilerden" geliyormuş gibi görünmesi için
    e-posta kimlik doğrulama kurallarına uymaları mümkündür


  • Yetkili Göndericiler, Beyaz Liste:

    Beyaz listede, güvenilir adresler veya alan adlarından oluşan bir dizi belirtebilirsiniz.
    Başlangıçta kişisel adres defteriniz ve geçmişte aldığınız e-postalar büyük yardımcı olacaktır.

    Bir gönderici bu listede yer alıyorsa, tüm kontroller atlanır ve mesaj gecikme olmadan alınır.
    Bu yöntem, e-posta adresi sahteciliğini* önlemek için E-posta Kimlik Doğrulama ile birlikte kullanıldığında uygulaması kolay ve çok etkilidir.
    * = mesajın gerçek kaynağından farklı birinden geliyormuş gibi görünmesini sağlamak için sahte bir gönderici kullanılması.

    Güvenilir kişiler listeniz dolduğunda, bilinmeyen hiçbir gönderici posta kutunuza ulaşamaz.
    İstenmeyen tüm mesajlar, günde bir kez veya daha nadiren kontrol edilmek üzere farklı bir posta kutusuna yönlendirilebilir.

    Spam gönderenler, her alıcının güvenilir göndericilerinin hangileri olduğunu zorlukla bulabilirler.
    Bunu başarsalar bile, e-posta kimlik doğrulama kontrolleri sizi sahtekarlık konusunda uyaracaktır.

başa dön

DMARC nasıl çalışır - güncellendi

DMARC, Google Mail ve Office 365 ile nasıl çalışır? (güncellendi)

En popüler kurumsal e-posta sağlayıcıları olan Google Mail ve Office 365 posta kutularına
e-posta teslimatının kimlik doğrulamasından nasıl etkilendiğini tekrar test ettik

Sonuçlar iki gruba ayrılabilir:

e-postaların teslimi

(SPF, DKIM ve DMARC'nin gönderilen mesajların teslimatını nasıl etkilediği)
# Google Mail : E-postalar her zaman kabul ediliyor, SPF kimlik doğrulaması hiç dikkate alınmıyor gibi görünüyor.
DKIM imzası yalnızca Gönderen e-posta adresiyle uyumluysa ve DMARC politikası "karantina" veya "reddet" olarak ayarlanmışsa değerlendiriliyor.
# Office 365 : SPF'ye tamamen duyarlı, bir mesaj SPF kontrolünden geçtiğinde Gelen Kutusu'na ulaşıyor.
DKIM imzası yalnızca Gönderen e-posta adresiyle uyumluysa dikkate alınıyor, aksi takdirde önemi yok.
Notlar: Ağustos ayının son haftasında Office 365'te garip bir davranış gözlemlendi:
ve Gelen Kutusu'na teslim edildi.    
olan mesajlar
 
 
 

sahtekarlık koruması

(SPF, DKIM ve DMARC'ın gönderenin e-posta adresinin sahtekarlıktan korunmasına nasıl yardımcı olduğu*)
* = mesajın gerçek kaynağından farklı birinden gelmiş gibi görünmesini sağlar.
 
# Google Mail: DMARC etkinleştirildiğinde, sahtekarlık yapan göndericiler Spam klasörüne filtrelenir (p=karantina ile) veya reddedilir (p=reddet ile).
   Politika "yok" (p=yok) olarak ayarlanırsa hiçbir şey olmaz, bu durumda tüm mesajlar Gelen Kutusu'na ulaşır.
 
# Office 365: "spf fail" veya "spf softfail" sonuçları, sahte göndericileri Önemsiz e-posta klasörüne göndermek için yeterlidir.

 

kimlik doğrulama gereksinimleri

Önerilen e-posta kimlik doğrulama gereksinimleri aşağıdaki gibi özetlenmiştir:

e-postaların teslimi sahtekarlık koruması
Google Mail dkim pass (alan adı hizalı) dmarc, p=karantina veya p=reddetme ile ayarlandı
Office 365 spf pass ve dkim pass (alan uyumlu) SPF ayarı ve DMARC ayarı (ek güvenlik için)

 

e-posta gönderim testi sonuçları

Aşağıda yapılan testlerin tam listesi bulunmaktadır

Google Mail Google Mail
(dmarc ayarı)
Office 365 Office 365
(dmarc seti)
spf Geçişi dkim yok gelen kutusu gelen kutusu gelen kutusu gelen kutusu
spf Başarısız dkim yok gelen kutusu istenmeyen e-posta hurda hurda
spf SoftFail dkim yok gelen kutusu istenmeyen e-posta hurda hurda
spf yok dkim yok gelen kutusu istenmeyen e-posta hurda hurda
spf Geçişi dkim farkı gelen kutusu gelen kutusu gelen kutusu gelen kutusu
spf Başarısız dkim farkı gelen kutusu istenmeyen e-posta hurda hurda
spf SoftFail dkim farkı gelen kutusu istenmeyen e-posta hurda hurda
spf yok dkim farkı gelen kutusu istenmeyen e-posta hurda hurda
spf Geçişi dkim geçişi gelen kutusu gelen kutusu gelen kutusu gelen kutusu
spf Başarısız dkim geçişi gelen kutusu gelen kutusu gelen kutusu gelen kutusu
spf SoftFail dkim geçişi gelen kutusu gelen kutusu gelen kutusu gelen kutusu
spf yok dkim geçişi gelen kutusu gelen kutusu gelen kutusu gelen kutusu
spf Geçişi dkim geçersiz gelen kutusu gelen kutusu gelen kutusu gelen kutusu
spf Başarısız dkim geçersiz gelen kutusu istenmeyen e-posta hurda hurda
spf SoftFail dkim geçersiz gelen kutusu istenmeyen e-posta hurda hurda
spf yok dkim geçersiz gelen kutusu istenmeyen e-posta hurda hurda

Notlar:

  • "Gönderen adresi (görünür gönderici)" ve "Posta gönderen" (aynı zamanda "zarf gönderen" veya "geri dönüş yolu" olarak da adlandırılır) aynıdır, aynı etki alanına atıfta bulunurlar
  • “dkim pass”: dkim imzalama etki alanı, Gönderen adresinin etki alanıyla aynıdır (etki alanı hizalanmıştır)
  • “DKIM farkı”: DKIM imzalama alanı, Gönderen adresinin alanından farklıdır (alan eşlenik DEĞİLDİR)

DMARC için DKIM alanı

DKIM etki alanı hizalaması DMARC kimlik doğrulamasını nasıl etkiler?

DMARC (Domain-based Message Authentication, Reporting and Conformance),
sahte alan adı e-postalarına karşı mücadele etmek için geliştirilmiş bir e-posta kimlik doğrulama standardıdır.

“3.1. Tanımlayıcı Hizalaması” başlıklı bölümde şöyle yazıyor:

   E-posta kimlik doğrulama teknolojileri, tek bir mesajın çeşitli (ve birbirinden farklı) yönlerini doğrular. Örneğin, [DKIM], mesaja imza ekleyen etki alanını doğrular; [SPF] ise [SMTP]'nin RFC5321.MailFrom (Posta Gönderen) bölümünde görünen etki alanını veya RFC5321.EHLO/HELO etki alanını veya her ikisini birden doğrulayabilir. Bunlar farklı etki alanları olabilir ve genellikle son kullanıcı tarafından görülemezler. DMARC, RFC5322.From etki alanının, Doğrulanmış Tanımlayıcı ile eşleşmesini (uyumlu olmasını) gerektirerek bu etki alanının kullanımını doğrular. -- https://tools.ietf.org/html/rfc7489#section-3.1

Bu basitçe şu anlama gelir:

   Bir gönderici e-postasını SPF ve/veya DKIM kullanarak doğruladığında, alan adlarından en az birinin gönderen "Gönderen" alan adıyla uyumlu olması gerekir

Bir mesajın SPF veya DKIM kontrolünden mümkün olup olmadığı bizim için net değildi
yine de DMARC kimlik doğrulamasından geçmesinin

Bunu herkesin kullanabileceği bir araç kullanarak test ettik: Gmail posta kutusu.
Sonucu görmek için mesajı açın ve "Orijinali göster" seçeneğini seçin:

Test 1 - iletilen mesaj: spf-fail, dkim-pass (hizalanmış)
spf-fail dmarc-pass

Test 2 - bozuk dkim anahtarı: dkim-fail, spf-pass (hizalanmış)
dkim-fail dmarc-pass

Sonuç ortada, mesaj şu durumlarda DMARC kimlik doğrulamasından geçiyor:
SPF ve alan adı uyumu. <OR> DKIM ve alan hizalaması

DMARC kontrolünden geçmek için, bazı durumlarda DKIM imzasının doğrulanması önemlidir:
imzalayan etki alanı (d=example.com) ile Gönderen etki alanı aynı hizada olmalıdır.

Normalde işe yaramayacak olan “DMARC-PASS” sonuçlarına örnekler:

Durum 1 - yönlendirme SPF kimlik doğrulamasını bozuyor

  • SPF-FAIL: SPF kimlik doğrulama kontrolleri çoğunlukla başarısız olur,
    çünkü iletilen e-postayı orijinal gönderenin SPF kaydında yer almayan yeni bir kuruluş gönderir.

  • DKIM-PASS (hizalanmış): E-posta yönlendirme DKIM imzasını etkilemez

Sonuç: DKIM hizalaması, mesajın DMARC kontrolünden geçmesini sağlar.

Durum 2 - ESP (E-posta Servis Sağlayıcısı) tarafından sağlanan SPF etki alanı,
Gönderen etki alanı ile aynı hizada OLAMAZ.

  • SPF~GEÇTİ (HİZALANMAMIŞ): SPF Kimlik Doğrulaması, alan adı hizalamasında başarısız oldu,
    çünkü ESP tarafından Mail-From adresinde kullanılan alan adı, From sender adresindeki alan adından farklı.

  • DKIM-PASS (hizalanmış): DKIM imzası, From göndericisinin alan adıyla aynı alan adını kullanır

Sonuç: DKIM hizalaması, mesajın DMARC kontrolünden geçmesini sağlar.

en popüler E-POSTA SAĞLAYICILARI

2020 yılında en popüler e-posta sağlayıcıları hangileridir?

E-postaların teslim edilebilirliğini izlemek için, alıcılarınızın hangi e-posta sağlayıcılarını kullandığını bilmek önemlidir.

İşletmeden İşletmeye

B2B dünyası için kesin rakamlarımız yok. İşletme e-postalarının büyük bir kısmı "Bulut Ofis Paketlerine" geçiyor ve pazar payı "G Suite" ve "Office 365" arasında paylaşılıyor.
datanyze.com verilerine göre, bu ikisi birlikte küresel işletme e-posta pazar payının %90'ından fazlasını kapsıyor.

Tek bir işletme için bu bilgileri toplamak oldukça kolaydır.
Şirket alan adının mx kaydından kullanılan e-posta sağlayıcısını görebiliriz:
"G Suite" için aspmx.l.google.com,
"Office 365" için mail.protection.outlook.com.

Şirketiniz B2B alanında faaliyet gösteriyorsa, bu iki sağlayıcının her biri için ayrı bir e-posta kutusunu düzenli olarak izlemeniz önerilir.

Üçüncü oyuncu ise Zoho (mx.zoho.com) olup, pazar payı yaklaşık %2'dir (kaynak: ciodive.com).

İşletmeden Tüketiciye

B2C'de analiz daha karmaşık. İnternet trafiğine dayalı kamuya açık "e-posta verileri" bulunmuyor.

E-posta alıcıları hakkında bilgi edinmenin tek yolu, bu bilgileri iletişim listemizden çıkarmak veya büyük e-posta servis sağlayıcılarından almaktır. Bunlardan bazıları, internet topluluğuyla paylaşmak üzere yıllık raporlar yayınlamaktadır.

Aşağıdaki veriler, yirmi beş ülkedeki en iyi üç e-posta sağlayıcısını göstermektedir; bilgiler Sendgrid tarafından yayınlanan "2019 E-posta Kıyaslama ve Etkileşim Çalışması"ndan alınmıştır.

Ülkeler

Arjantin, Avustralya, Belçika, Brezilya, Kanada, Şili, Çin, Kolombiya, Danimarka, Fransa, Almanya, Hindistan, Endonezya, İtalya, Japonya, Meksika, Yeni Zelanda, Rusya, Suudi Arabistan, İspanya, Güney Afrika, İsveç, İsviçre, Birleşik Krallık, Amerika Birleşik Devletleri

Arjantin

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
AR gmail.com 45.8% hotmail.com 33.7% yahoo.com.ar 8.2% 87.7%

başa dön

Avustralya

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
AU gmail.com 38.0% hotmail.com 18.7% büyükpond.com 5.4% 62.1%

başa dön

Belçika

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
OLMAK gmail.com 30.6% hotmail.com 23.0% telenet.be 9.8% 63.4%

başa dön

Brezilya

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
BR gmail.com 52.9% hotmail.com 22.5% yahoo.com.br 6.1% 81.5%

başa dön

Kanada

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
Kaliforniya gmail.com 38.6% hotmail.com 18.8% yahoo.com 4.5% 61.9%

başa dön

Şili

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
CL gmail.com 67.3% hotmail.com 18.2% yahoo.es 1.7% 87.2%

başa dön

Çin

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
CN NetEase (126.com 163.com) na. Tencent (qq.com) na. Sina (sina.com) na. na.

Not: Bu bilgiler ReturnPath'in "Ülke genel bakışı: Çin" adlı çalışmasından alınmıştır

başa dön

Kolombiya

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
CO gmail.com 41.3% hotmail.com 38.7% yahoo.com 4.3% 84.3%

başa dön

Danimarka

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
Danimarka gmail.com 35.8% hotmail.com 14.0% canlı.dk 3.7% 53.5%

başa dön

Fransa

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
FR gmail.com 36.0% hotmail.fr 9.8% turuncu.fr 8.2% 54.0%

başa dön

Almanya

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
DE gmail.com 20.8% gmx.de 10.0% web.de 9.5% 40.3%

başa dön

Hindistan

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
İÇİNDE gmail.com 82.4% yahoo.com 3.4% yahoo.co.in 1.6% 87.4%

başa dön

Endonezya

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
İD gmail.com 82.6% yahoo.com 7.1% yahoo.co.id 1.0% 90.7%

başa dön

İtalya

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
BT gmail.com 46.8% libero.it 9.9% hotmail.it 7.2% 63.9%

başa dön

Japonya

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
JP gmail.com 33.8% yahoo.co.jp 12.7% docomo.ne.jp 8.6% 55.1%

başa dön

Meksika

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
MX gmail.com 42.6% hotmail.com 31.5% yahoo.com.mx 4.0% 78.1%

başa dön

Hollanda

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
NL gmail.com 35.4% hotmail.com 19.5% canlı.nl 2.5% 57.4%

başa dön

Yeni Zelanda

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
Yeni Zelanda gmail.com 46.3% hotmail.com 10.9% xtra.co.nz 9.0% 66.2%

başa dön

Rusya

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
RU posta.ru 34.8% gmail.com 22.7% yandex.ru 19.6% 77.1%

başa dön

Suudi Arabistan

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
SA gmail.com 47.0% hotmail.com 31.0% yahoo.com 7.8% 85.8%

başa dön

İspanya

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
ES gmail.com 50.2% hotmail.com 25.8% yahoo.es 3.8% 79.8%

başa dön

Güney Afrika

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
ZA gmail.com 65.5% yahoo.com 4.1% hotmail.com 2.9% 72.5%

başa dön

İsveç

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
SE gmail.com 33.2% hotmail.com 21.0% canlı.se 3.0% 57.2%

başa dön

İsviçre

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
CH gmail.com 25.5% mavikazanç.ch 14.6% hotmail.com 10.5% 50.6%

başa dön

Birleşik Krallık

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
Birleşik Krallık gmail.com 30.8% hotmail.com 10.4% hotmail.co.uk 9.2% 50.4%

başa dön

Amerika Birleşik Devletleri

ISO Sağlayıcı #1 % Sağlayıcı #2 % Sağlayıcı #3 % Toplam
BİZ gmail.com 41.9% yahoo.com 15.1% hotmail.com 5.3% 62.3%

başa dön

DMARC nasıl çalışır?

DMARC, 2020 yılında Google Mail ve Office 365 ile nasıl çalışıyor?

En popüler kurumsal e-posta sağlayıcıları olan Google Mail ve Office 365'e
e-posta gönderiminin kimlik doğrulamasından nasıl etkilendiğini test ettik

Sonuçlar iki gruba ayrılabilir:

  1. E-posta teslimi
    (SPF, DKIM ve DMARC'ın gönderilen mesajların teslimini nasıl etkilediği)
    Google Mail: E-postalar her zaman kabul ediliyor, kimlik doğrulama hiç dikkate alınmıyor gibi görünüyor.
    Office 365: SPF ve DKIM'e genel olarak duyarlı. Gelen kutusuna ulaşan tutarlı sonuçlar elde etmenin tek yolu, bunları DMARC ile ilişkilendirmektir.
     

  2. Sahtekarlık koruması
    (SPF, DKIM ve DMARC'nin gönderenin e-posta adresinin sahtekarlığa karşı nasıl korunduğu*)
    * = mesajın gerçek kaynağından farklı birinden geliyormuş gibi görünmesini sağlar.
    Google Mail: DMARC ve SPF'yi (fail veya softfail niteleyicileri) birleştirerek, sahtekarlık yapan göndericiler Spam klasörüne filtrelenir veya reddedilir (DMARC ayarlarınıza bağlı olarak).
    Office 365: SPF (fail veya softfail niteleyicileri) sahte göndericileri Önemsiz e-posta klasörüne göndermek için yeterlidir.

 
Bunlar aşağıdaki gibi özetlenebilir:

e-postaların teslimi sahtekarlık koruması
Google Mail Her zaman kabul edilir, kimlik doğrulama hiç dikkate alınmaz dmarc + spf (başarısız veya geçici başarısızlık)
Office 365 dmarc + spf geçişi veya dmarc + dkim geçişi spf (başarısız veya geçici başarısızlık)

 
Aşağıda yapılan testlerin tam listesi bulunmaktadır.

Google Mail Office 365
spf Pass - dkim none gelen kutusu gelen kutusu
spf Başarısız - dkim yok gelen kutusu hurda
spf SoftFail - dkim yok gelen kutusu hurda
spf Nötr - dkim yok gelen kutusu gelen kutusu
spf yok - dkim yok gelen kutusu hurda
spf Pass - dkim pass gelen kutusu hurda*
spf Başarısız - dkim Başarılı gelen kutusu hurda
spf SoftFail - dkim pass gelen kutusu hurda*
spf Nötr - dkim geçişi gelen kutusu hurda*
spf yok - dkim geçişi gelen kutusu hurda*
spf Şifresi - dkim geçersiz gelen kutusu hurda
spf hatası - dkim geçersiz gelen kutusu hurda
spf SoftFail - dkim geçersiz gelen kutusu hurda
spf Tarafsız - dkim geçersiz gelen kutusu hurda
spf yok - dkim geçersiz gelen kutusu hurda
spf Geçişi - dkim geçersiz - dmarc reddi gelen kutusu gelen kutusu
spf hatası - dkim geçersiz - dmarc reddi dsn=5.0.0, stat=Hizmet kullanılamıyor hurda
spf SoftFail - dkim geçersiz - dmarc reddi dsn=5.0.0, stat=Hizmet kullanılamıyor hurda
spf Nötr - dkim geçersiz - dmarc reddi gelen kutusu gelen kutusu
spf yok - dkim geçersiz - dmarc reddi dsn=5.0.0, stat=Hizmet kullanılamıyor hurda
spf Geçişi - dkim geçişi - dmarc reddi gelen kutusu gelen kutusu
spf başarısız - dkim başarılı - dmarc reddet gelen kutusu gelen kutusu
spf SoftFail - dkim geçişi - dmarc reddi gelen kutusu gelen kutusu
spf Nötr - dkim geçişi - dmarc reddi gelen kutusu gelen kutusu
spf yok - dkim geçişi - dmarc reddi gelen kutusu gelen kutusu
spf Geçişi - dkim diff - dmarc reddi gelen kutusu gelen kutusu
spf hatası - dkim farkı - dmarc reddi dsn=5.0.0, stat=Hizmet kullanılamıyor hurda
spf SoftFail - dkim diff - dmarc reject dsn=5.0.0, stat=Hizmet kullanılamıyor hurda
spf Nötr - dkim diff - dmarc reddi gelen kutusu gelen kutusu
spf yok - dkim fark - dmarc reddi dsn=5.0.0, stat=Hizmet kullanılamıyor hurda

Notlar:

  • Gönderen adresi (görünür gönderici) ve zarfın gönderdiği adres (geri dönüş yolu) aynı etki alanından gelmektedir
  • “dkim pass”: dkim imzalama alanı, gönderen adresinin alanıyla aynıdır.
  • “DKIM farkı”: DKIM imzalama alanı, gönderen adresinin alanından farklıdır
  • İkinci gruptaki yıldız işaretleri, sonuçların zaman içinde tutarlı olmadığını göstermektedir