İyi bir fikir? Gelen e-postaları kendi alan adımız biten ile reddetmek? (çünkü onlar sahte olmalı)

33

Exchange Sunucumuz hakkında bir sorum var: Sonunda kendi etki alanımıza sahip gelen harici e-postaları reddetmenin iyi bir fikir olduğunu düşünüyor musunuz?

Gibi harici e-posta gibi fake@example.commi?

Çünkü şirketimizde gerçek bir göndericiden gelecekse, e-posta asla dışarıdan gelmeyecek mi?

Eğer evet ise, bunu yapmanın en iyi yolu nedir?

security email-server exchange-2013

— Steffen Maier
kaynak

3

Şu anda herhangi bir spam filtreleme çözümünüz var mı?

— ewwhite

14

Kendi etki alanınızdan göndermeye çalışan herhangi bir web uygulaması satıcısının bulunmadığını tekrar kontrol etmelisiniz. Mesela "payroll@example.com" adresinden personelinize e-posta gönderebilecek bir bordro sisteminiz varsa. Ayrıca pazarlama veya İK'nın harici bir toplu posta hizmeti kullanıp kullanmadığını ve personelin bu mesajları almasını isteyip istemediklerini de kontrol edin. Genellikle bu mesajların göndericisi veya en azından pazarlama veya İK'da yer alan birisinin cevap adresini vardır. Bu gibi durumlarda, genellikle hizmetin e-posta sunucularını izin verilenler listesine koyabilir ve kendi alan adınızın gelmesini engelleyebilirsiniz (yaptığımız şey budur).

— Todd Wilcox

6

@NeilMcGuigan Ne fark eder ki? Posta hala dahili bir posta sunucusundan mı kaynaklanmalı? Fiziksel olarak mevcut olmadığı için ağın dışından gelmeyecekti.

— Matt

@Matt gotya, brainfart

— Neil McGuigan

1

Sunucularınızdan birinden gelen otomatik e-posta bildirimleriniz varsa, örneğin, başarısız cron işleri bildirimleri veya IDS'den veya kaynak kullanımı izleyicisinden ihlal girişiminde bulunuyorsanız, Kim adresleri etki alanı adınızla olacak şekilde yapılandırılmışlardır. Bu e-postaları dahili posta sunucunuz üzerinden yönlendirmeye veya bu sunucuları izin verilen gönderenler olarak beyaz listeye almaya özen göstermeniz gerekir.

— Lie Ryan,

53

Evet, etki alanınız için e-postanın yalnızca kendi sunucunuzdan gelmesi gerektiğini biliyorsanız, o etki alanı için olan herhangi bir e-postayı farklı bir sunucudan almanız gerekir. Gönderenin e-posta istemcisi başka bir ana bilgisayarda olsa bile, e-posta göndermek için sunucunuza (veya hangi e-posta sunucusunu kullanıyorsanız) giriş yapmaları gerekir.

Bir adım daha ileri giderek, sunucunuzu SPF kayıtlarını kontrol edecek şekilde yapılandırabilirsiniz. Bu tür bir e-posta etkinliğini kaç ana makinenin engellediğidir. SPF kayıtları bir DNS kaydıdır, bir TXT kaydıdır ve etki alanı için hangi sunucuların e-posta göndermesine izin verildiğine dair kurallar verir. SPF kayıt kontrolünün nasıl etkinleştirileceği, e-posta servisinize bağlı olacaktır ve burada nelerin kapsayacağı kapsamının ötesinde olacaktır. Neyse ki, çoğu barındırma ortamı ve yazılımı, SPF kayıtlarıyla çalışmak için belgelere sahip olacaktır. Genel olarak SPF hakkında daha fazla bilgi edinmek isteyebilirsiniz. İşte Wikipedia makalesi: https://en.wikipedia.org/wiki/Sender_Policy_Framework

— DKing
kaynak

3

@Kurtovic, iyi yapılandırılmış bir e-posta sunucusunun reddettiği e-postayı atlatması gerekir; böylece gönderene bildirilir.

— Calimo,

8

@Calimo Spam olduğu için e-postayı reddettiği zaman olmaz. Bunu yapmak, spam gönderenin algoritmanızın neye izin verdiğini ve izin vermediğini öğrenene kadar denemesini sağlar.

— Jon Bentley

27

@Calimo - hayır. kabul-ve-sıçrama, yapılacak en kötü şeydir, geri yayılan spam’e katkıda bulunuyorsunuz ve çok hızlı bir şekilde kara listeye alınacak. sadece istenmeyen postaları reddetmek - bununla ilgilenmek gönderen sunucunun problemidir. Bunu yapamazsanız, spam veya kötü amaçlı yazılım olup olmadığını kabul edin, kontrol edin ve atın. asla kabul etme ve zıplama.

— cas,

2

@cas: Üçüncü bir alternatif var: SMTP kabul zamanında reddet. Bu, eğer istiyorsa, gönderen SMTP sunucusunda bir hata yanıtı oluşturma yükünü bırakır ve böylece birçok meşru göndericinin, asla spam üretmeyeceğinizi garanti ederken postalarının reddedilip reddedilmediğini görmesini sağlar.

— R. ..

2

@R .. bence bunun üçüncü bir alternatif olmadığını göreceksiniz, söylediklerimin bir ifadesi var: "sadece istenmeyen postaları reddet - bununla ilgilenen gönderen sunucunun sorunu."

— cas,

31

Bunu zaten yapmak için bir standart var. Buna DMARC denir . Bunu DKIM imzasıyla uyguluyorsunuz (yine de uygulamak iyi bir fikir).

Üst düzey genel bakış, etki alanınızı DKIM başlığına bırakan her bir e-postayı imzalamanızdır (ki bu zaten iyi bir uygulamadır). Ardından, DMARC'yi posta sunucunuza çarpan her bir e-postayı, sahip olduğunuz bir etki alanından, geçerli bir DKIM üstbilgisi ile imzalanmayanları reddedecek şekilde yapılandırın.

Bu, harici hizmetlerin etki alanınıza e-posta göndermesini sağlayabileceğiniz anlamına gelir (barındırılan yardım masası yazılımı vb. Gibi), ancak mızrak kimlik avı girişimlerini engelleyebilir.

DMARC ile ilgili diğer harika bir şey de başarısızlık raporları almanızdır, böylece istisna yönetimini gerektiği gibi yönetebilirsiniz.

Aşağı tarafı, her şeyi önceden hallettiğinizden emin olmanız veya meşru e-postaları bırakmaya başlamanız gerektiğidir.

— Mark Henderson
kaynak

3

DMARC'yi test etmeden önce SPF ve DKIM'in uygulanması şiddetle tavsiye edilir.

— Todd Wilcox

DMARC, e-postalarla nasıl çalışır, sunucunuz tarafından imzalanmayacağından harici hizmetler gibi, sizinkinden farklı bir sunucudan nasıl gelir?

— jpaugh,

1

@jpaugh, diğer sunucular ortak anahtarını DNS'inizdeki DMARC kayıtlarınıza eklersiniz. Size eklemek için rekor verebilecekler.

— Mark Henderson

Bu cevabı + 1'ledim çünkü teknik olarak doğru - bu DMARC'ın tam olarak ne işe yaradığı ve ne işe yaradığı - ancak RARP'leri ihlal ettiği için posta listeleri gibi şeylerle birlikte çalışmak istiyorsanız, DMARC çok kötü bir fikir. genellikle yaramazlar.

— MadHatter

11

Böyle bir bloğun spam’i azaltması ve sosyal mühendisliği zorlaştırması muhtemeldir ancak meşru postayı da engelleyebilir. Örnek olarak, posta yönlendirme hizmetleri, posta listeleri, yanlış yapılandırılmış posta istemcileri olan kullanıcılar, ana posta sunucunuzu etkilemeden doğrudan webhost'tan posta gönderen webapps'ler vardır.

Dkim, ağınızdan gönderilen, bir posta listesi ya da iletici yoluyla dolanan ve daha sonra postanıza alınan bir iletiyi tanımlamanın bir yolunu sağlayarak bunu hafifletebilir, ancak bazı tedaviler dkim imzalarını kıracaktır. ve hala tüm meşru posta çıkış noktalarını takip etme ve bir dkim imzalayandan geçmelerinden emin olma problemin var.

Özellikle bunu varolan bir alana uygularsanız dikkatli olun.

— Peter Green
kaynak

3

Belki, ama böyle bir değişiklik yapmadan önce göz önünde bulundurmanız gereken bazı durumlar vardır.

1) Şirketinizdeki herhangi bir kişi, etki alanınızdan "e-posta" gibi görünen e-postaları göndermek için herhangi bir tür harici hizmet (örneğin, Anket Maymunu, Sürekli İletişim, vb.) Kullanıyor mu? Bugün yapmasalar bile gelecekte yapabilirler mi?

2) Kullanıcılarınıza ileten herhangi bir dış adres var mı? Örneğin, "mycompany.sales@gmail.com" gmail hesabının "sales@mycompany.com" adresine iletildiğini ve "bob@mycompany.com" kullanıcınızın "mycompany.sales@gmail.com" adresine gönderdiğini varsayalım. Bu durumda, mesaj "dış" dan, ancak "@ mycompany.com" Kimden: adresinden gelecektir.

3) Listenizdeki iletilerdeki orijinal "Kimden:" adresini koruyan dış dağıtım listelerine kullanıcılarınızdan herhangi biri abone oldu mu? Örneğin, eğer Bob "foo-list@lists.apple.com" a abone olup bir mesaj gönderirse, şunun gibi bir gelen bir mesaj alır: Kimden: bob@mycompany.com Kime: foo-list@lists.apple. com Gönderen:

Sunucunuz saf olarak "Kimden:" başlığına bakarsa ("Gönderen:" yerine), bu iletiyi dışarıdan aldığınız için reddedebilir.

Yukarıdakilerin tümü nedeniyle, "... şirketimizdeki gerçek bir göndericiden, e-postanın asla dışarıdan gelmeyeceği" şeklinde bir battaniye politikası olması her zaman mümkün değildir.

— David Gelhar
kaynak

2

Bunu, Anonim kullanıcıların yetkili bir etki alanı göndereni olarak göndermesini engellemek için Alıcı Bağlayıcı izinlerinizi güncelleyerek PowerShell'de yapabilirsiniz:

Get-ReceiveConnector <identity> | Remove-AdPermission -User "NT AUTHORITY\Anonymous Logon" -ExtendedRights ms-Exch-SMTP-Accept-Authoritative-DomainSender

Ancak, genellikle durum adınızı Kimden adreslerinde kullandığından, size durum e-postaları göndermesi gereken uzak uygulama sunucularınız olduğunda bu sorun ortaya çıkar. Kendi IP adresleri için ek bir Bağlayıcı Bağlantısı oluşturmak mümkündür, böylece onları yanlışlıkla dışlamazsınız.

— Neil
kaynak

1

GMail, e-posta adresinin ilk kez doğrulanması şartıyla, GMail dışı bir alan adıyla e-posta göndermenize izin veren bir ayara sahiptir. Kararınız bu e-postaları engeller.

Bu GMail özelliğini kullanabilecek kullanıcılara sahip olup olmamaları ve bunlara uymanın mantıklı olup olmadığı şirketinizdeki davranışa bağlıdır.

— Hristiyan
kaynak

-1

SPF, zarfı e-postayı zarfın içine eklerken uygun bir SPF geçişine (ör., Güvenli sunucular kullanarak spam gönderenlere) sahip olabileceğinden, bunu iyileştirmez. İhtiyacınız olan, kendi e-posta mesajınızın, zarfta sizin için kabul edilemeyecek bir kaynak e-posta sunucusu bulunan bir blok.

— Jim
kaynak

"İhtiyacınız olan, zarfta size gönderilemez bir menşe e-posta sunucusuna sahip kendi etki alanı e-posta iletisindeki bir bloktur" - SPF ile yaptığınız tam olarak, etki alanınız için meşru kaynak e-posta sunucularının bir listesini oluşturun.

— GAThrawn