インターネットなことの最近のブログ記事

最近、無料の Web サービスを利用することにハマっているので(笑)、「Wix ロゴメーカー」というサービスを使ってみた。

ただ、実際にはこのサイトは今まで俺がこのブログで紹介してきたような、「無料でWeb上のツールを使わせることで広告収入を得る」系のものではなく、「いずれ自社の有料サービスの客になるであろう潜在的ユーザを囲い込むための餌」的サービスである。

Wixという会社は簡単に言えば Web 制作の請負会社であり、この「Wix ロゴメーカー」も「ああ、もう、自分で作るのってやっぱり面倒臭い!Wix に頼もう!」というものを狙ったものであり、また、結論から言うと「Wix ロゴメーカー」は「Wix ロゴメーカー | 無料でロゴを作成しよう | Wix.com」と title ヘッダに設定されているが「無料ではない」。

無料で作れはするが、それは小さな使い物にならない大きさのサンプル画像だけで、しかも商業利用はできない規定となっている。
つまり、本当に「Wix ロゴメーカー」で作ったロゴを使おうと思うと、使い方によって違うが数千円の使用料を払わないといけないのである。(当然の対価だが)

そういうサービスなので、利用開始時にアカウントの登録を行う必要がある。
実際に Wix に将来 Web ページデザインを依頼する可能性の無い人は、まあ、試しに使ってみるのもやめておいたほうがいいだろう。使いもしないサービスにアカウントを登録するのはセキュリティレベルを下げる行為だ。

ま、俺は使ってみたけど(笑)。Wix の Web ページ制作サービスを利用することは将来に渡ってもないけど、こういうのって、どの程度の実力なのかな?って興味があったので。

作ってみたのは、最近活動を開始した(いや、まだ開始してないけど)「フィッシング紳士の会」のロゴである。

質問に答えながら進んでいくと、最終的にいくつかのデザイン候補が提示され、その中から気にったのを選ぶ。
どれも気に入らなければもう一度最初からやり直し、少し質問への回答を変えてみればいい。最後に選択したロゴに色を変えられるが、色によってけっこう雰囲気が大きく変わって面白い。ちなみに、デザインを確定してしまったあとは色は変えられない。変えたければお金が発生する。

ま、そういうわけで、最終的に作成した「フィッシング紳士の会」のロゴがこんな感じ。

Free_Sample_By_Wix.jpg

魚釣りクラブのロゴなので「Mellow Salmon」という色のセットで作成してみた。

うーん、まあ、このくらいなら高校時代は美術部部長だった俺は自分で作れるけど(笑)、まったくそういう素養のない人には作れないレベルのデザインではあるかな。なので、デザインは苦手だけど、自分の Web サイトが作りたいって人にはいいかも。数千円でこういうロゴが作れるんならね。(ちゃんとデザイナに依頼すれば、こういうロゴで数万円から数十万円する)

ちなみに、「フィッシング紳士の会」は休日もバタバタと仕事をしているのでなかなか釣りの時間が取れないような(つまり俺のような(笑))、中年、熟年の紳士が「近場でパパッと釣りをしてストレス発散する」ことを目的に結成された秘密結社です(笑)

英語では、Dandy Fishermen's Club と表記することにした。

実際のところ、紳士は Gentleman だし、釣り人は Angler だ。間違ってるだろう!!という指摘もあるだろうが、ちゃんと意味があってあえて「Dandy Fisherman」と名乗っているのだ。そのあたりの話は、今後(たぶん)掲載されるであろう活動報告の中で(笑)
ちょっとお客さん向けのデモ用に音声データを用意しないといけなくなったんだけど、PCにはマイクついてないし(いや、リモート会議用にカメラに無指向のマイクついてるけど、録音に使うのはなんかね・・・)、とりあえず iPhone のボイスメモ使って録音して、それを Dropbox 経由で PC に持ち込んだ。

Dropbox も色々言う人いるけど、こうやってちょっとしたファイル共有に使うのはかなり便利。やはりユーザー数が多いということでインタフェースも色々考えられてる。「たまーに、ちょっと使う」場合は同様のサービスの中で一番使いやすいと思う。

あ、したいのは Dropbox の話ではない。本題に戻る。

で、iPhone の録音データを持ってきたのだが、m4a 拡張子の AAC(Advanced Audio Coding ファイル)やん!ま、Apple だからそうか(笑)。iTunes で採用されている圧縮方式だからね。

こいつを 色々なプログラムで使えるように mp3(MPEG-1 Audio Layer-3 ファイル)に変換したい。mp3 の方が、断然使えるプログラムが多いからな。

ただ、この間から新たに開発で使っている DELL のノートPCに音声ファイルの変換ソフトは入れてない・・・ということで、無料のオンラインサービスを利用してみた。


ええやん。これ。
画面上にファイルをドラッグ&ドロップして、変換したい方式(mp3)選んで変換するだけやん。
あっというまに変換が終了し、Web画面からダウンロードしておしまい。

音声データを変換することも頻繁にあるわけじゃないので、もうこれでいいや。(以前使っていた開発用の PC や MacBook には音声ファイル変換プログラムがインストールされているけど(笑))

しかしすごいねえ。同じサイトで、動画ファイルの編集とかもできるんよ。
もちろん、回転したりトリミングしたり切ったりつなげたりくらいだけど、それがタダで、ソフトも入れずにできるってやっぱ凄いよ(笑)

以前、PDF編集オンラインサービスの話でも書いたけど、こういうサイトに広告収入以外の、例えば一回利用すると10円とか、そういう商売のできる少額決済サービスができてほしいよね。
(手数料の糞高いサービスなら既にありそうだけど(^^;;;)
PDF24 Tools 無料で使いやすいオンラインPDFツール」というサイトはいいね。

3ページほどのPDF資料を職場から税理士さんに送る必要が出てきたんだけど、よく見たら間に1ページ、不要な資料が混ざっている。

自宅のPCであれば CubePDF Utility が入っているのですぐにその余計なページだけ削除できるんだけど・・・

プログラミング作業に必要なら、自分が日ごろ使っているエディタやファイルコンバータなどのツール類は好きにインストールしていいと言われている良い職場なのだが(そういうのに、無意味なほどに厳しい会社あるからね)、さすがに俺の会社の用事のためにソフトを入れるのはね。

というわけで、初めてWebサービスの「PDF24 Tools」を使ってみたのだが、割合使えるな、これ。

間のページを抜く(削除する)という機能はないので、まずは「PDF分割」でページをバラバラに。4つのPDFファイルに分かれたものをダウンロード。
今度はその中で必要な3ページを「PDF結合」の画面にアップロード。ここで、ページ順の調整もできるのでする。まとめてアップすると、最初はページ順がバラバラになっているからな。そういう意味では、あまりにページ数の多いものの統合は大変かも。

で、結合されたファイルをダウンロードしたら終わり。簡単。

しかし、こういう Web サイトをタダで使えるとは、ユーザの立場としてはいい時代になったものだ。

でも、こういうサイトの収入が広告に頼るしかないというのがなあ・・・。Web システムの開発の現場にいるものとしては、早く10円単位で簡単に課金できる決済の仕組みが開発されるといいんだけど・・・と思わずにいられない。
一昨日は、(今のところ俺の小遣いで運営されている(笑))岩国市内の某スポーツ競技団体の Web サイトのサーバ証明書の更新を行った。
SecureCore,Inc.の CoreSSL という格安サーバ証明書である。年間 1,650円だ。

わが社では GMOグローバルサインやデジサートなど大手の企業向けサーバ証明書を販売している。一年間有効の証明書が何万円もする。「なのに自分のところは 1,650円の証明書を使っているのか!!?」と怒る人がいそうだが、的外れである。

この CoreSSL の認証方式は「ドメイン認証」である。
ドメインの登録者のメールアドレスでのやり取りだけで発行される証明書である。だから安い。発行に手間はかからないし。

一応、「そのドメインの管理者が申請していること」だけは保証されている。しかし、その「管理者」が例えばその会社の人間なのか?どこの誰兵衛なのかは保証されない。

どういうことかというと、例えば microsoft_soo_eigyosyo.jp という、「マイクロソフト祖生営業所」というマイクロソフト社の関連会社のものみたいなドメインがあったとして、「ドメイン認証」のサーバ証明だと、このドメインを申請したのがなんという会社なのかまでは保証されない。
なので、https://microsoft_soo_eigyosyo.jp/ というオンラインショッピングサイトがあっても信用できない。

まあ、つまり、「Chrome なんかに怪しいサイトって表示されないためだけに使用する証明書」みたいな感じやね。だから 1,650円なわけ。そして、うちの場合は不特定多数に Web サイトで何かを売りつけたりするわけではないので、この証明書で十分なのだ。

次が、「企業実在認証」。これは、サーバ証明書を発行する会社が、電話帳などを使って調べた電話番号に電話をして、申請してきた人が本当にその会社にいる人なのか?その人が本当に申請したのか?などを調べてからサーバ証明書を発行する。
まあ、電話を乗っ取るのはなかなか厳しいので、通常はこれで 100%近い信頼はおけるだろう。うちで販売しているのはこのタイプ。だから年間数万円という値段になる。

さらに、申請してきた会社の住所を登記簿などで調べて書類を郵送し、ちゃんと届けば認証する「EV 認証」。これは事務所がちゃんとあるのかまで調べるので、「この会社はちゃんと事務所もある。そこで人も働いている。詐欺をするためだけにつくられたペーパー会社ではないようだ」ということを証明でき、「じゃあ、安心してこの会社のサイトでショッピングできるね」となる。値段は企業実在認証の倍くらいするけど。

で、話を戻すが、この俺の小遣いで運営されているサイトだが、将来的には大会のエントリーをこのサイトからしてもらおうと考えている。
じゃ、証明書を年間何万円もするやつにしないと!!・・・って?いや、それは大丈夫。上に書いたように、まったくその会社のことを知らない人にも信用してもらうためには企業実在認証が必要だけど、うちのサイトはまず「今度大会やりますから、Webサイトから申請してね」という具合に主催者から連絡をする。
つまり、Web サイトの閲覧者には主催者がわかっており、「証明書で証明」しなくても実存証明にはなっているのだ。

というわけで、あなたのサイトにあった証明書を!(←なんの宣伝?(^^;)
qmail は本家 sendmail よりもセキュアな MTA として人気があったんだけど、更新がストップしてもう22年も経つため、仕様的には相当古くなってきた。

とは言っても、未だに見つかった脆弱性が「DoS攻撃」に関するものだけで、しかもこれもリソース制限を行うだけで回避可能で、なんでそれだけ堅牢なのかというと、本家 sendmai が高機能・多機能化してバグとセキュリティホールの塊と化していったのを反面教師にして、とことん機能を絞ってシンプルにしたから。

一部、UNIX ルールに則らない作りになってたり、ソースコードがけっこう癖があったりする MTA なので、qmail が嫌いな人はとことん嫌うんだけど(^^;、俺は、まあ、良い MTA だと思ってる。
qmail 用に考えられた Maildir 形式のメール保存方法は今や他の MTA にも実装されているしね。

ただ、冒頭に書いたように作られたのが随分前なので、qmail を使って新しい仕様のサービスを構築するのはなかなか難しい。有志たちが IMAP とか SMTP-AUTH とか、qmail 開発終了後に一般的になった機能を実装するための patch を作ってくれているので、それを利用することになるのだが、公式の開発チームがあるわけではないので「qmail で○○したくなった誰かが patch を作ってくれるのを待つ」しかできない。

で、特に最近 qmail を使っていて悩みの種なのが Gmail がらみである。

3月に構築した qmail サーバが今年の 4月頃から全然 Gmail にメールが送れなくなった。
インストールした時点では送れたはずなんだけどなあ・・・。250 ok は返ってくるのに、受信トレイには表示されない。ゴミ箱、迷惑メールにも入ってない。
このサーバは送信専用だったので Postfix に入れ替えて事なきを得たけど。

問題は、別の qmail+vpopmail で送受信に使っているサーバである。(マルチドメインのメールサーバなので、qmail だけ Postfix に入れ替えるわけにいかず、vpopmail で構築しているマルチドメイン環境も移行しなくてはいけないので、すぐにどうこうできるものではない)

こいつは、まったく Gmail に送れないわけではない。このサーバのユーザが exsample@gmail.com などに直接メールを送ればちゃんと相手に届く。
しかし、一点、変な動きをするパターンがあるのだ。

例えば、vpopmail で構築しているドメイン(仮に exsample.com)のユーザが転送ユーザだとする。
こんなふうに、xxxx@exsample.com ユーザの .qmail-xxxx ファイルの中で、

&aaa@exsample.co.jp
&bbb@gmail.com
&ccc@yahoo.co.jp

と 3人に転送する設定がされている。(Maildir には保存しない)

この時、aaa@exsample.co.jp の人が xxxx@exsample.com にメールを送った場合、そのメールは自分のところにも届く。&aaa@exsample.co.jp と転送設定がされているからだ。もちろん、bbb@gmail.com、ccc@yahoo.co.jp にも届く。
これは、ccc@yahoo.co.jp の人が xxxx@exsample.com にメールを送った場合も同じである。

ところが、bbb@gmail.com から xxxx@exsample.com にメールを送った場合は違う。aaa@exsample.co.jp と ccc@yahoo.co.jp には転送されたメールが届くが、bbb@gmail.com には来ないのである。

Gmail のサーバからは、

qmail: 1591000038.308115 delivery 3: success: 74.125.204.27_accepted_message./Remote_host_said:_250_2.0.0_OK__1591801038_p2si106412pjr.4_-_gsmtp/

と、250 ok が返ってきているのに!!

つまり Gmail に聞かないと「なぜ、自分に転送されるアドレスにメールした時だけ、転送されてきたメールが受信トレイに表示されないのか?」はわからないのだ。Yahoo! メールは問題ないので、Google がより厳しいチェックを行い「正式に受信しました」と相手には返しながら内部で破棄してるんだろうけど、何の情報も示さずに・・・というのはあんまりだ。

qmail の仕様が古いから、ヘッダ部に何らかの問題があるとかそういうことなんだろうけど、だったら MTA がエラーを返すか、250 ok で受け入れるのなら迷惑フォルダに振り分けるとか「調査が出来る情報」は与えて欲しいものである。

ちなみに、このサーバから(転送ではなく)普通に bbb@gmail.com に送ったメールは受信トレイに表示される。

というわけで、「qmail から Gmail にメールが送れない」「送れるけどちょくちょく問題が発生する」などの原因や解決策をご存知の識者の方は、ぜひご教授ください。(ググってみたけど、有効な問題にはたどり着けず・・・)
よくある、この手のメール。
 ↓
I know one of your password is: XXXXXXX

「私はお前のパスワードを知ってるから、それを公開されたくなかったら私にビットコインで 700$ 送りなさい」とか言うてくるやつね。

You can buy Bitcoin (BTC) here: http://www.paxful.com/ , http://www.binance.com/ , http://www.coinbase.com/buy-bitcoin or Google another exchanger.
My Bitcoin (BTC) wallet is: 13HCjYFfrZXXXXXXXXHBwFRuTJbX5hyJvP

ってね(笑)

載ってるパスワードが、過去に自分が使ったことのあるパスワードだったりするんでドキっとするんだけど、これって、情報漏えい済みのデータ(メールアドレス&パスワード)がネット上に流れてて、そこから拾ってメール本文を作成しているもの。
つまり、「すでに世の中に公開されちゃってるパスワード」である。なので、「公開されているパスワードを公開するぞ」って脅してきているわけで意味がないのよね(笑)

もちろん、漏洩しているパスワードをまだ使っていればすぐに変更しないといかんよ(こんなメールが来た時点で対応してたら手遅れだと思うけど(^^;)

というわけで、この手のメールは気にせず放置しとけばいいんで、もう振り分けルール書いて即ゴミ箱行きにしとけばいい(俺もそうしてる)んだけど、昨日、何年かぶりに Thunderbird 立ち上げたら(日頃は Gmail の Web 画面を使っている)、ゴミ箱の容量が足りないのでメールの移動が出来ないとかワーニング出て、久しぶりにこの手のメールが眼に入って・・・

「うわっ、昔俺が使ってたパスワードが書いてあるじゃん!!」と不覚にも一瞬驚いてしまったので、自責の意味もこめてここに書いておく(笑)

<追記>
ちなみに、有名所の漏洩に関しては、Firefox Monitor というサイトで、自分のメールアドレスに紐付いた情報が世の中に漏洩してしまっているかどうかが確認できる。俺のアドレスに紐付いたパスワードも 2つのサイトの漏洩事件で漏れてたけど、どっちも漏れた時に即対応済みなので問題無し。
先月からずっと原因も解決策もわからず悶々としてるんだけど・・・

qmail で構築しているメールサーバがあるのね。(qmail を使っていることの是非についての意見は聞きません。qmail 使用でパッケージ化されているシステムなのと、qmail がどうの、オリジナルの sendmail がどうの、postfix がどうこうという話は宗教感の違いでしかないので(笑))

で、そのメールサーバで空メールを受け取ってあれこれ処理をして結果をメールで返してるんだけど・・・

Gmail からメールした時だけ、

The recipient server did not accept our requests to connect. Learn more at https://support.google.com/mail/answer/**20 [mail.exsample.jp. xxx.xxx.xxx.xxx: unable to read banner]

というエラーになる。

IIJ Gio、NTT PC WebARENA、GMO クラウドなどのサーバ上から送信したメールはちゃんと処理される。

また、俺の実メールアドレスに転送する test という alias を作ってテストをしてみても、やっぱり同じエラーになるのでプログラムが悪いわけではない。

そうそう、Yahoo! の Web メールもちゃんと届く。本当にうまくいかないのは Gmail だけなのである。
ちなみに、gmail.com のアカウントから送っても、他のアカウントを From にセットして送っても一緒である。

しょうがないので、さっき postfix でメールサーバを再構築してみた。
そしたら、ちゃんと Gmail から空メールを送ってプログラムを実行することも、test というメールに送って俺の実メールに転送することも成功した。

どうも、Gmail+qmail サーバのみの問題のようだ。

もちろん、qmail サーバの設定がおかしいという可能性もあるが、Yahoo!メールや、他のレンタルサーバ上に構築されたメールサーバからの送信では問題が発生しない。そう考えると qmail の設定の問題というわけではないだろう。

netstat でみると、

tcp        1      0 adm01:smtp              mail-io1-f51.goog:30637 CLOSE_WAIT

という具合に SMTP のポートに接続には来ているようだ。qmail が反応しないんだなあ。

とりあえず、上記のように postfix でシステム再構築をしてうまくいっているのだが、はっきり qmail で駄目だった原因がわからないとどうにもすっきりしない。
原因がわかるという識者の方がいらっしゃれば、ぜひご教授ください。
以前から(お客さんに相談されたので、実際に自分のブログで試してみたんだけど)Amazon アソシエイト・プログラムには参加していた。ただし、右側に Amazon Widget を貼り付けていただけで、ブログ本文に商品リンクを貼ったりはしていなかった。ブログで金儲けとか考えてなかったので。
なんか、そういうことを考えだすと、記事の内容も絶対影響受けるしね。俺は自由に書きたいことを書きたいんじゃ!

ところが昨年のはじめだったかに、再びお客さんから質問が来て、色々調べたときに、

    • 支払い方法を「銀行振込」(ディフォルト)から「ギフト券」に変更
    • 記事に関係ある商品のリンクをたまに貼ってみる

という対応をしてみた。

「銀行振込」は紹介料が 5,000円以上たまらないと支払われない。しかし、2005年にアソシエイト・プログラムに参加して、2017年までの 12年間で俺のアカウントに貯まっている紹介料は 114円である(笑)
どう考えても、5,000円なんて貯まるわけがない。
ギフト券なら 500円以上で支払いが行われる。12年間で 100円そこそこなので、500円も相当遠い目標だが、まあ、5,000円より現実味がある。

ちなみに、俺のブログは「どこかで紹介したり相互リンクを貼ったり」といった営業活動はまったく行っていない。身内と知り合い、そして時々過去に書いた UNIX 系の記事が検索に引っかかって訪ねてくる人くらいにしか読まれない(^^;、そんなブログだ。

しかし、記事の後ろに(いつもではなく、思い出したときだけだけど)商品リンクなどを貼っていたら、この一年で少しずつ紹介料が入り始め、この 3月についに 500円を突破。731円のギフト券が発行されたのである!

お客さんに相談されて試しにやってみただけで、ブログで収入とか全然考えていないんだけど、でも、やっぱりギフト券がもらえるというのは嬉しい。いつもらえるんだろうとワクワクしてたんだけど・・・

全然支払いメールが来んやん。
よくわからないんだけど、ギフト券番号みたいなんが書かれたメールが届くんじゃないんかい?

そう思って、さっき Amazon に「なんか、ギフト券のメールを失くしちゃったので、再発行って出来ます?」って問い合わせしたんだけど(むっちゃ欲しがってるやん>俺(^^;;;)、その後、「60日以内に支払う」ってヘルプの一文を見つけた・・・
「2019/03/30 ギフト券による支払い」ってなってるので、実際にメールが来るのは 5月末くらいなのか?

もう少しおとなしく待ってよう。
まさか、「なんだ、こいつ、わけわからん問い合わせしてきやがって」って垢バンされんやろうなぁ(^^;
実は俺、昔理由もわからず Amazon アソシエイツで垢バンされたことあるのよね。怖い、怖い。

ブログには(下ネタとか、他人様をアホ、マヌケと罵倒する記事とか)好き放題を書いているので、嫁さんから「けっこう、皆があんたのブログを読んでるから、もうこれ以上変なことを書いて恥をかかせるな。ブログやめろ」といつも怒られる。
まあ、実際のところ、どこかで宣伝しているわけでもないし、ブログ仲間のようなのがいて相互リンクしているわけでもない。アクセス数なんて大したことは無いだろう。

ただ、意外な人からも「見とるで」と言われることもある。
例えば、東京の方に住んでる親父の同級生の人から電話がかかってきて、俺の声、親父そっくりなんで「あ、僕、息子です」なんて説明すると、「おお、あんたのブログ読んどるで」って言われたことがある(笑)30歳も歳の離れたじいさんに。

そんな具合に「知り合い」から言われるから、嫁さんには「たくさんの人が旦那の糞ブログを見ている」と映るのだろう。

で、なんで俺のブログが発見されてしまうのか・・・だ。
検索して、たまたま俺のブログがヒットした・・・というケースが多いんじゃないだろうか。
そこで、思いつくキーワードで Google で検索してみた。(【】内がキーワード)

【祖生】

8ページ目(71番目)として


がヒットした。
故郷「祖生」のことを検索してみたとしても、8ページ目まで見るんかな?まあ、見たんかもしれんな。

しかし、俺のブログよりも早く(2ページ目(12番目)、食べログの「ソオタス」の記事が出てくるな(笑)

【祖生 ソフトボール】

1ページ目(1番目)に


が出てくる。あとにも俺の記事がずらずら続く。
でも、いきなり「祖生 ソフトボール」なんてキーワードで検索する人間なんて、ソフトボール界の裏ボス、T口君くらいしかおらんやろう(笑)

【祖生東小学校】

2ページ目(19番目)に

祖生東小学校閉校式 - 電気ウナギ的

がヒット。
これはあるかもしれんな。5年前に廃校になった時には、検索されること多かったかもしれんし。あ、廃校の時にはまだこの記事はなかったか(^^;

【高森高校】

5ページ目(46番目)に


が引っかかるけど、これも、わざわざ 5ページまで見る人は少ないと思われ(^^;

【周東中学校】

5ページ目(44番目)に


が・・・
いやあ、これも 5ページ目か・・・。無いな(笑)

【伊陸ひむろ】

1ページ目(1番目)に


が出てくる!!堂々の第一位!
息子が入ってた野球チームだけど、伊陸の人に「見てるよ」って言われるのは、これ起源のような気がするな(笑)

ちなみに、これは iPhone用のページなんだけど、「伊陸ひむろ 少年野球」で検索したら、PC版が一番に表示される。

【そお小学校】

1ページ目(8番目)に


が。(これも iPhone用だな(笑))

これはあるかもな。自分の子どもが通う小学校の名前で検索したら、怪しいページがヒットして、見てみたらブログ所有者が「shinoda」なので、「え?これって shinoda さん?」ってなるという。

うーん。
どれも中途半端な検索順位なんでいまいちわかりかねるが、「そお小学校」が一番あり得るかな。
「いや、おれはXXXで検索したらヒットした」という方は、ぜひその「XXX」が何なのか教えてほしい。
俺が管理を任されているメールサーバに関する SPFレコードが適切に設定されていないということで、Gmail で正常にメールが受信できないという事案発生。すぐに DNS の zone ファイルに SPF レコードを追加。

設定チェックサイトで、「SPF Record Lookup」を選び状態チェック。「Pass」となったことを確認。

ところが、Postfix で構築したメールサーバでは、

Received-SPF: Permerror (SPF Permanent Error: include has trivial recursion: include:hoge.exsample.jp) identity=mailfrom; client-ip=XXX.XXX.XXX.243; helo=hoge.exsample.jp; envelope-from=root@hoge.exsample.jp; receiver=hoge@exsample.com

というようなエラーが出るという。

include の再帰呼び出しが問題ってか???

ああ、なるほど。SPF レコードが、

hoge 3600 TXT "v=spf1 ip4:XXX.XXX.9.6 ip4:XXX.XXX.XXX.243 include:hoge.exsamople.jp -all"

ってなってる。

hoge.exsamople.jp の SPF レコード内で自分自身のドメイン(hoge.exsamople.jp)の SPF レコードを(結果として再帰的に)include しようとしてるのが問題なのかな?

Google のメールサーバは許してくれるけど、Postfix は許してくれんということか。

hoge 3600 TXT "v=spf1 ip4:XXX.XXX.9.6 ip4:XXX.XXX.XXX.243 -all"

のように、include 記述を消してやった。
他のドメインの記述をそのまま真似て使ってたんで、再帰呼出しになってるとか全然気にしてなかったわ(^^;(そもそも Google じゃOKだったので)

このアーカイブについて

このページには、過去に書かれたブログ記事のうちインターネットなことカテゴリに属しているものが含まれています。

前のカテゴリはただ、日常です。

次のカテゴリはゲームです。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。


月別 アーカイブ

電気ウナギ的○○ mobile ver.

携帯版「電気ウナギ的○○」はこちら