SMTP “Gönderen” başlığının doğru kullanımı?

Web uygulamamız, birisi yeni içerik gönderdiğinde kişilere e-posta mesajları gönderir. Hem gönderen hem de alıcı uygulamamızdan e-posta mesajı almayı seçti. Böyle bir mesaj hazırlarken aşağıdaki SMTP başlıklarını ayarladık:

BAŞLANGIÇ: author@example.com
KİME: alıcı@example.com
GÖNDEREN: webapp@mycompany.com

Alıcıya en iyi deneyimi sunmak amacıyla yazarın e-posta adresini FROM başlığında kullanmayı seçtik; iletiyi posta istemcilerinde gördüklerinde, yazar açıktır. Kimlik sahtekarlığının ortaya çıkmasını önlemek için SENDER başlığını (kendi şirket e-posta adresimizle birlikte) yazarın adına ileti gönderdiğimizi açıkça belirtmek için ekledik. RFC 822 ve 2822'yi okuduktan sonra, bu, gönderici başlığının kullanım amacı gibi görünmektedir.

Çoğu alıcı posta sunucusu bunu iyi idare ediyor gibi görünüyor; e-posta mesajı normal olarak teslim edilir (alıcı posta kutusunun var olduğu, kotanın üzerinde olmadığı varsayılarak). Ancak, bir etki alanındaki bir adresten aynı etki alanındaki bir adrese ileti gönderirken, bazı alan adları iletileri aşağıdaki gibi bir yanıtla reddeder:

571 yanlış IP - psmtp (RCPT TO komutuna yanıt olarak)

Bu, alıcı sunucunun yalnızca FROM başlık adresinin kendi etki alanında olduğunu ve iletinin söz konusu etki alanı için ileti gönderme yetkisi vermediği bir sunucudan kaynaklandığını gördüğünü düşünüyorum. Başka bir deyişle, alıcı sunucu SENDER üstbilgisini yoksaydı.

Yerinde bir çözüm var: webapp, SENDER üstbilgisini yok sayıyor gibi görünen etki alanlarının bir listesini tutar ve FROM ve TO üstbilgileri bu tür bir etki alanında olduğunda, bunun yerine FROM üstbilgisini kendi e-posta adresimize ayarlar. Ancak bu liste bakım gerektirir.

İstenilen deneyimi elde etmenin daha iyi bir yolu var mı? İnternetin "iyi bir vatandaşı" olmak istiyoruz ve ilgili tüm taraflar - göndericiler ve alıcılar - katılmak ve bu mesajları almak istiyorlar. Bir alternatif, şirketimizin e-posta adresini her zaman FROM başlığında kullanmak ve yazarın adını / adresini konuya eklemek, ancak bu biraz sakar görünüyor.

Yanlış şeylere bakıyorsunuz. Bunlar mesaj başlıkları . SMTP zarfına bakmalısınız . (Zarfın nasıl belirtildiği, uygulamanızın posta sistemine nasıl posta gönderdiğine bağlıdır. Birçok sistemde zarf, posta gönderme yardımcı programına komut satırı bağımsız değişkenleriyle tam olarak belirtilir.) 571 yanıtı vermeye karar verir, SMTP Geçiş sunucusu ileti başlıklarını hiç görmemiş olabilir.

Yanıt metni, konuştuğunuz söz konusu SMTP Geçiş sunucusunun yöneticisinin SMTP zarfına koyabileceğinizi kısıtladığını söylüyor. Zarfın alıcı kısmı hakkında şikayet ediyor gibi görünüyor. Ancak, ilk alıcının spesifikasyonuna kadar zarf göndericisinin onaylanmasını erteleyebilir, bu nedenle gönderen hakkında şikayette bulunabilir.

Teslim durumu mesajları gönderildiği yeri Not zarf gönderici olduğunu ve edeceğiz değil tüm dünyada rastgele insanlara yönelik olanlar olmasını istiyorum. (Birçok kişinin bunu sevmemesi dışında, postanızın sizden başka birine gönderilmesi için teslim durumu mesajlarının bir anlamı yoktur .) Kendinizi zarf göndericisi olarak belirtin.

Bu arada, MXkaynak kayıtlarını istemek yanlıştır . Bir SMTP Geçiş sunucusu, herhangi bir kaynak kaydı bulunmadığında Ave AAAAkaynak kayıtları tarafından bulunabilir MX. Bkz. RFC 5321 § 5.1.

Yanılıyor olabilirim, ancak yukarıdaki hatanın, özellikle Postini durumunda, en olası nedeni, reddedildiğiniz alanların katı bir SPF politikasına sahip olmasıdır. SPF denetimli çoğu posta sunucusu yalnızca Kimden: üstbilgisini denetleyecek, Gönderen üstbilgisini umursamayacaklardır.

Durumun bu olup olmadığını kontrol etmek için "dig + short TXT domain.com" komutunu çalıştırın; burada domain.com size hata mesajı veren şeydir. Gibi bir şey geri almalısınız:

"v = spf1 mx -all"

Önemli olan -tüm. Bu, etki alanı sahibinin yalnızca posta sunucusu olarak görev yapan sunuculardan e-posta göndereceklerini belirttiği, diğer tüm postaların reddedileceği anlamına gelir.

Neyse ki, bu durumda, e-postayı göndermeden önce aktif olarak kontrol edebilirsiniz! Kullanıcı e-posta adresini girdiğinde SPF kontrolü yapmak için WebApp uygulamasını edinin. Yürürlükte katı bir politika varsa alan adınızı listenize ekleyin. SPF kontrolleri yapabilen tüm diller için kütüphane sıkıntısı yoktur.