Müşterilerimin alan adları adına e-posta göndermenin en iyi yolu nedir?


15

Posta sunucumun, gri listeye alınmadan ve hemen çıkma sorunlarından kaçınmadan, müşterilerimin etki alanları adına e-posta göndermesini sağlamanın en iyi yolunu bilmek istedim.

Burada , burada ve burada başka sorular okuyorum ama hiçbiri olası tüm çözümleri araştırmıyor. Karşılaştırmak istediğim bazı olasılıklar:

A.

HELO mymailserver.com
MAIL FROM<do-not-reply@myapp.com>  # mymailserver.com same IP as myapp.com
DATA
  From: <res@client.com>
  Sender: <do-not-reply@myapp.com>

Soru : Gmail'in yaptığı budur. Zarf göndericisi değil, farklı bir alana sahip olan msg başlığı "Kimden:".
emailclients gösterecektir : "do-not-reply@myapp.com aracılığıyla res@client.com Gönderen" veya : "res@client.com Adına do-not-reply@myapp.com itibaren" olan değil bir sorun benim için.
Şimdi, bu etki alanımın itibarını, "Kimden:" başlığının farklı bir alan adına sahip olması gerçeğini etkiler mi? (ve bunu yapan kişi Google değilse ..)

B.

HELO mymailserver.com
MAIL FROM<do-not-reply@myapp.com>
DATA
   From: <res@client.com>
   # same as A, but no "Sender:"

Google bir keresinde bunu yaptı ve bir hata olarak adlandırdı http://groups.google.com/group/Gmail-Help-Message-Delivery-en/browse_thread/thread/f651cb1db5d9dd23/3a8bcd0548487863?lnk=gst&q=%22on+behalf + /% 22 & pli = 1
Bir hata "Gönderen:" iletisini mesajlarından kaldırdı ve "üzerinden" e-posta istemcisinde görünmedi. (RFC, "Kimden:" ile aynı değilse mevcut olması gerektiğini söylüyor)

C.

HELO mymailserver.com
MAIL FROM<res@client.com>
DATA 
  From: <res@client.com>

Bu, client.com'un mesajı gönderiyormuş gibi (MAIL FROM "sahte"). Ancak, client.com etki alanı iyi biliniyorsa veya DNS'inde bir SPF girişi varsa, mymailserver.com adına ileti göndermesine izin vererek DNS'sini değiştirmek zorunda kalırım .. (Bu benim için imkansız çünkü ve ayrıca bazı müşterilerim alan adları üzerinde kontrol sahibi değiller, yani @ gmail.com'u kullanıyorlar)

D.

HELO mymailserver.com    
MAIL FROM<do-not-reply@myapp.com>
DATA 
  From: <do-not-reply@myapp.com>
  Reply-to: <res@myclient.com>

Soru : Bu en basit olanı, yalnızca bir "Yanıtla:" başlığı ekleyeceğim. Bu gerçekten e-posta istemcileri tarafından TÜM ZAMAN dikkate alınır mı? Bu da "Yanıtla" başlığına farklı alan adları ekleyerek parodi olarak algılanabilir ve alan adımın itibarını olumsuz etkileyebilir mi?
- RFC yalnızca "Yanıtla alanı varsa, yanıtın Kimden alanında belirtilen adreslere değil, o alanda belirtilen adreslere GİRMELİDİR " der .
- Yalnızca "Kimden:" başlık etiketi "sahte" olacaktır:
"Kimden: myclient.com (myapp.com aracılığıyla) <do-not-reply@myapp.com>".


RFC'leri okurken, 'SHOULD' çok güçlü bir öneri olduğu anlamına gelir. Bir müşterinin çoğu durumda yapmamasının tek nedeni, eski olması ve RFC'nin yazıldığından beri güncellenmemiş olmasıdır. Standart tanımlar için RFC 2119'a bakınız
Matthew Scharley


Ne yazık ki 2018'den itibaren birçok e-posta istemcisi Yanıtla başlığını hala görmezden geliyor. meta.discourse.org/t/...
Martin Meixger

Yanıtlar:


2

Mükemmel soru. Aynı şeyi araştırmak için birkaç saat geçirdim.

Daha önce e-posta formları için (çoğunlukla naif olmayan) C Seçeneğini kullanan çok sayıda web sitesi konuşlandırdım , ancak artan sayıda teslimat sorunu yaşıyoruz. E-posta sağlayıcıları işleri yavaş yavaş sıkılaştırıyor. Örneğin Yahoo kısa süre önce alıcılardan geçerli bir DKIM imzası olmadan tüm e-postaları reddetmeleriniFrom: ____@yahoo.com istemek için DMARC politikalarını değiştirdi . DMARC'ı izleyen SMTP sunucularını (Gmail'i ve muhtemelen Hotmail / Outlook.com ve Yahoo'yu) almak bu iletileri zorla geri döndürür . eBay ve Paypal, kimlik avını azaltmak için inandığım benzer sıkı politikalara sahip. Maalesef bir "Gönderen" başlığı belirtmek yardımcı olmaz.

(Bir Yahoo takma adı gönderirken Gmail'in bu sorunu nasıl çözdüğünü merak ediyorum ?!)

"Kimden" e-postasının katı bir DMARC politikası olmadığını biliyorsanız A seçeneği daha iyi bir seçenek olacaktır (bunu basit bir DNS sorgusu ile onaylayabilirsiniz).

Görsel olarak en az çekici olmasına rağmen, Seçenek D gerçekten en güvenli olanı ve gelecekteki projelerimizin çoğu için önereceğim şey. PayPal'ın daha önce Seçenek A'yı kullandığını, ancak şimdi Seçenek D'ye geçtiğini belirtmek gerekir .

Ek güvenilirlik ve artan teslimat şansı elde etmek için, SPF ve / veya DKIM'i uygulamaya bakacağım. Bunlar ve diğer şeyler Google'ın Toplu Gönderen Yönergeleri'nde belirtilmiştir yararlı bulduğum .


1

Ne istediğinden emin değilim. İstediğinizi yapmanın "güvenli" veya "güvensiz" yolu yoktur.

Ben her zaman D) tercih ederim. Ayrıca SPF kayıtları ekleyeceğim. Ama dediğim gibi, bu diğerlerinden daha güvenli veya güvenli değil (ne demek istersen).

Yanıtla başlığı itibarı hiçbir şekilde etkilemez. Müşteriye bu adresi yanıtlar için kullanmasını önerir (Duh, belki de ad nereden geliyor ?!). Müşteri bu tavsiyeye uyuyorsa bu öneri garanti edilmez.


"Güvenli" demek istediğim, yanlış bir spoofer / spam gönderici olarak düşündüğüm alan adımın gri listeye alınma olasılığını en aza indirgemektir. Evet, D ile devam edersem, alanıma bir SPF girişi ekleyebilir ve mesajları DKIM kullanarak imzalayabilirim.
dgaspar


@dgaspar Greylisting zarf tabanlıdır. Böylece içeriğiniz (Kimden :, Gönderen :, ...) tamamen yok sayılır. Herkes herhangi bir posta adresini gönderen olarak yazabildiğinden, her gönderenin adresi sahte olarak değerlendirilir. Postalarınızı SPF veya DKIM ile imzalamanız dışında.
mailq

0

İki güvenilir çözüm:

  1. müşterilerden posta sunucunuzu SPF alan adı kayıtlarına eklemelerini isteyin
  2. müşterilerden size bir e-posta hesabı kimlik bilgisi (posta sunucusu IP'si, kullanıcı adı, şifresi) vermelerini isteyin ve posta sunucularına bağlanmak ve e-posta göndermek için bunları uygulamanızın içinde kullanın (aslında uygulamanızın içinde bir e-posta istemcisi oluşturursunuz).
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.