Not downloading attachments over IMAP

Not downloading attachments over IMAP

[Niklas Morberg]

I'm using nnimap and quite often receive emails with
attachments that I don't need to see (at least not this
instant).

When gnus displays an article (email) with an attachment, it
will always download all attachments before the article is
displayed. For large attachments, this can take a while.

Can I tell gnus to not download attachments and just display
the message? Having buttons available that downloads the
attachment when I click them would be a nice bonus.

I've looked at the gnus-uu.* variables, but they only seem
to kick in once the attachment has been downloaded.

I'm also thinking about `gnus-ignored-mime-types', but it
does not feel quite right...

Niklas

Re: Not downloading attachments over IMAP

[Simon Josefsson]

On Wed, 28 Nov 2001, Niklas Morberg wrote:

> I'm using nnimap and quite often receive emails with
> attachments that I don't need to see (at least not this
> instant).
> 
> When gnus displays an article (email) with an attachment, it
> will always download all attachments before the article is
> displayed. For large attachments, this can take a while.
> 
> Can I tell gnus to not download attachments and just display
> the message? Having buttons available that downloads the
> attachment when I click them would be a nice bonus.

This is not possible now, and making it work would require changes to the
backend interface and the cache, agent, asynchronous support and possibly
more stuff.  Double plus non-trivial.  Patches welcome. :-)

A hack to not download large attachments could be written inside nnimap, 
but it wouldn't be very flexible (and wouldn't allow you to download the 
attachment using the normal interface at all).

Re: Not downloading attachments over IMAP

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> On Wed, 28 Nov 2001, Niklas Morberg wrote:
>
>> Can I tell gnus to not download attachments and just display
>> the message? Having buttons available that downloads the
>> attachment when I click them would be a nice bonus.
>
> This is not possible now, and making it work would require changes to the
> backend interface and the cache, agent, asynchronous support and possibly
> more stuff.  Double plus non-trivial.  Patches welcome. :-)

Couldn't nnimap fetch the message structure and rewrite the `large'
parts into external bodies?  Isn't there a MIME type where one stores
a reference to the real part, rather than the data itself, in the
message?

If all else fails, one could augment the URL package to grok imap://
URLs and insert those in the message.

kai
-- 
Simplification good!  Oversimplification bad!  (Larry Wall)

Re: Not downloading attachments over IMAP

[William M. Perry]

Simon Josefsson <jas@extundo.com> writes:

> On Wed, 28 Nov 2001, Niklas Morberg wrote:
> 
> > I'm using nnimap and quite often receive emails with
> > attachments that I don't need to see (at least not this
> > instant).
> > 
> > When gnus displays an article (email) with an attachment, it
> > will always download all attachments before the article is
> > displayed. For large attachments, this can take a while.
> > 
> > Can I tell gnus to not download attachments and just display
> > the message? Having buttons available that downloads the
> > attachment when I click them would be a nice bonus.
> 
> This is not possible now, and making it work would require changes to the
> backend interface and the cache, agent, asynchronous support and possibly
> more stuff.  Double plus non-trivial.  Patches welcome. :-)
> 
> A hack to not download large attachments could be written inside nnimap, 
> but it wouldn't be very flexible (and wouldn't allow you to download the 
> attachment using the normal interface at all).

Is there any way to manually put a button in the buffer?  You could then
stick an IMAP URL in there for the specific attachment, and make
activating the button fetch the correct attachment and call
mm-display-part directly.

-bp
-- 
Ceterum censeo vi esse delendam

Re: Not downloading attachments over IMAP

[Simon Josefsson]

On Wed, 28 Nov 2001, Kai Großjohann wrote:

> >> Can I tell gnus to not download attachments and just display
> >> the message? Having buttons available that downloads the
> >> attachment when I click them would be a nice bonus.
> >
> > This is not possible now, and making it work would require changes to the
> > backend interface and the cache, agent, asynchronous support and possibly
> > more stuff.  Double plus non-trivial.  Patches welcome. :-)
> 
> Couldn't nnimap fetch the message structure and rewrite the `large'
> parts into external bodies?  Isn't there a MIME type where one stores
> a reference to the real part, rather than the data itself, in the
> message?

Yup.  multipart/external.  But isn't it kind of gross to have the backend
change the contents of a message?  I wouldn't want that.  But I guess it 
could be useful.  Hm.

Re: Not downloading attachments over IMAP

[William M. Perry]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Simon Josefsson <jas@extundo.com> writes:
> 
> > On Wed, 28 Nov 2001, Niklas Morberg wrote:
> >
> >> Can I tell gnus to not download attachments and just display
> >> the message? Having buttons available that downloads the
> >> attachment when I click them would be a nice bonus.
> >
> > This is not possible now, and making it work would require changes to the
> > backend interface and the cache, agent, asynchronous support and possibly
> > more stuff.  Double plus non-trivial.  Patches welcome. :-)
> 
> Couldn't nnimap fetch the message structure and rewrite the `large' parts
> into external bodies?  Isn't there a MIME type where one stores a
> reference to the real part, rather than the data itself, in the message?
> 
> If all else fails, one could augment the URL package to grok imap:// URLs
> and insert those in the message.

The URL library already supports imap:: URLs, but I don't think it
supports pulling down just bits of the message.  Simon wrote the original
proof-of-concept, maybe we should ask him to finish it. :)

-bp
-- 
Ceterum censeo vi esse delendam

Re: Not downloading attachments over IMAP

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> On Wed, 28 Nov 2001, Kai Großjohann wrote:
>
>> Couldn't nnimap fetch the message structure and rewrite the `large'
>> parts into external bodies?  Isn't there a MIME type where one stores
>> a reference to the real part, rather than the data itself, in the
>> message?
>
> Yup.  multipart/external.  But isn't it kind of gross to have the backend
> change the contents of a message?  I wouldn't want that.  But I guess it 
> could be useful.  Hm.

Maybe the real solution is for Gnus to provide a way to fetch the
MIME tree for a message from the backend.  But I think that so far,
there is only one backend which allows for retrieval of the MIME
tree: nnimap.

Maybe rewriting nnimap to do what I suggested would also help in
devising a good interface for retrieving the MIME tree, and then the
nnimap functions can be moved into the Gnus proper, more or less: you
have nnchoke-retrieve-mime-tree which returns a useful data
structure, and the Gnus proper then decides what to do with it.
You'll also need nnchoke-retrieve-mime-part, of course.

How about that?

I wish I had time to work on this.

kai
-- 
Simplification good!  Oversimplification bad!  (Larry Wall)

Re: Not downloading attachments over IMAP

[Simon Josefsson]

On Thu, 29 Nov 2001, Kai Großjohann wrote:

> > Yup.  multipart/external.  But isn't it kind of gross to have the backend
> > change the contents of a message?  I wouldn't want that.  But I guess it 
> > could be useful.  Hm.
> 
> Maybe the real solution is for Gnus to provide a way to fetch the
> MIME tree for a message from the backend.  But I think that so far,
> there is only one backend which allows for retrieval of the MIME
> tree: nnimap.

Right.  Gnus should fetch the MIME tree if the backend supports it, 
otherwise it should fetch the entire message and parse MIME itself.

> Maybe rewriting nnimap to do what I suggested would also help in
> devising a good interface for retrieving the MIME tree, and then the
> nnimap functions can be moved into the Gnus proper, more or less: you
> have nnchoke-retrieve-mime-tree which returns a useful data
> structure, and the Gnus proper then decides what to do with it.
> You'll also need nnchoke-retrieve-mime-part, of course.
> 
> How about that?

Yup.  The problem is that making the above work is not enough, you would
need to fix the rest of Gnus to understand this as well.  Caching, Agent,
scoring and whatnot.

It would probably mean almost the same amount of work as replacing the
backend interface with something based on wmperry's URL package and thus
turning Gnus into a mail oriented URL browser (W3 being the web oriented
URL browser).  Which would be way cooler.

Re: Not downloading attachments over IMAP

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> Yup.  The problem is that making the above work is not enough, you would
> need to fix the rest of Gnus to understand this as well.  Caching, Agent,
> scoring and whatnot.

Maybe simple things can be done easily?  For example, if Gnus by
default turns some MIME parts into external body buttons, then the
Agent would do the same, and people would need to be online for
fetching the messages behind those.

kai
-- 
Simplification good!  Oversimplification bad!  (Larry Wall)