Virtual Vacations!!! ... from HatterasOnMyMind.com

Virtual Vacations!!! ... from HatterasOnMyMind.com

[HatterasOnMyMind.com]

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]

                      New from HatterasOnMyMind.com

                      For Beach Lovers Everywhere
                        ...Virtual Vacations!!!
                Delivered monthly to your email address

                                [Image]
     ScreenSavers Featuring Spectacular Coastal Island Photography

               Click here to preview this month's edition
                     and enjoy our risk free offer!

[-- Attachment #2.1: Type: text/html, Size: 1044 bytes --]

[-- Attachment #2.2: C:windowsTEMPnsmail9E.jpeg --]
[-- Type: image/jpeg, Size: 24422 bytes --]

multipart/alternative bug? (was: Virtual Vacations!!! ... from...)

[Toby Speight]

[-- Attachment #1: Type: text/plain, Size: 1542 bytes --]

Why does this not display properly for me?  (I'm not particularly
bothered about seeing this spam, but I'm concerned about genuine
mails...)  I see the message as if it were a multipart/mixed
containing one text/plain part, beginning with

Anon> --------------27BEBD72CFE816D2DAE0A30E
Anon> Content-Type: text/plain; charset=us-ascii
Anon> Content-Transfer-Encoding: 7bit

and ending with

Anon> FVRWi3+FfkcUWqD0q7BfppgKVRHQdEX37jAWUSVs0iUAMSjwIP8AzVkAG0lCFo+4rloaFh9I+Awr
Anon> axvT9q4UbrRSvw9fbFFLw0nEih4nvTFX/9k=
Anon>
Anon> --------------329329E610BEF8140BC1E45B--
Anon>
Anon> --------------27BEBD72CFE816D2DAE0A30E--

If I C-d on the article, I get the right structure:

> R +[ HatterasOnMyMind co: 492 ] <* mixed> Virtual Vacations!!! ... from HatterasOnMyMind.com
> R + [ HatterasOnMyMind co: 486 ] <1.* alternative>
> R +  [ HatterasOnMyMind co: 463 ] <1.2.* related>
>   +   [ HatterasOnMyMind co: 20  ] <1.2.1 html>
> R +   [ HatterasOnMyMind co: 430 ] <1.2.2 jpeg>
> R +  [ HatterasOnMyMind co: 13  ] <1.1 text>

Selecting the <1.* alternative> part gives me the raw message text,
but anything deeper than that works correctly.

Is it something to do with the InterScan_NT filter used by our
mail gateway?  (Perhaps the ^M at the end of the "Content-Type:
multipart/alternative" header).

Or is it a Gnus bug (5.8.8 on Emacs 20.7, from Debian "testing"
distribution)?

Here's the message as it arrived here, after being mangled by the
gateway (I've truncated the image data to reduce message size - but
that's not relevant here).


[-- Attachment #2: Type: message/rfc822, Size: 5655 bytes --]

[-- Attachment #2.1.1.1: Type: text/plain, Size: 427 bytes --]

                      New from HatterasOnMyMind.com

                      For Beach Lovers Everywhere
                        ...Virtual Vacations!!!
                Delivered monthly to your email address

                                [Image]
     ScreenSavers Featuring Spectacular Coastal Island Photography

               Click here to preview this month's edition
                     and enjoy our risk free offer!


[-- Attachment #2.1.1.2.1: Type: text/html, Size: 1044 bytes --]

[-- Attachment #2.1.1.2.2: C:windowsTEMPnsmail9E.jpeg --]
[-- Type: image/jpeg, Size: 311 bytes --]

Re: multipart/alternative bug?

[Toby Speight]

0> In article <s8u23duw5t.fsf@lanber.cam.eu.citrix.com>,
0> Toby Speight <URL:mailto:streapadair@gmx.net> ("Toby") wrote:

Toby> Why does this not display properly for me? (I'm not particularly bothered about seeing this spam, but I'm concerned about genuine mails...) I see the message as if it were a multipart/mixed containing one text/plain part, beginning with Anon> --------------27BEBD72CFE816D2DAE0A30E Anon> Content-Type: text/plain; charset=us-ascii Anon> Content-Transfer-Encoding: 7bit and ending with Anon> FVRWi3+FfkcUWqD0q7BfppgKVRHQdEX37jAWUSVs0iUAMSjwIP8AzVkAG0lCFo+4rloaFh9I+Awr Anon> axvT9q4UbrRSvw9fbFFLw0nEih4nvTFX/9k= Anon> Anon> --------------329329E610BEF8140BC1E45B-- Anon> Anon> --------------27BEBD72CFE816D2DAE0A30E-- If I C-d on the article, I get the right structure: > R +[ HatterasOnMyMind co: 492 ] <* mixed> Virtual Vacations!!! ... from HatterasOnMyMind.com > R + [ HatterasOnMyMind co: 486 ] <1.* alternative> > R + [ HatterasOnMyMind co: 463 ] <1.2.* related> > + [ HatterasOnMyMind co: 20 ] <1.2.1 html> > R + [ HatterasOnMyMind co: 430 ] <1.2.2 jpeg> > R + [ HatterasOnMyMin
 d!
!
 co: 13 ] <1.1 text> Selecting the <1.* alternative> part gives me the raw message text, but anything deeper than that works correctly. Is it something to do with the InterScan_NT filter used by our mail gateway? (Perhaps the ^M at the end of the "Content-Type: multipart/alternative" header). Or is it a Gnus bug (5.8.8 on Emacs 20.7, from Debian "testing" distribution)? Here's the message as it arrived here, after being mangled by the gateway (I've truncated the image data to reduce message size - but that's not relevant here).

I'm not sure why that all got folded onto one line - I'm obviously
having problems with 5.8.8!  I'll try this again:

Why does this not display properly for me?  (I'm not particularly
bothered about seeing this spam, but I'm concerned about genuine
mails...)  I see the message as if it were a multipart/mixed
containing one text/plain part, beginning with

Anon> --------------27BEBD72CFE816D2DAE0A30E
Anon> Content-Type: text/plain; charset=us-ascii
Anon> Content-Transfer-Encoding: 7bit

and ending with

Anon> FVRWi3+FfkcUWqD0q7BfppgKVRHQdEX37jAWUSVs0iUAMSjwIP8AzVkAG0lCFo+4rloaFh9I+Awr
Anon> axvT9q4UbrRSvw9fbFFLw0nEih4nvTFX/9k=
Anon>
Anon> --------------329329E610BEF8140BC1E45B--
Anon>
Anon> --------------27BEBD72CFE816D2DAE0A30E--

If I C-d on the article, I get the right structure:

> R +[ HatterasOnMyMind co: 492 ] <* mixed> Virtual Vacations!!! ... from HatterasOnMyMind.com
>   + [ HatterasOnMyMind co: 486 ] <1.* alternative>
>   +  [ HatterasOnMyMind co: 463 ] <1.2.* related>
>   +   [ HatterasOnMyMind co: 20  ] <1.2.1 html>
>   +   [ HatterasOnMyMind co: 430 ] <1.2.2 jpeg>
>   +  [ HatterasOnMyMind co: 13  ] <1.1 text>

Selecting the <1.* alternative> part gives me the raw message text,
but anything deeper than that works correctly.

Is it something to do with the InterScan_NT filter used by our
mail gateway?  (Perhaps the ^M at the end of the "Content-Type:
multipart/alternative" header).

Or is it a Gnus bug (5.8.8 on Emacs 20.7, from Debian "testing"
distribution)?

Here's the message as it arrived here, after being mangled by the
gateway (I've truncated the image data to reduce message size - but
that's not relevant here).

Re: multipart/alternative bug? (was: Virtual Vacations!!! ... from...)

[Karl Kleinpaste]

I suspect it's a 5.8.8 bug.  I'm running Oort 0.03 and it displays
fine, but the embedded links are not active, evidently due to the fact
that W3 didn't like it enough -- from the Messages buffer:

Parsed  76% of 1045...
Parsed 100% of 1045...done
Drawing... -
Error while rendering html; showing as text/plain

Weirdly, it looks (at first) like a normal W3-rendered HTML thing,
until one tries to put the links to use and finds they're not mouse-active.

Perhaps it's related to the bogus .jpg image -- it's not a real image.
Even after saving it with `K o', xv(1) complains that "there is no
image data."

Re: multipart/alternative bug? [fix included]

[Toby Speight]

0> In article <vxkae55i1uq.fsf@cinnamon.vanillaknot.com>,
0> Karl Kleinpaste <URL:mailto:karl@charcoal.com> ("Karl") wrote:

Karl> I suspect it's a 5.8.8 bug.  I'm running Oort 0.03 and it displays
Karl> fine, ...

Funny, it works from my email quoting it, but it didn't work as
received.

BTW, this brokenness seems to be common to articles that have been
through the scanner's multipart filter, and it also happened with Gnus
5.8.3.

Could it be caused by an extraneous ^M in the multipart?  The original
had

> --------------InterScan_NT_MIME_Boundary
> Content-Type: multipart/alternative;
>  boundary="------------27BEBD72CFE816D2DAE0A30E"^M
>
> --------------27BEBD72CFE816D2DAE0A30E

where ^M is a CR character.  I'm wondering if Gnus's MIME parser
dislikes that.  What I see is exactly what you'd get if that header
was not there and the part defaulted to text/plain.

That would explain why it works when embedded.

[some time later]

Yes, that appears to be the case.  I think that the expression
> (memq c '(? ?\t ?\n))
in `ietf-drums-remove-whitespace' should be
> (memq c '(? ?\t ?\r ?\n))
to deal with this.  I'm not sure if there's anywhere else this appears,
but this one-liner looks safe to me.  Could someone please apply the
appropriate patch?  (ietf-drums.el, line 119).  Thanks.


Karl> but the embedded links are not active, evidently due to the fact
Karl> that W3 didn't like it enough ...

I never got that far - all rendered as text/plain, without even
loading w3.

Karl> Perhaps it's related to the bogus .jpg image -- it's not a real
Karl> image.  Even after saving it with `K o', xv(1) complains that
Karl> "there is no image data."

As I said, I cut out most of the image data (I didn't attempt to make
it a valid JPEG image, as that's not of interest).  The image in the
original was certainly okay by xv (my default for image/*).


Thanks for helping with this, Karl.