Meşru nedenler SMTP “MAIL FROM:”, DATA'daki “Kimden:” Başlığı ile eşleşmiyor


18

Posta listelerinin yanı sıra SMTP “MAIL FROM:” alanının bir iletinin VERİ bölümündeki “Kimden:” alanıyla eşleşmemesinin meşru bir nedeni var mı?

Gönderen /programming/1750194/smtp-why-does-email-needs-envelope-and-what-does-the-envelope-mean :

“Ancak, salyangoz posta metaforunuza devam etmek için, çoğu profesyonel harf, gönderenin ve alıcının mektubun kendisine yazdırılmış adreslerini içerecektir. Bu adresler postacı için gerekli değildir, bunun yerine alıcıya nezakettir. Dolayısıyla e-postanın aynı şekilde çalışması mantıklı. ”

Bu mantık çizgisi ile ilgili problem burada yatmaktadır: “alıcıya nezaket”. SMTP aracılığıyla bir e-postaya “Kimden:” adresini eklemek nezaket değildir; alıcının bir yanıt gönderebilmesi için gereklidir.

Kimden: Kimden üstbilgisi postfix'te MAIL FROM ile eşleşecek şekilde nasıl sınırlandırılır? :

“Ama eğer gerçekten From: ve MAIL FROM'dan emin olmak istiyorsanız, Return-Path: From: ile eşleşmesi için header_checks uygulamanız gerekir.”

Bunu yapmanın sonuçları nelerdir? Posta listeleri açıkça bir sorun olacaktır. Farklı “MAIL FROM:” ve “From:” başlık bilgilerinin başka meşru kullanımları var mı?

Yanıtlar:


22

Üstbilgi ve Zarf Kimden adreslerinin eşleşmemesinin birçok nedeni olabilir. Çoğu, posta gönderme, postaları kimin gönderdiğini veya kimler adına gönderildiğini veya kimin yanıtlanması gerektiğini temsil etmeyen bir adrese bildirilmesi gereken posta gönderen otomatik işlemler ile ilgilidir. Belirttiğiniz gibi posta listeleri iyi bir örnektir.

Bir kullanıcının posta istemcisinden gönderilen bir iletinin adreslerden farklı olmasının ana nedeni iletilen postalardır. Bu durumda posta içeriği aslına makul bir şekilde sadık olmalıdır, ancak teslimat hataları durumunda, bunlar orijinal göndereni değil, e-postayı ileten kullanıcıya bildirilmelidir.

SMTP başlığının yanı sıra, çeşitli programların orijinal gönderen ve ara gönderen ve / veya hataları bildirmek için tercih edilen adres arasında ayrım yapmak için kullandığı çeşitli MIME başlıkları da vardır.Eg Yanıtla, Gönderen, Başlangıçta , Hatalar-To, vb, her biri farklı semantik ile. Bunlardan bazıları standart desteğe sahipken, birçoğu yok, ancak yine de kullanımda olabilir. Çeşitli posta programlarının pratikte nasıl davrandığı oldukça değişkendir.

Posta adresleme yönteminin tavsiye edilip edilmeyeceği, sizin istediğiniz gibi "meşru" olup olmadığından farklı bir konudur. Burada potansiyel spam'ı ele alma politikası gibi bir meşruiyeti düşünüyorsanız, hayır, bu şekilde basit bir ayrım yapabileceğinizi düşünmüyorum.

E-postanın DKIM imzası ve e-posta etki alanları için posta sunucularının SPF kimlik doğrulaması hakkında bir düşünün. Çok fazla posta gönderiyorsanız, postanızın bu yollarla kimliğini doğrulamanız önemli olabilir ve bu, postanın adreslenmesi için bazı etkileri olabilir. .

-

Talep üzerine genişletildi:

Bir MIME 'Yanıtla' başlığı, bir MUA'yı (Posta Kullanıcı Aracısı, genellikle bir kişinin posta istemcisi) MIME 'Kimden' adresi yerine farklı bir adrese yanıt göndermeye yönlendirir. Bu, MTA (Posta Aktarım Aracısı) tarafından hatalar gibi şeyler için kullanılmaz.

Genellikle MTA, hata göndermek için SMTP Zarf 'MAIL Kimden' adresini kullanır. MTA komutu olan bir MIME 'Hatalar-Kime' üstbilgisi ile geçersiz kılınabilir. Tüm MTA'lar onurlandırmaz, bu nedenle SMTP Zarf adresini ayarlamak için daha düşük bir mekanizmadır, ancak bir mesajda MIME Üstbilgileri ayarlamanın mümkün olabileceği birçok durum vardır, ancak SMTP Zarf Kimden adresi değil. Örneğin, paylaşılan bir barındırma ortamında çalışan yazılım bu durumda kendini bulabilir.

'Gönderen', yazılım aracılarına bir talimat olarak çok daha belirsizdir, ancak e-postayı kimin veya neyin gönderdiği, Gönderen adresinden farklı olan ve posta adına kimin gönderildiği gibi olanı belirtir. Örneğin, çevrimiçi bir e-posta politikacı formunu doldurduğunuzda, ortaya çıkan e-postanın postanızı Kimden başlığında kullanması çok uygun olur, ancak formu kuran kuruluşla ilgili bir Gönderen adresine sahip olmanız gerekir.

'Başlangıçta Gönderen', bazı MUA yazılımları tarafından posta yönlendirilirken, gönderenin adresi 'Kimden' başlığı için kullanılır. Diğer MUA'lar Kimden adresini yalnız bırakacak ve bir 'Tekrar Gönderme' başlığı kullanacaktır. MUA'nın bu çeşitli üstbilgileri aldığı e-postaların üstbilgileri faydalı bir şekilde yorumlayıp yorumlamadığı, hatta görüntüleyebileceği oldukça değişkendir. Size gönderilen bir postayı yanıtlarken, yanıt varsayılan olarak kime gitmelidir? Belki bu 'Yanıtla' başlığını ayarlamak en iyisidir?

MUA'ların davranışı değişkendir ve zamanla iyileşiyor gibi görünse de kötü tanımlanmıştır. Aksine, Zarfın anlambilimi çok daha tanımlanmıştır. Tipik olarak MTA'ların kendilerini MIME üstbilgileriyle asla ilgilenmemesi gereken güçlü bir pozisyon vardır, ancak MTA'lar posta içeriğinden giderek daha fazla sorumlu tutulduklarından (örneğin, bkz. SPF ve ortaya çıkan DMARC standartlarına bakın), bu pozisyonun açıklığının bozulmasına yönelik baskı vardır. Hatalar-To gibi uzun süredir devam eden mekanizmalar, MTA'ların başlık içeriğine bakmama kavramıyla da çelişmiştir, bu da bu mekanizmaların neden her zaman tutarsız bir şekilde uygulandığının bir parçasıdır. Yazılım yazarlarının felsefeleri değişiklik gösterir.

Http://tools.ietf.org/html/rfc4021#section-2'ye bakmak yararlı olabilir , ancak çok sayıda posta yazılımının gerçek uygulamalarının, standartların kutsanması gerekmeyen şekillerde değiştiğini unutmayın.

Postanın nasıl kullanılması gerektiğini düşündüğünüze dair net bir felsefe bulmaya çalışmak iyidir, ancak diğer herkesin nasıl olması gerektiğini düşündüğünüzü yapmasını beklemeyin.


Hala ödül bu ödül zaman var ve ek senaryolar ilgilenen am başlıkların kullanılmasını gerektirecektir böyle: `Gönderen, Aslen-itibaren Hatalar-To` Yapılır Cevap
goodguys_activate

Eklemeler için teşekkürler. MTA'nın beklenen davranışları, vs ne uygulandıkları hakkında net bir anlayış elde etmeyi umuyorum. Ayrıca, bu q ilginizi çekebilir: Sadece e-posta (BATV benzeyen) beyaz liste ile ilgili Sec.StackExchange yayınlanan security.stackexchange.com/q/41008/396
goodguys_activate

1
+1, neden sadece 4 oy?
Pacerier

11

Otomatik işlem büyük bir nedendir. Ayrı olarak işlenmek üzere hemen çıkma / otomatik uygulama / hata gönderebilmeniz gerekir, aksi takdirde bu iletiler kaybolur veya yok sayılır veya bazı zayıf özlerin bunlardan geçmesi gerekir. Evet, işleme için bir X başlığı eklemek mümkündür, ancak çoğu zaman zıplar / vb. orijinal e-postayı veya yalnızca karışık bir bölümünü içermez ve kaynağı alamazsınız.

Örneğin, birisinin web sitenize kaydolduğunu ve kaydolduğunuz için teşekkür eden bir e-posta gönderdiğinizi varsayalım. MAILFROM ve From öğeleriniz şöyle görünebilir:

MAIL FROM: <user-signup-123123123@bounces.example.com>
From: Website X <noreply@example.com>

Bu şekilde, kullanıcı posta istemcisinde "kolay gelen" görür. Ancak kullanıcı yoksa, MTA'sı hemen çıkma mesajını şu adrese gönderir:

user-signup-123123123@bounces.example.com

ve otomatik bir işlem, kullanıcı kimliğini (123123123 kısmı) ve sistemin sıçramayı (-signup- kısmı) oluşturan kısmını başlıktan kolayca çekebilir ve bu kullanıcıyı kolayca devre dışı bırakabilir / işaretleyebilir.


8

Smtp ileti dizisindeki posta: geri dönenlerin gideceği yer olarak tasarlanmıştır İleti gövdesindeki Kimden: üstbilgisi alıcıya görüntülemek için ve Yanıtla: üstbilgisi ayarlanmamışsa yanıt adresi olarak kullanılır.

Sıçrama oluşturmaması gereken e-postalar zarfta boş göndereni ayarlamalıdır, örneğin bir iade makbuzu genellikle şunlara sahip olacaktır: mail from:<>kullanıcının adı from: başlığında.

Başka bir durum, bir posta sunucusunun sahte zıplamaları reddetmek için BATV'yi kullanmasıdır. Posta adresi: prvs=tag-value=mailbox@example.com biçiminde olacaktır.


Sanırım geri dönüşler ve NDR'ler için bir X-başlığı görüyorum. Bunun ne zaman ve nasıl kullanıldığını biliyor musunuz?
goodguys_activate

X başlıkları başlangıçta MUA ve / veya MTA aracı olarak özel meta veriler koymak için eklenmiştir ve bazıları standartlar haline gelmemekle birlikte herhangi bir standartta belirtilmemiştir. Yazılımın otomatik olarak geri dönen iletileri sınıflandırmasına yardımcı olmak için tanımlanan rfc 6522'de tanımlanan çok bölümlü / rapor mime türünü düşünüyor olabilirsiniz . Bunlar yine posta yoluyla boş bir zarfla gönderilecek:
Richard Salts

1

Başlıklarımı veya soruyu doğru bir şekilde okumadığım sürece, BlackBerry'imden gelen e-postalar BlackBerry sunucusundan gönderilir ve temel olarak alanların hiçbiri eşleşmez. Kullanıcıların küçük bir yüzdesinin farkındayım. Son zamanlarda posta sunucumu değerlendirirken bakıyordum. Aşağıda, BlackBerry cihazımdan Gmail hesabıma gönderilen anonim bir e-posta adresi verilmiştir:

Delivered-To: recipientusername@gmail.com
Received: by 10.50.11.138 with SMTP id q10csp217364igb;
        Wed, 14 Aug 2013 00:18:53 -0700 (PDT)
X-Received: by 10.42.83.84 with SMTP id g20mr4290552icl.10.1376464731205;
        Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Return-Path: <SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com>
Received: from smtp08.bis6.us.blackberry.com (smtp08.bis6.us.blackberry.com. [74.82.85.8])
        by mx.google.com with ESMTP id lq6si7427361icb.102.2013.08.14.00.18.51
        for <recipientusername@gmail.com>;
        Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Received-SPF: pass (google.com: domain of SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com designates 74.82.85.8 as permitted sender) client-ip=74.82.85.8;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com designates 74.82.85.8 as permitted sender) smtp.mail=SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com
Received: from b15.c8.bise6.blackberry ([192.168.0.115])
    by srs.bis6.us.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id r7E7InfH019786
    for <recipientusername@gmail.com>; Wed, 14 Aug 2013 07:18:49 GMT
Received: from 172.29.201.172 (cmp2.c8.bise6.blackberry [172.29.201.172])
    by b15.c8.bise6.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id r7E7IlCt013236
    for <recipientusername@gmail.com>; Wed, 14 Aug 2013 07:18:47 GMT
X-rim-org-msg-ref-id: 587275596
Message-ID: <587275596-1376464726-cardhu_decombobulator_blackberry.rim.net-631052459-@b17.c8.bise6.blackberry>
Reply-To: senderusername@example.com
X-Priority: Normal
Sensitivity: Normal
Importance: Normal
Subject: Test
To: "Recipient Name" <recipientusername@gmail.com>
From: senderusername@example.com
Date: Wed, 14 Aug 2013 07:18:45 +0000
Content-Type: text/plain
MIME-Version: 1.0

Test
Sent via BlackBerry by AT&T

Bunun mükemmel bir nedeni var - SPF yeniden yazma . BlackBerry bunu yapmasaydı, cihazınızdan gönderilen çok daha fazla SPF hatası alırsınız.
MikeyB

Doğru, ancak BlackBerry sunucumu göndermek için kullanmıyor.
Paul
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.