Subject: open_mail, flags and synchronization

From: "Tomas Pospisek's Mailing Lists" <[email-masked]>
Date: Wed, 9 Jun 2004 16:29:16 +0200 (CEST)

I'm trying to fix mailsync a mail synchronizer to properly work wrt to
flags. I'm trying to accomplish this by using c-client.

I need to:

* read the headers in box A
* read the headers in box B
* determine from the header which emails I have already seen in what
  inbox (same algorithm CVS is using)
* copy all messages that A hasn't seen from B to A
* copy all messages that B hasn't seen from A to B
* delete all messages on B that were deleted on A
* delete all messages on A that were deleted on B
* expunge A
* expunge B

Now the mailsync source code is juggling with mail_open in a rather ugly
way and I am not sure whether it is really succeeding in all cases
to keep all the flags (especially "seen") intact on both A and B and at
the same time trying to do that transparently with respect to where those
boxes are (IMAP, mbox, mh, remote, locally, ...).

So my first question is:
  is there a way to achieve the above with c-client, that is guaranteed to
  work? Basically this means:

  * open a box for reading messages
  * open a box for appending messages
  * expunge a box

  and at the same time keep all flags as they were.

Second question:
  some of my MH users say that re-mail_open'ing a MH store will make it
  forget all all removal flags.

  Is this a known bug/problem/feature. Is there a work around or should I
  try to fix c-clients source with respect to this?

Thanks a lot,
*t

--
-----------------------------------------------------------
  Tomas Pospisek
  http://sourcepole.com -  Linux & Open Source Solutions
-----------------------------------------------------------

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

---

From: "Tomas Pospisek's Mailing Lists" <[email-masked]>
Date: Thu, 10 Jun 2004 09:30:12 +0200 (CEST)

Since Mark seems to be listening on the list, but there's no reply yet:
let's make the requirements a bit lighter and ask some more specific
questions. I'll cut this email in two, since it is two different
questions actually.

>   and at the same time keep all flags as they were.

"Expunging" a box will, AFAIK traverse all messages, look for those that
are marked for deletion and remove them. A side effect of this seems to
be, that all those traversed messages seem to get marked as "Seen" aka
"Status: O" ("old"). Is this a requirement of some sort? Isn't there a way
around it?

So if there isn't - can we fullfull our requirements, that is to leave all
flags alone, even the "Seen" one, if we don't expunge? Or can't that be
guaranteed even then?
*t

---

From: "Tomas Pospisek's Mailing Lists" <[email-masked]>
Date: Thu, 10 Jun 2004 09:36:16 +0200 (CEST)

>   try to fix c-clients source with respect to this?

osdep/unix/mh.c says:

void mh_check (MAILSTREAM *stream)
{
  /* Perhaps in the future this will preserve flags */
  if (mh_ping (stream)) mm_log ("Check completed",(long) NIL);
}

So I guess the problem is known.

But I don't understand what would be required to fix it. I can't see
the big picture. AFAI can see mh_ping is not changing the status of
messages.

So do you flag messages in memory or something similar when marking them
for deletion? And so a mh_ping doesn't take in memory structures in
account and only checks "on disk" messages and by this invalidates in
memory information? But even then - I don't see mh_ping flushing any in
memory data? So where do those flags get lost?
*t

---

From: "Shawn Walker" <[email-masked]>
Date: Thu, 10 Jun 2004 10:18:11 -0500

I'm trying to get c-client to see a embedded message that I have inserted  
in the BODY structure.

I got the structure to look right after I sent the email, but the embedded  
message is missing (no header or body).  What I did is do the following:

part->body.type                         = TYPEMESSAGE;
part->body.subtype                      = cpystr("RFC822");
part->body.disposition.type             = cpystr("ATTACHMENT");

part->body.nested.msg                   = mail_newmsg();
part->body.nested.msg->env              = mail_newenvelope();
part->body.nested.msg->body             = mail_newbody();

// setup the embedded message header

embed->createEnvelope(part->body.nested.msg->env);

// setup the embedded message body

embed->createBody(part, part->body.nested.msg->body);

Seems like c-client is ignoring the "part->body.nested.msg" part.

Is there something I'm missing?

Thanks,
Shawn

---

From: Mark Crispin <[email-masked]>
Date: Thu, 10 Jun 2004 08:59:25 -0700 (PDT)

On Thu, 10 Jun 2004, Shawn Walker wrote:
> I'm trying to get c-client to see a embedded message that I have inserted in 
> the BODY structure.

I presume that you meant to say, "I am trying to *send* an embedded 
message, but when I go to read the message that I have sent I see that it 
is empty."

You apparently missed the point where it says that composing a message 
that is not of type MULTIPART, you use body->contents.text (store the text 
in body->contents.text.data and its size in body->contents.text.size).

You do this even when body->type is TYPEMESSAGE and body->subtype is 
"RFC822"; you supply the complete message in body->contents.text.data 
instead of using body->nested.msg.

Put another way, when sending, embedded messages look like any other type 
of text attachments.  The body->nested.msg stuff is only used when reading 
messages.  The body structure for a message being sent is not the same as 
that for a message that was read back.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: "Shawn Walker" <[email-masked]>
Date: Thu, 10 Jun 2004 11:05:58 -0500

Hrmm, so what about the header?  Do I need to format the header into a  
string and put both header and body of the embedded message and set  
body->contents.text.data and body->contents.text.size?

On Thu, 10 Jun 2004 08:59:25 -0700 (PDT), Mark Crispin  
<[email-masked]> wrote:

>> I'm trying to get c-client to see a embedded message that I have  
>> inserted in the BODY structure.
>
> message, but when I go to read the message that I have sent I see that  
> it is empty."
>
> that is not of type MULTIPART, you use body->contents.text (store the  
> text in body->contents.text.data and its size in  
> body->contents.text.size).
>
> Put another way, when sending, embedded messages look like any other  
> type of text attachments.  The body->nested.msg stuff is only used when  
> reading messages.  The body structure for a message being sent is not  
> the same as that for a message that was read back.
>
> -- Mark --
>

---

From: Mark Crispin <[email-masked]>
Date: Thu, 10 Jun 2004 09:12:28 -0700 (PDT)

On Thu, 10 Jun 2004, Shawn Walker wrote:
> Hrmm, so what about the header?  Do I need to format the header into a string 
> and put both header and body of the embedded message and set 

Yes, if you're forwarding a message, just fetch the message as raw text.

Since forwardings is what most embedded messages are (digests are after 
all just a form of forwarding), it turned out to make no sense to break a 
message into ENVELOPE and BODY only to have the sender reassemble them.

-- Mark --

---

From: Mark Crispin <[email-masked]>
Date: Thu, 10 Jun 2004 09:15:51 -0700 (PDT)

> "Status: O" ("old"). Is this a requirement of some sort? Isn't there a way

That's not "Seen" status; that's "Recent" status or rather "not Recent" 
status.  "Seen" is "Status: R".

No, there is no way to get around the "not Recent" happening once the 
mailbox has been opened readwrite.  The definition of "Recent" is that the 
message has arrived since the last time the mailbox was opened readwrite.

-- Mark --

---

From: Mark Crispin <[email-masked]>
Date: Thu, 10 Jun 2004 09:18:59 -0700 (PDT)

> the big picture. AFAI can see mh_ping is not changing the status of

mh format does not have any place to store flags permanently.  Flags are 
only maintained for a session, after which they are lost.

Some people have extended mh format to have a place to store flags, but 
this is effectively a different format.  The only reason to use mh is to 
interoperate with the ancient mh program.  Otherwise, you should use some 
other format.

-- Mark --

---

From: Vadim Zeitlin <[email-masked]>
Date: Thu, 10 Jun 2004 18:44:32 +0200 (Romance Daylight Time)

On Thu, 10 Jun 2004 09:18:59 -0700 (PDT) Mark Crispin <[email-masked]> wrote:

MC> Some people have extended mh format to have a place to store flags, but 
MC> this is effectively a different format.  The only reason to use mh is to 
MC> interoperate with the ancient mh program.  Otherwise, you should use some 
MC> other format.

 But MH is the only format among those supported by c-client (except
support for it is so poor that it is unusable in practice) which supports
folders having both messages and subfolders. It is also "plain text" (and
so is preferrable to MBX) and vastly faster than MBOX. For these reasons,
it would be a great format to use for me -- if only the driver for it had
flags support.

 Regards,
VZ

---

From: Mark Crispin <[email-masked]>
Date: Thu, 10 Jun 2004 10:10:53 -0700 (PDT)

On Thu, 10 Jun 2004, Vadim Zeitlin wrote:
> folders having both messages and subfolders.

No, there is also mx format.

> It is also "plain text" (and
> so is preferrable to MBX) and vastly faster than MBOX.

I don't think that you'll find that mh is faster than mbox in general. 
Some operations (e.g. expunge) may be faster on Linux, but not operations 
involving many messages (e.g. search).

On UNIX (as opposed to Linux), mh is extremely slow.

-- Mark --

---

From: Vadim Zeitlin <[email-masked]>
Date: Thu, 10 Jun 2004 19:30:40 +0200 (Romance Daylight Time)

On Thu, 10 Jun 2004 10:10:53 -0700 (PDT) Mark Crispin <[email-masked]> wrote:

MC> On Thu, 10 Jun 2004, Vadim Zeitlin wrote:
MC> > But MH is the only format among those supported by c-client (except
MC> > support for it is so poor that it is unusable in practice) which supports
MC> > folders having both messages and subfolders.
MC> 
MC> No, there is also mx format.

 Sorry, I forgot about that one. But AFAIK it's very uncommon compared to
mbox and mh. In fact, I don't know any programs using it, do you?

MC> > It is also "plain text" (and
MC> > so is preferrable to MBX) and vastly faster than MBOX.
MC> 
MC> I don't think that you'll find that mh is faster than mbox in general. 

 For a typical usage scenario it definitely is. I didn't do any hard
testing but mh was certainly much faster for me than mbox for mailboxes
containing from 1000 to 20000 messages.

MC> Some operations (e.g. expunge) may be faster on Linux, but not operations 
MC> involving many messages (e.g. search).
MC> 
MC> On UNIX (as opposed to Linux), mh is extremely slow.

 Traditional Unix with ufs -- maybe. But modern Unix systems (even other
than Unix) have much faster filesystems. If there were any chance of you
accepting patches to the mh driver, I would do some tests comparing mbox
and mh on a few different systems to prove it.

 Regards,
VZ

---

From: Mark Crispin <[email-masked]>
Date: Thu, 10 Jun 2004 11:08:39 -0700 (PDT)

> mbox and mh. In fact, I don't know any programs using it, do you?

Well, gee, you're talking about a hack to extend mh format for c-client 
that mh itself won't know about.  That's a different format.

> containing from 1000 to 20000 messages.

With what client?  With a POP client hacked to babble IMAP such as 
Outlook, perhaps.  If you actually use IMAP as IMAP, with such things as 
fetching envelopes and searches, you'll find something different.

I'm not interested in optimizing IMAP for POP.

> than Unix) have much faster filesystems.

I must disagree.  I am spending a lot of cycles right now dealing with a 
modern UNIX system which has a horrendously slow filesystem.

> If there were any chance of you

Since those patches won't be compatible with the original mh program, I'm 
not interested.

mh is a dead format.  The only purpose to support it is for compatibility 
with the past; and without that compatibility it isn't worth supporting. 
The successors in the one-message/one-file style of doing things are such 
formats as Cyrus, mx, and yes maildir.

Getting that style to work well with IMAP is not easy.  Nobody has a 
satisfactory maildir implementation for IMAP; it's either slow, or broken, 
or incompatible with DJB's maildir definition, or a combination of these.
Cyrus has special hacks in the format to support IMAP, and is focused on 
IMAP-only access (not local file).

-- Mark --

---

From: Vadim Zeitlin <[email-masked]>
Date: Thu, 10 Jun 2004 20:24:42 +0200 (Romance Daylight Time)

On Thu, 10 Jun 2004 11:08:39 -0700 (PDT) Mark Crispin <[email-masked]> wrote:

MC> On Thu, 10 Jun 2004, Vadim Zeitlin wrote:
MC> > Sorry, I forgot about that one. But AFAIK it's very uncommon compared to
MC> > mbox and mh. In fact, I don't know any programs using it, do you?
MC> 
MC> Well, gee, you're talking about a hack to extend mh format for c-client 
MC> that mh itself won't know about.  That's a different format.

 But backwards compatible with MH and mostly (or even fully) compatible
with quite a few of modern MUAs which use similar "mh+" formats.

MC> > For a typical usage scenario it definitely is. I didn't do any hard
MC> > testing but mh was certainly much faster for me than mbox for mailboxes
MC> > containing from 1000 to 20000 messages.
MC> 
MC> With what client?

 Both XFMail and my own Mahogany (using cclient). The performance hit when
I had to abandon mh (because flags are too useful to have) was really
painful.

MC> If you actually use IMAP as IMAP, with such things as 
MC> fetching envelopes and searches, you'll find something different.

 I don't see why fetching envelopes would be slow(er), as for searches it's
not something that I do every 30 seconds (unlike expunging).

MC> > If there were any chance of you
MC> > accepting patches to the mh driver, I would do some tests comparing mbox
MC> > and mh on a few different systems to prove it.
MC> 
MC> Since those patches won't be compatible with the original mh program, I'm 
MC> not interested.

 I might be missing something there but why wouldn't they be compatible?
The mh program would still work with these files, just not benefit from any
new features.

MC> The successors in the one-message/one-file style of doing things are such 
MC> formats as Cyrus, mx, and yes maildir.

 I've looked up mx in cclient docs and you write yourself that you have
abandoned it -- hardly a good sign. The other 2 are ok except cclient
doesn't have support for them...

 Basically the problem is that the only reasonably well performing format
in cclient is mbx but it:

1. doesn't allow dual use mailboxes (yes, I'm one of these strange people)
2. is a binary format with all corresponding problems

 Having a well-behaving mh driver or a possibility to use an optional index
for mbox (as all non-toy programs using this format do) would be great.
It's a pity that neither is apparently going to happen.

 Regards,
VZ

---

From: David B Funk <[email-masked]>
Date: Thu, 10 Jun 2004 14:00:58 -0500 (CDT)

> mbox and mh. In fact, I don't know any programs using it, do you?

Hmm, programs that can use mx format? Try: pine, ipop3d, imapd, tmail,
dmail or any other program that is written to use the 'c-client'
library. Say like all the implementations of "webmail" systems based
upon PHP which uses the 'c-client' library, such as 'imp' 'squirrelmail'
etc.

That should get you a few million programs that can use it.

Do people actually use it?, we have several thousand clients who
use it daily on our imap/pop server.

-- 
Dave Funk                                  University of Iowa
<dbfunk (at) engineering.uiowa.edu>        College of Engineering
319/335-5751   FAX: 319/384-0549           1256 Seamans Center
Sys_admin/Postmaster/cell_admin            Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{

---

From: Vadim Zeitlin <[email-masked]>
Date: Thu, 10 Jun 2004 21:09:34 +0200 (Romance Daylight Time)

On Thu, 10 Jun 2004 14:00:58 -0500 (CDT) David B Funk <[email-masked]> wrote:

DBF> On Thu, 10 Jun 2004, Vadim Zeitlin wrote:
DBF> 
DBF> > On Thu, 10 Jun 2004 10:10:53 -0700 (PDT) Mark Crispin <[email-masked]> wrote:
DBF> >
DBF> > MC> No, there is also mx format.
DBF> >
DBF> >  Sorry, I forgot about that one. But AFAIK it's very uncommon compared to
DBF> > mbox and mh. In fact, I don't know any programs using it, do you?
DBF> 
DBF> Hmm, programs that can use mx format? Try: pine, ipop3d, imapd, tmail,
DBF> dmail or any other program that is written to use the 'c-client'
DBF> library.

 Of course there was an implicit "except for cclient" in my question, I'm
well aware of the fact that cclient supports it. But it could also support
an enhanced mh format without problems. Anyhow, I'd be glad to use mx if it
were not officially abandoned (see cclient docs).

 Regards,
VZ

---

From: Mark Crispin <[email-masked]>
Date: Thu, 10 Jun 2004 13:26:16 -0700 (Pacific Daylight Time)

> were not officially abandoned (see cclient docs).

mx is at least as supported as mh is, and doesn't have the burden of being 
compatible with ancient history.

If there is interest in mx, there would certainly be support/activity.

-- Mark --

---

From: "Tomas Pospisek's Mailing Lists" <[email-masked]>
Date: Fri, 11 Jun 2004 09:26:57 +0200 (CEST)

> only maintained for a session, after which they are lost.

The problem I'm fighting against here is that when reopening a connection
the c-client's mh driver will loose knowledge of which messages were
removed.

And wrt *that* "flag", my sources seem to be clear - a removed message is
prepended with a ',' or with a '#' [1] (that's what one of the mh users is
seeing in RL as well).

IMHO c-client should do just that: rename all the removed messages, but
...

But even if it doesn't, then it should remove - however that should be
done - removed messages at mh_check instead of forgeting about the fact
they were removed.

?

*t

[1] http://www.ics.uci.edu/~mh/book/mh/rem.htm

---

From: "Tomas Pospisek's Mailing Lists" <[email-masked]>
Date: Fri, 11 Jun 2004 09:33:59 +0200 (CEST)

> with the past; and without that compatibility it isn't worth supporting.

Allthough mailsync beeing a tiny little tool lost somewhere in the huge
masses of OSS I do have 2-3 users that I know of that they are using mh. I
can't say in what quantitative relation to other mailformats that number
is though.
*t

---

From: Mark Crispin <[email-masked]>
Date: Fri, 11 Jun 2004 01:25:03 -0700 (PDT)

> the c-client's mh driver will loose knowledge of which messages were

That problem is insurmountable.

If it is a problem for you, the solution is simple: do not use mh format.

> prepended with a ',' or with a '#' [1] (that's what one of the mh users is

Like POP style deletion, what mh calls "deletion" seems similar to IMAP 
deletion (and c-client implements strict IMAP semantics).  That similarity 
is deceptive.  Once you do a careful study of how mh actually works and 
what IMAP requires, it becomes clear that it is impossible to implement 
the IMAP semantics of deletion using mh deletion.  There is a difference 
between "working some of the time" and "working all the time"; and it is 
not an option to deviate from strict compliance with IMAP requirements.

If it was possible to do it, I would have done it 12 years ago.

The solution is not to use mh format.

-- Mark --

---

From: "Tomas Pospisek's Mailing Lists" <[email-masked]>
Date: Fri, 11 Jun 2004 16:04:10 +0200 (CEST)

> If it is a problem for you, the solution is simple: do not use mh format.

Let me see what my users will answer me.

> The solution is not to use mh format.

So it's better to leave the mh driver broken and very hard to use in a
useful way, because it would not be possible to make it "strictly IMAP
semantics compliant" (presonally it's still not clear why).

*Is* the mh driver "strictly IMAP semantics compiant" right now? Is the
fact that a) it forgets about all the flags and b) when reusing an open
connection it just forgets about all the deleted messages "strictly IMAP
semantics compliant"?

Would it make the situation worse to fix that behaveour?
*t

---

From: Mark Crispin <[email-masked]>
Date: Fri, 11 Jun 2004 09:42:47 -0700 (PDT)

> connection it just forgets about all the deleted messages "strictly IMAP

Yes and yes.  It properly advertises the mailbox as not having any 
PERMANENTFLAGS.  Your client should have observed the empty PERMANENTFLAGS 
list and taken appropropriate action.

> Would it make the situation worse to fix that behaveour?

Yes.  Read the mh specification carefully, and pay close attention to the 
requirements in RFC 3501 section 3.1.  It will probably also help to look 
at some mh source code (which I did when I wrote the mh driver).

The answer to your request is not a "no" that becomes a "yes" if you ask 
enough times.  The answer is a "no" that will always be a "no".

You might "fix" it, and it might even work in your client.  But presently 
it will break some other client.  Sad experience tells me that the blame 
for that breakage will first be attributed to that client, and then by the 
author of that client to UW imapd, and only after long investigation 
(typically an incredible amount of time wasted by me) to your "fix".

-- Mark --

---

From: "Tomas Pospisek's Mailing Lists" <[email-masked]>
Date: Fri, 11 Jun 2004 20:26:56 +0200 (CEST)

> (typically an incredible amount of time wasted by me) to your "fix".

Thanks for the answer
*t

---

From: "Shawn Walker" <[email-masked]>
Date: Thu, 17 Jun 2004 09:40:52 -0500

I'm trying to use the utf8_mime2text() to convert a UTF-8 string to text.

The sample string that I'm trying to convert is:

=?UTF-8?Q?Us=C3=A9r T=C3=A9st?=

The string translate to "Usér Tést".

mime2_text() is returning NIL because there is a space in the string.

What is the correct method of decoding the strings?

I'm using imap-2004.

Thanks,
Shawn

---

From: "Shawn Walker" <[email-masked]>
Date: Thu, 17 Jun 2004 12:31:40 -0500

How does c-client handle 3rd party CAPABILITY strings from the IMAP  
server?  What I mean is what if there is a CAPABILITY string  
"X-SUPPORT-SOMETHING"?

Thanks,
Shawn

---

From: Mark Crispin <[email-masked]>
Date: Thu, 17 Jun 2004 10:43:27 -0700 (Pacific Daylight Time)

On Thu, 17 Jun 2004, Shawn Walker wrote:
> How does c-client handle 3rd party CAPABILITY strings from the IMAP server? 
> What I mean is what if there is a CAPABILITY string "X-SUPPORT-SOMETHING"?

Capabilities not known to c-client are ignored.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: "Shawn Walker" <[email-masked]>
Date: Thu, 17 Jun 2004 12:55:21 -0500

> Capabilities not known to c-client are ignored.

Well, I guess I will have to modify c-client to either store the unknown  
capabilities to mail_stream or make a mm_capability() to pass unknown  
capability then.

---

From: Mark Crispin <[email-masked]>
Date: Thu, 17 Jun 2004 11:49:46 -0700 (PDT)

> =?UTF-8?Q?Us=C3=A9r T=C3=A9st?=

That is not a proper MIME quoted-word, and consequent utf8_mime2text() 
declines to deal with it.

> What is the correct method of decoding the strings?

That string is properly MIME decoded as the text
 	=?UTF-8?Q?Us=C3=A9r T=C3=A9st?=

A proper MIME quoted-word, such as
 	=?UTF-8?Q?Us=C3=A9r_T=C3=A9st?=
would be decoded into a string with 8-bit characters.

The syntax for MIME quoted words was very carefully selected so that there 
would be no mistaken decodings.  It is necessary to consider the effects 
of RFC 2822 line wrapping with spaces.  Consequently, spaces are forbidden 
within quoted words.

I understand the argument of "why aren't you more forgiving in an obvious 
case such as this?".  The answer is that you should take a look at 
Outlook.  Many of the exploits in Outlook involve attacking Outlook's 
willingness to "just work" in "obvious cases."  Without strict rules to 
follow, software is deprived of clear guidelines to follow that will 
enable it to reject absurd cases.  To make matters worse, the code paths 
to forgive such "obvious forgivable cases" is rarely exercised; most data 
complies with the rules.  This creates a fertile breeding ground for bugs.

-- Mark --

---

From: "Shawn Walker" <[email-masked]>
Date: Thu, 17 Jun 2004 14:29:12 -0500

On Thu, 17 Jun 2004 11:49:46 -0700 (PDT), Mark Crispin  
<[email-masked]> wrote:

> The syntax for MIME quoted words was very carefully selected so that  
> there would be no mistaken decodings.  It is necessary to consider the  
> effects of RFC 2822 line wrapping with spaces.  Consequently, spaces are  
> forbidden within quoted words.
>
> I understand the argument of "why aren't you more forgiving in an  
> obvious case such as this?".  The answer is that you should take a look  
> at Outlook.  Many of the exploits in Outlook involve attacking Outlook's  
> to forgive such "obvious forgivable cases" is rarely exercised; most  
> data complies with the rules.  This creates a fertile breeding ground  
> for bugs.
>

I finally figured out that quoted string is invalid.  If it's invalid, I  
say "tough", blame it on the person that formed a invalid quoted string.

---

From: "Shawn Walker" <[email-masked]>
Date: Mon, 21 Jun 2004 12:07:49 -0500

Does c-client has any functions that can do mime encoding for to, subject  
and body of the message, like RFC 1522?

Thanks,
Shawn

---

From: Mark Crispin <[email-masked]>
Date: Mon, 21 Jun 2004 10:53:11 -0700 (PDT)

On Mon, 21 Jun 2004, Shawn Walker wrote:
> Does c-client has any functions that can do mime encoding for to, subject and 
> body of the message, like RFC 1522?

c-client has functions to do MIME encoding of bodies, but not to do MIME 
quoted-word encoding of headers such as Subjects and personal names in 
From/to/cc addresses (there is a decoding routine for quoted-words into 
UTF-8).

-- Mark --

---

From: "Shawn Walker" <[email-masked]>
Date: Mon, 21 Jun 2004 13:37:36 -0500

On Mon, 21 Jun 2004 10:53:11 -0700 (PDT), Mark Crispin  
<[email-masked]> wrote:

>> Does c-client has any functions that can do mime encoding for to,  
>> subject and body of the message, like RFC 1522?
>

That is what I thought.  Just wanted to make sure I wasn't missing a  
encoding for subject and personal names.

I saw some code in pine that does that.