Date: Thu, 26 Apr 2001 02:07:04 +0200 From: Anders Nordby <anders@fix.no> To: Doug Barton <DougB@DougBarton.net> Cc: jim@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, ports@FreeBSD.org Subject: Re: cvs commit: ports/mail/imap-uw Makefile distinfo pkg-message ports/mail/imap-uw/files patch-ac patch-ah patch-ai Message-ID: <20010426020704.A14512@totem.fix.no> In-Reply-To: <3AE6FBEF.188F7673@DougBarton.net>; from DougB@DougBarton.net on Wed, Apr 25, 2001 at 09:31:43AM -0700 References: <200104250543.f3P5hXc80256@freefall.freebsd.org> <20010425111050.B49519@guinness.osdn.com> <3AE6FBEF.188F7673@DougBarton.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 25, 2001 at 09:31:43AM -0700, Doug Barton wrote:
>> Is there any particular reason why this port is following the betas that
>> seem to change every other day and leave it broken instead of 2000c? I
>> don't use this port or even IMAP, I just noticed that people are always
>> complaining about it being broken on -ports. Just curious.
> I'm starting to think that we need an imap-uw-devel category for this, and
> that we should revert imap-uw to 2000c. I do use this port, and the last
> two snapshots have resulted in a problem where mail that I delete keeps
> coming back from the trash marked unread.
I was first notified of the problem with trash mail yesterday. You may
want to cut me some slack here. What client are you using? And what
exact versions of the port(s) did you have this problem with? Is it an
issue with 0104241750 (the latest version)? Reporting detailed
information is good (TM). Anyway, I can not reproduce this with
imap-uw+cclient 0104241750 and mozilla 0.8.1, Outlook Express
5.50.4522.1200 or Netscape 4.76. And, AFAIK there is no special Trash
folder for IMAP. Any folder (except INBOX) is like the other, it's just up
to the clients to use them as wanted. RFC 2683 (the only IMAP RFC even
mentioning "trash" that I can find) states:
"3.4.8. Creating Special-Use Mailboxes
It may seem at first that this is part of the namespace issue; it is
not, and is only indirectly related to it. A number of clients like
to create special-use mailboxes with particular names. Most
commonly, clients with a "trash folder" model of message deletion
want to create a mailbox with the name "Trash" or "Deleted". Some
clients want to create a "Drafts" mailbox, an "Outbox" mailbox, or a
"Sent Mail" mailbox. And so on. There are two major
interoperability problems with this practice:
1. different clients may use different names for mailboxes with
similar functions (such as "Trash" and "Deleted"), or may manage
the same mailboxes in different ways, causing problems if a user
switches between clients and
2. there is no guarantee that the server will allow the creation of
the desired mailbox.
The client developer is, therefore, well advised to consider
carefully the creation of any special-use mailboxes on the server,
and, further, the client must not require such mailbox creation -
that is, if you do decide to do this, you must handle gracefully the
failure of the CREATE command and behave reasonably when your
special-use mailboxes do not exist and can not be created.
In addition, the client developer should provide a convenient way for
the user to select the names for any special-use mailboxes, allowing
the user to make these names the same in all clients used and to put
them where the user wants them."
I do try to fix anything that is reported to me. The issues on these
ports since I started working on them has been, as far as I can
remember:
a) (fatal) missing distfiles. Has been an issue for these ports for a
long time. Permanently fixed through local master sites that I update
now.
b) missing info on pam session. The daemons were complaining about "No
modules loaded for "foo" service." Confusing for some. Fixed in
pkg-message.
c) missing imap-uw.cnf preventing "make cert" to work with the imap-uw
port. Forgotten by me and/or nsayer@freebsd.org. Fixed.
d) misleading info on pam session. My bad, I refered to pam_unix which
does not have session support at all. Fixed.
e) (fatal) troubles building imap-uw due to people not upgrading their
cclient installation while upgrading their imap-uw one. I've tried to
give feedback to those asking.
f) an alleged, insufficiently reported trash problem.
The ports have however gained PAM, SSL and DRAC support lately. SSL
support also for the Pine port. So I do not think these efforts have
been in vain. Latency on getting my updates commited have also
contributed greatly to the user problems/complaints here. And I've only
been maintainer of the ports for 9 days.
> The maintainer's logic for following the snaps is rooted in the dire
> warning on the ftp site that all previous versions of imap and cclient have
> bugs, however that is true of all software. :)
My logic goes more in the line of using what the UW imap developers
recommend and present as their main imap distribution. These days, that is
unfortunately a development snapshot. My plan is to move over to a
stable release once a new one is ready. I believe we should slow down on
updating to the latest snapshots though (or even temporarily stalling on a
_good_ snapshot), perhaps also revert to an older one if the latest does
not work well.
Info about older versus newer versions, from the author(s):
http://www.washington.edu/imap/listarch/current/msg00325.html
http://www.washington.edu/imap/listarch/current/msg00399.html
ftp://ftp.cac.washington.edu/imap/imap-README (which you mentioned)
> Anders, what do you think about splitting out -devel versions of imap-uw
> and cclient?
Not necessary in my opinion, the ports have gotten quite stable. It
would also be a more demanding effort. Maintainers for these ports
hasn't really been growing on trees lately, and I would not support the
direction of splitting out -devel versions. Meaning someone else would
have to maintain both devel and "stable" versions of the ports then.
Regards,
--
Anders.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010426020704.A14512>