この問題の下位構造は Java よりも広い可能性があり、すべての Jelastic 展開に適用される可能性があります。しかし、ここでは Java について説明します。
OPがリンクされている投稿でよく説明されているように、最初のステップはアプリケーションの依存関係を確認することです。OPは、アプリケーションがテスト/開発に取り組んでいたと説明していますが、Java展開エラーの一般的な原因としてこれについても言及しています。
次に、Jelastic はメール転送アプリケーション (Java Mail が配信に使用) を提供しません。そのため、Jelastic ホストで提供される MTA は、基盤となるオペレーティング システムによって提供されます。もちろん、ほとんどのサーバーにはそのような規定がありますが、ホストによって異なる場合があります。
メール輸送は別のサービスであるため、これは私には理にかなっています。Jelastic がメール トランスポートを提供する場合、別の/監視可能/課金可能なプラグインとしての制御が期待されます。しかし、そのようなプラグインがないということは、メールを送信するアプリがホストの基盤となるプロビジョニングに依存していることを意味します (...しかし、少し下を見てください)。このトランスポートの欠如は論理的かもしれませんが、共有サーバーに対する一般的な期待に反しています。
私の次の発言は、Layershift の Jelastic の実装に適用されますが、他の Jelastic ホストの提供はほとんど同じであると思います。
- 証跡アカウントと IPv4 をお持ちですか?
有料アカウントと静的 IP アドレスを持っていない限り、Layershift の MTA は有効になりません。それはそれと同じくらい簡単です。
- Layershift の MTA 構成
は、ポート 25 でのみ機能し、SSL は機能しません。
OPがLayershift、または同様のソフトウェアスタックを持つJelasticホストを使用していた場合、ポート25のみが機能するのはそのためです。この規定の欠如が、明らかに正常に配信されたメールがサーバーに転送されなかった理由です (OP はこれを知ることができませんでした)。
ポート 25 の制限のみの規定が見つかりました。一部の SMTP サーバーは、スパム対策として他のポートを開きます。ただし、Layershift のサポートを受けて自分でこれを実行したところ、その提供は限定的ではなく、単純に大ざっぱなようです。これから...
Layershift は、基礎となるトランスポートに依存しないことを明示しています (テストのみ)。彼らは、電子メールの送信元がメール用ではないアップストリームのパブリック IP からのものであり、たとえば、スパム対策チェックを満たさないことを指摘しています。彼らのスタンスは、トランザクション電子メールの送信は、次のような新しい外部サービスの 1 つによってより適切に処理されるというものです。
メールジェット、マンドリル、センドグリッド
（申し訳ありませんが、これらのリンクを投稿することはできません）
これらのサービスの一部は、使用量が少ない場合は料金が発生しないことに注意してください。
繰り返しますが、これはサービス提供として非常に理にかなっていますが、一般的な期待に反しています。
最後に、非常に専門的なニーズがある場合は、Jelastic が独自の電子メール サーバーを実行するコードを有効にしています。これはOPのニーズに反しているように思えます-手間とメンテナンスが多すぎますが、それが目的である場合、
Jelastic - 独自のメール サーバーを実行する
それが役立つことを願っています。