Yönlendirme posta sunucusu için SRS yeniden yazımı kesinlikle gerekli mi?


14

Etki alanım için Postfix e-posta sunucusu kullanıyorum, örneğin alanadim.com. Çoğunlukla yönlendirme e-posta sunucusu olarak işlev görür: kullanıcılar @ alanadim.com adresinde bir e-posta adresi alır, ancak genellikle adreslerini harici bir gelen kutusuna (Gmail, Yahoo vb.) Yönlendirmeyi seçer. Yönlendirilen birkaç bin adres var, bu nedenle sunucu oldukça önemli miktarda posta trafiği işliyor.

Geçmişte, sunucu SRS yeniden yazmayı kullanmıyordu. Bu, elbette, ip adresimin orijinal gönderenin etki alanı adına e-posta göndermek için teknik olarak yetkilendirilmemesi nedeniyle, yönlendirilen postanın SPF kontrollerinde başarısız olacağı anlamına geliyordu. Ancak, görebildiğim kadarıyla önemli sorunlara yol açıyor gibi görünmüyor. Genellikle Gmail, Yahoo vb. Kullanıcılardan gelen hiçbir şikayet, SPF hatalarını görmezden gelip mesajları yine de iletecek kadar akıllı görünmemektedir.

Bunu akılda tutarak, SRS yeniden yazmayı etkinleştirmek gerçekten gerekli mi? Bunu etkinleştirmeyi düşünüyorum ama ana endişem, alan adı spam kaçınılmaz olarak kötüleştiğinde spam göndermek için kara listeye alınacak olmasıdır. Yeniden yazma işlemi spam iletinin göndericisiymişim gibi görünmesini sağlamaz mı? (En azından Gmail’in Posta Sunucularını Yönlendirmek için En İyi Uygulamalarını okuduğumda bu benim anlayışım ).

Verilmiş, iletilmeden önce şüpheli spam konu satırına "SPAM" eklemek için SpamAssassin kullanmak, yüksek güven (15+ puan) spam iletmemek ve spamhaus engelleme listesini kullanmak gibi önerilen önlemlerden bazılarını zaten alıyorum, ancak bu önlemler açık değil mükemmel değil ve spam hala işaretlenmemiş olarak kayabilir.

Yanlışlıkla spam gönderici olarak işaretlenme riskini artırıyorsa, SRS yeniden yazmayı etkinleştirmek buna değer mi? Yoksa sadece olduğu gibi bırakmak ve SPF arızalarını görmezden gelmek daha mı güvenli olur?


Deneyimlerimden, Birleşik Krallık'taki bazı ISS'lerin kendi müşterilerinden olduğunu iddia eden gelen e-postaları reddedeceğini, ancak kendi postalarından gönderilmediğini biliyorum. Aynı şey Gmail, Yahoo ve AOL için de geçerli olabilir. Bu gibi durumlar yalnızca gönderen adresini yeniden yazarak çözülebilir.
roaima

Yanıtlar:


9

Bana öyle geliyor ki, sorunuz şu şekilde ortaya çıkıyor: " Gelen e-postadaki kaç posta sunucusu SPF kayıtlarını kontrol ediyor? " Çoğu ise, SRS bir yönlendirme sunucusu için mutlak bir gerekliliktir; eğer bunlardan hiçbiri değilse, SRS'ye ihtiyacınız yoktur.

Ne yazık ki, bu konuda herhangi bir akademik çalışmaya hemen el koyamıyorum. Ancak gelen e-postalarda SPF'yi kontrol ettiğim için, bazı posta sunucularının kontrol ettiğini kesin olarak söyleyebilirim . Sunucunuzu sunucumdaki hesaplara yönlendiren müşterilerinizden herhangi biri, -allSRS kullanmadığınız sürece biten bir SPF'nin reklamını yapan gönderenlerden gönderilen e-postaları kaybedecektir . SRS olmadan müşterilerinizin bazı e-postalarının teslim edilmeyeceğini kesinlikle söyleyebilirim .

Marc'tan Almanca okuyamadığım için özür dilerim, bu yüzden alıntıladığı PDF'nin zorlayıcı argümanları ilerletip ilerletmediğini söyleyemem, ancak SRS olmadan müşterilerinizin e-postalarının bir kısmının teslim edilmeyeceğini tekrarlayabilirim. Bu kesirin ne olduğunu söyleyemem, ama sıfır değil - ve verilen, SRS çalıştırmaktan başka alternatifiniz olduğunu düşünmüyorum.

Sunucunuzun SPAM'ı ileterek kendisine yardımcı olmayacağını kabul ediyorum, ancak tecrübelerime göre, itibar hasarının çoğu, zarftan gelen etki alanına değil, IP adresine yapılır; bu, SRS kullanımına bakılmaksızın yapılacaktır.

Sorunuzun daha derin yanıtı, SPF ve onun (kötü düşünülmüş ve internet kırıcı) takibi DMARC arasında, posta iletme hizmetlerinin günlerini geçirmiş gibi görünüyor. Kullanıcılarımdan biri dışında tüm kullanıcıların sunucumda son teslim almasını istedim ve bir kullanıcının 2016'da değişmesi veya ayrılması gerekecek. Günümüzde, birçok web posta sistemi, sunucu dışı postaları toplayarak birden çok posta kutusu üzerinde entegrasyona izin verecek IMAP veya POP ve birçok posta istemcisi birden çok IMAP veya POP hesabının tek bir tümleşik INBOX olarak sunulmasına izin verir, bu nedenle iletme eskiden olduğu merkezi okumaya nimet değildir.

Kısacası, kısa vadede SRS'ye ve uzun vadede yeni bir iş modeline ihtiyacınız olduğunu söyleyebilirim.


Mesele şu ki, SRS, SPF'nin yönlendirme sorunlarını düzeltmek için bir çözümdür. SRS yeniden yazarlar, örn. Kullanıcı @ A - A = kullanıcı @ B ve B'nin SPF kayıtları sorumludur. Sorun: B hala adresleri taklit edebilir! Bu nedenle, bazıları yeniden yazılan adrese crypt-hashes ve zaman damgaları ekliyor. Bunun büyük ölçekte çalışması için, orada olmayan küresel olarak benimsenmesi gerekir. Ayrıca yalnızca bir kez bir şey yönlendiriliyorsa çalışır, ancak daha fazla değil. Ayrıca cevaplar bir sorundur. Ayrıca, SPF'nin kendi kötüye kullanım alanınızı korumak için bir teknik olduğunu, başka bir şey olmadığını unutmayın.
Marc Stürmer

@ MarcStürmer " SRS, SPF'nin yönlendirme sorunlarını düzeltmek için bir çözümdür ": evet, tam olarak budur. SPF'nin basit iletimi bozduğu bilinmektedir; SRS'nin ödemeye değer bir fiyat olduğunu düşünmüyorsanız, bir SPF kaydının reklamını yapmayın. " Sorun: B adresleri yine de taklit edebilir ": A'nın etki alanına veya iyi bir SPF kaydıyla korunan başka bir etki alanına değil, posta SPF kapsamında reddedilir; ama bunun dışında, evet, yapabilir, ve bunu bir problem olarak görmüyorum. " SPF kendi kötüye kullanım alanınızı korumak için bir tekniktir, başka bir şey değil ": Kabul ediyorum.
MadHatter

@ MarcStürmer: "Aynı zamanda sadece bir şey iletiliyorsa çalışır, ama daha fazla olmaz." Hata. SRS birçok yönlendirme sunucusunda tamamen iyi çalışır. Yalnızca satırda etiketleme olmayan bir sunucu varsa acı çeker. Ancak bu, ilk veya sonraki bir ileri atlama olsun, genel olarak herhangi bir etiketleme olmayan sunucu ile aynı sorundur. Bir SPF dünyasında, SRS'ye ihtiyacınız yoktur, sadece iletilen postanın sorumluluğunu üstlenmeniz ve olası bir geri dönüş sağlayabildiğinizden emin olmanız gerekir. SRS bunu yapan tek bir tekniktir, google örneğin farklı bir şey kullanır.
Adrian Zaugg

Sorun, SRS kullanımı DMARC hizalama denetimini (ör. Zarf göndereni! = From:-Başlığı) bozar ve From:üstbilgideki alanın p=rejectDMARC politikasında bulunması durumunda Gmail'in iletileri reddetmesini sağlar . Siz de yeniden yazarsanız From:, posta kendi alan adınızın kurallarına göre kontrol edilir. Ancak bir DKIM denetimi başarısız olur ve posta istemcisinde gösterilen gönderici karıştırılır.
mbirth

@mbirth afaik, haklısın. Ancak şahsen DMARC'ı tek başına posta listelerini tek taraflı olarak bozduğundan değil, tam bir felaket olarak görüyorum ve (büyük bir topluluk listesinin yöneticisi olarak kapasitemde) insanlara bir p=rejectpolitika yayınlayan herhangi bir ISS'yi kullanmamalarını tavsiye ediyorum . SRS, DMARC'yi kırarsa, DMARC için bu sadece zor.
MadHatter

9

SRS kağıt üzerinde iyi bir fikir gibi görünüyor, ancak Heinlein Support'un milletlerine göre pratikte çok iyi çalışmıyor (100000'den fazla hesapla orta ölçekli bir posta hizmeti yürütüyorlar.)

Ayrıntılar konuşuluyor, ancak Almanca'da, neden: https://www.heinlein-support.de/sites/default/files/SPF-DKIM-Greylisting_FrOSCon_2012.pdf

Bunun ana nedeni, SRS'nin gerçekte SPF'nin uygulanmasında ciddi sorunlar için küçük bir yama olmasıdır, çünkü SPF, bazı yaygın e-posta kullanım durumlarını çok iyi kapsamaz. SRS'nin anlamlı olması için, büyük olasılıkla gerçekleşmesi muhtemel olmayan geniş bir sunucu tabanına dağıtılması gerekir. Dolayısıyla, bu geniş sunucu tabanına dağıtılıncaya kadar, pek mantıklı değil.

Büyük posta sağlayıcıları ile ilgili sorun, bugünlerde gerçek bir büyük kullanıcı tabanına sahip olmaları ve daha fazla teknik (DMARC için halef zaten boru hattında) uygulamakta olup, bu da normal posta sunucusu kurulumları onlara güvenilir bir şekilde göndermek için.

Postanızın Gmail, Hotmail ve benzeri büyük posta sağlayıcılarına daha iyi teslim edilmesini istiyorsanız, en az DKIM ve DMARC uygulamalısınız, ancak aynı zamanda en iyi şekilde başarısız olacak ve belki de posta teslimi için bazı hız sınırlayıcı mekanizmalar uygulayacaksınız. sizin için harikalar yaratırdı.

Büyük sağlayıcılarla ilgili bu sorun, günümüzde Mailchimp, Mandrill veya Returnpath gibi hizmetlerin olmasının nedenidir. Bu sağlayıcılar Google & Co'ya para ödüyor. daha iyi teslimat kalitesi için.


1
Buradaki sorun SRS değil SPF. Bazı ISS'ler SPF'yi kullandıkları sürece, yönlendirmenin hepsiyle çalışmasını sağlamak için SRS (veya benzer bir şey) uygulamanız gerekir. Gri liste ile ilgili sorun farklıdır, gri liste için SRS etiketli gönderen adreslerini "paketten çıkarmalısınız" (BATV etiketli postalar gibi).
Adrian Zaugg

3

Her @MadHatter kelimesine katılıyorum, ancak Google hakkında önemli bir gerçek!

Gmail'e bir yönlendirme hizmeti sağlarsanız, Gmail kullanıcılarınız sizin tarafınızdan depolanan adres adına Gmail'den posta gönderebilmeleri için SMTP erişimi de sağlama şansınız yüksektir.

Bu durumda - gmail bu e-posta için bir iletici olduğunuzu bilir ve SPF denetimi başarısız olsa bile iletilerinizi spam olarak işaretlemez.

Müşterilerinize postalarınızı bill@microsoft.com adresinden gönderebilirsiniz. Mesaj herhangi bir uyarı yapmadan gelen kutularına ulaşacaktır! (Microsoft var -all spf kaydında)

Kontrol edildi ve doğrulandı. Ekli örnek.

bu mesaj gelen kutusuna gitti.gmail Orijinali Göster

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.