beyaz listeye alınmış IP adresleri

Kullanıcı kimlik doğrulamasıyla uğraşmadan e-posta gönderin.

Size, yalnızca bağlantınızın IP adreslerini kontrol ederek
geçiş yapmanıza izin verdiğimiz açık bir port sağlıyoruz

Hangi IP adreslerinden bağlandığınızı belirtmeniz yeterli
, e-postalarınızı göndermeye hazırsınız.

dijital olarak imzalanmış mesajlar

E-posta suistimaline karşı korunmak için, giderek daha fazla e-posta sunucusu
mesajı iletmeden önce gönderenin kimliğini doğruluyor

RealSender kullanmadan e-posta gönderdiğinizde , emin olamazlar
aldıkları mesajın sizin tarafınızdan oluşturulduğundan

RealSender kullanarak e-posta gönderdiğinizde , gönderdiğiniz tüm mesajlar
dijital olarak imzalanır, böylece alıcılar bunlara güvenebilir .

Gönderenin kimliğini doğrulamak için iki standart vardır: SPF ve DKIM.
RealSender her ikisini de sunmaktadır:

• SPF, belirli bir etki alanı için yetkili SMTP sunucularının hangileri olduğunu belirtir
• DKIM, belirli bir alan adından ve ilgili SMTP sunucusundan gönderilen her mesajı dijital olarak imzalar.
  DKIM imzalı mesajları kontrol etmek için kullanılan tüm bilgiler,
  alan adının DNS ayarlarında kaydedilir ve kilitlenir.

özel IP adresi

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

İnternet üzerinden herhangi bir iletişim bağlantısı kurulduğunda başka bir bilgisayar tarafından
otomatik olarak yakalanan, kişisel olarak tanımlanabilir bilgidir
İnternet üzerindeki hiçbir başka cihazın aynı IP adresine sahip olması mümkün değildir.
Bu, bir cihazın başka bir cihazla iletişim kurabilmesi için gereklidir.

"Özel" IP adresleri, e-posta mesajlarının gönderilmesi için önemlidir
çünkü itibarları, kabul edilip edilmemelerinde büyük etkiye sahiptir.

İş iletişiminde "paylaşımlı" IP adresleri kullanmak,
aynı müşteriye her seferinde farklı bir satış temsilcisi göndermeye benzer.
Tanımadığı müşteri, ona şüpheyle yaklaşacaktır.
Aşırı durumlarda, aynı satıcı her gün farklı ürünler sunarsa,
bir sonraki sefer kapıyı çaldığında artık kabul edilmeme olasılığı çok yüksektir.

İnternetteki çoğu SMTP hizmeti, müşterilerine "paylaşımlı" IP adresleri sağlar.
Her e-posta gönderdiğinizde farklı bir IP adresi atanır.
Benzer bir durum, "dakika başına" hizmet sunan bulut barındırma sağlayıcılarında da geçerlidir.
Bu durumda, bir veya daha fazla "geçici olarak atanmış" IP adresi verirler.

2009'daki kuruluşundan bu yana RealSender, yalnızca "özel" IP adreslerine sahip SMTP sunucuları sunmaya karar vermiştir.
Bu, her müşterinin zaman içinde değişmeyecek bir IP adresi alacağı anlamına gelir.
Bunu e-posta kimlik doğrulaması yoluyla kurumsal alan adına bağlamak, her ikisini de daha yetkili hale getirecektir.

İletişimleriniz tutarlı ve beklendiği gibi olursa,
alıcılar tarafından yavaş yavaş fark edilecek ve daha yüksek bir itibar kazanacaklardır.
otomatik olarak kabul edilip Önemli veya Yüksek Öncelikli olarak değerlendirilmesine
kadar yüksek seviyelere ulaşabilir

güvenlik ayarları

Mevcut posta sunucunuzdan RealSender'ın güvenli ortamına geçin.

Eğer SMTP sunucusu sizin alan adınız altındaysa, aynı kimlik doğrulama bilgilerini ve SMTP sunucu adını
kullanabilirsiniz

Kimlik doğrulaması yapmadan bile e-posta mesajlarını güvenli bir şekilde gönderebilirsiniz.

Bu alandaki konular:

e-posta istemci ayarları

RealSender'ı kullanmaya başlamak için:

1. Ücretsiz deneme hesabı talep edin
   
   
2. E-posta istemcinizdeki giden posta (SMTP) ayarlarını değiştirin:
   Outlook - Outlook 2007 - Outlook 2013 2016 - Mac OS/X Mail - Thunderbird - Zimbra Desktop
   Yukarıdaki listede yok mu? Bize ulaşın !
   Merkezi bir e-posta sistemi kullanıyorsanız " E-posta Sunucusu " alanını ziyaret edin
   Toplu e-posta göndermeyi planlıyorsanız " Bülten yazılımı " alanımızı kontrol edin
   
   
   
   
3. Gönderilen mesajların SPF ile kimlik doğrulaması yapılabilmesi için alan adınızın ayarlarını değiştirin
   (bu işlem genellikle deneme süresinden sonra yapılır).
   
   

• Neden mi? Alan adınızdan gönderilen e-postaların üçüncü taraf bir hizmet üzerinden gönderilmesini istiyorsanız,
  SPF kaydınızı hizmet sağlayıcısının IP adreslerinden teslimata izin verecek şekilde yapılandırmanız gerekir.
  Bunu yapmazsanız, e-posta alıcılarının alan adınızdan gönderilen tüm e-postaları reddetme riskiyle karşı karşıya kalırsınız.
  
  
• RealSender SPF kaydını oluşturmak çok kolay:
  Tek yapmanız gereken SPF kaydınıza include:spf.realsender.com eklemek ve işlem tamam

E-postaları otomatik olarak DKIM ile imzalıyoruz, bu nedenle başka bir şey yapmanıza gerek yok.

Sorularınız mı var? Bize ulaşın!

e-posta sunucusu ayarları

RealSender'ı kullanmaya başlamak için:

1. Ücretsiz deneme hesabı talep edin
   
   
2. E-posta sunucunuzdaki giden posta (SMTP) ayarlarını değiştirin:
   Microsoft Exchange Server - Microsoft Office 365 - Zimbra Collaboration.
   Yukarıdaki listede yok mu? Bize ulaşın !
   Bireysel olarak yapılandırılmış e-posta istemcileri kullanıyorsanız, " E-posta İstemcisi
   Toplu e-posta göndermeyi planlıyorsanız, " Bülten yazılımı " alanımızı kontrol edin
   
   
   
   
3. Gönderilen mesajların SPF ile kimlik doğrulaması yapılabilmesi için alan adınızın ayarlarını değiştirin
   (bu işlem genellikle deneme süresinden sonra yapılır).
   
   

• Neden mi? Alan adınızdan gönderilen e-postaların üçüncü taraf bir hizmet üzerinden gönderilmesini istiyorsanız,
  SPF kaydınızı hizmet sağlayıcısının IP adreslerinden teslimata izin verecek şekilde yapılandırmanız gerekir.
  Bunu yapmazsanız, e-posta alıcılarının alan adınızdan gönderilen tüm e-postaları reddetme riskiyle karşı karşıya kalırsınız.
  
  
• RealSender SPF kaydını oluşturmak çok kolay:
  Tek yapmanız gereken SPF kaydınıza include:spf.realsender.com eklemek ve işlem tamam

E-postaları otomatik olarak DKIM ile imzalıyoruz, bu nedenle başka bir şey yapmanıza gerek yok.

Sorularınız mı var? Bize ulaşın!

inxbox uygulaması

RealSender'ın "inxbox" uygulaması , yetkilendirilmiş alana gönderilen tüm mesajları alan
, kullanıma hazır bir e-posta sunucusudur
MX kaydı ona işaret ettiği anda hemen çalışmaya başlar.

Genellikle acil durum posta sunucusu olarak kullanılır.

Eğer kullandığınız e-posta servisi çökerse,
inxbox kendisine gönderilen tüm mesajları anında kabul eder. Bunun için
bireysel kullanıcı e-posta adreslerini belirtmek gibi
özel bir yapılandırmaya gerek yoktur

E-postaların geçmişe dönük arşivi olarak yapılandırıldığında ,
otomatik bir işlem mesajları
alıcıya, aya ve yıla göre kaydeder.

Başlıca özellikler:

spamstop uygulaması

Siber saldırıların ana kanalı e-postadır.

Gönderen adresinin sahtekarlığı, e-posta kimlik doğrulama bilgileriyle tespit edilebilir.

RealSender'ın "spamstop" uygulaması, kimlik doğrulama kontrollerinin sonuçlarını
alınan mesajların konu kısmında doğrudan gösterir.

Bu , adres defterinizde bulunmayan göndericilere göre mesajları ayıran
bir filtreyle birlikte kullanıldığında etkili bir spam önleme çözümüdür

Bu özellik, tüm alan adı için veya sadece birkaç e-posta adresi için etkinleştirilebilir.

Başlıca özellikler:

haber bülteni yazılımı ayarları

RealSender'ı kullanmaya başlamak için:

1. Ücretsiz deneme hesabı talep edin
   
   
2. E-posta bülten yazılımınızdaki giden posta (SMTP) ayarlarını değiştirin:
   GroupMail - Inxmail Professional - Joomla AcyMailing - MaxBulk Mailer - phplist
   SendBlaster - Sendy - WordPress MailPoet 3 - WordPress MailPoet 2 - WordPress Mailster
   Yukarıdaki listede yok mu? Bizimle iletişime geçin !
   copymail uygulaması ” seçeneğini değerlendirin !
   Bireysel olarak yapılandırılmış e-posta istemcileri kullanıyorsanız “ E-posta İstemcisi
   Merkezi bir e-posta sistemi kullanıyorsanız “ E-posta Sunucusu ” alanını ziyaret edin
   
   
   
   
3. Gönderilen mesajların SPF ile kimlik doğrulaması yapılabilmesi için alan adınızın ayarlarını değiştirin
   (bu işlem genellikle deneme süresinden sonra yapılır).
   
   

• Neden mi? Alan adınızdan gönderilen e-postaların üçüncü taraf bir hizmet üzerinden gönderilmesini istiyorsanız,
  SPF kaydınızı hizmet sağlayıcısının IP adreslerinden teslimata izin verecek şekilde yapılandırmanız gerekir.
  Bunu yapmazsanız, e-posta alıcılarının alan adınızdan gönderilen tüm e-postaları reddetme riskiyle karşı karşıya kalırsınız.
  
  
• RealSender SPF kaydını oluşturmak çok kolay:
  Tek yapmanız gereken SPF kaydınıza include:spf.realsender.com eklemek ve işlem tamam

E-postaları otomatik olarak DKIM ile imzalıyoruz, bu nedenle başka bir şey yapmanıza gerek yok.

Sorularınız mı var? Bize ulaşın!

Abonelikten çıkmayı kolaylaştırın

Alıcılara mesajlarınızdan kolayca abonelikten çıkma olanağı her zaman sunun. Kişilerin mesajlarınızdan abonelikten çıkmasına izin vermek, açılma oranlarını, tıklama oranlarını ve gönderim verimliliğini artırabilir. Önemli: Günde 5.000'den fazla mesaj gönderiyorsanız, pazarlama ve abonelik mesajlarınızın tek tıklamayla abonelikten çıkmayı desteklemesi gerekir. -- Gmail, E-posta gönderici yönergeleri, 2024

List-Unsubscribe başlıkları hakkında daha fazla bilgi edinmek için RFC 2369 ve RFC 8058'e.

Müşterilerimizin çoğunun gönderdikleri mesajlarda List-Unsubscribe: başlıklarını kullanmadığını göz önünde bulundurduktan sonra,
bu başlıklar zaten mevcut değilse her mesaja otomatik olarak eklemeye karar verdik.

İptal talepleri iki gün içinde işleme alınmalıdır.
Aboneliğinizi iptal etme talebinizi başka hiçbir şekilde iletmemelisiniz.

Gmail ve diğer sağlayıcılar tarafından otomatik olarak bir e-posta mesajı oluşturulacaktır.
Bu mesaj, bize bildirdiğiniz e-posta adresine (birden fazla e-posta adresi olsa bile) gönderilecektir.

Alternatif olarak, rsXXX-realsender.com/unsubs adresinden,
aşağıdaki örnekte olduğu gibi, son yedi gün içinde alınan tüm abonelikten çıkma isteklerine JSON formatında
erişebilirsiniz :

  { "posta kutusu": "rsXXX", "kimlik": "20241107T001800-0000", "gönderen": "<john.doe@gmail.com> ", "ile": [ "<abuse@rsXXX-realsender.com> " ], "konu": "RealSender :: rsXXX 7 Kasım 4A6NDqsl008203 :: lütfen abonelikten çıkın ::", "tarih": "2024-11-07T00:18:00.938050657+01:00", "posix-millis": 1730935080938, "boyut": 4350, "görüldü": false },

kapı görevlisi uygulaması

Yanlış/aktif olmayan alıcılara tekrar tekrar e-posta göndermek "spam gönderen davranışı" olarak kabul edilir.
Son yıllarda bu nedenle giderek daha fazla SMTP sunucusu kara listeye alınmıştır.

En belirgin hata, geri dönen mesajları alan "Gönderen/Dönüş Yolu" adresli posta kutusunun
dolu veya mevcut olmaması durumunda ortaya çıkar.
Binlerce mesaj gönderildiğinde, bunların %20'si geri dönerse, büyük bir gelen kutusunu bile dakikalar içinde doldurmak kolaydır.

Geri dönen tüm mesajları okumadan almak küçük bir kusur olarak görülebilir.
Kimsenin umursamadığı hata ayrıntılarıyla birlikte, sürekli olarak geri dönen adreslere e-posta gönderiyorsunuz.

Her iki durumda da sonuç, SMTP sunucusunun kara listeye alınmasıdır. Bu şekilde,
mesajlar geçersiz alıcılara iletilmeyecek, aynı zamanda geçerli alıcılar da bu mesajları SPAM olarak alacaktır.

İlk sorunu çözmek için uzun zamandır " bülten posta kutuları " sunuyoruz
Geri dönen mesajların analizi daha zordur ve çok iyi çalışan bir araç gerektirir.

Hatalı e-postaları analiz eden ve daha önce bounceHammer 4 olarak bilinen " Sisimai: Mail Analyzing Interface seçtik
açık kaynaklı yazılımı . Bu yazılım , RFC5322 geri dönen e-postaları ayrıştırarak JSON formatında yapılandırılmış veri üretiyor.

Sisimai'nin ayrıştırdığı tüm olası hata kodları hakkında fikir edinmek için, " SMTP Saha Kılavuzu " na göz atabilirsiniz
büyük e-posta servis sağlayıcılarından gelen ham SMTP hata kodu yanıtlarının bir derlemesi olan

Otomatik kara liste

RealSender'da geri dönüş işleyiciyi uygulamak basittir.

1. “ Bülten posta kutusunu ” etkinleştirin
2. Gönderen uygulamanızı yeni Return-Path adresini kullanacak şekilde yapılandırın
3. Kurulumun doğrulanmasını ve "geri dönüş işleyicisinin" etkinleştirilmesini isteyin

“Bouncehandler” uygulaması, geri dönen mesajları kontrol etmeye başlar.
İki engelleme listesi etkinleştirilir:

1. Kalıcı hata veren e-posta adreslerini içeren "kalıcı yanıt vermeyenler " https://…hardbounces.email.weekly
   listesi
   "kullanıcı bilinmiyor" veya "sunucuya ulaşılamıyor" gibi
   
   kalıcı hatalar üreten tüm e-posta adreslerini içerir.
   Haftalık kalıcı yanıt vermeme kayıtları şu web adresinde mevcuttur:

2. Geçici hatalar listesi,
   bu https://…softbounces.email.weekly
   en az bir hafta arayla meydana geldiği
   
   tüm e-posta adreslerini içerir.
   Haftalık geçici hata kayıtlarına şu web adresinden ulaşılabilir:

Kara listeye alınmış bir alıcıya mesaj göndermek şu şekilde bir hata oluşturacaktır:

Bloklarınızı bağımsız olarak yönetin

Size aşağıdaki dosyaları,
parola veya IP adresiyle korunan web adresleri olarak sağlıyoruz:

https://…bounces.json dosyası
, son yedi günde alınan geri dönüşlerin ayrıntılarını JSON formatında sunar; örneğin:

  { "feedbacktype": "", "adreser": "info@circuitocinemascuole.com", "diagnostictype": "SMTP", "timezoneoffset": "+0200", "lhost": "linp.arubabusiness.it", "destination": "gmail.com", "timestamp": 1635536166, "senderdomain": "circuitocinemascuole.com", "deliverystatus": "5.1.1", "token": "daad8f8fc89cef70e1406a9d2b38be6c35326e03", "alıcı": "...@gmail.com", "konu": "Prenotazioni aperte_Giornata Internazionale dei Diritti dell'Infanzia ve dell'Adolescenza_Film FIGLI DEL SOLE", "origin": "/home/rs109-bounce/Maildir/new/1635528969.21113_0.rsbox.realsender.com", "rhost": "gmail-smtp-in.l.google.com", "reason": "userunknown", "diagnosticcode": "550-5.1.1 Ulaşmaya çalıştığınız e-posta hesabı mevcut değil. Lütfen alıcının e-posta adresini yazım hataları veya gereksiz boşluklar açısından tekrar kontrol edin. Daha fazla bilgi için https://support.google.com/mail/?p=NoSuchUser adresini ziyaret edin. z3si7494964ybg.507 - gsmtp 503 5.5.1 RCPT first. z3si7494964ybg.507 - gsmtp", "messageid": "McuPi4DjtlyhvlSMVNB4wTXsUKQeIy6XwlKoAZuJ4@www.circuitocinemascuole.com", "listid": "", "action": "failed", "softbounce": 0, "replycode": "550", "catch": null, "alias": "", "smtpagent": "Sendmail", "smtpcommand": "DATA" },

https://… hardbounces.json
son yedi günde alınan sert geri dönüşlerin (hard bounce ⁾ ayrıntılarını JSON formatında içerir

https://…hardbounces.email kalıcı
son yedi gün içinde ^yanıt hatası (hard bounce) oluşturan e-posta adreslerinin listesi

¹ = seçim kriterleri: softbounce == 0

https://… softbounces.json
^2'nin ayrıntıları , JSON formatında

https://…softbounces.email soft
son yedi gün içinde bounce ² oluşturan e-posta adreslerinin listesi

² = seçim kriterleri: softbounce == 1

Bunlar, otomatik engelleme listesi tarafından kullanılan dosyalarla aynıdır:

https://…hardbouncesfull.email ,
birbirlerinden en az bir hafta arayla
iki veya daha fazla kalıcı hata (hard bounce) oluşturan tüm e-posta adreslerinin listesi.

https://…softbouncesfull.email ,
birbirlerinden en az bir hafta arayla
üç veya daha fazla yumuşak geri dönüş (soft bounce) oluşturan tüm e-posta adreslerinin listesi.

copymail uygulaması

RealSender'ın "copymail" uygulaması , e-posta istemcinizden doğrudan binlerce alıcıya
toplu e-posta göndermenizi sağlar

Üç kolay adımda:

1. Alıcı listenizi yükleyin
2. Dağıtmak istediğiniz mesajı size sağlayacağımız "list-post" e-posta adresine gönderin
3. Gönderimi başlatmak için mesajı onaylayın

Her alıcı, mesajı sanki yalnızca kendisine gönderilmiş gibi alacak ve
gönderen olarak sizin e-posta adresiniz görünecektir.

Temel özellikler:

• Üyelik Listesi
• Toplu Abonelikler
• Onay bekleyen mesajlar

Üyelik Listesi

başa dön

Toplu Abonelikler

başa dön

Onay bekleyen mesajlar

başa dön

kimlik doğrulaması olmadan SMTP

Bazen eski yazılımlar veya çok basit uygulamalar,
RealSender'ın gerektirdiği gibi güvenli bir kimlik doğrulama işlemi yapılmasına izin vermez.

Çözüm, SMTP sunucusu üzerinden geçiş için açık bir port sağlamak ve
yalnızca bağlantının IP adresini ve gönderenin e-posta adresini kontrol etmektir.

Bu sayede e-posta mesajlarınızı kimlik doğrulaması yapmadan gönderebileceksiniz,
ancak mümkün olan her durumda kimlik doğrulaması yapmanıza her zaman izin verilecektir.

RealSender ortakları ve büyük kuruluşlar,
yetkilendirilmiş IP adresleri listesini bağımsız olarak güncelleyebilirler.

özel sunucu adına sahip SMTP

Kurumsal bir SMTP sunucu adı, birden fazla uygulama ayarında kullanılır.
Bunu değiştirmek, zaman alan ve hata olasılığı yüksek bir işlemdir.

RealSender, aşağıdaki gibi alt alan adınızı tanımlamanıza olanak tanır:

smtp.youremaildomain.com

Güvenli SMTP kimlik doğrulaması için gerekli olan
SSL sertifikaları da dahil olmak üzere her şeyle biz ilgileneceğiz

Bu kurulum , SMTP sunucu adının sizin kontrolünüz altında olduğunu bilmenin
verdiği tam bir gönül rahatlığı sağlayacaktır

BT personelinizin ayarların nerede yapılandırıldığını hatırlamasına gerek kalmayacak
çünkü artık değiştirmeye gerek kalmayacak.

Lütfen dikkat: Gerekli özel yapılandırma,
teklif aşamasında belirtilecek
ek bir yıllık maliyet içermektedir

API üzerinden gönderme

Bu alandaki konular:

HTTP isteği yoluyla gönderiliyor

Bu alandaki konular:

Form oluşturucu aracılığıyla gönderme

İnternet üzerinden net ve yapılandırılmış bilgi almak karmaşık olabilir.
Kullanıcı arayüzünün doldurulması ve veriyi gönderen bir sunucu uygulamasına ihtiyaç duyar.

RealSender'ın "form oluşturucu" özelliği,
verileri doğrudan e-posta adresinize gönderecek,
tabletlerde ve küçük ekranlı akıllı telefonlarda da kullanılabilen , basit ve duyarlı formlar oluşturmanıza olanak tanır

Sorularınızı yapılandırmanıza yardımcı olacak birkaç "Sürükle ve Bırak" bileşeni şunlardır:

Kaynak kod, kullanıma hazır bir “form.html” dosyası olarak indirilebilir:

Form oluşturucuyu kendiniz şu adreste deneyebilirsiniz:
» formmail.realsender.com/form_builder

• Formu göndermenizi sağlayacak bir "Metin Girişi" alanı ve bir "Düğme" ( "Düğmeler" sekmesinde) ekleyin
• Dosyayı yerel olarak kaydetmek için ("Rendered" sekmesinde) "İndir" düğmesine tıklayın
• form.html dosyasını açın, biraz metin girin ve içeriği göndermek için düğmeye basın
  (NOT: Çevrimiçi olarak yayınlanmadığı için "Teşekkürler" sayfası kaba olacaktır).

Mesaj, RealSender'ın "geçici e-posta" hizmeti olan inxbox.realsender.com

NOT: form.html dosyasında üç parametre değiştirilebilir: - recipient = Alıcının e-postasıyla ilişkili kod. Kötüye kullanımı önlemek için e-posta adresi gönderme betiğinde önceden kodlanmıştır; "0" bırakılırsa mesaj RealSender'ın "geçici e-postasına" alınır. - email = Formu dolduran kişinin e-posta adresi (ID=email). Yalnızca formda "email" alanı YOKSA kullanılır. - subject = E-posta mesajının konusu

HTML dosyasını çevrimiçi olarak yayınlamak istiyorsanız ücretsiz deneme sürümü talep edin
Bu sayede aşağıdaki gibi şık bir onay açılır penceresi alacaksınız.
Girilen veriler doğrudan e-posta kutunuza gönderilecektir.

bağlantı oluşturucu aracılığıyla gönderme

Bağlantı oluşturucuyu şu adresten deneyebilirsiniz:
» flashmail.realsender.com/link_builder

Bazı örnekler

Bu ayki kampanya hakkında daha fazla bilgi için buraya tıklayın: https://click.youremaildomain.com/s/flash.pl?promo=yes

Etkinliğe katılmak isterseniz, buraya tıklayın: https://click.youremaildomain.com/s/flash.pl?event=yes

Yeni ürünü sipariş etmek için buraya tıklayın: https://click.youremaildomain.com/s/flash.pl?newproduct=yes

Aşağıda belirtildiği gibi, bağlantının sonuna e-posta adresini eklerseniz,
yanıt adresi eklenecek ve yanıt, bağlantıya tıklayan kişinin e-posta adresine gönderilecektir:

&email=name@example.com

Verilerin gönderilmesinin ardından görüntülenecek "açılış sayfasını" ayarlamak için,
aşağıdaki örnekte gösterildiği gibi bağlantının sonuna "rdir" parametresini ekleyin:

&rdir=/ok

Alternatif olarak, web sitenizin adresini belirtebilirsiniz, örneğin:

&rdir=www.example.com/thankyou

Kurmak

İletişimlerinizde yer alan bağlantıların
"kimlik avı girişimi" olarak değerlendirilmesini önlemek için,
gönderen alan adının bir alt alan adı yapılandırılmalıdır, örneğin:

click.youremaildomain.com CNAME click.realsender.com

Bildirim alıcısı (birden fazla olabilir) komut dosyasında belirlenir.
Bunu yapılandırma aşamasında bize bildireceksiniz.

Web posta

Yukarıdaki örneklerde, bildirimler
geçici e-posta adresimize ulaşmaktadır; bu adrese şu adresten ulaşabilirsiniz:
https://inxbox.realsender.com/monitor

kullanıcı kodu anahtar yöneticisi

"Kullanıcı kodu", kullanıcının korumalı bir sisteme giriş yaparken girdiği alfa/sayısal bir koddur.

RealSender'ın "kullanıcı kodu anahtar yöneticisi", her saat başı otomatik olarak benzersiz bir kullanıcı kodu oluşturur ve
bu kod, talep üzerine ilgili e-posta adresine gönderilir.

Yalnızca önceden yetkilendirilmiş e-posta adresleri kullanıcı kodu talep edebilir.
Kullanıcı kodunun uzunluğu ve karmaşıklığı sistem yapılandırması sırasında kararlaştırılır.

Örneğin, kullanıcı kodunu gönderen e-posta mesajının içeriği şöyledir:

Kullanıcı kodunuz: 665407 !! Kullanıcı kodu her saat başı 03:00'te sona eriyor

Güvenli sisteminizle entegrasyon basittir:

1. Kullanıcı kodunu almak için yetkilendirilmiş IP adresini yapılandırıyoruz
2. Sisteme erişim yetkisi olan her kullanıcı için şifreyi otomatik olarak güncelleyen bir cronjob* ( zamana dayalı görev zamanlayıcı
   kurarsınız
   (güncelleme, alınan kullanıcı koduna göre yapılmalıdır).

Güvenliği artırmak için, belirli sayıda başarısız giriş denemesinden sonra ziyaretçileri engelleyen
"fail2ban" korumasını etkinleştirmenizi öneririz

RealSender deneme hesabını etkinleştirerek bunu uygulamada görebilirsiniz .
E-posta göndermek için gerekli verilerle birlikte, kullanıcı alanınıza erişim yönergelerini de alacaksınız.

Örneğin, RealSender kullanıcı alanına ve web alanına erişim
talimatlarını içeren e-posta mesajının içeriği şöyledir :

Kullanıcı alanınıza erişim bağlantısı: https://username:usercode@rsXXX.realsender.com/reserved.area/ Web alanınıza erişim bağlantısı: https://username:usercode@rsXXX.realsender.com/view/ !! Erişim bağlantıları her saat başı :03'te sona erer

Bu durumda, kullanıcı kodu "temel kimlik doğrulama" ile korunan web tabanlı bir erişim sisteminde kullanılır.
Hem "kullanıcı adı" hem de "kullanıcı kodu" parametreleri otomatik olarak doldurulur ve
kullanıcıya basit ve hızlı bir erişim deneyimi sağlanır.

Sisteminiz otomatik giriş özelliğini desteklemiyorsa,
kullanıcı kodunu e-posta mesajı içinde PIN veya erişim kodu olarak iletebilir
ve kullanıcının bu kodu manuel olarak girmesini sağlayabilirsiniz, örneğin:

Güvenli örnek bağlantınız: https://secure.example.com - erişim kodu: 000000

emailconnect uygulaması

RealSender'ın "emailconnect" uygulaması,
aslen IBM tarafından geliştirilen Node-RED v5 tabanlı, açık kaynaklı, akış tabanlı bir görsel geliştirme aracıdır.

E-postayı ağa bağlı donanım aygıtları, API'ler ve çevrimiçi hizmetlerle entegre etmek için kullanılır.
Önceden tanımlanmış öğeleri sürükleyip bırakabileceğiniz
ve blok öğelerini (düğüm olarak adlandırılır) birbirine bağlayarak otomatik uygulamalar oluşturabileceğiniz web tarayıcı tabanlı bir arayüz sağlar.

Uygulama, aşağıdakiler gibi belirli görevler için tasarlanmış bazı iş akışlarıyla birlikte gelir:

• Google haber uyarıları
• SMTP durum kontrolü
• web sitesi durum kontrolü

Müşteriler , entegre RealSender hizmeti aracılığıyla e-posta gönderme işlemlerini kolayca
gerçekleştirebilir, akışları kendileri değiştirebilir veya bağımsız olarak kendi akışlarını geliştirebilirler

Sunulan sistem, sürekli güncellenen, güvenli ve güvenilir bir ortamda,
her müşteri için ayrı bir sanal sunucuda barındırılmaktadır
Hizmetler sürekli olarak izlenmekte ve gerektiğinde otomatik olarak yeniden başlatılmaktadır.

ters proxy uygulaması

E-posta proxy sunucusu size şunları sağlar:

• SMTP sunucunuzun güvenliğini, performansını ve ölçeklenebilirliğini iyileştirin
• Sertifikalı e-posta sağlayıcılarına sorunsuz bir şekilde bağlanın
• Tek satırla e-posta iletişimini basitleştirin
• NTfy uygulamasına (Android ve iPhone için mevcut) bildirim gönder
• Yalnızca cep telefonu numaraları bilinen alıcılarla iletişim kurmak

Başlıca Özellikler:

Hakkımızda

2006-2009 yılları arasında,
on yılı aşkın bir süre boyunca Alman menşeli bir e-posta pazarlama platformunun dağıtımını yaptıktan sonra,
SMTP sunucusunun itibarının önemini anladık.

Bunu garanti etmenin tek bir yolu vardı:
her müşteri için özel bir IP adresine sahip, özel bir SMTP sunucusu.

Bu, güvenilir ve sürekli olarak izlenen bir ortamda
yenilikçi çözümler sunma yolunda attığımız ilk adımdı

Görevimiz: "E-postalarınızı güçlendirmek".
Bunun için her gün çok çalışıyoruz.

Size giden e-postalar üzerinde tam kontrol ve bilgi sahibi olma imkanı vererek,
alıcıların mesajlarınızı güvenle almasını ve anlamasını sağlıyoruz.

iletişim

Ticari veya teknik sorular için:

1. Uzmanla sohbet etmek için bir bağlantı alın

2. Bir web formu doldurun

3. E-posta: contact@mx.realsender.com

4. Telefon: +41 61 5000365

5. SMS: +41 79 6276163

Ofisimiz Pazartesi-Cuma günleri, Orta Avrupa Saatiyle 09:00 ile 19:00 saatleri arasında açıktır.

Bize nasıl ulaşabilirsiniz:

• Stabio
  tren istasyonundaki Park+Rail (6855, İsviçre)
  
  
• Milano Malpensa (MXP)
  uluslararası havaalanı
  
  

KDV/AB KDV Kimlik No. IT02457460125

planlar ve fiyatlandırma

	RealSender, haftada 10.000'e kadar e-posta gönderebilen (genellikle bire bir/işlemsel e-postalar için kullanılan) tek bir özel SMTP sunucusuna sahiptir.
	HighSender, birden fazla özel SMTP sunucusuna tek bir e-posta ağ geçidi üzerinden yönlendirme yapar ve 2 ila 100 sunucu arasında otomatik dengeleme ile haftada 1.000.000'a kadar e-posta gönderebilir (genellikle haber bültenleri/toplu e-posta gönderimleri için kullanılır).
	"Uygulama" olarak tanımlanan hizmetler ek ücrete tabidir, daha fazla bilgi için lütfen bizimle iletişime geçin.

hizmet şartları

RealSender, istenmeyen e-posta reklamlarına (SPAM) karşı sıfır tolerans politikası uygulamaktadır. İstenmeyen ticari e-posta, yasaklı reklam veya diğer taciz edici veya yasa dışı materyalleri e-posta yoluyla gönderen müşterilerin hesapları, herhangi bir geri ödeme yapılmaksızın derhal sonlandırılacaktır. Yanlış alıcılara tekrar tekrar e-posta göndermek ve haftalık limite uymamak "spam gönderen davranışı" olarak kabul edilir.

Her RealSender hesabı için “gönderen e-posta adresleri”, aynı şirket tarafından kayıtlı bir veya daha fazla alan adı altında olmalıdır. Her sunucu haftada en fazla 10.000 e-posta gönderebilir. Her e-postanın alıcı sayısı 100 ile sınırlıdır. RealSender hizmeti yalnızca kurumsal kullanım içindir: hem tam posta adresi hem de vergi kimlik numarası gereklidir.

RealSender yalnızca e-postaları iletir ve bunların içeriğini hukuki, olgusal veya diğer açılardan kontrol etmez. RealSender ayrıca ilettiği e-postaların içeriğinden de sorumlu değildir.

Müşteri, hesabının her türlü kullanımından kaynaklanan her türlü sorumluluğa karşı RealSender'ı tazmin etmeyi kabul eder. Ayrıca, Müşteri, Hizmet Sözleşmesinin ihlali veya başka bir tarafa doğrudan veya dolaylı olarak verdiği zararla ilgili olarak ortaya çıkabilecek her türlü iddia ve masraftan (makul avukatlık ücretleri dahil) RealSender'ı tazmin etmeyi ve zararsız tutmayı kabul eder.

Müşteri, RealSender hizmetinin kullanımının tamamen kendi sorumluluğunda olduğunu açıkça kabul eder. RealSender veya bilgi sağlayıcıları, lisans verenleri, çalışanları veya temsilcilerinden hiçbiri, hizmetin kesintisiz veya hatasız olacağını garanti etmez; RealSender veya bilgi sağlayıcıları, lisans verenleri, çalışanları veya temsilcilerinden hiçbiri, hizmetin kullanımından elde edilecek sonuçlar konusunda herhangi bir garanti vermez. Hizmet, bu hizmet sözleşmesine uygulanan yasalar uyarınca ima edilen ve hariç tutulması, kısıtlanması veya değiştirilmesi mümkün olmayan garantiler dışında, açık veya zımni hiçbir garanti olmaksızın, "olduğu gibi" esasında dağıtılır; bu garantiler arasında mülkiyet garantileri veya zımni satılabilirlik veya belirli bir amaca uygunluk garantileri veya başka garantiler de bulunur. RealSender veya hizmetin oluşturulmasında, üretilmesinde veya tesliminde yer alan herhangi bir kişi, hizmetin kullanımından veya hizmetin kullanılamamasından veya herhangi bir garantinin ihlalinden kaynaklanan doğrudan, dolaylı, arızi, özel veya sonuçsal zararlardan sorumlu tutulamaz. Müşteri, bu paragraftaki hükümlerin üçüncü taraf içerikleri ve hizmet aracılığıyla sunulan diğer tüm içerikler için de geçerli olacağını açıkça kabul eder.

RealSender, Müşteriye yazılı, faks veya e-posta yoluyla bildirimde bulunması halinde, bu Hizmet Sözleşmesini veya fiyatları değiştirebilir ve önceden bildirimde bulunmaksızın, kendi takdirine bağlı olarak Hizmetin herhangi bir yönünü veya tamamını durdurabilir veya revize edebilir.

RealSender ve Inxbox, AB'de tescilli ticari markalardır.

teklifimizin sınırları

• Her müşteri için özel bir SMTP sunucusu hazırlanır, ayarlanır ve 7/24 aktif tutulur.
  Bu, paylaşımlı SMTP ortamlarında bulamayacağınız minimum maliyeti sağlar;
  paylaşımlı ortamlar ise çok az garanti sunar ve kullananlar için yüksek riskler taşır.

• Gönderilen mesajların içeriğini kontrol etmiyoruz; bu durum mesajların istenmeyen posta/gereksiz posta klasörüne düşmesine neden olabilir.

• Bazı ücretsiz e-posta sağlayıcıları, varsayılan olarak bilinmeyen göndericilerden gelen mesajları istenmeyen posta klasörüne gönderir. İstenmeyen
  
  posta önleme sistemleri, kullanıcılarının aldıkları mesajlarla ne yaptıklarından öğrenir.
  Alıcı, aldığı e-postayı bir kez istenmeyen posta olarak işaretlerse, sistem bunların geçerli mesajlar olduğunu öğrenir
  ve bunları "İstenmeyen Posta" yerine "Gelen Kutusu" klasörüne göndermeye başlar.
  
  Alternatif olarak, göndericinin alıcının adres defterinde olması veya daha önce e-posta alışverişinde bulunulmuş olması gerekir.
  
  Teknik ekibimiz, bu durumları belirlemenize ve etkili bir teslimat stratejisi uygulamanıza yardımcı olacaktır.

Gizlilik politikası

RealSender, müşterileri adına e-postaları iletir ve içeriği izlemez veya arşivlemez.

Son 7 güne ait kayıtları ve oluşturulan trafiğe ilişkin istatistikleri tutuyoruz ve bu veriler, burada açıklandığı gibi müşterilerimizin kullanımına sunulmaktadır:
Kayıtlar ve teslimat
istatistikleri

Hizmetin kullanımı, müşterilerimizin Hizmet Şartlarını kabul etmesine bağlıdır.

Kötüye kullanım durumlarında, kara listeye alma sistemimiz sayesinde hızlı bir şekilde harekete geçiyoruz.

Sunucularımızın ana sayfalarının tamamında, müşterilerimiz tarafından gönderilen istenmeyen reklam e-postalarını bildirmek için şu e-posta adresi yer almaktadır: [abuse@realsender.com] (mailto: abuse@realsender.com)

Veri Koruma Sorumlusuna bu formu doldurarak ulaşabilirsiniz .

sözlük

• Kapalı döngü pazarlama,
  müşteri verilerinin pazarlama kampanyalarınızı besleyerek satış performansını artırmasına olanak sağlayan süreçtir.

• Alan Anahtarlarıyla Tanımlanmış E-posta (DKIM)
  , göndericinin giden e-postaları alıcı tarafından doğrulanabilecek şekilde imzalamak için açık anahtar şifrelemesini kullanmasını sağlayan bir e-posta kimlik doğrulama protokolüdür. DKIM spesifikasyonu, önceki Alan Anahtarları ve Tanımlanmış İnternet E-postası protokollerine dayanmaktadır. DKIM, IETF RFC 4871'de tanımlanmıştır. DKIM standardı, Gmail ve diğer büyük şirketler tarafından internet e-postalarından kimlik avı ve sahtekarlığı tamamen ortadan kaldırmak için zaten benimsenmektedir.

• Bir e-posta mesajının, gönderildiğini iddia ettiği alan adından kaynaklanıp kaynaklanmadığını doğrulayan e-posta kimlik doğrulama teknolojisi [2]. Bir e-postada geçerli bir kimliğin sağlanması, spam, sahtekarlık, dolandırıcılık ve hatta daha ciddi suçları durdurmada hayati bir ilk adım haline geldi. [3]

• İnternet Mühendisliği Görev Gücü (IETF),
  internet mimarisinin evrimi ve internetin sorunsuz çalışmasıyla ilgilenen ağ tasarımcıları, operatörleri, satıcıları ve araştırmacılarından oluşan büyük, açık ve uluslararası bir topluluktur. İlgilenen herkese açıktır. IETF'nin amacı internetin daha iyi çalışmasını sağlamaktır.

• Mesaj Aktarım Aracısı (MTA)
  , bir mesajı alıp işleyebilen, DNS'te (veya diğer yönlendirme tablolarında) hedef bilgilerini arayabilen ve amaçlanan alıcı sisteme iletebilen, SMTP yönlendirme yazılımı çalıştıran herhangi bir sistemdir. MTA'lar tipik olarak Sendmail, Microsoft Exchange, Postfix, Lotus Domino, qmail, PowerMTA vb. gibi sunucu uygulamalarıdır.

• SMTP sunucusu ve istemcisinin İnternet üzerinden özel, kimlik doğrulamalı iletişim sağlamak için TLS (Transport Layer Security) kullanmasına olanak tanıyan SMTP hizmetine uzantısı. [1]
  güvenli SMTP

• Gönderici Politika Çerçevesi (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.

• Basit Posta Aktarım Protokolü (SMTP),
  İnternet Protokolü (IP) ağları üzerinden elektronik posta (e-posta) iletimi için bir İnternet standardıdır. SMTP ilk olarak Jonathan Postel tarafından IETF RFC 821'de (1982) tanımlanmış ve son olarak genişletilmiş SMTP (ESMTP) eklemelerini içeren IETF RFC 5321 (2008) ile güncellenmiştir ve bugün yaygın olarak kullanılan protokoldür. SMTP, giden posta iletimi için belirtilmiştir ve 25 numaralı bağlantı noktasını kullanır.

• Taşıma Katmanı Güvenliği (TLS),
  internet üzerinden iletişim güvenliği sağlayan bir protokoldür. Protokol, istemci/sunucu uygulamalarının gizlice dinlemeyi, kurcalamayı veya mesaj sahteciliğini önleyecek şekilde iletişim kurmasına olanak tanır. TLS, IETF standart izleme protokolüdür ve en son RFC 5246'da güncellenmiştir.

Referanslar:

[1] RFC 3207 - Taşıma Katmanı Güvenliği Üzerinden Güvenli SMTP için SMTP Hizmet Uzantısı
[2] 2008 OTA E-posta Kimlik Doğrulama Durum Raporu
[3] David MacQuigg tarafından E-posta Kimlik Doğrulaması

e-posta kimlik doğrulamasının temelleri

Bu alandaki konular:

e-posta kimlik doğrulaması gelişmiş

Bu alandaki konular:

e-posta teslimat analizi

Bu alandaki konular:

sistem durumu sayfası

Hizmetin doğru çalışmasını doğrulamak için
otomatik bir kontrol ortamı etkinleştirdik.

Harici bir uygulama her on dakikada bir her SMTP sunucusuna bağlanır
, sistemin kullanılabilirliğini ve doğru çalışmasını
garanti etmemizi sağlar

Sonuç, RealSender sunucunuzun "durum sayfası"nda yayınlanır ve
bu sayfaya rsXXX-realsender.com/status adresinden ücretsiz olarak erişilebilir.

Veriler, aşağıda gösterilen örnek verilerde olduğu gibi gerçek zamanlı olarak görüntülenir.
Gösterilen bilgiler son yirmi dört saate aittir.

2024-09-11 06:25:26 UTC rsXXX - her on dakikada bir ÇALIŞMA SÜRESİ KONTROLÜ (bir e-posta başarıyla gönderildi) - Tamam 2024-09-11 06:16:18 UTC rsXXX - her on dakikada bir ÇALIŞMA SÜRESİ KONTROLÜ (bir e-posta başarıyla gönderildi) - Tamam 2024-09-11 06:05:56 UTC rsXXX - her on dakikada bir ÇALIŞMA SÜRESİ KONTROLÜ (bir e-posta başarıyla gönderildi) - Tamam 2024-09-11 05:55:41 UTC rsXXX - her on dakikada bir ÇALIŞMA SÜRESİ KONTROLÜ (bir e-posta başarıyla gönderildi) - Tamam 2024-09-11 05:45:57 UTC rsXXX - her on dakikada bir ÇALIŞMA SÜRESİ KONTROLÜ (bir e-posta başarıyla gönderildi) - Tamam 2024-09-11 05:35:58 UTC rsXXX - her on dakikada bir ÇALIŞMA SÜRESİ KONTROLÜ (e-posta başarıyla gönderildi) - Tamam 2024-09-11 05:25:27 UTC rsXXX - her on dakikada bir ÇALIŞMA SÜRESİ KONTROLÜ (e-posta başarıyla gönderildi) - Tamam 2024-09-11 05:16:30 UTC rsXXX - her on dakikada bir ÇALIŞMA SÜRESİ KONTROLÜ (e-posta başarıyla gönderildi) - Tamam 2024-09-11 05:05:57 UTC rsXXX - her on dakikada bir ÇALIŞMA SÜRESİ KONTROLÜ (e-posta başarıyla gönderildi) - Tamam 2024-09-11 04:55:36 UTC rsXXX - her on dakikada bir ÇALIŞMA SÜRESİ KONTROLÜ (e-posta başarıyla gönderildi) - Tamam

click.it izlenen bağlantılar oluşturur

Bu sayfa, verileri gönderecek izlenen bağlantılar oluşturur:
» clickit.realsender.com

Ücretsiz sürüm , bazı sınırlamalarla birlikte tamamen işlevseldir:

• E-posta mesajları, inxbox demo geçici posta kutusuna gönderilir ve yedi gün boyunca orada saklanır
• Tıklamanın ardından tarayıcı standart bir "teşekkür" sayfası gösterecektir
• Takip edilen alan adı "click.it"tir

Ücretli sürüm özelleştirilebilir ve size şunları sağlar:

• Mesajları e-posta adresinize gönderin, örneğin: test@example.com
• Kendi açılış sayfanızı belirtin, örneğin: www.example.com/thankyou
• İzleme için kendi alt alan adınızı kullanın, örneğin: https://click.example.com

Enigma sırları güvenli bir şekilde paylaşıyor

E-posta gizli veya güvenli değildir. Gizlilik veya güvenlik düşünülerek tasarlanmamıştır .
, 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

E-posta için uçtan uca (e2ee) şifreleme, yalnızca gönderenin ve alıcının mesajın içeriğini okuyabilmesini
sağlamak için kullanılabilir
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.

“ Enigma ” , RealSender tarafından seçilip barındırılan, Yopass projesine dayalı açık kaynaklı bir uygulamadır
Mesajları, şifreleri ve dosyaları güvenli, geçici (çok kısa süreliğine geçerli) bir şekilde paylaşmanıza olanak tanır
Tek veya çok satırlı bir gizli anahtar girin, geçerlilik süresini belirtin ve [Mesajı şifrele] düğmesine tıklayın.
Tek kullanımlık URL'yi hedeflediğiniz alıcıyla paylaşın.

email.locker geçici arşivi

email.locker, e-posta mesajlarının saklanabileceği ve gerektiğinde alınabileceği bir yerdir.
E-posta mesajları yedi gün sonra otomatik olarak silinir.

Şimdi deneyin:

1. any.word@email.locker adresine mesaj gönderin.
2. Kutuya şu adresten erişebilirsiniz: https://email.locker/any.word

Email.locker kutuları, onlara bir e-posta mesajı gönderilerek anında oluşturulur.
Kayıt olma zorunluluğu olmadığı için email.locker adresi esasen bir şifredir,
bu nedenle kolayca tahmin edilemeyecek bir şey seçin.

Hassas bilgiler alıyorsanız, kutuyu rezerve etmeyi ve erişimi kısıtlamayı
veya "@locker.yourcompany.com" adresinden özel bir e-posta kilidi edinmeyi düşünün. Ayrıntılar için bizimle iletişime geçin

email.locker adresine gelen tüm mesajlar RealSender kimlik doğrulama kontrolleriyle taranır,
böylece gönderen adresinin gerçek mi yoksa sahte mi olduğunu doğrulayabilirsiniz.

Gelen her e-postanın konusuna,
SPF ve DKIM ile doğru şekilde doğrulanıp doğrulanmadığını gösteren bir önek eklenir .
Gönderenin alan adının doğruluğundan %100 emin olduğunuzda ise sonuna || OK || eklenir

inxsend sahte SMTP/API servisi

inxsend, uygulamalarda e-postaları kolayca test etmek için kullanılan, tüm mesajları tek bir posta sunucusuna gönderen sahte bir SMTP/API hizmetidir

SMTP sunucu ayarları

SMTP sunucusunu aşağıdaki parametrelerle yapılandırın:

Sunucu Adı: inxsend.realsender.com Port: 25 |veya| 2525 |veya| 587 (+TLS) |veya| 465 (+SSL) Kullanıcı Adı: CDED54 Şifre: 478DED

API sunucu ayarları

" API üzerinden gönderme " talimatlarında açıklandığı gibi , aşağıdaki parametrelerle API erişimini kullanın:

Sunucu adresi: (https://) inxsend-api.realsender.com/mail/send apiuser: CDED54 apipass: 478DED

Bir test mesajı gönderin

[Adınız]@inxbox.realsender.com
adresine mesaj gönderin.

!! Gelen tüm mesajlar herkes tarafından görülebilir !!
(Diğer alıcılara gönderilmeyecektir)

Herhangi bir sorunla karşılaşırsanız lütfen bize bildirin

Resepsiyonu kontrol edin

https://inxbox.realsender.com/monitor adresini açın ve sinyal olup olmadığını kontrol edin
(Google Chrome tarayıcısını > Yeni Gizli Pencere veya Microsoft Edge tarayıcısını kullanın).

Bu posta kutusu hakkında daha fazla bilgi şu adreste mevcuttur: inxbox uygulama demosu.

SPF ve DKIM doğrulama test cihazı

RealSender , e-posta mesajı göndererek SPF ve DKIM ayarlarınızı doğrulamak için
ücretsiz bir çevrimiçi kontrol aracı sunmaktadır :

1. spf@tester.realsender.com adresine bir e-posta gönderin.
2. SPF doğrulama sonuçlarını tester.realsender.com/spf
   (görüntülenmesi bir dakika sürebilir).

Doğrulama sırasında, mesaj doğru şekilde doğrulanmazsa
konu başlığına bir önek eklenir

İşleyişine dair ayrıntılar,
web sitesinin "e-posta kimlik doğrulamasının temelleri" bölümünde yer almaktadır:

• <spf>çevrimiçi kontrol edin
• <dkim>çevrimiçi kontrol edin

E-posta kimlik doğrulama yönergeleri

!! 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ü

DİZİN

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ır¹.

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

1.3. Referans Belgeleri

» 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.

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 ⁴ 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ı ⁵ 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 sunucusu^6, 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ştirilebilir⁷.

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.

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üm¹⁰;
• a: kullanılan şifreleme algoritması¹¹;
• d: Mesajın orijinalliğini beyan eden imzalama alanı¹²;
• s: DNS kaydında hangi DKIM genel anahtarının aranacağını belirten seçici¹³;
• h: imzaya dahil edilen e-posta başlıklarının listesi¹⁴;
• bh: mesaj gövdesinin base64 formatında kodlanmış özeti¹⁵;
• b: Özel anahtarla oluşturulan ve base64 formatında kodlanan gerçek dijital imza¹⁶;
• 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ı ¹⁷ ve b alanında imzalama alanının özel anahtarıyla oluşturulan mesajın dijital imzasını içerir.

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 eden^adı 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)

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üm²⁰;
• 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.

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

BCC e-postalarına iyi bir alternatif

Ö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?
• GNU Mailman "tek yönlü" liste
• GNU Mailman hakkında bazı tarihsel bilgiler
• VERP sıçrama yönetimi
• "Gönderen" ve "Posta Gönderen" adreslerinin hizalanması

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

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

• e-posta adresleri:
  [a-zA-Z0-9._-]+@[a-zA-Z0-9._-]+\.[a-zA-Z0-9_-]+
  kaynak: stackoverflow - regex ile dizelerden e-posta adreslerini ayıklama

• Bir tarih:
  \d{4}-\d{2}-\d{1,2}
  Kaynak: Stack Overflow - Dizeden tarih çıkarmak için regex

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.

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.

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"

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.

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üş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.

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?
  • Onları görmezden gelemezsiniz
  • Onların anlamını anlamalısınız
  • Sekme kontrolünün nasıl çalıştığını bilmelisiniz
• Sıçrama sayısını kontrol edin
• Sekme yönetimi için yeni trendler
• Geri dönen mesajların durum kodları

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.
  
  
  
• Sınıflandırma, düzenlenebilen bazı kurallara tabidir
  
  
  
• Seçenekler, yumuşak sekme hareketlerinin ne zaman sert sekme hareketine "yükseltileceğini" tanımlar
  
  

» 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

Sekme yönetimi için yeni trendler

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

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.

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.

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
• Doğrulanmış bir gönderici neden bu kadar önemli?
• Alan hizalaması nedir?
• CNAME kaydı mı yoksa TXT kaydı mı daha iyi?
• Özel IP adresi nedir?
• Şirketin alan adı DNS ayarlarını doğrudan biz mi yönetmeliyiz?

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ı.

* = 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.

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

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

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

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:

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

"İ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:

• E-posta gizliliği: Bugün neler oluyor?
• “yasal” açıdan
• “yasadışı” tarafta
  
  
• E-posta gizliliği: zorluklar
• Anonimlik ve Gizlilik
• Uçtan Uca Şifreleme
  
  
• E-posta gizliliği: çözümler
• < teknik > Oldukça İyi Gizlilik - PGP olarak da bilinir
• < teknik > PGP şifrelemesi nasıl kullanılır
• < easy > PGP şifrelemesine alternatifler

bugün neler oluyor

“yasal” açıdan

“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.”

• -  CIA'den Gus Hunt'ın Büyük Veri Üzerine Görüşleri, Huffington Post'ta
• -  CIA'den Gus Hunt'ın Büyük Veri Üzerine Konuşması, YouTube'da

“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.”

• -  Edward Snowden - TED 2014

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 […]

• -  Glenn Greenwald - TEDGlobal 2014

“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.

• -  Dolandırıcılık Kaynak Merkezi - İş E-posta Güvenliğinin Tehlikeye Atılması

İş 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
[…]

• -  Dolandırıcılık ve Güvenlik - İş E-posta Güvenliğinin Ele Geçirilmesi

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.

• -  TOR Nasıl Çalışır - Computerphile

İ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.

• -  E-posta Öz Savunması - GnuPG şifrelemesiyle gözetlemeye karşı mücadele rehberi

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.

• -  Thunderbird'de Uçtan Uca Şifreleme Nedir?

başa dön

çözümler

< 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.

• -  Wikipedia'da Pretty Good Privacy (Gizlilik Konusunda İyi Bir Yaklaşım)

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.

• -  E-posta Öz Savunması - Bilgilendirici Grafikler

< 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ı:

• Mailvelope, Mozilla Firefox ve Google Chrome için kullanılabilen ücretsiz, açık kaynaklı bir tarayıcı eklentisidir ve
  PGP'ye yaklaşmanın muhtemelen en kolay yoludur.
  "Mailvelope Tanıtımı" iyi hazırlanmış bir eğitim videosudur.

• Mozilla Thunderbird uygulaması, PGP imzalı mesajlar göndermek için gereken her şeyi entegre eder.
  Thunderbird'de Uçtan Uca Şifrelemeye Giriş

• GnuPG, OpenPGP standardının eksiksiz ve ücretsiz bir uygulamasıdır.
  Gpg4Win kullanarak bir Acemi PGP Rehberi [Kolay 5 Dakikalık Kurulum] nasıl kullanılacağını açıklıyor.

< 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

2. 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,

• e-posta pazarlama kampanyaları
• izin tabanlı pazarlama

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:

• kullanıcı tepkilerini takip etmek
• İki seviyeli izin (gizlilikle ilgili sorunlar)
• kullanıcı takibi nasıl çalışır
• Açılma oranı ölçümünün nasıl çalıştığı

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 teslim edilebilirliği
• tohum e-postaları
• hemen çıkma oranları
• e-posta pazarlama kıyaslama ölçütleri

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

İki seviyeli izinler - gizlilikle ilgili sorunlar

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:

• Mailchimp müşterileri, tek kişilik girişimlerden,
  küçük işletmelerden "Fortune 500" şirketlerine kadar geniş bir yelpazeyi kapsıyor;
  bu verilerde tüm yelpaze temsil ediliyor.

• Sektöre Göre E-posta Pazarlama Kıyaslamaları ve İstatistikleri

• Campaign Monitor , Ocak ve Aralık 2020 tarihleri ​​arasında
  dünya genelinde gönderilen 100 milyardan fazla e-postayı analiz etti.

• Sektöre ve güne göre e-posta performans karşılaştırmaları

• Bölgeler arasındaki kıyaslama ölçütlerini karşılaştırın

• Return Path'in sekizinci yıllık e-posta teslim edilebilirlik kıyaslama raporuna
  bakarak kaç e-postanın gelen kutusuna, spam klasörüne veya engellenen klasöre teslim edildiğini görebilirsiniz.
  
  2020 Teslim Edilebilirlik Kıyaslama Raporu (PDF) içeriği :

• Teslim edilebilirlik nedir ve nasıl ölçülür?

• Gönder düğmesine bastıktan sonra bir e-postaya neler olabilir?

• Dünya genelinde ortalama olarak kaç e-posta gelen kutusuna ve spam filtresine düşüyor?

• 30 ayrı ülke için teslim edilebilirlik istatistikleri

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.

• Kullanıcıların
  mesajlara vereceği tepkiler, alıcılar tarafından beklenilen/istenilen tepkiler olmalıdır.
  
  
• Teknik noktalar:
  E-posta mesajlarının kabul edilmesi için temel ayarlar gereklidir.
• IP adresi ve IP sınıfı itibarı
• doğru SMTP sunucu kurulumu
• Doğru e-posta kimlik doğrulaması
• SPAMASSASSIN kontrolü
  
• Deneyin ve ne olacağını görün.
  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.

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 , 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ı, 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:

• iki tür iş e-posta adresi
• Genel iş e-posta adresleri, herhangi bir kısıtlama yok
• şirket araçlarındaki kişisel şirket posta kutusu gibi
• davranışsal yönergeler
• yalnızca belirli koşullar altında okunabilir
• çalışanı bilgilendirin
• Büyük çaplı çekler yasaktır
• yasal gereklilikler
• e-posta mesajlarını arşivleme yükümlülüğü
• çalışanı bilgilendirme yükümlülüğü
• e-posta mesajlarını silme yükümlülüğü
• posta kutularını devre dışı bırakma yükümlülüğü

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?
• Spam'in maliyetleri nelerdir?
• En yeni spam önleme teknikleri nelerdir?
  • Spam önleme (oluşmadan önce)
  • Spam'i (oluştuğu sırada) ortadan kaldırın

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ı.

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-posta gönderim testi sonuçları

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

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ış)

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

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

başa dön

Avustralya

başa dön

Belçika

başa dön

Brezilya

başa dön

Kanada

başa dön

Şili

başa dön

Çin

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

başa dön

Kolombiya

başa dön

Danimarka

başa dön

Fransa

başa dön

Almanya

başa dön

Hindistan

başa dön

Endonezya

başa dön

İtalya

başa dön

Japonya

başa dön

Meksika

başa dön

Hollanda

başa dön

Yeni Zelanda

başa dön

Rusya