Soru E-posta sekansı almak istemiyorsa ne yapmalı?


Arkaplan — standartlar

RFC 5321 §4.5.5 devletler:

Diğer tüm mesaj türleri (yani, gerekli olmayan herhangi bir mesaj)   bir Standart-Track RFC tarafından boş bir ters-yola sahip olmak için) GÖNDERİLMELİDİR   geçerli, boş olmayan bir ters yol ile.

Şüpheye mahal vermemek için RFC 2119 §3 "tanımlarMELİ" gibi "Belirli durumlarda belirli bir öğeyi görmezden gelmek için geçerli nedenler mevcut olabilir, ancak farklı bir yol seçmeden önce tüm sonuçları anlaşılmalı ve dikkatlice tartılmalıdır."

Durum

Dikkate alınan "özel durumlar" Alice'in olduğu yerlerdir. istemiyor teslimat durumu bildirimleri almak (kaynaklandığı e-postalarla ilgili).

Birkaç seçeneği var:

  1. Aldığında böyle bildirimleri göz ardı etme / göz ardı etme- açıkça bu davranış tamamen doğru olur, ama bu bir sıkıntıdır (ve kaynaklarının israfı);

  2. bazı alt düzeylerde bu tür bildirimleri kabul etmeyi reddetmek- muhtemelen ters-yol artık “geçerli” (RFC'de ne yazık ki tanımlanmamış) olmayacaktı ve eğer öyleyse böyle bir davranış RFC'nin tavsiyelerine aykırı olacaktır; veya

  3. İlk etapta bildirimlerin asla üretilmemesi için e-postayı boş bir ters yolla kaynaklayın- RFC'nin tavsiyelerinin aksine.

Sorular

Bu koşulların, RFC'nin yukarıda belirtilen öneriyi görmezden gelmek için "geçerli bir neden" teşkil ettiğinden eminim - ancak 2 ve 3 numaralı seçeneklerin "tam etkilerini" anladığımdan emin olmak istiyorum.

Özellikle şunu not ettim:

  • Seçenek 2 altında, bazı aracılar, ters yolun geçerli olmadığını algılayabilir.

  • 3. seçenekte, bazı ajanlar, özel durumlar olarak null ters yollarla postaları işleyebilir

Her iki durumda da, aracılar, e-postayı kabul etmeyi / aktarmayı / teslim etmeyi reddedebilir veya spam olarak işaretlenme olasılığını artırmak için bu bilgileri kullanabilir. Pratikte bu tür önlemler ne kadar yaygındır?

Düşünmem gereken başka kaygılar var mı?


5
2018-04-16 16:37


Menşei


Yani Alice postalarının geçmediğini bilmek istemiyor mu? Bunun neden olabileceğini düşündüğüm birkaç nedeni düşünebilirim, ama hepsi çok kötü. - Michael Hampton♦
@MichaelHampton: Alice bir webapp'tır ve e-postalar belirli web formlarını gönderdiklerinde site kullanıcılarına gönderilen onaylardır. İletilerin teslim edilmediğini kimse umursamıyor ve hiç kimse, alınmadığı takdirde teslim durumu bildirimlerini okumaz veya harekete geçiremez. - eggyal
Bunun olağan çözümü, adresten varolmayan bir kullanıcıya geçmektir. - Michael Hampton♦
@MichaelHampton: "adresinden" ile demek istiyorsun zarf göndereniO zaman yukarıdaki seçenek 2 ile aynı değil mi? - eggyal
Bu nedenle, site kullanıcılarınızın e-posta adreslerinin geçerli olup olmadığını bilmemenizin etkilerini dikkatle düşünmelisiniz. :) Ayrıca, bu olacak Ayrıca maske sorunları sizin e-posta sistemi. - Michael Hampton♦


Cevaplar:


Seçenek 1'i kullanmak her zaman daha iyi bir çözümdür. Bunu kağıt posta gibi düşünün; İşlevsel bir dönüş adresi zorunludur. Açık politikadan yararlanan spam'lar nedeniyle e-posta yalnızca daha kısıtlı (DMARC, vb.) Oluyor. İlgilendiğin cevaplarla uğraşmayı otomatikleştirmek o kadar da zor değil. Ancak muhtemelen e-posta sunucularının% 10'undan daha azı bu kadar kısıtlayıcıdır. Ayrıca sunucunuzun bir dnsbl'de listelenmesini önlemek için emin olun.

Kurallar çoğu yerde lak (Ben herkese yolladım ve geri çekilmek için hazırlanmışsa bir çeşit DDOS çalacak olan bir e-posta gönderebilirim.) Tüm kısıtlamalara bakın. Postfix Hangi kuralların geçerli olabileceğini bilmek istiyorsanız.

Her ikisine de sahip olamazsın; düzgün şekilde etiketleyin (# 1) veya spam göndericiye etiketlenmekten çekin (en azından bazılarına göre). Google, no-reply@google.com adresini kullanıyor ve bu bana hiç ulaşmayacak çünkü posta sunucum için bir doğrulanmış gönderen. Google, spam olmadığının en iyi yoludur.


2
2018-04-16 20:25



Ayrıca ilginç exim komut satırı belgeleri devletleri -f seçenek: "Boş bir gönderici, hiçbir zaman bir sıçrama çıkaran bir ileti oluşturmak için güvenilir veya hiç bir kullanıcı tarafından belirtilebilir“Bu, elbette, soru # 3 seçeneğini uygulayacaktır. Bu istisna, RFC'nin tavsiyelerine açıkça aykırı olmasına rağmen böyle bir seçenek sağlar, belki de bunun korkunç bir fikir olmadığını gösterir. - eggyal
Linux her türlü korkunç davranışa izin verme politikasına sahiptir, bu yüzden onu seviyoruz çünkü kendi kutunuzda herhangi bir kısıtlama yoktur, başka biriyle uğraşmaya çalışın ve bunu sizin için zorlaştıracak birçok seçeneği vardır. - user1133275
Takip sorumumla ilgilenebilirsin: “Daha az güvenilir” bir ev sahibinden gelen (kritik olmayan) e-postaları yönlendirmek. - eggyal
Aslında, kullandıkları sırada no-reply@google.com (veya benzer) mesajGoogle'ın "Gönderen" adresi, e-postalarının dönüş yolunu mükemmel geçerli adreslere ayarladı: ör. abcdefghijklmno-pqrstuvwxyz12.345@somehost.bounces.google.com. - eggyal
yazım hatası düzeltildi. - user1133275


4 - zıplamayı işlemek.

Genel olarak en iyi yaklaşım, sıçramaların bir tür sıçrama işlemi, sürekli olarak alıcı adresi sıçraması sonucunda veritabanınızdan çıkarılabilir. Hangi "alice" için bir "olabilir" ya da zarf göndereni bir işleyici işlem olarak ayarlamak için olabilir.

"Alice" e-postanın e-posta alıp vermediği, alıcı sunucusunun yöneticiler veya filtreler sıklıkla yapar. Çoğu durumda, alıcı sunucuları sayılır Her sıçrama, negatif itibar noktalarıdır. Yeterince yap ve sonunda sen Onların kara listeleri ve hiçbir şey elde edemezsiniz.

Diğer insanların kaynaklarını çiğnemeyin çünkü kendiniz halledemeyecek kadar tembelsiniz.


4
2018-04-26 13:49



İyi puanlar var ama burada veritabanı yok — e-postalar sadece web kullanıcısı giriş / eylemlerine yanıt olarak etkileşimli olarak üretiliyor. Belirli bir adresin tekrar tekrar sıçradığını öğrensek bile davranışımızı değiştireceğimizi düşünemiyorum. - eggyal
Bahsetmeye değer birkaç şey var - bu şekilde kullanılan adresler bile yaşamak ve / veya sorunlara neden olmak için talihsiz bir yol var. Mesela, meşru bir kullanıcı, filtre sıçrayan bir şeye ya da bir şeye giriyor olabilir (bir sebepten ötürü sahip olduklarını düşünen bir arkadaşım var) onun adresleri ve bankalarını bu hesaba kayıt ettirin) ve kim olduklarını belirlemek iyi olur - örneğin: bir kullanıcı bekledikleri bir e-postayı almadıklarından şikayetçidir. Daha da kötüsü, birisi sizin tesisinizi spam veya DOS birisine kullandıysa. Sıçramalarla / dev / null ile, ne kadar iyi çalıştığını asla anlayamazsınız. - Chris Lewis
Anladım. Ancak bu özel uygulamada, e-postalar yalnızca bir eylemin gerçekleştirildiği kullanıcıya (girdikleri adreste) bir onaydır. Adresleri saklanmaz veya başka bir amaçla kullanılmaz. Yanlış bir adres girmeleri durumunda, bu adres bildirimlerini alır. Sağladıkları adres sıçrama yaparsa, o zaman yapılacak hiç bir şey yoktur, ancak zıplamayı iptal eder. Amplifikasyon atakları için sistemlerimizin kötüye kullanılmasını önlemek için başka mekanizmalarımız var. - eggyal


Genel olarak, # 1'in muhtemelen en iyi çözüm olduğu konusunda hemfikirim, sunucudaki herhangi bir iadeyi iptal edebilirsiniz. / Dev / null adresine mesaj gönderen bir .forward yükleyin. Bant genişliği faturanızın zarar vermesi olası değil.

İletilerin teslim edilmemesini önemsemeniz gerekip gerekmediğine dair daha geniş bir tartışma için, gerçekten herhangi bir ölçekte kendi iadelerini işleyen herhangi bir kişi bilmiyorum, ancak SendGrid, MailGun, vb. Gibi hizmetler harikadır. HTTP POST aracılığıyla gönderir, IP alanı için itibar yönetir ve size iade edilen posta ve şikayetler hakkında bilgi verir.

Anahtarınız olmayabilir, ancak genel olarak, bugünlerde kendi posta teslimatımı yönetmekten kaçınmaya çalışıyorum. Çok fazla yanlış gidebilir ve büyük bir web yığınını korumanın diğer yönlerinden bu kadar büyük bir rahatsızlık olabilir.


1
2018-04-16 23:03



Lütfen @ user1133275'in cevabı hakkındaki yorumumu inceleyin. - eggyal