web-dev-qa-db-ja.com

「宛先」フィールドなしでこのメールを受信するにはどうすればよいですか？

I am still waiting for your feedbackに翻訳できるタイトルのみの私の言語（ヘブライ語）の空のメールを受け取りました（元：עדיין מחכה למשוב שלך）

私のGmailは複数のアカウントを（フォワードおよびuser\passで）処理するので、どのアカウントがターゲットであるかを理解しようとしましたが、驚いたことに、何もしませんでした！

Strange email without To

私の質問は単純ですが、Gmailがこのメールを受信トレイに入れることにしたのはなぜですか？添付のベローは、（gmailからの）電子メールの完全なソースです検閲された電子メールを除く。 これはセキュリティ違反ではなく、スパムフィルターによって阻止されていないのですか？

オリジナルメッセージ：

  • メッセージID <[email protected]>
  • 作成日：2018年1月16日火曜日2:54 PM（2秒後に配信）
  • From：joseph andrew Using Mail.Ru Mailer 1.0
  • に：
  • 件名：עדייןמחכהלמשובשלך
  • SPF：IP 217.69.138.160でのPASS詳細
  • DKIM：ドメインbk.ruでの「パス」詳細
  • DMARC： 'PASS'詳細
Delivered-To: ****<cencored>****@gmail.com
Received: by 10.2.76.217 with SMTP id q86csp4037724jad;
        Tue, 16 Jan 2018 04:54:21 -0800 (PST)
X-Google-Smtp-Source: ACJfBotHqXkzj6W7Gd+8IjEmxrwG9SqXBSC+QiTqyAB1j2Dt4ASXtmXr5UpqIpdU7Mge/EFmnzVI
X-Received: by 10.46.101.207 with SMTP id e76mr192303ljf.115.1516107261904;
        Tue, 16 Jan 2018 04:54:21 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1516107261; cv=none;
        d=google.com; s=arc-20160816;
        b=O+SDwmDS2Y7Jxi+mhwkV/+svfXK0KI3VvepeQgBpyhlgYY5gK3wln+RC4YPO+MMn71
         tyrGBUoc1iGKpeGcilWAovf0XLceJY+EAGoMX4Hl4Pse8C5mWiP0DJQXfmolB5myOFD/
         EoSl7Km4KDcQsvSC0DGwcni1yUPjgiQr+KIY+y19WCqVfm5EtCkbYkUCnFP1RWh/BUBp
         YZHKJrRYH/gWsSqBuIm/fDuSFk4bYAFaCOfkq5LfJcnkf7lpRFBnNYseignqwnnYMEzB
         aScqj1ppvCoYLbBuEiw+yLo1iQLoNdXwGOLShsGXELxkpdFpmchOEV44Wx2vp+RlJMF0
         v1/A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=content-transfer-encoding:message-id:reply-to:date:mime-version
         :subject:from:dkim-signature:arc-authentication-results;
        bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
        b=IPjf/U3N1a7Dx8HIw59iWKeccU4mS7Bd0Iy2FY/Be4Mx4QATd8uBvH7pLOVOLHRAXj
         iATzKUy69ZyLgu6gJVc+yjW3+i740O9ccPNbWAPQQASX1H9OkiMsmlhNYOU5u4KDKfbj
         nNm77TeMxrF57z4XKpbO3iE4YEv6JFankI949HvLnehC7wPP5M5YHpS8CllmV3zP8RX4
         2kb14n4PzguduwYoHL3q7wwWHHnyPUsa3UuhCKLvNJYw4KWKLWNY6Kt7fwReb83T+OsG
         lavZ7huDrCcf0P8Ee7YGepcNpGFyh2WjpA4o7l+gAlnqsb6+5FZloH6j7cmQx/gA+gKh
         aVng==
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass [email protected] header.s=mail header.b=kgyoMcic;
       spf=pass (google.com: domain of [email protected] designates 217.69.138.160 as permitted sender)
       [email protected];
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bk.ru
Return-Path: <[email protected]>
Received: from f493.i.mail.ru (f493.i.mail.ru. [217.69.138.160])
        by mx.google.com with ESMTPS id 1si926950ljd.480.2018.01.16.04.54.21
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 16 Jan 2018 04:54:21 -0800 (PST)
Received-SPF: pass (google.com: domain of [email protected] designates 217.69.138.160 as permitted sender) client-ip=217.69.138.160;
Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=mail header.b=kgyoMcic;
       spf=pass (google.com: domain of [email protected] designates 217.69.138.160 as permitted sender)
       [email protected];
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bk.ru
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bk.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:From;bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=kgyoMcicHiqU/OvYmq/2sQYQ3607jIk9ZHkh3oVDZTrA6cWDxLGvol37xuQ3L0mfrqIOpSTYHuJzssIjww+4FL/h/GwBRRO1AsuLgxyjSQaOLVqidNe0MUIz6EVQxYXLcUCl9USryPLWAWKBiwL80efALu5znH8K96P6fF33Gzw=;
Received: by f493.i.mail.ru with local (envelope-from <[email protected]>) id 1ebQkt-0004Zj-4G; Tue, 16 Jan 2018 15:54:19 +0300
Received: by e.mail.ru with HTTP; Tue, 16 Jan 2018 15:54:19 +0300
From: joseph
  andrew <[email protected]>
Subject: עדיין מחכה למשוב שלך
MIME-Version: 1.0
X-Mailer: Mail.Ru Mailer 1.0
Date: Tue, 16 Jan 2018 15:54:19 +0300
Reply-To: joseph
  andrew <[email protected]>
X-Priority: 3 (Normal)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Authentication-Results: f493.i.mail.ru; auth=pass [email protected] [email protected]
X-7FA49CB5: 0D63561A33F958A5898151702DBFE222A841889EBAE90B8E20672C31CB87FE38725E5C173C3A84C39B8A9203B4187291E49527301AB7C5D479C543ECCDAE434EC4224003CC836476C0CAF46E325F83A50BF2EBBBDD9D6B0F20A889B128FC2D163B503F486389A921A5CC5B56E945C8DA
X-Mailru-Sender: AEEF7784B292FD580FA14CB39DA65BAAC14FF9386EF48BFAB56EC34AB37A73FC68AD8B15A0E9EE36875DC23763F10D8F75E89B9EB25B1370F805D6321A69DA8E2FB9333096616C166E245241366DF001CF5B8F1B83B229A3C432A6261406F5E9E7E03437FF0094633453F38A29522196
X-Mras: OK
X-Spam: undefined

編集：

Bccと空の "to"で送信しようとしたところ、Gmailがbccを示しました。したがって、現在@Lucの回答が実際の回答であるようです（RCPT TOが使用されました）。

BCC try fail

emailspam
58
YoniXw

どうして？

2つの説明：

  • BCC
  • スパム

私はしばしば、彼らが何らかの理由でそれが宛てられた人にそれを隠したいと思われるスパムをしばしば受け取りました。私は私のドメインにキャッチオールを持っているので、彼らが使用したアドレスに関係なく私に届きます（私がブラックリストに登録したものを使用していない限り）。

これはどのようにして可能ですか？

SMTPトラフィックは次のようになります。

EHLO example.com 
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
RCPT TO:<[email protected]>
RCPT TO:<[email protected]>
DATA
Subject: test
From: <[email protected]>
To: <[email protected]>
CC: <[email protected]>

Hi Jake,
Just letting you know that email works.

.
QUIT

TCP任意のメールサーバーへの接続を開いてこれを入力すると、応答が返され、電子メールが配信されます（例では応答を省略しています）。Windowsでは、Telnetをインストールします。 Windowsの機能メニューからtelnet example.com 25と入力して、ポート25のexample.comでサーバーに接続します。

ご覧のとおり、user4はRCPT TOでアドレス指定されており、最終的にはメールの受信トレイに表示されますが、メールデータのfrom、to、またはccヘッダーには記載されていません。 DATAコマンドから1行の.までの電子メールデータは、電子メールクライアントで「ソースの表示」を開いたときに表示される部分です。したがって、実際のメール交換とはほとんど関係ありません。もちろん通常は一致しますが、悪意のあるケースでは、「通常」が何であるかを気にしません。また、BCCの場合は表示されません。

送信先に隠されたスパムがよく届きます。それを追跡できるようにするには、メールサーバーのログを掘る必要があります。

サーバー管理者もこのようなBCCを検索できますが、もちろん自分のドメインのみです（[email protected]および[email protected]にBCCされた場合、a.example.comの管理者にはステファンは表示されません] ）。

なぜGMailをBCCで自分に送信し、自分自身が受信側にリストされているBCCフィールドを表示できるのか：メールプログラム/プロバイダーは、BCCの各受信者に個別のSMTPメッセージを送信でき、BCCヘッダーがその受信者のみをリストするためのネストされた電子メールヘッダー。

84
Luc

To、Cc、Bccなどのヘッダーは基本的にすべて表面的なものです。 SMTPプロトコルに従って、電子メールの実際の受信者を制御しません。これらのフィールドに好きなものを入力し、プロトコルレベルでメールの送信先を個別に制御することができます。

インターネットでメールを送信すると、送信メールサーバーはSMTPによって受信メールサーバーと通信します。電子メールを送信するために、送信側サーバーは一連のコマンドを受信側サーバーに送信します。

  1. 送信サーバーのホスト名を指定するHELOコマンド（これは、プロトコルの新しいバージョンではEHLO（ "Extended HELO"の省略形）で置き換えることができます）。
  2. MAIL FROMコマンドは、メールの送信者のアドレスを通知します。
  3. RCPT TOコマンドはメッセージ受信者のアドレスを通知します。
  4. ヘッダーと本文を含むメッセージ自体の開始を通知するDATAコマンド。

To、Cc、Bccなどのメッセージ内のヘッダーは処理または使用されませんが、変更されずに送信されます。

これらのヘッダーが送信および受信メールサーバーによって無視される場合、なぜそれらが存在するのですか？

これらは、メールユーザーエージェント（メールクライアント）ソフトウェアで使用される一般的な規則であるため、ユーザーが実際にメールを送信するために対話するソフトウェアです。メールクライアントが機能する通常の方法は、ユーザーが「To」、「Cc」、および「Bcc」と呼ばれるメールクライアント内の3つのフィールドに受信者のアドレスを入力することです。 。次に、メールクライアントは「To」フィールドと「Cc」フィールドに書き込まれた内容を取得し、「To」と「Cc」と呼ばれるメールヘッダーに配置して、送信者がこれらのフィールドに最初に入力した内容の受信者を示します。これは、受信メールクライアントへの礼儀にすぎません。送信側のメールクライアントは、この秘密を保持することを選択できます。実際、それが "Bcc"フィールドで発生します。メールクライアントが送信する電子メールに "Bcc"ヘッダーを作成することはありません。これは、この機能が含まれていないためです。メール自体に。

メールクライアントには、「Subject」フィールドも含まれ、「Subject」ヘッダーとしてメールに配置され、送信者に関する情報を含む「From」ヘッダーがメールに作成されます。

これはセキュリティ上の問題ではないのですか？

そうです。送信者または受信者に関する偽の情報を電子メールに入れるのは簡単です。ユーザーがこれが正確であると信頼しているが、そうでない場合、それは潜在的なセキュリティ問題です。

メールクライアントはこのようなヘッダーを単に無視することができますが、この情報が存在し、本物である場合に、電子メールの宛先が誰であるかを知ることができず、同じロジックで、「From」と「From」も無視する必要があります。エンベロープ送信者（MAIL FROMコマンド）も同様で、誰が送信したかは表示されません。したがって、メールクライアントは、偽造されたとしても、この情報を表示することにはより多くの利点があるというアプローチを取ります。

DMARCと呼ばれる新しい標準は、他の標準DKIMおよびSPFに便乗して、受信メールクライアントが「From」ヘッダーのドメイン/ホスト名の部分が本物であることを確認できるようにします。これは、「From」ヘッダーの部分のみを検証し、「To」または「Cc」ヘッダーは検証しませんが、メールは、発信元であると主張しているシステムからのものでした。これが信頼できるシステムである場合、少なくともメールとそのヘッダーがそのシステムの承認されたユーザーによって作成されたと推測できます。

これらのオプションに加えて、電子メールはこれらすべてを検証できるように設計されていませんでした。さらに必要な場合は、メッセージの上部でPGPなどの何らかの形式の暗号検証を使用し、帯域外で権限を検証する方法を使用する必要があります。

32
thomasrutter

これまでのところ、あなたのアドレスは [〜＃〜] bcc [〜＃〜] として使用されていたと思います。

18
Mirsad

驚くかもしれませんが、SMTPプロトコルではこれはごく普通のことです。メッセージは、ヘッダーと本文で構成されます。メールトランスポートエージェントのチェーンを介して送信されます。ボディを変更するエージェントはありませんが、ヘッダーを変更して、主にReceivedフィールド、存在しない場合はDateフィールド、および独自の処理で必要なその他のフィールドを追加できます。ただし、ToフィールドもFromフィールドも特別ではなく、特にこれらはメールの配信に使用されません 。 MTAは、エンベロープと呼ばれるものを使用します。つまり、MAIL FROMおよびRCPT TO SMTPプロトコルのコマンド。

メールユーザーエージェント（Thunderbirdなど）はTo、Cc、Bccフィールドを使用してエンベロープを構築しますが、 SMTPプロトコル がわかっている場合は、ToおよびFromが偽造または不在のメールを簡単に送信できます。ヘッダー。

15
Serge Ballesta