Subject: mail_fetch_structure function

From: "DINH V. Hoà" <[email-masked]>
Date: Sun, 12 Nov 2000 14:22:50 +0000

around line 1185 in mail.c, there is :

(in function mail_fetch_structure)

********************************
1   if (stream->dtb && ((body && !*b) || !*env || (*env)->incomplete)) {
2     mail_free_envelope (env);	/* flush old envelope and body */
3     mail_free_body (b);
4 				/* see if need to fetch the whole thing */
5     if (body /* || !elt->rfc822_size*/) {
6       s = (*stream->dtb->header) (stream,msgno,&hdrsize,flags &
~FT_INTERNAL);
7 				/* make copy in case body fetch smashes it */
8       hdr = (char *) memcpy (fs_get ((size_t) hdrsize+1),s,(size_t)
hdrsize);
9       hdr[hdrsize] = '\0';	/* tie off header */
10      (*stream->dtb->text) (stream,msgno,&bs,(flags & ~FT_INTERNAL) |
FT_PEEK);
11      if (!elt->rfc822_size) elt->rfc822_size = hdrsize + SIZE (&bs);
12      if (body)			/* only parse body if requested */
13	rfc822_parse_msg (env,b,hdr,hdrsize,&bs,BADHOST,stream->dtb->flags);
14      else
15	rfc822_parse_msg
(env,NIL,hdr,hdrsize,NIL,BADHOST,stream->dtb->flags);
16      fs_give ((void **) &hdr);	/* flush header */
17    }
18    else {			/* can save memory doing it this way */
19      hdr = (*stream->dtb->header) (stream,msgno,&hdrsize,flags |
FT_INTERNAL);
20      c = hdr[hdrsize];		/* preserve what's there */
21      hdr[hdrsize] = '\0';	/* tie off header */
22      rfc822_parse_msg
(env,NIL,hdr,hdrsize,NIL,BADHOST,stream->dtb->flags);
23      hdr[hdrsize] = c;		/* restore in case cached data */
24    }
25  }
***********************************

I commented "|| !elt->rfc822_size" at line 5.

may I do that is the condition "!elt->rfc822_size" necessary in
mail_fetch_structure ?

I wished to do that to make a patch to support TOP command for POP3 in
c-client.

-- 
Hoa
-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Sun, 12 Nov 2000 10:30:18 -0800 (PST)

> may I do that is the condition "!elt->rfc822_size" necessary in

mail_fetch_structure() guarantees that the elt is fully loaded when it
returns.  Applications depend upon this.

> I wished to do that to make a patch to support TOP command for POP3 in

In my opinion, it is better to produce IMAP clients instead of wasting time
being fancy with a dying protocol like POP.

---

From: "DINH V. Hoà" <[email-masked]>
Date: Sun, 12 Nov 2000 22:35:35 +0000

Mark Crispin wrote:
> > may I do that ? is the condition "!elt->rfc822_size" necessary in
> > mail_fetch_structure ?
> 

It does not answer the question "what is exactly the condition
!elt->rfc822_size for ?". I consider that the condition "body"
is suffisant to test if we have to fetch the text of the mail or not.

> being fancy with a dying protocol like POP.

the problem is that I have no choice about my mail server. It is POP3,
that's all. I want to make a mail client that I can use depending my own
needs.

-- 
Hoa

---

From: Mark Crispin <[email-masked]>
Date: Sun, 12 Nov 2000 17:32:09 -0800 (PST)

> is suffisant to test if we have to fetch the text of the mail or not.

If the rfc822_size is not loaded at this point, then the only way that it can
be loaded by the driver is via getting the text of the message.

To reiterate: mail_fetch_structure() guarantees that the elt is fully loaded
when it returns.  Consequently, mail_fetch_structure() is required to ensure
that elt->rfc822_size ia non-zero before it returns.

The test is correct as it stands.

If you want to write a POP3-only client, you may want to use something other
than c-client.  c-client is focused on IMAP, not POP3; and c-client's IMAP
functionalities are not going to be broken to accomodate POP3.

---

From: Sven Carstens <[email-masked]>
Date: Mon, 13 Nov 2000 12:49:49 +0100 (MET)

> is suffisant to test if we have to fetch the text of the mail or not.

mail_fetch_structure is not really intended to fetch the full content of a given message.
It is used to only fetch the structure (ie. the parts contained in that message) as provided
by the imap server (server side processed mail).
As RFC2683 states you should consider using only the envelope to populate the users view
to a mailbox. (Performance)

> that's all. I want to make a mail client that I can use depending my own

A better way would be to add pop3_fetch_overview (or pop3_fetch_header) directly to
the pop module. This way it would not break interoperability with other clients too easily
and might be accepted by Mark one day.

I'm using mail_fetch_overview. But Mark says it should only be used for NNTP. But I ignored
him and patched some parts to realy suit me anyway :) . Now I have got the problem to adapt
my patchset to each and every update.

CU Sven

---

From: "Jaldhar H. Vyas" <[email-masked]>
Date: Fri, 17 Nov 2000 00:42:00 -0500 (EST)

I got a bug report from a user who was trying to link an application with
the c-client library (ver 4.7c2) on Debian GNU/Linux 2.2 .  This is what
he got:

bash-2.04$ cc test.o mailget.o
mailget.o: In function `openmailbox':
/home/jcz/projects/voxmail/mailget.c:7: undefined reference to `mail_open'
collect2: ld returned 1 exit status
bash-2.04$ cc -lc-client test.o mailget.o
/usr/lib/libc-client.so: undefined reference to `mm_expunged'
/usr/lib/libc-client.so: undefined reference to `mm_diskerror'
/usr/lib/libc-client.so: undefined reference to `mm_lsub'
/usr/lib/libc-client.so: undefined reference to `mm_flags'
/usr/lib/libc-client.so: undefined reference to `mm_fatal'
/usr/lib/libc-client.so: undefined reference to `mm_nocritical'
/usr/lib/libc-client.so: undefined reference to `mm_notify'
/usr/lib/libc-client.so: undefined reference to `mm_searched'
/usr/lib/libc-client.so: undefined reference to `mm_status'
/usr/lib/libc-client.so: undefined reference to `mm_login'
/usr/lib/libc-client.so: undefined reference to `mm_list'
/usr/lib/libc-client.so: undefined reference to `mm_critical'
/usr/lib/libc-client.so: undefined reference to `mm_exists'
/usr/lib/libc-client.so: undefined reference to `mm_log'
/usr/lib/libc-client.so: undefined reference to `mm_dlog'
collect2: ld returned 1 exit status

As I have mentioned before, I have compiled c-client as a shared
library.  Just in case that was the problem, I asked the user to link in
the "approved" way with libc-client.a (which was compiled with make
lnp)  This time the results were like this:

bash-2.04$  cc test.o mailget.o /usr/lib/libc-client.a 2>&1|head
/usr/lib/libc-client.a(mail.o): In function `mail_valid':
/home/jaldhar/src/imap/imap-4.7c/c-client/mail.c:424: undefined reference to `mm_log'
/usr/lib/libc-client.a(mail.o): In function `mail_create':
/home/jaldhar/src/imap/imap-4.7c/c-client/mail.c:684: undefined reference to `mm_log'
/usr/lib/libc-client.a(mail.o): In function `mail_delete':
/home/jaldhar/src/imap/imap-4.7c/c-client/mail.c:739: undefined reference to `mm_log'
/usr/lib/libc-client.a(mail.o): In function `mail_rename':
/home/jaldhar/src/imap/imap-4.7c/c-client/mail.c:761: undefined reference to `mm_log'
/usr/lib/libc-client.a(mail.o): In function `mail_status_default':
/home/jaldhar/src/imap/imap-4.7c/c-client/mail.c:813: undefined reference to `mm_status'
bash-2.04$ 

Now I swear this used to work, I don't know why it doesn't now.  Is it the
applications job to define these functions?  (I notice it is done
seperately in imapd, ipop3d etc.)  Debian recently upgraded its gcc and
ld.  Could that be the problem?

fyi, I get the same problem with imap 2000 with the added bonus of
unresolved SSL symbols.

-- 
Jaldhar H. Vyas <[email-masked]>

---

From: Mark Crispin <[email-masked]>
Date: Thu, 16 Nov 2000 22:16:08 -0800 (PST)

mm_* functions are callbacks from c-client to the appliation, and as such are
defined by the application.  So, yes, it is the application's job to define
these functions.

---

From: "Jaldhar H. Vyas" <[email-masked]>
Date: Fri, 17 Nov 2000 10:56:28 -0500 (EST)

> defined by the application.  So, yes, it is the application's job to define

Thanks.  Is this documented somewhere so I can include the information in
my package and hopefully save someone some trouble in the future?

---

From: Hollis R Blanchard <[email-masked]>
Date: Fri, 17 Nov 2000 12:22:52 -0500 (EST)

> my package and hopefully save someone some trouble in the future?

docs/internals.txt says (around line 2515):

                        Main Program Callbacks

     All applications which use the c-client must have the following
callbacks to handle events from c-client.  Note that in any callback
which involves a mail stream, the stream is locked and you can not
recursively call c-client from the callback.  This may also be true in
callbacks which do not have a stream; in general, the rule is "do not
call c-client, especially any mail_xxx() function, from a c-client
callback".

The second part of that paragraph is worth noting too (if you're going to
be writing some docs). :)

-Hollis