Indy IdSMTP和Thunderbird中的附件

在D2010上使用Indy tiburon的最新快照。像一個非常簡單的項目：Indy IdSMTP和Thunderbird中的附件

var 
    stream: TFileStream; (s is TidSMTP and m is TidMessage) 
begin 
    s.Connect; 
    Stream := TFileStream.Create('c:\Test.zip', fmOpenRead or fmShareExclusive); 
    try 
    with TIdAttachmentMemory.Create(m.MessageParts, Stream) do 
    begin 
     ContentType := 'application/x-zip-compressed'; 
     Name := ExtractFilePath('C:\'); //' 
     FileName := 'Test.zip'; 
    end; 
    finally 
    FreeAndNil(Stream); 
    end; 
    s.Send(m); 
    s.Disconnect(); 
end;

一切都在Outlook中，蝙蝠！OE，雅虎等工作確定...但在雷鳥附件沒有顯示。在Thunderbird中查看消息的來源，附件就在那裏。我能信息之間找到印和其他客戶端發送的唯一區別是，印地消息具有順序如下：

Content-Type: multipart/mixed; boundary="Z\=_7oeC98yIhktvxiwiDTVyhv9R9gwkwT1" 
MIME-Version: 1.0

，而任何其他客戶端具有順序：

MIME-Version: 1.0 
Content-Type: multipart/mixed; boundary="Z\=_7oeC98yIhktvxiwiDTVyhv9R9gwkwT1"

不知道如果這是問題的根源，但如果是這樣的話：這是Thunderbird上的一個錯誤還是這是indy的問題，它會使消息頭「變形」？這個訂單是一個問題嗎？無論如何，這是否重要？

來源

2010-03-16 Lobuno

你是否可以將完整的消息放在某處（例如pastebin）？ – glob 2010-03-17 01:02:01

最新版本（今天）印有在頭一個問題：

的問題似乎是圍繞在郵件標頭行：

內容類型：多重/混合;邊界=「oIROJ8Yu4KsL8BbjOo0fc \ = _ O7oAqLVq97i」

的「=」內部邊界標識被換成了一個「\」（可能逃脫它），但是在郵件正文中的邊界看起來是這樣的：

--oIROJ8Yu4KsL8BbjOo0fc = _O7oAqLVq97i

如果你看看在印第安納波利斯的源頭，在文件idGlobalProtocols，ReplaceHeaderSubItem調用QuoteString，這是增加了反斜槓之一。你可以仔細改變這裏的邏輯並重新編譯Indy。

來源

2010-03-18 09:26:07 cobian

THANKKKKKKKKSSSS。那是！！！！ – Lobuno 2010-03-18 09:31:19

這已經在最新的快照中得到解決。 – 2010-03-19 08:48:15

@Remy，我仍然在Indy10中繼版本4308中遇到這個問題。您能否指出它已修復的修訂版本？ – andrius 2011-07-25 06:23:34

RFC 1521明確規定：

消息按照本文檔MUST組成包括這種頭域，具有以下逐字文本：

MIME-版本：1.0

並注意它是一個標題字段：

個

頭字段是字段名構成的線，後面跟着冒號：通過CRLF終止，隨後是場體，並且（「」）。（RFC 2822）

由此如果印地不設置它作爲一個報頭字段它是一個印錯誤，IMHO其語法是無效的，它不能在該內容 - 類型的線路設定（也許只是一個丟失CRLF？） - 而TB只是逐字地遵循RFC，而另一個人則知道RFC通常沒有完全遵循並處理文檔。

來源

2010-03-16 14:15:40

不知道爲什麼堆棧溢出混亂的佈局，但Indy確實包括CRLF：一行： Content-Type：multipart/mixed;邊界=「Z \ = _ 7oeC98yIhktvxiwiDTVyhv9R9gwkwT1」下一行： MIME-Version：1.0但是按照這個順序，其他程序反過來。這可能是問題的原因 – Lobuno 2010-03-16 14:43:39

歡迎來到Stack Overflow，Lobuno。你發佈的內容是正確的，但格式不正確。 Rruz試圖格式化它，但沒有得到正確的分界線。堆棧溢出不是責任。請在下次發佈之前查看預覽。如果您稍後發現錯誤，請按照Rruz和我所做的那樣編輯修復它。 – 2010-03-16 17:10:18

嗯，我被騙了:)。那麼，MIME版本頭字段在內容類型之前是有意義的，因爲它返回MIME版本，接下來可能依賴於它（儘管到現在爲止不需要它）。 RFC在Content-type之前引入了MIME版本，儘管AFAIK沒有指定順序。這可能是TB在解析中非常嚴格。嘗試導出消息，更改標題位置並重新打開它。如果它顯示附件是TB解析器，儘管Indy也應該改變順序。 – 2010-03-16 17:17:32

你應該試試這樣的：（注意：代碼不會告訴你如何發送消息，只是如何創建它，還有另一種服務發送郵件）。

Msg := TIdMessage.Create(nil); 
try 
    {create the message} 
    Msg.Subject := Subject; 
    with Msg.Recipients.Add do 
    begin 
    Text := EMailAddress; 
    end; 
    Msg.From.Address := From; 
    Msg.From.Name := Copy(From, 1, pos('@', From) - 1); 
    with Msg.ReplyTo.Add do 
    begin 
    Text := From; 
    end; 
    with TIdMessageBuilderHtml.Create do 
    try 
    {plain text} 
    PlainText.Text := 'body text' 
    {html body} 
    Html.Text := '<html><body><p>' + 'body text' + '</p></body></html>'; 
    {attachments} 
    for i := 0 to AttachFiles.Count - 1 do 
     Attachments.Add(AttachFiles.Strings[i]); 
    FillMessage(Msg); 
    finally 
    Free; 
    end; 
    {save the message for sending} 
    Msg.NoEncode := False; 
    Msg.NoDecode := False; 
    Msg.SaveToFile(locfilename + TempExt); 
finally 
    Msg.Free; 
end;

答到羅伯肯尼迪的下面評論：我張貼了這個代碼，因爲對我來說，這個代碼與所有主要的電子郵件客戶端。代碼是自我解釋的，用附件創建消息並保存。我發佈了一個可行的解決方案。我沒有時間（我在工作）比較原始代碼的標題或消息來源和我發佈的代碼，以瞭解我的原因。原來的海報可以自由地做，並報告回來。

來源

2010-03-16 16:34:13

您能否描述一下是什麼讓這段代碼正確，另一段代碼錯了？這段代碼的什麼部分是什麼使它「這樣的事情」？不要只是發佈一些代碼來盲目複製和粘貼。幫助我們學習。 – 2010-03-16 17:17:12

Indy IdSMTP和Thunderbird中的附件

回答

相關問題