タグ付けされた質問 「email」

sendmail用の自動応答スクリプトを作成しようとしています（いいえ、事前に作成したスクリプトをまだ使用したくありません）が、サーバーで受信したメールの場所を見つけることができないようです。私の構成がデフォルトではないことを指定する必要があります。 を調べましたが/root、メールフォルダはありません。（私はroot以外のユーザーはいません）。を調べましたが/var/mail/root、メールで送信されたログがいくつかありますが、ユーザーから受信した外部メールはありません。 確認しました/var/log/maillogが、エラーはありません。 どこを見ればいいかわからない。誰か助けてもらえますか？

10 email  sendmail 

mail.mydomain.comのSPKおよびDKIMレコードを設定する必要があります。namecheapで以下を設定しました- SPFの場合- Record type :TXT Hostname : mail.mydomain.com Value : v=spf1 ip4:x.x.x.x ~all DKIMの場合- Record type : TXT Host : mailer._domainkey Value : "v=DKIM1; k=rsa; p=LONGSTRING" これは、mail-tester、mxtoolboxなどのオンラインチェックツールでチェックすると機能しません。 [解決済み] 以下の回答の1つとは異なり、サブドメインのレコードを設定することもできます。Namecheap（および他のプロバイダーも同様）の問題です。このようにホスト名を設定する必要があります- SPF hostname : mail DKIM hostname : mailer._domainkey.mail Namecheapは自動的にdomain.comを最後に追加します。追加する必要はありません。また、DKIMレコードのDNS伝播には15時間以上かかりました。

10 domain-name-system  email  email-server  domain  subdomain 

私はあらゆる場所を検索してきましたが、これに本当に苦労しています。私はすべてを試してみたと思います。 背景情報 CentOS 6.7のVPS Postfix 2.6.6 dovecot、amavis、mysql、fail2ban 私のVPSプロバイダーは、ポートをブロックしないことを確認しました。 私がやったこと ストックsendmailを削除 完全なメールソリューションのためにpostfix、dovecot、mysqlなどをインストールしました STARTTLSでimap、smtpのみを許可しています（ポート143および587） SSHログインは無効になり、キーのみ メールを受信できる（ポート143経由） localhostから両方のポート（587、25）にtelnetで接続でき、Postfixグリーティングが表示されます 587または25（メールクライアントまたはtelnet）に接続しようとすると、応答がゼロになります（接続タイムアウト）。 私が試したもの 1）ポートは開いていますか？はい、iptables： Chain INPUT (policy DROP 11 packets, 1375 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:587 0 0 ACCEPT tcp …

9 centos  email  postfix  smtp 

ドメインexample.comを例にとると、2つのメールサーバーmail1.example.comとmail2.example.comがあり、どちらも既に構成されています。通常、次の設定を使用します。 example.com. 1200 IN MX 10 mail1.example.com. example.com. 1200 IN MX 10 mail2.example.com. mail1.example.com. 1200 IN A 172.16.10.1 mail2.example.com. 1200 IN A 172.16.10.2 同僚が次の設定を提案しました： example.com. 1200 IN MX 10 mail.example.com. mail.example.com. 1200 IN A 172.16.10.1 mail.example.com. 1200 IN A 172.16.10.2 mail1.example.com. 1200 IN A 172.16.10.1 mail2.example.com. 1200 IN A 172.16.10.2 …

9 domain-name-system  email  mx-record 

EC2インスタンスでホストされているeコマースWebサイトからトランザクションメールを送信する必要があります。通常のメールサービスはGoogleがホストしています。 問題は、SESが利用できないアジア太平洋地域に拠点を置いていることです。では、SESを使用するためだけにリージョンを変更できますか？EC2インスタンスに影響はありますか？これに関するドキュメントが見つかりません。

9 email  amazon-ec2  amazon-ses 

当社のSPFレコードフォーマットは以下の通りです： "V = spf1レコードが含まれます：_spf.google.com 〜すべてのmx IP4：XX0.0 / 23は以下のとおりです。spf.example.comをすべての？" したがって、SPFレコードの中央に「〜all」があります。上openspf.comのウェブサイト、彼らは「すべて」のメカニズムについて、これを言います： このメカニズムは常に一致します。これは通常、SPFレコードの最後に置かれます。 したがって、彼らは「すべて」がSPFレコードの最後に行く必要があるとは言いませんが、通常は最後に行くと言います。 弊社では、最近、SPFレコードにリストされているサーバーから送信された電子メールにソフトフェイルが発生するのを目にしていますが、SPFレコードはこれまでに見つかったすべての検証ツールを通過しています。 私が思っているのは、Google Apps（_spf.google.com）のインクルードの直後の「〜all」が原因で解析が停止し、SPFレコードの残りの部分が認識されないのでしょうか。パスとソフトフェイルは、誰がそれを解析し、S​​PFレコードを処理する方法の具体的な実装に依存しますか？SPFレコードの最後にない「すべて」のメカニズムを使用する理由はありますか？ そして、はい、SPFレコードを変更するだけでよいことはわかっています。この質問は、これがどのように機能するかを明確にすることに関するものであり、必ずしも特定の状況を解決することに関するものではありません。

9 domain-name-system  email  spam  g-suite  spf 

ドメインのSPFレコードを設定しましたが、次のような偽のメールサービスを使用してドメインのメールアドレスを偽装することができます。http：//deadfake.com/Send.aspx メールがGmailの受信トレイに届きます。 メールのヘッダーには次のようなSPFエラーがあります。spf=fail (google.com: domain of info@mydomain.com does not designate 23.249.225.236 as permitted sender)ただし、問題なく受信されています。つまり、誰でも私のメールアドレスを偽装することができます... 私のSPFレコードは： v=spf1 mx a ptr include:_spf.google.com -all 更新誰かが興味を持っている場合のために、私のSPFレコードと一緒にDMARCポリシーを公開し、Gmailがなりすましメッセージを正しくマークするようになりました（画像）

9 email  spf 

電子メールにSPFのマークが付いているにもかかわらず、偽造された電子メールが主要な電子メールプロバイダー（gmail.com、outlook.com）に配信されている理由を理解しようとしていますhardfail。メールはMicrosoft Exchangeにも配信さPermErrorれ、同じSPFレコードに対してがスローされます。 壊れたSPFレコードを定義するSOME_DOMAIN.comドメインを使用してメールを送信しています。電子メールは、SOME_DOMAIN.comのSPFレコードに明示的にリストされていない自分のIPアドレスから送信されます。SOME_DOMAIN.comのSPFレコードには次の3つのプロパティがあり、最初の2つはSPF RFC-4408の違反です。 のため、SPFレコード全体を解決するには、10を超えるDNSクエリが必要include:です。 SPFレコードの1つに構文エラーがあり、python-spfが解析エラーをスローします。 SPFレコードは、ルールの両方が含まれている~allと-all、両方のすべてのアドレスのセットがすべきことを言ってsoftfailやhardfail admin@SOME_DOMAIN.comになりすましてoutlook.comアドレスに送信されたメールには、配信されたメールのSMTPヘッダーに次のエラーが含まれます。このメールは通常、ユーザーの受信トレイに配信されました： Received-SPF: PermError (: domain of SOME_DOMAIN.com used an invalid SPF mechanism) Gmailもユーザーの受信トレイにメールを配信しますが、別のSPFエラーをスローします。 spf=hardfail (google.com: domain of admin@SOME_DOMAIN.COM does not designate x.x.x.x as permitted sender) smtp.mail=admin@SOME_DOMAIN.COM ここで何が起こっているのでしょうか？SPFにもかかわらずメールが配信されるのはなぜhardfailですか？壊れたSPFレコードがあるということは、他のSMTPサーバーがSPFを完全に無視するということですか？または私がここで見逃しているものがあります...

9 email  exchange  smtp  spf 

私はamavisを実行しているpostfixサーバーとSpamAssassinを使用してスパムのフィルタリングを支援しています。スパムとして検出されたメッセージは、ユーザーのMaildirに配信されると次のようになります。 2013年3月15日01:46:20にtom @ tom-mintから リターンパス：<tom @ tom-mint> X-Original-To：tom@my-server.com 配信先：tom@my-server.com X-Virus-Scanned：my-server.comのDebian amavisd-new X-Spam-Flag：はい X-Spam-Score：6.463 X-Spamレベル：****** X-Spam-Status：はい、スコア= 6.463 tagged_above = 2必須= 6.31 tests = [DRUGS_ERECTILE = 2.221、FH_FROMEML_NOTLD = 0.18、 FSL_HELO_NON_FQDN_1 = 0.001、HELO_NO_DOMAIN = 0.001、RCVD_IN_PBL = 3.558、 RDNS_DYNAMIC = 0.363、TO_NO_BRKTS_DYNIP = 0.139] autolearn = no 日付：金、2013年3月15日01:46:19 -0400 宛先：tom@my-server.com 件名：*** SPAM ***こんにちは User-Agent：家宝mailx 12.5 …

9 linux  email  postfix  spam 

SMTPリレーへの認証を必要とするPostfixサーバーがあります。MySQLデータベースでは仮想メールボックスを使用します。 システムを介してメッセージがリレーされたため、メッセージの送信に使用されたユーザーアカウントを特定する必要があります。 メッセージヘッダーには以下が含まれます。 Received: from User (c-76-109-241-139.hsd1.fl.comcast.net [xx.109.xxx.139]) by ourserver.com (Postfix) with ESMTPA id 7BA184B4AD4; Tue, 3 Jul 2012 05:42:59 -0400 (EDT) 「ユーザー」というユーザーがいないため、IPアドレスはメールの送信元ではありません。メッセージの送信時に送信者が認証したユーザーアカウントを確認します。 これを追跡する方法はありますか？

9 email  postfix  security 

私のグーグルアプリドメインの奇妙な振る舞いに気づきました。ほとんどのメールは予想どおりに届きますが、ある期間、特定の送信者からのメールが届かないという結論に達しました。メールが届かない送信者を1人特定した後、私にメールを送信して「配信失敗」の応答を通常のGmailに転送するように依頼しました。 配信失敗の応答には、次のスニペットが含まれていました。 -----セッションのトランスクリプトが続きます----- <myusername@GHS.L.GOOGLE.COM>...遅延：ghs.l.google.comで接続がタイムアウトしました。 これは、Google Appsヘルプフォーラムのこのページに私を導いたクイック検索を行うことによって問題を特定するのに役立ちました。実際、ドメインのDNSレコードを確認したところ、@ghs.google.comに設定されていました。（CNAME）、それをすべきではありません。これを@ 74.125.93.121 (A)*に変更すると、問題は解決しました。 メールが届かない場合は、CNAMEルックアップによってドメイン名が正規の名前に置き換えられたため、myusername@ghs.l.google.comではなくにメールが送信されたと理解していますmyusername@mydomain.com。しかし、それが送信者の大多数で機能したのはなぜですか？メールが届かない送信者は、別の種類のメールプロトコル、奇妙なDNS設定を使用していましたか、それとも何ですか？ グーグルで問題を調査することで私が見ることができたものから、これは広範囲にわたる問題であるように思われます（battle.netからの電子メールが届かないという多くの人々は、1つの人気のある例です）、人々はそうではないようです問題は送信者側ではなく、独自のDNS設定にあることに注意してください。 これはどのように説明できますか？ * ここで読んだことから、このIPを使用しましたが、どのIPでもうまくいくと思います。誰でもこれを確認できますか？単に@レコードを削除しても問題は解決せず、変更する必要があったことに注意してください。

9 domain-name-system  email  g-suite  cname-record 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ サーバー障害のトピックになるように質問を更新します。 5年前休業。 私が実行しているcPanelサーバーの1つで、侵害された電子メールアカウントに関する問題が常に発生しています。このサーバーのユーザーの多くは非常に弱いパスワードを持っていると思います。最小限のパスワードセキュリティを強化しましたが、それはパスワードが変更された場合にのみ有効になります...すべてのcPanelアカウントとcPanel電子メールアドレスのワンタイムパスワード変更を強制する方法はありますか？このようにして、すべてのユーザーに新しい安全なパスワードを生成させることができます。 更新：各アカウントには~/etc/domain.name/{passwd,shadow}、すべての電子メールアカウントのUnixスタイルのpasswdファイルとshadowファイルを含むファイルがあることがわかりました。ただし、手動で編集した場合でも、メールを送信できます:-( eximがユーザーの認証に使用するファイルを見つけて、そこでパスワードを壊すことができれば、私の問題は解決します...

9 security  email  exim 

私はMicrosoft Exchangeを使用している人と使用していない人がいる環境で働いています。Exchangeから送信される会議の招待状には、iCal形式の会議情報を含むテキスト/カレンダーの添付ファイルが含まれています。また、空のtext / plainと空のtext / htmlパーツも含まれます。 Exchangeを構成して、text / plainまたはtext / html部分のいずれか（または両方）に、人間が読める形式の会議概要を入力する方法はありますか？これは、テキスト/カレンダーの添付ファイルをネイティブでサポートしていないメールクライアントを使用している人々を助けるでしょう。

9 email  exchange 

RFC 2822（電子メールの定義）で定義されているように、78文字（CRLFを除く）を超えてはならず、998文字を超えてはなりません（SHOULD）。quoted-printableを使用すると、長い行はより多くの行に分割され、実際の改行に達するまで各行は「=」で終了します。メールが標準（78（または998）文字より長い行を含むがquoted-printableでエンコードされている場合） quoted-printableメッセージをデコードした後、受信メールクライアントに長い行があるため、これは準拠していないという議論があります。 編集：David Caryの質問のとおりに質問を明確にするために：はい、私はquote-printableでエンコードされたメールはquoted-printableと互換性があるべきであることを意味します、つまり行が76文字を超えないことを意味します。ただし、デコードされたメッセージには、この制限より長い行がある場合があります。だから私の質問です：RFC 1521を実装するクライアントソフトウェアは、quoted-printableテキストコンテンツをデコードした後、無期限に長い行を処理するはずですか？これは、これまでの両方の回答で「はい」と回答されています（ありがとう）。これは、ネチケット（RFC 1855）によって推奨されないという制限があります。しかし、Netiquetteは、行の長さを65文字に制限し、誰も守らない制限にさえしています。

9 email  rfc 

SPF TXTレコードを含めるために、ドメインのDNSレコードがWeb開発者からリクエストされました。私はこれについて異なる意見を見つけました... あなたが提供できるコメントや洞察は高く評価されます。これは経験的な質問自体ではないことは承知していますが、それでも主観的な提供に感謝します...特に、ウェブポストやオンラインドキュメントなど、参考資料が含まれている場合は調べてみます。

9 domain-name-system  email  spf