Bana gönderilen e-posta MAIL@MAIL.COM adresine gönderilir. Bu nasıl yapılır?

Geçenlerde bir aldatmaca e-posta gönderildi ve kıkırdıyor için onu okumak için açtım. Çok sade ve fazla çaba sarfedilmedi.

Özel bir şey fark ettim; bu e-posta bana gönderilmedi. İlk başta bir CC'den veya bir BCC'den şüphelenmiştim, ancak hiçbir yerde adresimde posta adresim yok. Aşağıda bir resim verdim. Bu nasıl yapılır?

Bir İnternet e-posta mesajı iki bölümden oluşur. Onlara zarf ve yük mesajı veya basitçe mesaj olarak bakabiliriz .

Zarfın yönlendirme verileri var: öncelikle, gönderen adresi ve bir veya daha fazla alıcı adresi.

Mesajın mesaj içeriği vardır: konu satırı, mesaj gövdesi, ekler, vb. Ayrıca, trace ( Received:) başlıkları, DKIM verileri vb. Gibi bazı teknik bilgileri de taşır ; yanı sıra görüntülenen gönderen ve alıcı adresleri (sen gördüklerinizi From, Tove Ccalanlar posta istemcisi).

İşte bunun özü: İki anlaşmaya varmak zorunda değilsiniz!

Mesajın nasıl gönderileceğini belirlemek için bir posta sunucusu zarf verilerine bakacaktır. Öte yandan, birkaç istisna dışında, mesajın kendisi sadece veri olarak değerlendirilecektir. Özellikle, bir uslu posta sunucusu değil bakmak To:ve Cc:alıcıların listesini belirlemek için mesajın kendisi alanlarında, ne de nasıl bakar From:gönderenin adresini belirlemek için sahada.

Bir e-posta oluşturup gönderdiğinizde, e-posta istemciniz Kime, Bilgi ve Gizli alanlarına girdiklerinizi alır ve bunu zarf yönlendirme bilgilerine dönüştürür. Bu, esasen herhangi bir tam adı kaldırarak yapılır (yalnızca e-posta adreslerini bırakarak), ancak adres yeniden yazma, takma ad genişletme vb. Şeyleri de içerebilir. Sonuç, posta istemcinizin konuştuğu posta sunucusuna alıcıların listesi olarak verilen e-posta adreslerinin bir listesidir. Kime ve Bilgi listeleri e-postada tutulur, ancak Bcc sunucuya iletilmez ve bu da mesaj alıcılarına görünmez hale gelir. Gönderenin adresi çok benzer şekilde çalışır.

Mesaj son hedefine ulaştığında, zarf verileri atılır veya ayrıntılı mesaj başlıklarında tutulur. Bu Spittin 'BT'nin soruna bir yorum yazarken tüm mesaj başlıklarını sormasının nedeninin bir kısmı.

Ek olarak, İnternet e-postasıyla, doğrudan bir posta sunucusuyla konuşmak ve böylece normal, iyi davranışlı bir e-posta istemcisinin yapamayacağı zarf verileri ile ileti verileri arasında uyuşmazlık bulunan bir mesaj enjekte etmek mümkündür. oluşturmana izin ver. Ayrıca, posta sunucuları gönderenin adresinde zarf verilerinde verilmiş oldukları çeşitli derecelerde kontroller yapar; Bazıları , sözdizimsel olarak geçerli bir e-posta adresi olduğundan emin olmaktan öte , neredeyse hiç kontrol etmiyor . Mesaj verilerinin başlığından daha az incelemeye tabi tutulur.

Alıcı e-posta istemcisi, Kimden, Kime ve Cc başlıklarında ne olduğunu gösterdiğinden, zarftaki adres verilerini değil, orada istediğiniz herhangi bir şeyi koymak mümkündür ve alıcı e-posta istemcisinin kendisine güvence vermekten başka bir isteği olmaz makul derecede doğru. Meşru posta için genellikle yeterince doğrudur; spam için, neredeyse asla.

Bizim tarafımızdan isimlendirilen somut, fiziksel nesneler dünyasında , zarf gönderici ve zarf alıcısı , zarfın dışına yazdığınız sırasıyla iade adresine ve alıcı adresine karşılık gelir; ve From:ve To:/ Cc:başlıkları, zarfın içine yazdığınız mektuba sırasıyla sizin ve alıcının adresleri olarak yazdıklarınıza karşılık gelir.

tl; altta dr.

SMTP protokolü CC veya BCC alıcıları kavramına sahip değildir; Bu posta müşterileri tarafından düzenlenen bir kongredir. SMTP sunucusu sadece yönlendirme bilgileri ve verilerini önemser. Bu önemli bir ayrımdır, çünkü bu özellik olmadan, BCC mevcut olamazdı. Meşru BCC iletişimi olarak aşağıdaki müşteri transkriptini düşünün:

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<anonymous@another-mail-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
BCC: "Anonymous" <anonymous@another-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

Şimdi, bu durumda, Anonim bu toplantı hakkında bir mesaj gönderildi. Ancak, posta bu sürümü oldu değil Jane Doe yönlendirilir; Anonim'e bildirilmekle ilgili hiçbir şey bilmiyor. Buna karşılık, Jane Doe farklı bir beden ve başlık ile mesaj gönderilecektir:

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<jane.doe@to-mail-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

Burada, Anonim BCC'de olduğundan, Jane Doe'ye gönderilen mesaj BCC alıcı listesini içermiyordu. BCC sözleşmesi nedeniyle, e-posta zarfı mesajı gerçekten alan alıcıları içermeyebilir ve ayrıca mesaj başlıklarında görünmeyen alıcıları da içerebilir.

Aynı zamanda dahil etmek istediğim @JonasWielicki tarafından belirtildiği gibi, MUA'nın (Posta Kullanıcı Aracısı) tipik olarak BCC'yi uygulamak için gereken birden fazla e-postayı göndermekten sorumlu olmasıdır. E-posta sunucuları BCC hakkında hiçbir şey bilmez ve bu nedenle MUA, zarf başlıklarında belirtilen farklı e-posta yollarına sahip birden fazla e-posta göndererek MUY'yi uygulamak zorundadır. Bu nedenle, BCC'lerin normal e-postalardan daha uzun yol alması gerekir, çünkü farklı mesaj gövdelerinin ayrı ayrı oluşturulması ve gönderilmesi gerekir.

Bu aynı zamanda bazı e-posta uygunluk kurallarına yardımcı olur. Örneğin, bir posta sunucusu otomatik olarak BCC'yi bir arşiv e-posta sunucusuyla (kendisine gönderilen tüm e-postalar da arşivlenir) otomatik olarak yapılandırılmış kurallara sahip olabilir; bu durumda posta sunucusu gerçek bir alıcı olmayabilir.

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<mail-archive@archive-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
BCC: "Anonymous" <anonymous@another-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

Burada alıcı, herhangi bir alıcıya ve hatta gönderene açıklanmayan başka bir taraftır. Bu, genellikle iletilerin iletilmesinde veya arşivlenmesinde kullanılan protokolün bir özelliğidir.

Bu spam mesajının yaptığı, bu davranıştan yararlanmak. Teknik olarak herhangi bir uyumlu posta sunucusuyla çalışması gereken standart bir boşluktur. Tabii ki, güncellenmiş birçok sunucu, böyle bir e-postanın gerçek olduğunu doğrulamak için DKIM gibi "uzantıları" kullanıyor, ancak orada hala umursamayan birçok eski posta sunucusu var, çünkü sadece kırılmayan şeyleri düzeltmemeyi cazip hale getiriyor.

Ayrıca bir Tarih başlığını nasıl belirttiğime dikkat edin. Bu, herhangi bir isteğe bağlı (ancak iyi biçimlendirilmiş) değer olabilir; Birçok müşteri uzak geçmişten uzak geleceğe kadar yasal tarih aralığını memnuniyetle gösterecektir. Kişisel olarak kendime yıllar önce kendime bir e-posta gönderdim; bu, yaşam beklentimden uzun bir süre sonra posta kutumun en üstünde kalacak ve ayrıca e-posta hesabımı ve kendi doğumumu hazırlayan bir e-postayı alacağım.

tl; Dr.

Böylece, özet olarak, gönderen bir e-postayı sahteledi, kaynak posta sunucusu tarafından kabul edildi / aktarıldı, e-posta sunucunuz kabul etti ve gelen kutunuza sakladı ve müşteriniz gelen kutunuzda bulunan verileri tamamen sarsmadan gösterdi. Herhangi bir güvenlik "Gönderme" güvenliği genellikle bu perspektifte güvenliği almaktan çok daha az kısıtlıdır, çünkü POP3 bir posta kutusuna erişmeden önce her zaman bir kullanıcı adı ve şifre gerektirir (bunu teorik olarak engelleyebilirsiniz, ancak herhangi bir meşruiyet bilmiyorum) posta hizmetleri yapar).

SMTP ve e-posta, güvenlik ve kimlik doğrulamanın çok daha az ciddiye alındığı bir döneme ait çok eski Internet hizmetleridir (DNS başka bir örnektir). Protokolün tasarımı, gönderenin adresinin doğruluğunu doğrulamak için hiçbir çaba göstermez ve alıcı adresini yalnızca postanın teslim edilebilir olduğundan emin olduğu sürece doğrular.

E-posta, SMTP protokolü aracılığıyla iletilir. SMTP protokolü nispeten aptaldır; düz metni bir e-posta adresine iletme olanağı ve çok daha fazlası için bir olanak sağlar. Bu düz metnin yapısı RFC 5322 tarafından tanımlanmıştır . Genel fikir, e-posta metninin başlık olarak adlandırılan meta verileri ve mesajın asıl metin gövdesi olduğu yönündedir. Bu e-posta başlığı gönderen tarafından oluşturulur (hiçbirine güvenilemez) ve "to:", "from:", "subject:", vb. Gibi alanlar içerir ...

SMTP protokolü, e-posta başlıklarının, aslında e-posta adresiniz ve hiçbir zaman hiçbir zaman onaylanmayan bir gönderen e-posta adresi olan SMTP protokolünde tanımlanmış çok az şeyden herhangi biriyle eşleştiğini doğrulamaz.

Bir e-posta iletisindeki hemen hemen her şey sahte olabilir.

Bugün e-posta içerikleri hakkında uzaktan bile güvenilir olan tek şey, e-postanın alan adı tescil ettiren tarafından onaylanan bir e-posta sunucusu aracılığıyla işlendiğini kanıtlayan DKIM imzalarıdır. Daha derine inerek, bu aldatmaca e-postasının DKIM imzası bulunmadığını göreceksiniz.

ToE-posta başlığındaki adres bilgi amaçlıdır ve e-posta istemcisi tarafından gösterilir. Gerçek alıcı adresi RCPT TOSMTP ile birlikte verilir . Mektubu yazarsanız, zarfa koyarsanız, Zarf üzerine Adres-1'i yazdığınızda aynıdır. O zaman kuryeye git, başka bir Adres-2 ver. Kurye, zarfınızı Adres-2 ile birlikte daha büyük bir zarfa koyar ve sevkiyat oraya gider. Sekreteriniz (e-posta istemcisi yazılımı), dış zarfı çöpe atıp size iç zarfı Adres-1 ile gösterecektir. Bunu, e-posta mesajının RAW görünümü ile görebilirsiniz.

Bu, başlıkları incelemeye dayanan biraz farklı bir görünümdür. Diğer cevaplar SMTP'nin ayrıntılarını benden daha iyi ele alıyor.

Eğer tam başlıklarını, sonra adresi için onları aramak alabilirsiniz varsa, olabilir adında bir alanda bulabilirsiniz Envelope-to, Delivered-toya da X-Apparently-to. İlki posta sağlayıcım, ikincisi Gmail; Üçüncü kullanılanı da gördüm. Bunlar farklı alanlardır ancak amaçlarımız aynı anlama gelme eğilimindedir: mesajı gerçekten teslim edecek posta kutusu. BCCed alıcısıyla görünümden (masaüstü sürümü) göndererek test ettim.

Posta sağlayıcım da Delivered-Toalanı kullanır ancak sunucularındaki posta kutusu adı için kullanılır. Bu, e-posta adresim gibi görünmese de (düşünüyorum ChrisH-$ACCOUNTNAME@$SERVER.mail.com).

Öte yandan, Outlook (değişim sunucusuyla birleştirilmiş), BCC olarak listeleniyorsanız, başlıklarda alıcının e-posta adresiyle birlikte tek bir alan içermez.