ドラフトが公開されるとんちき仕様を修正

.woodpecker/.woodpecker.yml

@@ -8,7 +8,7 @@ steps:
   build:
     image: klakegg/hugo:ext-alpine
     commands:
-      - hugo -D
+      - hugo
   deploy:
     image: drillster/drone-rsync
     secrets: [USER, HOTS, SSH, PORT]

content/post/test.md

@@ -25,7 +25,7 @@ REAL_IP_FROM=あんたのグローバルIP
 セットアップウィザードの甲斐あって他に修正すべき箇所はあまりない。**今は。**もし皆さんがCloudflareなどのCDNを間に挟んで**いなければ**ここからの話はかなりスムーズになる。だが、今どきそんな人いるか？　それこそ10年前とは違う。今やなんでもCDNの時代だ。なんでもCDNの上に乗っているものだからオリジンサーバが文字通り雲隠れしたように見える。ところがメールサーバはそれが通用しない。だから面倒くさいんだ。
 
 ## 特殊なDNSの設定
-Cloudflareの設定を例にとる。メールサーバに用いるドメインを選択して**DNS →  レコード**からレコードを設定する。通常であればサーバのIPアドレスをAレコードでドメインと紐づけておしまいだが、メールサーバの場合は「プロキシ」を有効にしては**ならない。** 適用後の表示が「DNSのみ」になるように設定する。
+Cloudflareの設定を例にとる。メールサーバに用いるドメインを選択して**DNS →  レコード**からレコードを設定する。通常であればサーバのIPアドレスをAレコードでドメインと紐づけて、MXレコードにドメインを登録しておしまいだが、メールサーバの場合は「プロキシ」を有効にしては**ならない。** 適用後の表示が「DNSのみ」になるように設定する。
 
 つまり、メールサーバに用いるドメインはCloudflareの恩恵を受けられない。それがなにを意味するのか？　彼らのSSL証明書を使えないのだ。僕がこのブログで散々おすすめしているCloudflareのオリジンサーバ証明書はもちろん、エッジ証明書すらもらえない。そう、同じドメイン下なら使える証明書がメールサーバに振ったサブドメインに限っては使えないので、別の証明書を新たに発行しなければならないのである。
 
@@ -43,4 +43,4 @@ Cloudflareの設定を例にとる。メールサーバに用いるドメイン
 
 この時、`letsencrypt`の設定で自動取得させるドメインの対象は`mx.hogefuga.com`の方だ。`mail.hogefuga.com`はただのWebフロントエンドに過ぎないので堂々とCloudflareのプロキシを有効にできる。こうすると`mx.hogefuga.com`はメールクライアントで設定する際にしか用いられないのでWebの方の心配をする必要がなくなり、`mail.hogefuga.com`はCloudflareの恩恵がさんさんと降り注いで勝手にSSL化される寸法となる。
 
-簡単そうに言ったけどな、この解決策を探し当てるまでに2日もかかったよ僕は。もしかしてこれって割と当たり前のメソッドだったりする？
+簡単そうに言ったがけどな、この解決策を探し当てるまでに2日もかかったよ僕は。もしかしてこれって割と当たり前のメソッドだったりする？