Partial message handling in pterodactyl gnus?

Partial message handling in pterodactyl gnus?

[Hamish Macdonald]

TM had mechanisms for sending/handling split messages (message/partial
MIME stuff).  I don't see anything in pterodactyl gnus 0.83 pertaining 
to this.  I don't like sending split messages, but I sometimes receive 
them from people and it would be nice if pgnus could grok them.

Is any work being done on this?

Thanks,
 Hamish.

Re: Partial message handling in pterodactyl gnus?

[Lars Magne Ingebrigtsen]

Hamish Macdonald <hamish@sybarus.ca> writes:

> TM had mechanisms for sending/handling split messages (message/partial
> MIME stuff).  I don't see anything in pterodactyl gnus 0.83 pertaining 
> to this.

No, there is nothing in Pterodactyl for handling message/partial.  I
don't even know if I want Gnus to be able to create message/partial,
but it certainly should be able to grok it...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Partial message handling in pterodactyl gnus?

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> No, there is nothing in Pterodactyl for handling message/partial.  I
> don't even know if I want Gnus to be able to create message/partial,

Oh yes.  Some sendmails simply refuse to grok emails larger than a
number of bytes (often set quite low), in which case having a MIME
mechanism for sending larger things is very useful.

Re: Partial message handling in pterodactyl gnus?

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Oh yes.  Some sendmails simply refuse to grok emails larger than a
> number of bytes (often set quite low), in which case having a MIME
> mechanism for sending larger things is very useful.

Okidoke; so support for creating message/partial will have to be
added. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Partial message handling in pterodactyl gnus?

[Lars Magne Ingebrigtsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 2146 bytes --]

François Pinard <pinard@iro.umontreal.ca> writes (to me, but I'm
answering on the list):

> We would most probably like to find some way to receive and re-assemble
> them, however.  I agree that it is not easy to solve that problem elegantly,
> yet you already made notable efforts in Gnus to reassemble split shars.

Yes, but I don't think that we should do it that way.

I've now read the bits in RFC2046 that talks about message/partial,
and it's quite explicit in how it feels that these messages should be
displayed.  In short, the user should not see several messages -- the
user shouldn't even see one encapsulated message.  The user should
only see one message, and that message should have the headers from
the encapsulated message coupled with some of the headers from the
messages themselves.  (Yes, I know that that probably doesn't make
sense the way I said it, but just read RFC2046.  :-)

So the obvious way to attack this problem would be to have Gnus, on
group entry, looking for message/partial messages, and if it finds a
complete one, it should present the user with just one message in the
summary buffer, which, when selected, should be the unencapsulated
message.

But... how would one do that?  Gnus only knows about The Nine Headers
(and certainly not the Content-Type header) when generating the
summary buffer.

So, let's say we don't do that, but only have Gnus assemble the
partials when you select one partial.  How is Gnus supposed to do even 
that?  It seems to me that that would require a traversal of all the
articles looking for the other message/partials that have matching
IDs.

(The way gnus-uu does its work is by just guessing, and even though it 
guesses correctly most of the time, that's not good enough.)

Here's an idea: How about defaulting gnus-extra-headers and
nnmail-extra-headers to `(Content-Type)'?  That would allow Gnus to do 
the assembly during summary buffer generation... but it wouldn't work, 
for instance, when assembling message/partials from nntp servers that
have NOV.

Hmm.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Partial message handling in pterodactyl gnus?

[Aaron M. Ucko]

RFC 2046, section 5.2.2.1 (fragmentation and reassembly) reads in part

    (2)   All of the header fields from the initial enclosing
          message, except those that start with "Content-" and
          the specific header fields "Subject", "Message-ID",
          "Encrypted", and "MIME-Version", must be copied, in
          order, to the new message.

which means that all the partials corresponding to a given original
message will have the same From: and Date: headers, which should
narrow the search adequately in all but pathological cases.

-- 
Aaron M. Ucko, KB1CJC <amu@mit.edu> (finger amu@monk.mit.edu)

Re: Partial message handling in pterodactyl gnus?

[Lars Magne Ingebrigtsen]

amu@MIT.EDU (Aaron M. Ucko) writes:

>     (2)   All of the header fields from the initial enclosing
>           message, except those that start with "Content-" and
>           the specific header fields "Subject", "Message-ID",
>           "Encrypted", and "MIME-Version", must be copied, in
>           order, to the new message.
> 
> which means that all the partials corresponding to a given original
> message will have the same From: and Date: headers, which should
> narrow the search adequately in all but pathological cases.

No, it's the other way around.  The assembled message should copy the
headers from the partial messages.  The partial messages may have
completely different headers in all respects.  Well, except for the
Content-Type headers.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Partial message handling in pterodactyl gnus?

[Aaron M. Ucko]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> amu@MIT.EDU (Aaron M. Ucko) writes:
> 
> >     (2)   All of the header fields from the initial enclosing
> >           message, except those that start with "Content-" and
> >           the specific header fields "Subject", "Message-ID",
> >           "Encrypted", and "MIME-Version", must be copied, in
> >           order, to the new message.
> > 
> > which means that all the partials corresponding to a given original
> > message will have the same From: and Date: headers, which should
> > narrow the search adequately in all but pathological cases.
> 
> No, it's the other way around.  The assembled message should copy the
> headers from the partial messages.  The partial messages may have
> completely different headers in all respects.  Well, except for the
> Content-Type headers.

Hmm.  On closer inspection, that quote does sound more like it's
describing reassembly, but the introductory text says the rules are
for "_generating_ and reassembling" (emphasis added), and I'd
certainly be surprised if the From: header ended up varying among
parts.

-- 
Aaron M. Ucko, KB1CJC <amu@mit.edu> (finger amu@monk.mit.edu)

Re: Partial message handling in pterodactyl gnus?

[Lars Magne Ingebrigtsen]

amu@MIT.EDU (Aaron M. Ucko) writes:

> Hmm.  On closer inspection, that quote does sound more like it's
> describing reassembly, but the introductory text says the rules are
> for "_generating_ and reassembling" (emphasis added), and I'd
> certainly be surprised if the From: header ended up varying among
> parts.

I wouldn't be, because I know how many weird MIME "implementations"
there are out there.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen