Akopia Akopia Services

[Date Prev][Date Next][Thread Prev][Thread Next][Minivend by date ][Minivend by thread ]

RE: [mv] MIME error (was How-To PGP 6.5)



******    message to minivend-users from David Babler <dbabler@Rigel.orionsys.com>     ******



On Thu, 25 May 2000, Cameron B. Prince wrote:

> ******    message to minivend-users from "Cameron B. Prince" <cbp@InternetExpertsLLC.com>     ******
> 
> Well David, actually I was unaware that it was bad mime.
> 
> I originally encrypted only the attachments and they worked fine for me.
> Then later I began encrypting the entire order and I have left the mime tags
> in place as you see them in the code I pasted. I only changed the primary
> encryptor to /bin/cat.

Did you get mail that had a PGP block containing the CC info *in* the
first text part *and* an attachment that contained the same thing? That's
what I was getting. And only if I manually inserted a boundary following
the header (otherwise Pine wouldn't display it).

> I get the encrypted message and when I decrypt it, I see the header you
> mentioned before over the credit card number. The number is no longer an
> attachment at least in Outlook (I know Outlook sucks, but I have an Exchange
> server I must access), but displays fine.
> 
> I haven't investigated why it is no longer an attachment or even bothered to
> remove the mime because they haven't bothered me.
> 
> Have you tired to view the reports in something other than Pine? Maybe it's
> a problem only specific to Pine.

Actually, I'm looking at the real mail file, not just how Pine interprets
it. I'd assume that if you're actually generating the same message headers
and contents that I am here, the reason that Outlook is "working" is that
it is assuming that text leading up to a boundary is a message, whereas
Pine believes that the first part must be preceeded by the boundary
line. From what I've seen, any declaration of MIME type in MV results in 
the header lines:

	MIME-Version: 1.0
	Content-type: MULTIPART/MIXED; BOUNDARY="...

RFC-1521 states:

	"...each body part is preceded by an encapsulation boundary. The
	encapsulation boundary MUST NOT appear inside any of the
	encapsulated parts."

So my reading is that if the message is declared multipart (defining the
encapsulation boundary) then the message body must contain 0 or more
encapsulated parts, each introduced with a boundary. So I'd say that Pine
is Doing the Right Thing here in not seeing the "message" that isn't
encapsulated properly. Many MIME messages include a plain text "you
shouldn't be able to read this" notice preceding the first boundary to
alert users that their MUA isn't MIME compliant.

Including the necessary MIME encapsulation boundary and (optionally) the
message type in the attachment is syntactically wrong.

I'll probably play with Outlook eventually, but at first glance it didn't
seem to want to use PGP at all and wanted to install certs from Verisign
and others instead. I assume that's why people here are tending to use
PGP5 and 6 (as well as international export reasons)... but of course all
versions of PGP have some sort of non-commercial use caveat in their
licenses... but that's a whole other can of worms.

Anyway, to return to the original subject, I don't know whether the
problem here lies with the simple syntax in etc/report or deeper in the
Perl modules. I only know this output is incorrect and explains why some
people get no message, some get what looks okay and some are wondering
what the heck it is I'm jabbering about. <G>

-Dave

-
To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
Archive of past messages: http://www.minivend.com/minivend/minivend-list


Search for: Match: Format: Sort by: