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

まともなサイズのプロジェクトのバグトラッカーは、私にとっては簡単なことのように思えます。問題が衝突したり混同したりすることなく、数百または数千の問題を非常に簡単に整理できます。 そのため、Gitのように、メンテナンスと開発を調整する主な方法としてメーリングリストを使用するいくつかの非常に大きなプロジェクトを見ると、少し圧倒されます。例： Git-コミュニティページ： ...バグレポートはこのメーリングリストに送信する必要があります。 WikipediaごとのDebianバグ追跡システム： ...そのユニークな機能は、バグレポートを編集するためのウェブインターフェースの形式がないことです-すべての変更は電子メールを通して行われます。 最新のバグトラッカーの多くは、電子メール（見ているバグや自分に割り当てられているバグに関するコメントや通知を受け取ることができます）やバージョン管理システム（問題を解決するなどのマークを付けることができます）と非常によく統合されています。）。この多くは、メーリングリストを使用して手動で行う必要があり、興味のないバグに関する大量の電子メールを受け取ることになります。 それでは、Webベースのバグトラッカーに対するメーリングリストの主な利点は何ですか？一部の大きなプロジェクトでメーリングリストのみが使用されるのはなぜですか？

65 project-management  communication  issue-tracking  email 

この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 8年前に移行され ました。 Webサイトの顧客が購読する電子メールアラートを設定する場合、どのようなエチケットのルールに従う必要がありますか？ 私は頭の上のいくつかを考えることができます： ユーザーはオプトアウトできます テキストのみ（または味のあるリモートイメージ） 週に1回以上送信されない クライアントは、メールの受信対象をきめ細かく制御できます（関心のあるもののみを受信します） 他に考慮すべき点は何ですか？ プログラミングの観点から、電子メール通知を設定および実行するための最良の方法は何ですか？ ASP.NETサービスを使用する必要がありますか？Windowsサービス？どちらに落とし穴がありますか？ 送信された電子メールをログに記録するにはどうすればよいですか？それらが受信されたかどうかは気にしませんが、メールを送信したかどうかを証明する必要があります。

21 c#  asp.net  web-development  email 

私はこの答えを読んで、パスワードをメールで送信しないことを主張するコメントを見つけました： パスワードをメールで取得できないようにする必要があります。これは、パスワードがどこかにプレーンテキストで保存されていることを意味します。リセットのみが必要です。 これにより、[パスワードを忘れた場合]オプションを処理する問題が生じます。 ユーザーがそれを読むことができるように、どんなUIでも生のパスワードを表示する必要があります。「パスワードを忘れた」を処理する方法は何でしょうか

18 programming-practices  security  email  passwords 

同僚に送信したメールの言い換え システムAに問題があることに気づきました。Xが原因ではないと判断しました。Yが原因であると思われます。（Yを担当しているので）見てください （この同僚はYを担当していることをよく知っているため、括弧内の部分は私のメールに含まれていませんでした...それが理解できるように、それが彼にメールを送信していた理由です） 半日後に同僚に出会い、「まだシステムAの問題を見ていましたか？」と言います。「ああ、そうです、システムAが壊れているというメールを受け取りましたが、おそらくXが原因だと思ったので、確認するのを待っていました。」 明らかに、私のメッセージは伝えられませんでした。これは私が送信する電子メールのあまりにも一般的な結果であり、非常に落胆しています...しかし、私はどのように私の電子メールをもっと明確にすることができるかわかりません。それらは常に、簡潔で明確で、私が作成できるほど重要です。助言がありますか？たぶん、これらのタイプのコミュニケーションに効果的ではない電子メールの媒体に固有のものがありますか？

15 communication  email 

少なくともソルト/ハッシュせずにパスワードを保存するのはひどい考えであることは誰にとっても明らかです（私は願っています）。 メールはどうですか？サブスクリプションの電子メールアドレスを保持しているとしましょう。適切に暗号化すると、ユーザーに電子メールを送信することができなくなる可能性があります。一方、暗号化せずにデータベースが盗まれると、すべてのユーザーが潜在的なスパムの危険にさらされます。 この質問は、法律に固有の問題（それらは与えられるかもしれませんが、国依存のままです）やデータベース自体の暗号化に関するものではありません。

14 database  security  email 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 5年前に閉鎖されました。 現在、ほとんどの一般的なアプリケーションでは、メールによるアカウントのアクティベーションが必要です。開発したアプリを使ったことがないので、重要なセキュリティ機能が欠けていますか？ メールのアクティベーションとは、サイトに登録すると、アカウントがアクティベートされる前にクリックする必要があるリンクを含むメールを送信することを意味します。

13 security  email 

JavaMailは、通常は電子メールプロバイダーのSMTPインターフェイスを介して、電子メールサーバーを使用して電子メールを送信します。電子メールを送信するために電子メールサーバーを使用する必要がありますか？ 電子メールを送信するWebサイトがあり、可能であれば、電子メールサーバーを使用せずに、Webサイトコードから直接電子メールを送信したいと思います。JavaMail FAQには、電子メールサーバーが必要であると書かれています。 JavaMailまたは別のAPIを使用して、電子メールサーバーを使用せずに電子メールを送信する方法はありますか？

11 java  email 

主に企業で使用されるソフトウェアを書いています。 次に、特定のドメインのメールに登録するすべてのユーザーが自動的に会社グループに入れられるように、メールドメインを登録する方法を企業に提供するというアイデアがありました。 私はSlackがこのようなことをして機能することを知っていますが、いくつかの問題があります...たとえば、「live.it」（Microsoftによるlive.comイタリア語版）を登録したばかりです。 ユーザーが特定のドメインでメールを検証した場合、同じdomain_mailを持つすべてのユーザーを同じグループに入れても安全だとは思いません。 たとえば、me @ gmail.comで登録した場合、ユーザーが「gmail.com」に独自のドメインを登録できるようにしたくありません。 「ドメインのルートにhtmlファイルを置く」、「TXTレコードを設定する」などの方法の使用を避けたいので、どうすればよいか迷っていました。

10 email  domain-name-system 

私たちは、クライアント/ユーザーがサイトを使用する前にメールアドレスを確認することを要求する、かなり標準的な登録プロセスを備えたWebアプリケーションを開発しています。このサイトでは、確認後にメールアドレスを変更することもできます（メールフィールドを再入力することもできます）。 ユーザーにメールを再確認してもらうことの長所と短所は何ですか。これも必要ですか？ 編集： 以下の回答とコメントの要約： 「過剰検証」は人々を困らせるので、重要でない限りそれを使用しないでください タイプミスを防ぐために「メールの再入力」フィールドを検討してください。ただし、ユーザーはコピー/貼り付けを行って、それを無効にすることができます。 既知の良好なデータを潜在的に良好なデータで上書きすることに注意してください 通知のために古いメールを送信します。検証のために新しい ユーザーがまだ古いメールにアクセスできるとは限りません アカウントが侵害された場合の誤ったメールの影響を特定する

8 security  email  authentication 

ベイジアンスパムフィルタリングについて読んでいて、理論は理解していると思いますが、メッセージに特定の単語が含まれている場合、メッセージがスパムである可能性を計算するためにこのアプローチが必要な理由がわかりません。 ユーザーによって「スパム」または「ハム」のいずれかに分類された一連のメッセージがあり、分類したい新しいメッセージ（選択した単語を含む）を受け取った場合、確実に行う必要があるのは、数を除算することだけです。単語を含むスパムメッセージの数、単語を含むメッセージの総数...なぜすべての方程式なのか？

8 algorithms  math  email 

多くのウェブサイトと同様に、ログインのユーザー識別子としてメールアドレスを使用しています。 RFC 5321 [ ＃2.3.11 ]には、電子メールアドレスのローカル部分は次のように記載されています。 アドレスのドメイン部分で指定されたホストのみがセマンティクスを解釈して割り当てる必要があります つまり、メールアドレスを処理するアプリケーションでは、GMailがユーザー名を決定するときにドットを無視する方法など、2番目に推測することはできません。また、ローカルパーツが指定されているため、アプリケーションはメールアドレスのローカルパーツを大文字と小文字を区別するものとして扱う必要があります。 しかし、ユーザーは愚かで、最近のケースでは、大文字のメールアドレスでサインアップした（そして確認メールを正常に受信してクリックした）ユーザーが、小文字のメール形式を使用しているため、ログインできないことに気付きました。住所。 受信トレイで大文字と小文字を区別するメールサーバーに遭遇したことはありません。一部がどこかに存在することは間違いありませんが、メールのユーザー名の大文字と小文字を区別することには、それを維持する問題よりも大きなメリットがないのではないかと疑問に思っています。 私は、GMailのドット処理やあらゆる種類のプラスアドレッシングをエミュレートすることはしません。なぜなら、それらはユビキタスであるとは思われず、大文字と小文字を区別するほど自動的に想定されないからです。しかし、私はそれが白黒のシナリオではないことを知っているので、誰かが実際に広範囲の大文字と小文字を区別するメールアドレスがどれくらいあるか知っているかどうか興味があります。

8 email  case-insensitivity