エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
届いたメールの料理の仕方 (3) 〜qmail編〜 : DSAS開発者の部屋
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
届いたメールの料理の仕方 (3) 〜qmail編〜 : DSAS開発者の部屋
前回の後半で、dot-qmailで実行したコマンドの終了コードによって、次の配送を行うかどうかを制御できる... 前回の後半で、dot-qmailで実行したコマンドの終了コードによって、次の配送を行うかどうかを制御できると書きました。 今回は、この仕組みを活用した例を2つ紹介したいと思います。 携帯電話からのメールをあるプログラム(process-ktai-mailとします)で処理したいとします。 携帯メールのenvelope fromのドメインパートはキャリア毎に決まっているので、ドメインパートを見れば携帯メールかどうかを判断することができます。 しかし、この判断ロジックを同じようなプログラムのそれぞれに実装するのは面倒ですしDRY (Don't Repeat Yourself)の原則からも外れるので、こんな風にしてみましょう。 mobile-valveというプログラムが、携帯メールかどうかの判断を行う。 mobile-valveは、携帯メールの場合はexit 0(後続の配送命令を実行する)し、そう