On 001130, at 18:32:42, Anand Buddhdev wrote:
> Ok. I've done some more digging. After I send a signed message, I can
> verify the fcc copy. However, I can't verify the cc: copy, and also,
> the recipient can't verify the copy he receives. I've traced it down to
> the following:
>
> The boundary is different because the MTA has re-written
> it. Also notice that the order of the Content-Disposition and the
> Content-Transfer-Encoding headers is different. If I now manually edit
> the Cc: copy (and the recipient also modifies his copy) to make the
> order of the headers the same as the original message, THEN the message
> signature verifies correctly.
>
> Now I'm not an expert on MIME and PGP, so I don't know who's at fault
> here. The author of the MTA I use (courier) says that MTAs are free to
> rewrite headers as necessary, while obviously it's causing a problem
> for me. I also realise that it's not really a mutt issue at all, so I
> will not pursue this issue on the mutt list anymore.
A few weeks ago, Thomas Roessler explained how PGP/MIME works:
> On 2000-10-03 01:45:02 +0300, Eugene Paskevich wrote:
>
> > Can you explain what do you mean? app/pgp is Content-Type;
> > but what is PGP/MIME? And is it the way decide my problem?
>
> PGP/MIME is what mutt uses to send pgp-encrypted and -signed
> messages. The idea is basically this: You take the message, then
> MIME-encode it entirely. The result looks like this (for example):
>
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: quoted-printable
>
> This attachment contains umlauts: =E4=F6=FC=DF
>
> Now, this entire MIME body part is encrypted/signed, and eventually
> put into some more MIME sugar. Here, PGP only ever touches us-ascii
> text (with which it deals nicely); the actual character set
> conversions are left to the software which interprets the inner MIME
> layers.
Which leave two possibilities:
- The author of courier is mistaken
- The relevant standards are ambiguous
--
David Ellement <[EMAIL PROTECTED]>
