Txt. attachment problem

HCL Domino Domino Forum
1

Recently, I have noticed that “txt” attachments sent from external mail server do not appear as attachments an email, instead I can only see the text in the body of the email and no txt attachment icons are shown. Is there a way to correct this?

2

Subject: RE: txt. attachment problem

Solution - do not use Notes as e-mail program.

Notes is not RFC compliant sometimes. Like there is no perfection in this world

3

Subject: Re: Notes is not RFC compliant sometimes???

Really?

Notes is far more RFC compliant than any other MUA I use on a regular basis.

The problem is almost certainly the MIME structure of the source emails in this case. if $original_poster can post the MIME source of a sample here, we can verify this.

(hint - in Notes 6, open one of the messages that is displaying .txt “attachments” as in-line text, then use menu option View, Show, Page Source, then copy the source to the clipboard and paste it in a response to this thread)

HTH

Chris Linfoot

4

Subject: RE: Re: Notes is not RFC compliant sometimes???

Ever tried to exctract inline txt attachments from Notes?

look here

5

Subject: I agree about that but…

It is a different issue.

What $original_poster appeared to say was that Notes 6 was presenting .txt attachments as in-line text which is somewhat different to the known issue of Notes not having the option to save in-line message parts as files (as described in the thread you pointed me at).

That still looks like a sender side MIME issue to me.

Tried a test, sending a .txt attachment to myself using a POP client. Said .txt file was delivered as an attachment with MIME structure quite clearly showing it as such.

Content-Type: multipart/mixed;

	 boundary="----=_NextPart_000_0035_01C33420.D3795D50"

------=_NextPart_000_0035_01C33420.D3795D50

Content-Transfer-Encoding: 7bit

Content-Type: text/plain;

	 charset="iso-8859-1"

there is a .txt file attached here

------=_NextPart_000_0035_01C33420.D3795D50

Content-Type: text/plain;

	 name="example.txt"

Content-Disposition: attachment;

	 filename="example.txt"

Content-Transfer-Encoding: base64

So $original_poster’s problem could be a problem with Content-Disposition or with the Content-Type of the message (multipart/mixed, multipart/related, multipart/alternative…

Naming no names, but other popular MUAs are known to be less than wholly reliable where these matters are concerned :wink: