受信メール本文、添付ファイルのFromで始まる行

[松田]

長年mewのお世話になっており、現在はFreeBSD 12.2-release 上で Mew 6.8 / emacs 27.1
を使っております。

最近になって少し困ったことが起きております。
受信したメール本文やテキスト形式の添付ファイルに
From
で始まる行があると
>From
に変換されるという現象です。(行頭に '>' が追加されます。)


再現するためには、自分宛てに

From abc

と本文に書いたメールを送ってみてください。
mew で受信すると

>From abc

と表示されます。（他のメーラーではこの変換は起きないことは確認しております)

どなたか解決のヒントを頂けますと幸いです。よろしくお願い致します。

[池野 直樹]

池野です。

FreeBSD 12.1-RELEASE-p10 + Mew version 6.8 on Emacs 27.1 ですが
ローカルで送信するのと、gmailから送るのとで試してみましたが、
ご連絡いただいたような現象は発生しませんでした。

ご報告まで
-----------
IKENO Naoki
Mail: n...@kyo-to.net
-----------

> --
> このメールは Google グループのグループ「Mew ユーザ」の登録者に送られています。
> このグループから退会し、グループからのメールの配信を停止するには mew-ja+un...@googlegroups.com にメールを送信してください。
> このディスカッションをウェブ上で閲覧するには、https://groups.google.com/d/msgid/mew-ja/e4fa206f-0c2b-4c4f-9d43-b4952fe591e5n%40googlegroups.com にアクセスしてください。

[村田 隆]

> 最近になって少し困ったことが起きております。
> 受信したメール本文やテキスト形式の添付ファイルに
> From
> で始まる行があると
>>From
> に変換されるという現象です。(行頭に '>' が追加されます。)

mailbox のように、１ユーザ１ファイルで複数メールを格納して管理する形式では、
メールの区切りに行頭「From 」(From+空白)を使うことがあります(Solaris以外)。
そのため、本文に「From 」があると誤動作してしまうので、mailbox にあるとき
には「>From 」に変換しておき、POP等でメール単位の取得をしたとき、「>From 」
を「From 」に戻す、という変換をすることがあります。

普通はサーバ側で処理してしまうので、ユーザの目には見えないと思いますが、
どこかで変換が抜けてしまうのでしょうか。

> と表示されます。（他のメーラーではこの変換は起きないことは確認しております)

他のメーラーでの挙動は分かりませんが、経路が違ったり、メーラー側で変換して
しまうのかも知れません。

[松田]

池野様、村田様、情報ありがとうございます。

受信メールは、メールサーバーにfetchmailで定期的に取りに行くようにして運用しております。

fetchmail が ~/Mail/inbox に取り込んだメールを見ると、既に行頭の>が付加された状態でした。

村田様のおっしゃるようにサーバーもしくは取り込みの問題のようで、mew は無関係でした。ご指摘ありがとうございました。

お騒がせしてもうしわけございません。

が、問題の解決はまだこれからです。

もし何かお気づきのことがございましたら教えて頂けますと幸いです。

2020年11月25日水曜日 14:04:09 UTC+9 村田 隆:

[松田]

fetchmailの取り込み先は /var/mail/ユーザー名 のmbox形式の単一ファイルで ~/Mail/inbox ではありませんでした。

失礼致しました。いずれにしても mew は無関係でした。

2020年11月25日水曜日 14:20:36 UTC+9 松田:

[Takahiro Kambe]

こんばんは。

既に回答は出ていますが、これが話題に上がるとは思いませんでした。(しみじみ)

In message <20201125.140335....@qb3.so-net.ne.jp>
on Wed, 25 Nov 2020 14:03:35 +0900 (JST),

村田 隆 <tmu...@qb3.so-net.ne.jp> wrote:
>> 最近になって少し困ったことが起きております。
>> 受信したメール本文やテキスト形式の添付ファイルに
>> From
>> で始まる行があると
>>>From
>> に変換されるという現象です。(行頭に '>' が追加されます。)
>
> mailbox のように、１ユーザ１ファイルで複数メールを格納して管理する形式では、
> メールの区切りに行頭「From 」(From+空白)を使うことがあります(Solaris以外)。

いにしえでもないかもしれませんが、UNIX mailbox形式では確か、

From エンベロープの送信者のメールアドレス ctime(3)形式の日時

の行を個々のメッセージの開始行として使用しています。今時のLinuxにある
かどうかわかりませんが、from(1)なんていうコマンドは、これを使って誰か
らメールが届いたかを表示するコマンドでした。

ほんで、届いたメッセージのボディに"From "を含んだ行があると上記の行と
区別が付かなくなるたため、">From "と書き換える様にしていました。本文で
あろうが添付ファイルであろうが書き換えるのは、MIMEなんて知らないメール
のボディはテキストと信じている時代の仕組みなので結果的にそうなります。

(余談ですが、MIMEの規格的には「本文」と「添付ファイル」といった区別は
なく、単なるマルチパートのメッセージのtextとそれ以外のパートの違いでし
かありません。)

この書き換えは、mailbox形式に格納する処理を行うローカルの配送エージェン
ト、いにしえにはUCB MailやMailxではない/bin/mailの仕事です。

Solarisでは、この様な変換を行う代わりに、"Content-Length"というヘッダー
のフィ－ルドを使用して、ここにメッセージのボディのバイト数を格納するこ
とで次の"From "行の位置を特定するようにしていたと記憶しています。

> そのため、本文に「From 」があると誤動作してしまうので、mailbox にあるとき
> には「>From 」に変換しておき、POP等でメール単位の取得をしたとき、「>From 」
> を「From 」に戻す、という変換をすることがあります。

戻す処理をするPOP3等のサーバーの実装を見たことはありませんが、技術的に
は可能でしょうねぇ。

今時は、Maildirや他の形式でメッセージを保持するため、私的には見掛ける
ことは殆どなくなりました。

--
神戸 隆博 (かんべ たかひろ) at 伊勢近辺

[村田 隆]

古(いにしえ)のメールサーバー管理者です。20年ぐらい前になります。

> 既に回答は出ていますが、これが話題に上がるとは思いませんでした。(しみじみ)

そうですね。調べようにもうまくぐぐれず、記憶を辿るしか無さそうで難儀します。

> この書き換えは、mailbox形式に格納する処理を行うローカルの配送エージェン
> ト、いにしえにはUCB MailやMailxではない/bin/mailの仕事です。

sendmail でも、ローカルの格納は /bin/mail か、格納専用の mail.local を
使っていましたね。

> Solarisでは、この様な変換を行う代わりに、"Content-Length"というヘッダー
> のフィ－ルドを使用して、ここにメッセージのボディのバイト数を格納するこ
> とで次の"From "行の位置を特定するようにしていたと記憶しています。

その通りです。説明をありがとうございます。

>> そのため、本文に「From 」があると誤動作してしまうので、mailbox にあるとき
>> には「>From 」に変換しておき、POP等でメール単位の取得をしたとき、「>From 」
>> を「From 」に戻す、という変換をすることがあります。
> 戻す処理をするPOP3等のサーバーの実装を見たことはありませんが、技術的に
> は可能でしょうねぇ。

POP3等ではサーバーでの格納方式を隠蔽するため、mailbox形式なら >From の
逆変換をPOPで実装しなくちゃいけない、と考えたんですが、どうでしょうか？
現役の頃は qpopper とか使っていたと思いますが、今は Dovecot ？
Solaris を使っていたので、気にしていませんでした。

ローカルで取得するなら、Mew でも逆変換する必要がありそうですが、incm とか
軽くソース見ても、そんな記述が見当たらないような。

> 今時は、Maildirや他の形式でメッセージを保持するため、私的には見掛ける
> ことは殆どなくなりました。

omatsuda000 さんの以下の記述を見ると、mailbox形式ですね。/var/mail で
「>From 」になるのは正しい動作のようです。それを Mew が取得するときに、
逆変換していない問題でしょうか。

>> 受信メールは、メールサーバーにfetchmailで定期的に取りに行くようにして運用しております。
>> fetchmail が ~/Mail/inbox に取り込んだメールを見ると、既に行頭の>が付加された状態でした。
>

> fetchmailの取り込み先は /var/mail/ユーザー名 のmbox形式の単一ファイルで ~/Mail/inbox ではありませんでした。
> 失礼致しました。いずれにしても mew は無関係でした。

消極的な解決としては、fetchmail で MailDir形式とする(procmail を使う？)、
というのはあります。大仰ですが。
--
村田 隆 / tmu...@qb3.so-net.ne.jp <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

[Takahiro Kambe]

おはようございます。

In message <20201126.012210....@qb3.so-net.ne.jp>
on Thu, 26 Nov 2020 01:22:10 +0900 (JST),

村田 隆 <tmu...@qb3.so-net.ne.jp> wrote:
>> この書き換えは、mailbox形式に格納する処理を行うローカルの配送エージェン
>> ト、いにしえにはUCB MailやMailxではない/bin/mailの仕事です。
>
> sendmail でも、ローカルの格納は /bin/mail か、格納専用の mail.local を
> 使っていましたね。

そうです。

>>> そのため、本文に「From 」があると誤動作してしまうので、mailbox にあるとき
>>> には「>From 」に変換しておき、POP等でメール単位の取得をしたとき、「>From 」
>>> を「From 」に戻す、という変換をすることがあります。
>> 戻す処理をするPOP3等のサーバーの実装を見たことはありませんが、技術的に
>> は可能でしょうねぇ。

と、書きましたが、記憶を辿る限りは不可能だったと思います。

> POP3等ではサーバーでの格納方式を隠蔽するため、mailbox形式なら >From の
> 逆変換をPOPで実装しなくちゃいけない、と考えたんですが、どうでしょうか？

なぜなら、

(1) "From ..." という行を ">From ..."と置き換え
(2) ">From ..." という行は ">From ..."とそのまま

とするので、そんな行が最初からある場合は稀だとはいえ、元から">From "だっ
たかどうかを判別する術がなかったと思います。

従って、この変換が嫌なならmailbox形式以外を使用する様にサーバー側で
対処するしかなかったかと。

[村田 隆]

こんにちは。

>> POP3等ではサーバーでの格納方式を隠蔽するため、mailbox形式なら >From の
>> 逆変換をPOPで実装しなくちゃいけない、と考えたんですが、どうでしょうか？
> なぜなら、
>
> (1) "From ..." という行を ">From ..."と置き換え
> (2) ">From ..." という行は ">From ..."とそのまま
>
> とするので、そんな行が最初からある場合は稀だとはいえ、元から">From "だっ
> たかどうかを判別する術がなかったと思います。

格納時に先頭">"の繰り返しを含め、">"を１個追加、という仕様なら、と思っ
たのですが、調べたら、そもそも mail.local の仕様が、デリミタを避けるた
めに空行＋"From "の場合のみ">"を追加、という仕様でした。なら復元は不可
能ですね。失礼しました。Mew も POP3 も無実でした。

だんだん思い出しましたが、">From"となる現象に遭ったとき、仕方がないこ
と、と諦めていたような気がします。

> 従って、この変換が嫌なならmailbox形式以外を使用する様にサーバー側で
> 対処するしかなかったかと。

はい。そう思います。

もしくは今なら、送信時に base64 を選択できれば、とも思いますが、手動の
手段も無さそうで、簡単には無理ですね。

[ARAI Shun-ichi]

あらいです。

In Msg <20201126.111055....@qb3.so-net.ne.jp>;
Subject "Re: [mew-ja] 受信メール本文、添付ファイルのFromで始まる行":

>> 従って、この変換が嫌なならmailbox形式以外を使用する様にサーバー側で
>> 対処するしかなかったかと。
>
> はい。そう思います。
>
> もしくは今なら、送信時に base64 を選択できれば、とも思いますが、手動の
> 手段も無さそうで、簡単には無理ですね。

　松田さんのお話だと、受信時の問題で、他のメーラーでは発生しない、メー
ル取得にはfetchmailを使用している、とのことでしたね。

　以前私がfetchmailを使っていた頃の設定を掘り出してみたら、mdaには
procmailを指定していました。fetchmailconfとかで作ったような気がするの
ですが、松田さんのところでもそうかも知れません。そうすると、procmailが
"From "の変換をしていそうです。
　だとすると、村田さんが前に言われたように、

In Msg <20201126.012210....@qb3.so-net.ne.jp>;
Subject "Re: [mew-ja] 受信メール本文、添付ファイルのFromで始まる行":

> 消極的な解決としては、fetchmail で MailDir形式とする(procmail を使う？)、
> というのはあります。大仰ですが。

というのが良いのではないでしょうか。

　.procmailrcにMAILDIRとして適当なディレクトリを指定し、Mewではincmの
引数の-dでそのディレクトリを指定すれば行けそうな気がします。
　procmailrc(5)によれば、.procmailrcのMAILDIRは、'/'で終わるように書け
ばmaildirとなるようですし、incmの-dは、MewのInfoによるとディレクトリで
あればmaildirと解釈されるようです。

> (setq mew-mbox-command "incm")
> (setq mew-mbox-command-arg "-u -d /path/to/mbox")
> ;; If /path/to/mbox is a file, it means "mbox".
> ;; If /path/to/mbox is a directory, it means "maildir".

[松田]

皆様色々と情報をいただきありがとうございます。

こちらではfetchmail単独で使っていました。

mbox形式に取り込んでいる限り >From となることを回避できないことを理解致しました。

（なぜこれまで気づいていなかったのか不思議ですが)

色々考えて fetchmail を諦め mew から直接 pop サーバーにつなぐことにしました。

以前これをやろうとしたときはうまくいかず fetchmail を使い続けていたのですが、今回意を決して

設定し直したところ、何とかできたようです。

ありがとうございました。

2020年11月26日木曜日 13:44:45 UTC+9 her...@ceres.dti.ne.jp:

[松田]

松田です。

お陰様で快適になりました。最後に少しだけおまけです。

fetchmail を使っていた時は xbiff でメールの到着を知ることができて便利でした。

mew にも biff 機能があり、以下のようにしておけば emacs のステータス行にメール到着を表示できます。

       (setq mew-use-biff t)
       (setq mew-use-biff-bell t)
       (setq mew-biff-interval 1)

が、xbiff の旗の上がるのが楽しいので何とかならないかと色々調べていたところ、 man xbiff で、指定されたファイルの有無でメールの到着を判定する -file オプションがあるのを見つけました。以下を ~/.mew.el に書いておき(~/.emacs.el ではだめです)、

  xbiff -file ~/.xbiff_flag &

を実行すれば、見慣れた xbiff のアイコンでメールの到着を知らせてくれます。

emacs を走らせて mew のウインドウを開いておかないといけませんが。

(defun mew-biff-bark (n)
  (if (= n 0)
      (progn
        (setq mew-biff-string nil)
        (if (file-exists-p "~/.xbiff_flag")
            (shell-command "rm -f ~/.xbiff_flag")))
    (if (and mew-use-biff-bell (eq mew-biff-string nil))
        (beep))
    (progn
      (setq mew-biff-string (format "Mail(%d)" n))
      (shell-command "echo abc > ~/.xbiff_flag"))))

(defun mew-biff-clear ()
  (progn
    (setq mew-biff-string nil)
    (if (file-exists-p "~/.xbiff_flag")
            (shell-command "rm -f ~/.xbiff_flag"))))