Re: S/MIME with Wanderlust

[Kazuhiro Ito <kzhr@d1.dion.ne.jp>]

> 3. showing "mime-view-entity"
>    or
> showing "mime-view-entity-header”
>    in new buffer
> ==========================
> 
> [mime-buffer-entity
>  [0 0 0 0 0 0 0]
>  #<buffer  *WL:Message*-nil>
>  ((type . message)
>   (subtype . x-broken))
>  nil nil nil
>  ((type . attachment))
>  "7bit"
>  ((Content-Transfer-Encoding . "7bit
> ")
>   (Content-Disposition . "attachment;
> \n	filename=smime.p7s
> "))
>  nil #<buffer  *WL:Message*-nil> 1 4215 4215 4215]

mime-view-entity's property shows how the raw content is parsed, and
this result seems broken.

1. Last 4 numbers indicate positions of the beginning of headers, the
end of headers, the beginning of body, the end of body respectively.
The fact that last 3 numbers are equal means delimiter between headers
and body are found at the end of the raw content, i.e. actual
delimiter is ignored.

2. Moreover, last 3 numbers are too big.  The buffer which has 4214
characters returns 4215 as point-max function's result.  The decrypted
raw content actually has 4214byte.  But CRs in EOL are truncated in
raw content's buffer.  As a result, point-max's result is more smaller
than 4215.


Your broken mime-view-entity's property is similar to the case that
gpgsm append extra CR in its output.  I guess gpgsm outputs extra
character before LF.  Please visit the decrypted raw content buffer
according to [wl-en: 05587] and run hexl-mode to check whether there
is garbage especially before LF.


-- 
Kazuhiro Ito