「Mercury/32 v4.73」と「Windows Server 2008 Service Pack 2」で質問です。

一行が非常に長いメールは長すぎる部分が届かない事は多いです。

実際、一行1000文字越えるメールを送りつけられた時には998文字を越えた部分が消えてましたし。

仕様という話なら、

RFC2822

2.1.1. Line Length Limits

There are two limits that this standard places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding

the CRLF.

http://www.puni.net/~mimori/rfc/rfc2822.txt

上記ページの翻訳文を引用すれば

## 行の長さの制限

##

## この標準では１行中の文字数に２つの制限がある。それぞれの行の文字はCRLF

## を除いて、決して998文字以下でなければならず(MUST)、78文字以下であるべ

## きである(SHOULD)。

改行なしに998文字を越えれば、どのメールサーバでも正常に配送される事は期待できません。

> 「Mercury/32 v4.73」のSMTPサーバ(MercuryS)もしくはPOP3サーバ(MercuryP)は、

> 添付ファイルBase64部分が改行されていないメールデータが送られると、途中でデータを破壊する仕様なのでしょうか？

SMTPの仕様が998文字以内ですから、SMTPを実装した様々なメールサーバがその仕様で作られています。使っているSMTPサーバを改変し依り長いメールが配送できるように変えても普通のメールサーバを一つ介せばそれで長い部分は破棄されると思います。

> 送り側で改善できるか、今後参考にさせて頂きます。

> …が、今すぐはこの長文データを何とかする必要があります

> Mercury上でなんとかする方法はないもんでしょうかorz

送り側(固定)→(IPトンネル)ClamWin(IPトンネル)→Mercury

上記の様な感じかな。

ClamWinってオープンソースならその出力部分で1000文字を越える行は改行を追加するなど改造したり、もう一段IPトンネル入れて単機能の変換ソフトをでっち上げて入れちゃうっていうのが楽な気がします。(Mercury上でなんとかするより)

※長すぎるデータはClamWinもチェックできてないかも知れませんしMercuryやその後のソフトが捨てちゃう危険もあります。メール関係のソフトは全て一行1000文字を越えるデータを扱う事は想定されてませんのでたまたま1500文字で動いたからといって1600文字で問題が起こらないとは言えませんので。

※全部検証するよりMercuryに入る前で扱えるデータに変えてしまって対応する方が良さそうに感じました。本当はClamWinの手前が良いのだろうな。

※どこかでバッファオーバフロー状態になりセキュリティ上の問題が起こらないとも限りませんし。

2回目の回答なので今回が最後です。