headers
Arcady Genkin | 1 Jun 2000 06:00
X-Face

\XXX symbols in text

I actually meant to ask this for a long time. Below is an artifact
of a message in plain text, which contains escaped characters like
`\222'. In the header it shows as:

,----[ Headers snippage ]
| Content-Type: text/plain; charset="iso-8859-1"
| Content-Transfer-Encoding: 8bit
`----
,----[ Here's an example of what I see in the buffer ]
| ⌠By offering a free ISP service, we will provide the type of
| technologically advanced virtual Internet service that our customers
| demand,■ said Derek J. Burney, executive vice-president, engineering and
| chief technology officer of Corel Corporation.  ⌠Not only is the service
| free, but there are no streamed advertisements that impact the
| consumer▓s Internet experience.■
`----

So, those `\XXX' symbols don't get decoded in whatever they were meant
to show as.  Is this a bug in Gnus or the mailer of the author, which
originated the message?

Thanks!
--

-- 
Arcady Genkin
Nostalgia isn't what it used to be.
Permalink | Reply | 1 comment |
headers
Shenghuo ZHU | 1 Jun 2000 06:20
X-Face
Picon
Favicon

Re: \XXX symbols in text

>>>>> "Arcady" == Arcady Genkin <antipode <at> thpoon.com> writes:

Arcady> I actually meant to ask this for a long time. Below is an
Arcady> artifact of a message in plain text, which contains escaped
Arcady> characters like `\222'. In the header it shows as:

Arcady> ,----[ Headers snippage ]
Arcady> | Content-Type: text/plain; charset="iso-8859-1"
Arcady> | Content-Transfer-Encoding: 8bit
Arcady> `----
Arcady> ,----[ Here's an example of what I see in the buffer ]
Arcady> | ``By offering a free ISP service, we will provide the type of
Arcady> | technologically advanced virtual Internet service that our customers
Arcady> | demand," said Derek J. Burney, executive vice-president, engineering and
Arcady> | chief technology officer of Corel Corporation.  ``Not only is the service
Arcady> | free, but there are no streamed advertisements that impact the
Arcady> | consumer's Internet experience."
Arcady> `----

Arcady> So, those `\XXX' symbols don't get decoded in whatever they
Arcady> were meant to show as.  Is this a bug in Gnus or the mailer of
Arcady> the author, which originated the message?

They are M******** sm*rtq**t*s, not our old friends.  The author is
using M$ mailer or so.  `W d' treats them.

Shenghuo
Permalink | Reply | 0 comments |
headers
Vladimir Volovich | 1 Jun 2000 11:54
Picon

word-encoder creates short lines; possible bug in encoder

Hi!

1. when gnus uses encoded-word encoding (of type B or Q) in headers,
it tends to create more short lines than necessary. Say, i received a
message with subject:

Subject: =?koi8-r?B?Iu7P18HRINDB0sHEycfNwSDEzNEg09TB0s/KINTFz9LJySI=?=

when replying to this message, gnus created a subject like:

Subject: Re: "=?koi8-r?b?7s/XwdEg0MHSwcTJx83B?=
 =?koi8-r?b?IMTM0SDT1MHSz8og1MXP?=
 =?koi8-r?b?0snJ?="

it seems that gnus used AT LEAST one extra line, creating short lines
in headers. Is it possible to change the function which encodes
headers to use optimal line number (i.e. try to use the smallest
possible number of lines, breaking only really wide lines)?

2. AFAIR, RFC says that encoded-word should not appear inside quotes.
is the above header (created by gnus) correct in this respect?
i mean "=?koi8-r?b? .... ?="
should the quotes be "hidden" inside encoded-word?

3. maybe, gnus should switch to SEMI library (SEMI is Emacs MIME
   Interfaces) which provides basic fubctions e.b. for word-encoding,
   etc.  Because AFAIK SEMI is very strict WRT RFC-compliance.

Best,
v.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Steinar Bang | 1 Jun 2000 13:10
Picon

Re: denying nnimap server causes nnimap-close-group to crash

>>>>> Simon Josefsson <jas <at> pdc.kth.se>:

> Steinar Bang <sb <at> metis.no> writes:

>> Would it be possible to make Gnus open agentized denied servers in
>> the unplugged state, without having to open the servers in the
>> server buffer?

> Wouldn't that be kind of unexpected?  If you tell Gnus the server is
> denied, you'd expect it to remain denied, wouldn't you?

I didn't.  I expected "denied" to deal with network traffic, and I
expected to be able to read agent-cached articles in unplugged mode
for groups belonging to these servers.
Permalink | Reply | 2 comments |
headers
Shenghuo ZHU | 1 Jun 2000 16:33
X-Face
Picon
Favicon

Re: word-encoder creates short lines; possible bug in encoder

>>>>> "VV" == Vladimir Volovich <vvv <at> vvv.vsu.ru> writes:

VV> Hi!
VV> 1. when gnus uses encoded-word encoding (of type B or Q) in headers,
VV> it tends to create more short lines than necessary. Say, i received a
VV> message with subject:

VV> Subject: =?koi8-r?B?Iu7P18HRINDB0sHEycfNwSDEzNEg09TB0s/KINTFz9LJySI=?=

VV> when replying to this message, gnus created a subject like:

VV> Subject: Re: "=?koi8-r?b?7s/XwdEg0MHSwcTJx83B?=
VV>  =?koi8-r?b?IMTM0SDT1MHSz8og1MXP?=
VV>  =?koi8-r?b?0snJ?="

VV> it seems that gnus used AT LEAST one extra line, creating short lines
VV> in headers. Is it possible to change the function which encodes
VV> headers to use optimal line number (i.e. try to use the smallest
VV> possible number of lines, breaking only really wide lines)?

According to RFC2047, 

   Each 'encoded-word' MUST represent an integral number of
   characters.  A multi-octet character may not be split across
   adjacent 'encoded-word's.

It is difficult to decide where to break the line.  For the safety
reason, the subject is broken into several lines.  If you can figure
out the optimal algorithm to break wide lines, that's great.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nevin Kapur | 1 Jun 2000 18:32
Favicon

Problem with drafts group

Trying to edit a message in my drafts group with 'D e' I get the
following:

Signaling: (void-variable mml-buffer-list)
  gnus-draft-setup(2 "nndraft:drafts" t)
  #<compiled-function nil "...(88)" [get-text-property gnus-intangible to
gnus-summary-goto-subject gnus-number gnus-summary-last-subject article
gnus-summary-mark-as-read gnus-canceled-mark gnus-draft-setup gnus-newsgroup-name t
set-buffer-modified-p save-buffer nil gnus-verbose-backends gnus-request-expire-articles
lambda when gnus-buffer-exists-p gnus-summary-buffer save-excursion set-buffer
gnus-cache-possibly-remove-article (nil nil nil t) message-send-actions] 10
("/usr/src/gnus/lisp/gnus-draft.elc" . 2265) nil>()
  call-interactively(gnus-draft-edit-message)
Permalink | Reply | 2 comments |
headers
Shenghuo ZHU | 1 Jun 2000 19:42
X-Face
Picon
Favicon

Re: Problem with drafts group

>>>>> "Nevin" == Nevin Kapur <nevin <at> jhu.edu> writes:

Nevin> Trying to edit a message in my drafts group with 'D e' I get the
Nevin> following:

Nevin> Signaling: (void-variable mml-buffer-list)
Nevin>   gnus-draft-setup(2 "nndraft:drafts" t)
Nevin>   #<compiled-function nil "...(88)" [get-text-property gnus-intangible to
gnus-summary-goto-subject gnus-number gnus-summary-last-subject article
gnus-summary-mark-as-read gnus-canceled-mark gnus-draft-setup gnus-newsgroup-name t
set-buffer-modified-p save-buffer nil gnus-verbose-backends gnus-request-expire-articles
lambda when gnus-buffer-exists-p gnus-summary-buffer save-excursion set-buffer
gnus-cache-possibly-remove-article (nil nil nil t) message-send-actions] 10
("/usr/src/gnus/lisp/gnus-draft.elc" . 2265) nil>()
Nevin>   call-interactively(gnus-draft-edit-message)

mml-buffer-list is defined in mml.el. The file should be loaded when
starting Gnus.  Could you recompile Gnus and try it again?

Shenghuo
Permalink | Reply | 1 comment |
headers
Nevin Kapur | 1 Jun 2000 21:07
Favicon

Re: Problem with drafts group

>>>>> "ZSH" == Shenghuo ZHU <zsh <at> cs.rochester.edu> writes:

 ZSH> mml-buffer-list is defined in mml.el. The file should be loaded
 ZSH> when starting Gnus.  Could you recompile Gnus and try it again?

After posting I decided to get the latest version from the CVS. I no
longer have the problem. Thanks.

-Nevin
Permalink | Reply | 0 comments |
headers
Hrvoje Niksic | 2 Jun 2000 09:50
X-Face
Picon
Favicon

Message forwarding annoyance and message-forward-show-mml

It seems that the changes to message forwarding in the last months are
going from bad to worse.  We seem to be reliving the early pgnus
nightmare all over again.

So I press `S o m' to forward a relatively complex message.  What do I
get?  A bunch of MML!  No, Virginia, I almost never want Gnus to muck
with the original message -- for one because it's so easy to fuck up
and send garbage.  But even when it doesn't fuck up, I resent the idea
of destructuring a forwarded message to MML only to re-assemble it
again two seconds later without intermediate changes.  In most cases,
I don't want to edit the messages I forward.

Looking for ways to break the legs of "helpful" MML-ification of
forwarded messages, I stumble upon `message-forward-show-mml'.  Great,
said I, setting this to nil will surely make things sensible again.
But what do I get:

    <$part type=message/rfc822 disposition=inline buffer=" *Gnus forward*<3>">
    <$/part>
    (# intentionally transformed to $)

Now I don't even get to *see* the message I'm forwarding.  If it's not
MML, I'm not supposed to see it at all lest I be made into a pillar of
salt by raw MIME.  And I don't even want to know about the "<3>"
following the buffer name.

Could this please be fixed to behave sensibly, specifically so that
pressing `S o m' inserts this:

    <$part type=message/rfc822 disposition=inline>
(Continue reading)

Permalink | Reply | 19 comments |
headers
Shenghuo ZHU | 2 Jun 2000 14:52
X-Face
Picon
Favicon

Re: Message forwarding annoyance and message-forward-show-mml

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic <at> iskon.hr> writes:

[...]

Hrvoje> Looking for ways to break the legs of "helpful" MML-ification of
Hrvoje> forwarded messages, I stumble upon `message-forward-show-mml'.  Great,
Hrvoje> said I, setting this to nil will surely make things sensible again.
Hrvoje> But what do I get:

Hrvoje>     <$part type=message/rfc822 disposition=inline buffer=" *Gnus forward*<3>">
Hrvoje>     <$/part>
Hrvoje>     (# intentionally transformed to $)

Hrvoje> Now I don't even get to *see* the message I'm forwarding.  If it's not
Hrvoje> MML, I'm not supposed to see it at all lest I be made into a pillar of
Hrvoje> salt by raw MIME.  And I don't even want to know about the "<3>"
Hrvoje> following the buffer name.

Hrvoje> Could this please be fixed to behave sensibly, specifically so that
Hrvoje> pressing `S o m' inserts this:

Hrvoje>     <$part type=message/rfc822 disposition=inline>
Hrvoje>     ... *raw* message (except for quoting of MML-like keywords ...
Hrvoje>     <$/part>

Hrvoje> Pretty please?

What is the definition of the *raw* message?  What if the original
message contains non-ASCII characters or other base64- or qp-encoded
parts?  If not decoded, it is still non-readable.  If decoded, it has
(Continue reading)

Permalink | Reply | 17 comments |

Gmane