Dönüş yolu, yanıtla ve yanıtla arasındaki davranış farkı nedir?


162

Posta başvurumuzda aşağıdaki başlığa sahip e-postalar gönderiyoruz:

FROM: marketing@customer.com
TO: subscriber1@domain1.com
Return-PATH: bouncemgmt@ourcompany.com

Karşılaştığımız sorun, bazı e-posta sunucularının hemen bir iletiyi geri döndürmesi ve sıçrama mgmt sunucumuz yerine gelen veya ters yolunu (marketing@customer.com) kullanmasıdır. Tüm sıçramayı yakalayabileceğimiz takdirde, başlığında yanıt-dönüşünü dönüş yolu ile aynı olacak şekilde değiştirip değiştirmeyeceğimizi bilmek istiyoruz.

Başka fikirleri bekliyoruz?

Aşağıdaki belgeleri referans olarak kullanıyoruz: VERP RFC Bounce Messages

Zıplama almak için SMTP Günlük Ayrıştırma

DÜZENLEME 1: Bu çözümü alıp alamayacağımızı görmek için birkaç bilgi daha.

İletiyi geçiren e-posta sunucusunun yanıt yolunu geri dönüş yolunu kullanmayı seçeceğini bilmek istiyoruz. İletiyi geçiren ilk smtp sunucusu reddedildiğinde iletiyi yanıtlamaya gönderdiğini, ancak bir atlamadan sonra gerçekleştiğinde iletiyi dönüş yoluna gönderdiğini fark ettik.


1
Gönderen: ve Öncelik: alanlarını belirtmeye ne dersiniz? Sıçramalara ve ofis tipi otomatik uygulamalara gelince farklı posta sunucularını nasıl etkilediği hakkında daha fazla bilgi edinmek istiyorum. Bir kimse?
PapaFreud

Yanıtlar:


257

Basit bir örnekle başlayalım. Diyelim ki aşağıdaki RFC2822 içeriğini gönderecek bir e-posta listeniz var .

From: <coolstuff@mymailinglist.com>
To: <you@yourcompany.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123@mymailinglist.com>

This is a very simple body.

Şimdi, diyelim ki VERP (veya farklı bir dönüş yolu kullanan başka bir hemen çıkma izleme mekanizması) uygulayan bir posta listesinden göndereceksiniz . Diyelim ki bir dönüş yolu olacak coolstuff-you=yourcompany.com@mymailinglist.com. SMTP oturumu şöyle görünebilir:

{S}220 workstation1 Microsoft ESMTP MAIL Service
{C}HELO workstation1
{S}250 workstation1 Hello [127.0.0.1]
{C}MAIL FROM:<coolstuff-you=yourcompany.com@mymailinglist.com>
{S}250 2.1.0 me@mycompany.com....Sender OK
{C}RCPT TO:<you@yourcompany.com>
{S}250 2.1.5 you@yourcompany.com 
{C}DATA
{S}354 Start mail input; end with <CRLF>.<CRLF>
{C}From: <coolstuff@mymailinglist.com>
To: <you@yourcompany.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123@mymailinglist.com>

This is a very simple body.
.

{S}250 Queued mail for delivery
{C}QUIT
{S}221 Service closing transmission channel

Burada {C} ve {S} sırasıyla İstemci ve Sunucu komutlarını temsil eder.

Alıcının postası şöyle görünecektir:

Return-Path: coolstuff-you=yourcompany.com@mymailinglist.com
From: <coolstuff@mymailinglist.com>
To: <you@yourcompany.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123@mymailinglist.com>

This is a very simple body.

Şimdi farklı "FROM" ları açıklayalım.

  1. Dönüş yolu (bazen ters yol, zarf göndereni veya zarf denir - tüm bu terimler birbirinin yerine kullanılabilir) komuttaki SMTP oturumunda kullanılan değerdir MAIL FROM. Gördüğünüz gibi, bunun ileti başlıklarında bulunan değerle aynı olması gerekmez. Yalnızca alıcının posta sunucusunun e-postanın üstüne bir Dönüş Yolu başlığı eklemesi gerekir. Bu, SMTP oturumu sırasında gerçek Dönüş Yolu göndericisini kaydeder. İletide bir Dönüş Yolu başlığı zaten varsa, bu başlık kaldırılır ve alıcının posta sunucusu tarafından değiştirilir.

SMTP oturumu sırasında oluşan tüm sıçramalar, Dönüş Yolu adresine geri dönmelidir. Bazı sunucular tüm e-postaları kabul edebilir ve ardından alıcının posta kutusuna gönderecek ücretsiz bir iş parçacığı olana kadar yerel olarak sıraya alabilir. Alıcı yoksa, onu kaydedilen Dönüş Yolu değerine geri döndürmelidir.

Tüm posta sunucularının bu kurala uymadığını unutmayın; Bazı posta sunucuları FROM adresine geri döner.

  1. FROM adresi, FROM başlığında bulunan değerdir. Bu mesajın kimden olması gerekiyordu. Çoğu posta istemcisinde "FROM" olarak gördüğünüz şey budur. Bir e-postanın Yanıtla başlığı yoksa, tüm insan (posta istemcisi) yanıtları FROM adresine geri dönmelidir.

  2. Yanıtla başlığı gönderen (veya gönderenin yazılımı) tarafından eklenir. Tüm insan yanıtlarının da ele alınması gereken yer burasıdır. Temel olarak, kullanıcı "yanıtla" yı tıkladığında, Yanıtla değeri yeni oluşturulan e-postanın alıcısı olarak kullanılan değer olmalıdır. Yanıtla değeri hiçbir sunucu tarafından kullanılmamalıdır. Yalnızca istemci tarafı (MUA) kullanımı içindir.

Ancak, anlayabileceğiniz gibi, tüm posta sunucuları RFC standartlarına veya önerilerine uymaz.

Umarım bu şeyleri temizlemeye yardımcı olur. Ancak, bir şeyi kaçırırsam, bana bildirin, cevap vermeye çalışacağım.


Bu çok yardımcı. Zaman ayırdığınız için teşekkürler. Bir soru. Geri dönüş yolu yerine bazı geri dönüşler yanıtlamaya gidiyor olabilir mi?
Geo

5
iyi, teknik olarak bir dönüş yolu üstbilgisi ekleyebilirsiniz (ancak gerekmemektedir), ancak bir dönüş yolu üstbilgisi varsa, alınan smtp sunucusu tarafından üzerine yazılmalıdır. Hiçbiri yoksa, başlıkların üstüne eklenmelidir.
dave wanta

7
Nasıl return-pathkullanıldığından biraz emin değilim . Eğer return-pathbir dönüş adresi olması gerekiyordu, neden alıcının posta sunucusu yerine gönderenin bu alanı dolduracak? Alıcının sunucusu oraya ne koyacağını nasıl bilecekti? Bu geriye doğru görünmüyor mu?
greatwolf

6
Alıcının posta sunucusu, gönderenin posta sunucusu tarafından sağlanan değeri SMTP "MAIL FROM" komutuna kopyalayarak Dönüş Yolu başlığını iletiye ekler. Posta odası açılış postasında bir katip düşünün - zarfın üzerindeki iade adresine bakarlar ve mektubun üstüne yazarlar (ve zarfı atarlar).
John Hascall

5
Sender:Üstbilgi tüm bunlara nasıl uyuyor?
Simon East

150

Düşünmek için başka bir yol Return-Pathvs Reply-Tosalyangoz posta ile mukayese etmektir.

Postaya bir zarf gönderdiğinizde, bir iade adresi belirtirsiniz . Alıcı yoksa veya postanızı reddederse, posta yöneticisi zarfı iade adresine geri döndürür. E-posta için, dönüş adresi olan Return-Path.

Zarfın içinde bir harf olabilir ve mektubun içinde alıcıyı " Örnek adrese yazışma gönder " şeklinde yönlendirebilir. E-posta için örnek adres olduğunu Reply-To.

Esasen, bir Posta İade Adresi SMTP'nin Return-Pathbaşlığıyla karşılaştırılabilir ve SMTP'nin Reply-Tobaşlığı bir mektupta yer alan cevaplama talimatlarına benzer.


14
Bu hoş bir benzetmedir.
Lukasz Korzybski

2
@Jesse Hobart +1 güzel açıklama için, beni daha kolay anladığınız için teşekkür ederim.
Abhishek

26
Bu benzetmede yakalanmayan birincil kavramın, Return-Pathbaşlığın gönderen tarafından değil alıcı posta sunucusu tarafından eklendiğidir . Daha bu gibi Yani: Eğer içeride zarfın istiyorum hitap her ne yazabilir, ancak ehliyet (veya başka bir kimlik) postaneye götürüp onlara göstermek zorunda teslim etmek ve onlar Zarfın üzerinde bu adresi koymak göndermeden önce. Başka bir deyişle, başlık, diğerlerinin kolayca aldatılabileceği SMTP sunucusu tarafından yapılan denetimler kadar güvenilirdir. Return-Path
cdhowie

5

Buraya gelenler için sorunun başlığı çünkü:

Web Reply-To:formları ile adres kullanıyorum . birisi formu doldurduğunda, web sayfası sayfanın sahibine otomatik bir e-posta gönderir. From:Sahibi, web formunu dan bilmesi için, otomatik posta gönderenin adresidir. ancak Reply-To:adres, kullanıcı tarafından formda doldurulan adrestir, bu nedenle sahibi, kendileriyle iletişime geçmek için cevaba basabilir.


1

Redmine örneği tarafından gönderilen e-postalara bir Dönüş Yolu başlığı eklemek zorunda kaldım. Ben greatwolf katılıyorum sadece gönderen doğru (varsayılan olmayan) bir dönüş yolu belirleyebilir. Durum şu şekildedir: E-postalar varsayılan e-posta adresiyle gönderilir: admin@yourcompany.com Ancak eylemi başlatan gerçek kullanıcının geri dönen e-postaları almasını istiyoruz, çünkü yanlış alıcı e-postalarını nasıl düzeltebileceğini bilen biri olacak (ve kamçı diğer kediler olan uygulama yöneticileri değil :-)). Bunu kullanıyoruz ve uygulama sunucusundaki exim ve son şirket posta sunucusu olarak zimbra ile mükemmel bir şekilde çalışıyor.

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.