Subject: Remedial syslogd question

From: Mark Edwards <[email-masked]>
Date: Tue, 09 Oct 2001 15:33:17 -0700

Sorry for the remedial nature of this question, but I haven't been able to
find a good answer after some searching and manpage reading.

I have this line in /etc/syslog.conf --

*.notice;*.info;authpriv,remoteauth,ftp.none;kern.debug;mail.crit
/var/log/system.log

The *.notice is causing imapd and ipopd messages to get logged to
/var/log/system.log and I want them not to be.  I am routing them to a
separate file to keep things tidy.

Can someone recommend a good way to configure syslogd to continue its
*.notice behavior (this is the default with Mac OSX) with the exception of
imapd-related .notice messages?

Thanks a lot.

-- 
Mark Edwards
Engineer
Mr. Toad's
San Francisco

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

---

From: "Scot W. Hetzel" <[email-masked]>
Date: Wed, 10 Oct 2001 10:14:51 -0500

From: "Mark Edwards" <[email-masked]>
> imapd-related .notice messages?
Try adding the following to syslog.conf:

!imapd
*.*        /var/log/imapd.log
!pop3d
*.*        /var/log/pop3d.log

Scot

---

From: Mark Edwards <[email-masked]>
Date: Wed, 10 Oct 2001 09:16:39 -0700

Actually, I just added "local2.none" to the original line and that works.  
Thanks for the suggestion though.

--
Mark Edwards
San Francisco, CA
[email-masked]

---

From: Thomas Brown <[email-masked]>
Date: Wed, 10 Oct 2001 12:56:59 -0400

I'm not sure what UNIX you are running, but generally the entries like
"authpriv", "remoteauth", "ftp.none" contain invalid facility codes and
will either be ignored or produce a parsing error within syslogd.  Also,
unless you have some non-standard wacko UNIX, using things like "!imapd"
and the like are completely invalid.

The standard format of entries in syslog.conf is basically:

facility.level	OutputDestination

The only "standard" facility codes are "user, kern, mail, daemon, auth,
lpr, news, uucp, cron, and local0 through local7".  Some UNIX
implementations may allow others, but this is probably non-standard. 
You'll have to refer to your system's /usr/include/syslog.h file for
clarification.

The way the syslog "levels" work is that specifying a particular level
will allow messages of that level *or higher* severity to pass through
to the output file.  The standard levels, in order of severity from high
to low, are "emerg, alert, crit, err, warning, notice, info, debug,
none".

>From what I have observed, an unmodified C-client library produces
syslog messages on the 'mail' facility, commonly on either 'debug' or
'info' levels.  For instance, a typical IMAP connection produces:

Oct 10 12:37:37 tick imapd[9631]: [ID 806292 mail.debug] imap service
init from 10.207.212.5
Oct 10 12:37:37 tick imapd[9631]: [ID 234311 mail.info] Login
user=mailuser host=mailclient [10.207.212.5]
Oct 10 12:38:14 tick imapd[9631]: [ID 533678 mail.info] Logout
user=mailuser host=mailclient [10.207.212.5]

A similar IMAPS session looks like:

Oct 10 12:21:03 mailhost imapd[9329]: [ID 298158 mail.debug] imaps SSL
service init from 10.57.85.31
Oct 10 12:21:05 mailhost imapd[9329]: [ID 666661 mail.info]
Authenticated user=tbrown host=mailclient [10.57.85.31]
Oct 10 12:28:14 mailhost imapd[9329]: [ID 533678 mail.info] Logout
user=tbrown host=mailclient [10.57.85.31]

Therefore, to funnel just mail-related messages to /var/adm/mail.log,
use the following entry in syslog.conf:

mail.debug	/var/adm/mail.log

Also, get rid of the *.notice elsewhere in the file, or at least add
"mail.none" to the line to block sendmail/IMAP messages as follows:

*.notice;*.info;mail.none;kern.debug;mail.crit	/var/log/system.log

Note, however, that most editions of 'sendmail' also use the 'mail'
facility by default, with various levels including 'info', 'warning',
and 'notice'.  This may not be a problem, however, as you will have all
mail-related logging in one file, and this can be easily filtered as
each program (sendmail, imapd, ipop3d, etc.) will tag its name on each
line.

-Tom

---

From: Mark Edwards <[email-masked]>
Date: Thu, 11 Oct 2001 11:30:57 -0700

I've got imapd running along pretty well now in conjunction with the default
install of Sendmail on an OS X 10.0.4 machine with 512MB RAM.

There are about 14 users that all connect with imap using Outlook Express
Mac 5.02.  These 14 accounts are set up on several machines in the office so
that anyone can check their mail from any machine.

Here's the strange part.  If I set the client machines to check mail every 5
minutes, the server will periodically bog down and become unusable for 5
minutes or so, say every hour roughly.  I'll even get the occasional memory
error in my /var/log/system.log.  If I disable regular checking in the
clients and just have the clients sync with the server when someone looks at
their account, everything runs smooth.

I conclude that either imapd or the way Outlook is accessing imapd is
causing horrendous memory problems.  However, I don't see any direct
evidence of a problem.  If I check top while Outlook is set to check every 5
minutes, I see roughly 14 instances of imapd, which doesn't seem odd to me
since there are 14 accounts.  However, something is obviously sapping
resources like hell, and when I disable checking every 5 minutes it goes
away.

Does this behavior sound familiar to anyone?  I know Outlook sucks, but I
honestly don't see any other viable alternative for Mac OS9 right now.

Thanks!

-- 
Mark Edwards
Engineer
Mr. Toad's
San Francisco

---

From: Sebastian Hagedorn <[email-masked]>
Date: Fri, 12 Oct 2001 17:44:46 +0200

-- Mark Edwards <[email-masked]> is rumored to have mumbled on 
Donnerstag, 11. Oktober 2001 11:30 Uhr -0700 regarding imapd + Outlook =:

>  I know Outlook sucks, but I

Why? I don't want to evangelize, but there are alternatives...
--
Sebastian Hagedorn
Ehrenfeldgürtel 156, 50823 Köln, Germany
http://www.spinfo.uni-koeln.de/~hgd/

Winter is coming.

---

From: Mark Edwards <[email-masked]>
Date: Fri, 12 Oct 2001 09:17:07 -0700

Please evangelize!  I tried accessing imap with Eudora on OS9 and it just 
crashed.  Also, its multi-account functionality is pretty weak if you ask 
me.  What is there that does a decent job of checking multiple imap 
accounts from a single interface?

--
Mark Edwards
San Francisco, CA
[email-masked]

---

From: Sebastian Hagedorn <[email-masked]>
Date: Fri, 12 Oct 2001 19:52:49 +0200

-- Mark Edwards <[email-masked]> is rumored to have mumbled on Freitag, 

> accounts from a single interface?

Well, since you've asked... my favorite IMAP client is Mulberry from 
Cyrusoft (www.cyrusoft.com). It's actually the only GUI mailer I know that 
gets IMAP right. The only disadvantages are that it's not free (but there 
is a demo version) and that the UI is not very pretty. OE definitely looks 
nicer...

It takes some time to "get" how Mulberry works; it's not entirely 
intuitive. However, time spent on learning Mulberry is time spent well. 
It's more powerful than most other GUI mailers. Another plus is that the 
author of Mulberry is very responsive to feature requests.

Eudora Pro 5.1 seems to work OK with my IMAP servers, but I think that 
Mozilla 0.9.4/Netscape 6.1 are probably the best other free options.

Hope this helps...

Greetings, Sebastian

Winter is coming.

---

From: "Jeff Breitner (Mailing Lists)" <[email-masked]>
Date: Fri, 12 Oct 2001 13:47:07 -0400

What about Netscape 6.1?  When I gave up Windows and started using Linux 
on the desktop, I struggled to find a decent IMAP client.

Up to 6.1, I never liked Netscape, but the current release of Messenger 
works great and the interface is consistent across Windows and X.  I use 
it to manage 6 different IMAP accounts, mixed with SSL/TLS on some of them.

Mark Edwards wrote:

> Please evangelize!  I tried accessing imap with Eudora on OS9 and it 
> just crashed.  Also, its multi-account functionality is pretty weak if 
> you ask me.  What is there that does a decent job of checking multiple 
> imap accounts from a single interface?
>

---

From: Mark Crispin <[email-masked]>
Date: Fri, 12 Oct 2001 11:54:01 -0700 (PDT)

If you don't absolutely insist upon a GUI, Pine is another IMAP client that
gets IMAP right.  What's more, it's based upon c-client, and is developed by
very bright people who work in the same group as the author of c-client (and
inventor of IMAP)...in fact, a lot of c-client work is driven by Pine.

Pine runs on just about every form of UNIX you can imagine as well as 32-bit
Windows.  There was a DOS/16-bit Windows port, but that was abandoned after
version 3.96 of Pine.

There's also a GUI for the old NeXT computers called MailManager that the
author of c-client wrote in 1989.  Not much work on it has been done since
1991 other than to make it build with modern c-client, although it does have a
very basic MIME capability.  It may be possible to port it to Mac OS X.

I use MailManager and Pine interchangably throughout my day.

---

From: Mark Edwards <[email-masked]>
Date: Fri, 12 Oct 2001 14:04:41 -0700

> inventor of IMAP)...in fact, a lot of c-client work is driven by Pine.

Can anyone elaborate on what might be happening when checking with Outlook
in my case?  Presumably it isn't normal behavior for imapd to stress out a
system with 512MB ram when 20-40 connections are active.  What is Outlook
doing to cause trouble?  Again I don't see more imapd instances than
expected, usually only 14-20.  I've heard that Outlook is known for opening
tons of imap connections and causing problems, but I don't see evidence of
this.

Is this perhaps just a general issue with imap?  Should I not be checking
mail every 5 minutes like that?

I'd love to figure out exactly what the problem is, so I can make sure there
isn't something wrong on the server end.  I am tempted to blame Microsoft
for this, but I don't want to do it blindly.

-- 
Mark Edwards
Engineer
Mr. Toad's
San Francisco

---

From: Mark Edwards <[email-masked]>
Date: Fri, 12 Oct 2001 15:32:02 -0700

As I recall, the problem with Netscape for my situation is that sets certain
global parameters for all accounts, such as Name.  We have 8 people checking
email at shared stations, and we require that there's no logging out and in
each time someone wants to check their mail.  There needs to be a way of
having totally independent accounts accessible at the same time, with no
shared parameters between them.  Outlook is good at this.

Netscape does seem adequate as a personal email program.  However, that's
not how we're set up.

-- 
Mark Edwards
Engineer
Mr. Toad's
San Francisco

---

From: Mark Crispin <[email-masked]>
Date: Fri, 12 Oct 2001 16:01:41 -0700 (PDT)

On Fri, 12 Oct 2001 14:04:41 -0700, Mark Edwards wrote:
> in my case?

It's a long and sad story, and one which is still evolving as we learn more
about what's going on with it.

Let's just say that Outlook is known to have major issues.  It is very easy to
configure Outlook to beat the hell out of a server.

Outlook Express is a completely different program which is a much better IMAP
citizen, although it too is easily configured into a bad apple.  More recent
versions of OE are worse than previous ones.

> Presumably it isn't normal behavior for imapd to stress out a
> system with 512MB ram when 20-40 connections are active.

No, it isn't.

> I've heard that Outlook is known for opening

Check the logs to see if there are transient IMAP connections.  I think that
what you'll see is not "lots of sessions at one time", but "lots of sessions
starting up and dying right away."

> Should I not be checking

Well, you certainly should not be checking new mail in 300+ mailboxes every 5
minutes, running up a total of over 13,000 IMAP sessions in just a few hours.
[Local incident today at UW from an Outlook user]  Unfortunately, that's what
Outlook will do if you're not careful.

Good clients, such as Pine, don't do this sort of bad thing.

---

From: Mark Crispin <[email-masked]>
Date: Sat, 13 Oct 2001 14:18:01 -0700 (PDT)

On Sat, 13 Oct 2001 13:22:53 +0200, Sebastian Hagedorn wrote:
> > There's also a GUI for the old NeXT computers called MailManager
> I've wondered about that, but the source wasn't available anymore last time
> I looked.

MailManager source is the same place that it's always been:

ftp://ftp.cac.washington.edu/mail/next/MailManager.tar.Z

---

From: Sebastian Hagedorn <[email-masked]>
Date: Sat, 13 Oct 2001 13:22:53 +0200

-- Mark Crispin <[email-masked]> is rumored to have mumbled on 
Freitag, 12. Oktober 2001 11:54 Uhr -0700 regarding Re: imapd + Outlook =:

> 1991 other than to make it build with modern c-client, although it does
> have a very basic MIME capability.  It may be possible to port it to Mac
> OS X.

I've wondered about that, but the source wasn't available anymore last time 
I looked. I'm not sure if I'd be able to make the necessary fixes for it to 
compile under OS X, but I might give it a shot...

Pine is great for terminals and I've used it a lot, but I prefer a GUI 
mailer when I can get one.
--
Sebastian Hagedorn
Ehrenfeldgürtel 156, 50823 Köln, Germany
http://www.spinfo.uni-koeln.de/~hgd/

Winter is coming.

---

From: Sebastian Hagedorn <[email-masked]>
Date: Tue, 16 Oct 2001 10:25:45 +0200

--On Saturday, October 13, 2001 14:18:01 -0700 Mark Crispin 
<[email-masked]> wrote:

>> I've wondered about that, but the source wasn't available anymore last
>> time I looked.
>

You're absolutely right. I don't know where I'd been looking. Anyway, the 
main obstacle right now appears to be that the current incarnation of 
Interface Builder can't handle the NIBs. I'll try to find some advice from 
the NextStep community...

--
Sebastian Hagedorn
Ehrenfeldgürtel 156
50823 Köln

Winter is coming.

---

From: Mark Edwards <[email-masked]>
Date: Tue, 16 Oct 2001 16:14:45 -0700

Mulberry is indeed quite a nice email client, feature-wise.  The only thing
I don't like about it is that its multiple-windows, so every message and
every mailbox is a new window.  If Mulberry had the option to work in a
single window with panes, it would be everything I need.

Unfortunately, the multiple window thing turns into a mess pretty quickly.
Since I turned off checking every 5 minutes in OE, the problem seem to have
subsided.  Perhaps Microsoft will release a version of OE that solves these
issues, though I doubt it.  I think everything they release is going to be
for OS X from now on.

Thanks for the suggestion.  Everyone who has trouble finding a decent GUI
IMAP client should check out Mulberry.

-- 
Mark Edwards
Engineer
Mr. Toad's
San Francisco

---

From: Mark Edwards <[email-masked]>
Date: Wed, 17 Oct 2001 17:45:39 -0700

I was installing uw-imap from the ports collection that comes with the
latest version of FreeBSD (4.4) and I got the following warning message:

This port has been proven exploitable at several occasions (read up CERT
advisories), leaving systems subject to remote root access.  Before
installing this package, please consider: Whether you really want to use
this software. The integrity of your system may be at risk.

I have read the comments on this in the FAQ.

Given that the build that is in the FreeBSD ports collection is
imap-2001.BETA.SNAP-0106191041.tar.Z
I'm wondering ...

- What's the validity of this particular claim?

- Should I use a newer build of the software?  In general I'm trying to use
stuff from the ports collection, as I'm assuming that represents a certain
amount of testing from the FreeBSD community.

Thanks.
 
-- 
Mark Edwards
Engineer
Mr. Toad's
San Francisco

---

From: Mark Crispin <[email-masked]>
Date: Wed, 17 Oct 2001 17:59:23 -0700 (PDT)

The simple answer is that it's nonsense.  This type of non-professionalism on
the part of certain individuals in the FreeBSD community makes it difficult to
take FreeBSD seriously.

Yes, there were root-compromise bugs in past versions of imapd.  But that was
quite some time, and several versions, ago.  Certain other widely-used servers
distributed with FreeBSD have had many more CERT advisories.  I would prefer
not to speculate as to why FreeBSD singled out imapd.

imap-2001.BETA.SNAP-0106191041.tar.Z is a development snapshot from June 19,
2001 (at 10:41AM Pacific time).  We do not recommend that you run old
development snapshots, particularly ones from several months ago.

We recommend that you run either the final version of imap-2001:
	ftp://ftp.cac.washington.edu/mail/old/imap-2001.FINAL.tar.Z
or the current imap-2001a release candidate:
	ftp://ftp.cac.washington.edu/mail/imap.tar.Z
imap-2001a is a bugfix update to imap-2001, with one trivial new feature that
does not affect imapd.

---

From: Mark Edwards <[email-masked]>
Date: Fri, 19 Oct 2001 12:11:45 -0700

I've got imapd running along nicely now on FreeBSD 4.4, using /var/mail/ 
(unix format I suppose).

Two questions:

1) I was going to switch over to mbx format for the INBOX, but I can't get 
the tools to compile.  I get the message:

make: don't know how to make ../imap-2001a.RELEASE-CANDIDATE.1/c-
client/mail.h. Stop

I know the path to c-client is correct, because if I change it I get a 
different message about the path being wrong.

2) Do I need to use mbx format for imap access?  I had plenty of trouble 
using Outlook Express to access imap on a different server until I switched 
to mbx format.  If mbx is as necessary as it seems, why is the process of 
implementing it with imapd so obscure?  Why doesn't imapd create mbx format 
mailboxes by default?

Thanks.

--
Mark Edwards
San Francisco, CA
[email-masked]

---

From: Mark Crispin <[email-masked]>
Date: Fri, 19 Oct 2001 12:19:17 -0700 (PDT)

> make: don't know how to make ../imap-2001a.RELEASE-CANDIDATE.1/c-

Have you done a build inside the imap-2001a.RELEASE-CANDIDATE.1 directory yet?
You have to do that first.

> to mbx format.

One of the earmarks of a shoddy IMAP client is the assumption that it is
always "alright" to have multiple servers accessing the same mailbox
simultaneously.  Thus, instead of thinking how to do an operation in a session
that already has the mailbox open, it is "alright" to take the easy way out
and just spawn another session.  After all, why bother doing the right thing
when it's faster to write a kludge.

Well, it's not alright.

OE is the best of Microsoft's clients.  There are worse horror stories with
Outlook and especially Entourage.  Unfortunately, Microsoft does better at
writing IMAP clients than many of its competitors, so don't take this as a
Microsoft bash.

I wish that I could understand why it is so hard to write a good IMAP client.

> If mbx is as necessary as it seems, why is the process of

Not everybody wants a mail server that unilaterally changes mailbox formats to
something unique and supported by no other program, that's why.

The decision to switch to mbx format, or any other one-of-a-kind format such
as Cyrus, has to be made soberly and with careful consideration of the
consequences of incompatibility with the past 30 years of UNIX tools.

---

From: del <[email-masked]>
Date: Mon, 22 Oct 2001 01:22:25 -0400

Greetings,

I have compiled imap-2001a.DEV.SNAP-0110031901 on a Sun UltraSPARC 1 with 
gcc 3.01 with SSL support and I have NOT been able to get it to work with 
either Pine 4.10, Eudora 5.1 and Netscape Messenger 4.78.

When I tried using mtest specifying the {server}mailbox here is the response:::

bash-2.03# mtest
MTest -- C client test program
Debug protocol (y/n)?y
Mailbox ('?' for help): ?
Enter INBOX, mailbox name, or IMAP mailbox as {host}mailbox
Known local mailboxes:
  NIL INBOX, no inferiors
or just hit return to quit
Mailbox ('?' for help): {mx1.byteme.com}del
%rsh to IMAP server timed out
[Trying IP address [123.347.189.123]
l
à
%Missing IMAP reply key: l
à
* NO [CLOSED] IMAP connection broken (server response)
?[CLOSED] IMAP connection broken (server response)
Mailbox ('?' for help): ?
Enter INBOX, mailbox name, or IMAP mailbox as {host}mailbox
Known local mailboxes:
  NIL INBOX, no inferiors
or just hit return to quit
Mailbox ('?' for help): {mx1.byteme.com}del
%rsh to IMAP server timed out
[Trying IP address [123.347.189.123]
l
à
%Missing IMAP reply key: l
à
* NO [CLOSED] IMAP connection broken (server response)
?[CLOSED] IMAP connection broken (server response)
Mailbox ('?' for help):

when I was trying to see what was going on here is what i got::

bash-2.03# ps -ef | grep -i imapd
     root  5582     1  0 00:19:28 ?        0:00 /usr/bin/rsh mx1.byteme.com 
-l root exec /etc/rimapd
bash-2.03# ps -ef | grep -i imapd
     root  5582     1  0 00:19:28 ?        0:00 /usr/bin/rsh mx1.byteme.com 
-l root exec /etc/rimapd
bash-2.03# ps -ef | grep -i imapd
     root  5582     1  0 00:19:28 ?        0:00 /usr/bin/rsh mx1.byteme.com 
-l root exec /etc/rimapd

What is going on..? and what is it tying to call (/etc/rimapd)...????

of course i have made the appropriate changes to /etc/services and to 
/etc/inetd.conf

any help would be appreciated.

Donnie

---

From: Mark Crispin <[email-masked]>
Date: Sun, 21 Oct 2001 23:10:27 -0700 (PDT)

It would help enormously in analyzing your problem if you did not put in fake
domain names and equally fake IP addresses.  Fake data just wastes everybody's
time.

Your rimapd question is covered in the documentation included with the
software.  The included documentation also discusses what constitutes a
mailbox and the components of a mailbox name; a mailbox name on a newly
installed IMAP server is very unlikely to be your user name.

As matters stand, the only things that I can determine from your report are:
(1) something is badly wrong with how you have installed the software, (2) you
do not seem to have read much of the documentation and/or are very confused by
what you read.  The former is probably a consequence of the latter.  However,
although I've seen many ways that confused users get into trouble, the
symptoms you report are new to me; I don't have a clue of what you did wrong.

If you want a different reference than the included documentation, I recommend
that you buy a copy of "Managing IMAP", by Dianna Mullet & Kevin Mullet,
published by O'Reilly, ISBN 0-596-00012-X.  You may find that a bit easier to
follow.

There isn't very much else that can be done to help you.  Either you need to
read the documentation, or you need to be more forthcoming with information
necessary to investigate your problem (such as the real name of the IMAP
server system and/or its real IP address).

---

From: Rich Ramos <[email-masked]>
Date: Tue, 30 Oct 2001 22:37:53 -0600

I have been using Mulberry for over a year now (after using Netscape, 
Outlook Express and Eudora) and there is no comparison.  If you are in a 
Mac OS environment (also works on Linux, Solaris and Windows) it is hands 
down the best client out there.  Highly recommended.

By the way, I like the multiple window thing.  But if you don't, according 
to the main man at Cyrusoft (Cyrus Daboo) the next version coming out 
(version 3.0 I believe) will have the single window view.

-Rich

--- Original ---
From: Mark Edwards <[email-masked]>
To: Sebastian Hagedorn <[email-masked]>
CC: [email-masked]
Date: 10/16/01 4:14 PM -0700
Subject: Re: imapd + Outlook =

Mulberry is indeed quite a nice email client, feature-wise.  The only
thing I don't like about it is that its multiple-windows, so every
message and every mailbox is a new window.  If Mulberry had the option to
work in a single window with panes, it would be everything I need.

Unfortunately, the multiple window thing turns into a mess pretty quickly.
Since I turned off checking every 5 minutes in OE, the problem seem to
have subsided.  Perhaps Microsoft will release a version of OE that
solves these issues, though I doubt it.  I think everything they release
is going to be for OS X from now on.

on 10/12/01 10:52 AM, Sebastian Hagedorn at [email-masked]
wrote:

> Cyrusoft (www.cyrusoft.com). It's actually the only GUI mailer I know
> that gets IMAP right. The only disadvantages are that it's not free (but
> there is a demo version) and that the UI is not very pretty. OE
> definitely looks nicer...

-- 
Mark Edwards
Engineer
Mr. Toad's
San Francisco

---

From: Matthew Weigel <[email-masked]>
Date: Mon, 05 Nov 2001 22:10:46 -0500

> I've wondered about that, but the source wasn't available anymore
> last time I looked. I'm not sure if I'd be able to make the
> necessary fixes for it to compile under OS X, but I might give it a
> shot...

*whew* sorry for replying nearly a month after this whole thread is dead.

The trick is not 'porting to OS X,' but 'porting to OpenStep.'  The
NeXTStep 3.3 binary *runs* under 4.2, as I recall, but does not build,
because of the changes that went into the opening of the OpenStep class
library.

Once it builds under OpenStep, it should also be fairly straightforward
to build it under GNUStep and MacOS X (since it doesn't use any of the
more exotic features of DPS like NSBezierPath or the PostScript
functions).

I gave it a shot, but the 3.3->4.2 conversion documentation was pretty
poor, and I am fairly new to the OpenStep API.  I still want to return
to it at some point, since I've got OpenStep and OS X running here,
but I'm drowning in projects already.  I made a few posts to one of
the comp.sys.next.* (programmer? -probably) newsgroups awhile back,
and I think someone else was working on porting another project.

If you're interested in giving it a try, the conversion scripts may run
OK under OS X, and most of the walkthrough should still apply as well;
I can dig around my NeXT for the files.
-- 
 Matthew Weigel
 Research Systems Programmer
 [email-masked]

---

From: Sebastian Hagedorn <[email-masked]>
Date: Sat, 10 Nov 2001 13:07:55 +0100

-- Matthew Weigel <[email-masked]> is rumored to 
have mumbled on Montag, 5. November 2001 22:10 Uhr -0500 regarding Re: 

> *whew* sorry for replying nearly a month after this whole thread is dead.

No problem, I haven't yet spent much time on this...

> because of the changes that went into the opening of the OpenStep class

And OpenStep 4.2 projects don't build under OS X, or do they?

> more exotic features of DPS like NSBezierPath or the PostScript

Really? The main issue right now seems to be the different .nib-format.

> I can dig around my NeXT for the files.

Where would I find the conversion scripts? I'm curious about this, although 
I'm pretty sure I won't be able to do this on my own.
--
Sebastian Hagedorn
Ehrenfeldgürtel 156, 50823 Köln, Germany
http://www.spinfo.uni-koeln.de/~hgd/

Winter is coming.

---

From: Matthew Weigel <[email-masked]>
Date: Sat, 10 Nov 2001 18:19:20 -0500

> > NeXTStep 3.3 binary *runs* under 4.2, as I recall, but does not
> > build, because of the changes that went into the opening of the
> > OpenStep class library.
> 

Actually, I was under the impression that they did, maybe with a
little of futzing.  Certainly I've seen (small) projects that made the
leap in a single bound.

> Really? The main issue right now seems to be the different .nib-format.

One of the NeXTStep->OpenStep steps is .nib conversion, and OS X uses
the OpenStep .nib-format.  I just opened one of the .nibs from 4.2's
Edit.app on my iBook, to make sure.  The menu bar is a little 'wrong' -
it doesn't follow OS X interface guidelines - but it's there.

> Where would I find the conversion scripts? I'm curious about this,
> although I'm pretty sure I won't be able to do this on my own.

Probably from someone with OpenStep 4.2, such as myself ;)
-- 
 Matthew Weigel
 Research Systems Programmer
 [email-masked]

---

From: Mark Edwards <[email-masked]>
Date: Mon, 26 Nov 2001 20:00:50 -0800

Can anyone point me in the right direction to build imapd with SSL support
on FreeBSD 4.4?  OpenSSL is included with the OS by default, and in fact I
am using it with Webmin.  However, neither of the directories mentioned in
the SSLBUILD doc exist on my server:

/usr/local/ssl
/usr/local/ssl/include/openssl

They're just not there.  Can someone give me a hint?

Thanks.

-- 
Mark Edwards
Engineer
Mr. Toad's
San Francisco

---

From: Calvin Hendryx-Parker <[email-masked]>
Date: Mon, 26 Nov 2001 21:29:54 -0800

I had the same problem and ended up just changing the Makefile in the 
root like this:

SSLTYPE=unix

and then in the Makefile under src/osdep/unix:
SSLTYPE=unix

SSLDIR=/usr
SSLCERTS=$(SSLDIR)/local/certs
SSLINCLUDE=$(SSLDIR)/include
SSLLIB=$(SSLDIR)/lib

Since OpenSSL is now a part of the FreeBSD 4.4 install it is installed 
in the /usr bit of the system instead of under /usr/local/ like if you 
had instlled it from ports.  I then did the standard make bsf and it all 
seemed to compile up just fine for me.  I'm sure there is a way to do it 
all from the Makefile in the root, but this was pretty simple to change.

Calvin

-- 
Six Feet Up (TM)
"You put your feet up. We put your site up."
Refer a friend. Get $10.
http://www.sixfeetup.com

---

From: Mark Edwards <[email-masked]>
Date: Fri, 30 Nov 2001 14:54:42 -0800

Thanks, that got it working.  Now here's the hard question...

Has anyone managed to get uw-imap to compile with SSL under any version of
Mac OS X?  It seems to have OpenSSL, but I can't find the right directories,
specifically the include directory.

Anyone?

-- 
Mark Edwards
Engineer
Mr. Toad's
San Francisco

---

From: Sebastian Hagedorn <[email-masked]>
Date: Sat, 01 Dec 2001 12:59:23 +0100

-- Mark Edwards <[email-masked]> is rumored to have mumbled on Freitag, 
30. November 2001 14:54 Uhr -0800 regarding Re: imapd + Outlook =:

> Mac OS X?  It seems to have OpenSSL, but I can't find the right
> directories, specifically the include directory.

Hmm, you seem to be right, the header files aren't installed. The other 
parts of OpenSSL are here:
/System/Library/OpenSSL

Greetings, Sebastian

Winter is coming.

---

From: Mark Edwards <[email-masked]>
Date: Fri, 21 Dec 2001 16:46:51 -0800

One of my INBOX files bit the dust today, I think courtesy of Outloook
Express.

Here the is error I get when trying to use the file:

SELECT failed: Unable to find CRLF at 2827154 in 64 bytes, text: .

Does anyone know what can be done to resurrect it?  The info still appears
to be intact, but I get errors when trying to access it via a client, or
trying to use

mbxcopy INBOX #driver.mbx:backup

Help!

-- 
Mark Edwards
Engineer
Mr. Toad's
San Francisco

---

From: Mark Crispin <[email-masked]>
Date: Fri, 21 Dec 2001 16:53:08 -0800 (PST)

> One of my INBOX files bit the dust today, I think courtesy of Outloook

Outlook Express or no Outlook Express, it still isn't supposed to happen.

> Does anyone know what can be done to resurrect it?

Here's the FAQ topic/answer for this problem:

Q: What do the error messages:
     Unable to read internal header at ...
     Unable to find CRLF at ...
     Unable to parse internal header at ...
     Unable to parse message date at ...
     Unable to parse message flags at ...
     Unable to parse message UID at ...
     Unable to parse message size at ...
     Last message (at ... ) runs past end of file ...
   mean?  I am using mbx format.
A: The mbx-format mailbox is corrupted and needs to be repaired.
   You should make an effort to find out why the corruption happened.  Was
    there an obvious system problem (crash or disk failure)?  Did the user
    accidentally access the file via NFS?  Mailboxes don't get corrupted by
    themselves; something caused the problem.
   Some people have developed automated scripts, but if you're comfortable
    using emacs it's pretty easy to fix it manually.  DON'T USE vi OR ANY
    OTHER EDITOR UNLESS YOU ARE CERTAIN THAT EDITOR CAN HANDLE BINARY!!!
   If you are not comfortable with emacs, or if the file is too large to read
    with emacs, see the "step-by-step" technique later on for another way of
    doing it.
   After the word "at" in the error message is the byte position it got to
    when it got unhappy with the file, e.g. if you see:
     Unable to parse internal header at 43921: ne bombastic blurdybloop
    The problem occurs at the 43,931 byte in the file.  That's the point you
    need to fix.
  c-client is expecting an internal header at that byte number, looking
   something like:
     6-Jan-1998 17:42:24 -0800,1045;000000100001-00000001
   The format of this internal line is:
    dd-mmm-yyyy hh:mm:ss +zzzz,ssss;ffffffffFFFF-UUUUUUUU
  The only thing that is variable is the "ssss" field, it can be as many
   digits as needed.  All other fields (inluding the "dd") are fixed width.
  So, the easiest thing to do is to look forward in the file for the next
   internal header, and delete everything from the error point to that
   internal header.
  Here's what to do if you want to be smarter and do a little bit more work.
   Generally, you're in the middle of a message, and there's nothing wrong
   with that message.  The problem happened in the *previous* message.
  So, search back to the previous internal header.  Now, remember that "ssss"
   field?  That's the size of that message.  Mark where you are in the file,
   move the cursor to the line after the internal header, and skip that many
   bytes ("ssss") forward.  If you're at the point of the error in the file,
   then that message is corrupt.  If you're at a different point, then perhaps
   the previous message is corrupt and has a too long size count that "ate"
   into this message.
  Basically, what you need to do is make sure that all those size counts are
   right, and that moving "ssss" bytes from the line after the internal header
   will land you at another internal header.
  Usually, once you know what you're looking at, it's pretty easy to work out
   the corruption, and the best remedial action.  I generally don't use repair
   scripts because I prefer the flexibility of manual repair.  Repair scripts
   will make the problem go away but may not always do the smartest/best
   salvage of the user's data.
  Here is a step-by-step technique for fixing corrupt mbx files that's a bit
   cruder than the procedure outlined above, but works for any size file.  In
   this example, we will suppose that the corrupt file is INBOX, the error
   message is "Unable to find CRLF at 132551754", and the size of the INBOX
   file is 132867870 bytes.
    (1) Rename the INBOX file to some other name, such as INBOX.bad.
    (2) Copy the first 132,551,754 bytes of INBOX.bad to another file, such
        as INBOX.new.
    (3) Extract the trailing 316,116 bytes (132867870-132551754) of INBOX.bad
        into another file, such as INBOX.tail.
    (4) You no longer need INBOX.bad.  Delete it.
   In other words, use the number from the "Unable to find CRLF at" as the
   point to split INBOX into two new files, INBOX.new and INBOX.tail.
    (5) Verify that you can open INBOX.new in IMAP or Pine.
    (6) The last message of INBOX.new is probably corrupted.  Copy it to
        another file, such as badmsg.1, then delete and expunge that last
        message from INBOX.new
    (7) Locate the first occurance of text in INBOX.tail which looks like an
        internal header, as described above.  Remove all the text which occurs
        prior to that point, and place it into another file, such as badmsg.2.
        Note that in the case of a single digit date, there is a leading space
        which must not be removed (e.g. " 6-Nov-2001" not "6-Nov-2001").
    (8) Append INBOX.tail to INBOX.new.
    (9) You no longer need INBOX.tail.  Delete it.
    (10) Verify that you can open INBOX.new in IMAP or Pine.
   You are now ready to reinstall INBOX.new as INBOX.  If you haven't
    received any new messages while repairing INBOX, just rename INBOX.new to
    INBOX.  Otherwise, be sure to copy the new messages from INBOX to
    INBOX.new before doing the rename.
   You now have INBOX, badmsg.1 and badmsg.2.  There may be some useful data
    in the two badmsg files that you might want to try salvaging; otherwise
    you can delete the badmsg files.

---

From: Mark Edwards <[email-masked]>
Date: Tue, 15 Jan 2002 01:51:39 -0800

Where do I find the proper procedure for installing the c-client libraries 
on a FreeBSD 4.4 system?  I can't find a list of which files to put where.
   If I've overlooked something totally obvious here, sorry.

Thanks!

--
Mark Edwards
Engineer
Mr. Toad's
San Francisco
[email-masked]