I am still waiting for your feedback
に翻訳できるタイトルのみの私の言語(ヘブライ語)の空のメールを受け取りました(元:עדיין מחכה למשוב שלך
)
私のGmailは複数のアカウントを(フォワードおよびuser\passで)処理するので、どのアカウントがターゲットであるかを理解しようとしましたが、驚いたことに、何もしませんでした!
私の質問は単純ですが、Gmailがこのメールを受信トレイに入れることにしたのはなぜですか?添付のベローは、(gmailからの)電子メールの完全なソースです検閲された電子メールを除く。 これはセキュリティ違反ではなく、スパムフィルターによって阻止されていないのですか?
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
が使用されました)。
2つの説明:
私はしばしば、彼らが何らかの理由でそれが宛てられた人にそれを隠したいと思われるスパムをしばしば受け取りました。私は私のドメインにキャッチオールを持っているので、彼らが使用したアドレスに関係なく私に届きます(私がブラックリストに登録したものを使用していない限り)。
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
ヘッダーがその受信者のみをリストするためのネストされた電子メールヘッダー。
To
、Cc
、Bcc
などのヘッダーは基本的にすべて表面的なものです。 SMTPプロトコルに従って、電子メールの実際の受信者を制御しません。これらのフィールドに好きなものを入力し、プロトコルレベルでメールの送信先を個別に制御することができます。
インターネットでメールを送信すると、送信メールサーバーはSMTPによって受信メールサーバーと通信します。電子メールを送信するために、送信側サーバーは一連のコマンドを受信側サーバーに送信します。
HELO
コマンド(これは、プロトコルの新しいバージョンではEHLO
( "Extended HELO"の省略形)で置き換えることができます)。MAIL FROM
コマンドは、メールの送信者のアドレスを通知します。RCPT TO
コマンドはメッセージ受信者のアドレスを通知します。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などの何らかの形式の暗号検証を使用し、帯域外で権限を検証する方法を使用する必要があります。
これまでのところ、あなたのアドレスは [〜#〜] bcc [〜#〜] として使用されていたと思います。
驚くかもしれませんが、SMTPプロトコルではこれはごく普通のことです。メッセージは、ヘッダーと本文で構成されます。メールトランスポートエージェントのチェーンを介して送信されます。ボディを変更するエージェントはありませんが、ヘッダーを変更して、主にReceived
フィールド、存在しない場合はDate
フィールド、および独自の処理で必要なその他のフィールドを追加できます。ただし、To
フィールドもFrom
フィールドも特別ではなく、特にこれらはメールの配信に使用されません 。 MTAは、エンベロープと呼ばれるものを使用します。つまり、MAIL FROM
およびRCPT TO
SMTPプロトコルのコマンド。
メールユーザーエージェント(Thunderbirdなど)はTo、Cc、Bccフィールドを使用してエンベロープを構築しますが、 SMTPプロトコル がわかっている場合は、ToおよびFromが偽造または不在のメールを簡単に送信できます。ヘッダー。