mailing list archives

meli community discussions

⚠️ if something does not work as intended when interracting with the mailing lists,
reach out Github mirror Gitea repo @epilys:matrix.org

E-mail headers
From: Johannes Berg <johannes@sipsolutions.net>
To: imap-protocol@u.washington.edu
Date: Fri, 08 Jun 2018 12:34:37 -0000
Message-ID: 1152175506.4995.51.camel@localhost permalink / raw / eml / mbox
Hi,

A lot of people seem to have a need for being notified as soon as
possible when mail arrives into one of their mail folders as opposed to
just using IDLE on a single one.

I just found draft-melnikov-lemonade-imap-events-00.txt which tries to
give some guide on how to create untagged responses during IDLE for
message store changes in other folders than the currently selected one.

However, I think that this is not enough. Currently, any server can
create such responses and clients must expect them and at least ignore
them. And the server need not send them, in which lies the problem.

Should this be of use to clients, then the server needs to announce to
the client that such multifolder notification is supported.

This can be made arbitrarily complex, ranging from announcing a new
ALLFOLDERNOTIFY capability that guarantees to the client that the server
will always send untagged STATUS responses whenever a mailbox status
changes (except for the one that the client is currently IDLE'ing in, if
any).

Somewhere in the middle of the complexity spectrum there's the option of
using listext to announce a new capability and define a new list option
which indicates which folders are notified for.

And on the upper end you can have a new command that enables/disables
the status updates for any folder, and a new list option indicating
which are selected for status updates (along, of course, with a new
capability telling clients that this is available).

The first option might be problematic since apparently some clients are
in violation of the rules and don't cope with untagged responses well.

In any case, I'm very much interested in having this capability of
notification across folders, but as pointed out it needs to be possible
for the client to tell that it will get such notification in order to
rely on it instead of polling the folders every few minutes.

johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 845 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20060706/e5d8c450/attachment.sig>
Reply
E-mail headers
From: hippie@uchicago.edu
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:37 -0000
Message-ID: 44ADDAD9.4040200@uchicago.edu permalink / raw / eml / mbox
Hi, my name is Jeff Lowe and I am trying to get imapd to run on a Mac OS 
X. I have been back and forth a couple of times and last thing I tried was
make clean
make oxp

And this is the output plus errors that I recieved:

Red_Faction:/Library/Webserver/Documents root# cd imap-2004g
Red_Faction:/Library/Webserver/Documents/imap-2004g root# make clean
Removing old processed sources and binaries...
sh -c 'rm -rf an ua OSTYPE SPECIALS c-client mtest imapd ipopd mailutil 
mlock dmail tmail || true'
cd tools;make clean
sh -c 'rm -f *.o uahelper || true'
c-67-175-166-218:/Library/Webserver/Documents/imap-2004g root# make oxp
make sslnopwd
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Building in full compliance with RFC 3501 security
+ requirements:
++ TLS/SSL encryption is supported
++ Unencrypted plaintext passwords are prohibited
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Applying an process to sources...
tools/an "ln -s" src/c-client c-client
tools/an "ln -s" src/ansilib c-client
tools/an "ln -s" src/charset c-client
tools/an "ln -s" src/osdep/unix c-client
tools/an "ln -s" src/mtest mtest
tools/an "ln -s" src/ipopd ipopd
tools/an "ln -s" src/imapd imapd
tools/an "ln -s" src/mailutil mailutil
tools/an "ln -s" src/mlock mlock
tools/an "ln -s" src/dmail dmail
tools/an "ln -s" src/tmail tmail
ln -s tools/an .
make build EXTRACFLAGS='' EXTRALDFLAGS='' EXTRADRIVERS='mbox' 
EXTRAAUTHENTICATORS='' PASSWDTYPE=std SSLTYPE=nopwd IP=4 
EXTRASPECIALS='' BUILDTYPE=osx \
IP=6 EXTRAAUTHENTICATORS=" gss" \
SPECIALS="SSLDIR=/System/Library/OpenSSL SSLINCLUDE=/usr/include/openssl 
SSLLIB=/usr/lib PAMLDFLAGS=-lpam" \
PASSWDTYPE=pam \
EXTRACFLAGS=" -DMAC_OSX_KLUDGE=1"
Building c-client for osx...
echo `cat SPECIALS`  > c-client/SPECIALS
cd c-client;make osx EXTRACFLAGS='-DMAC_OSX_KLUDGE=1'\
 EXTRALDFLAGS=''\
 EXTRADRIVERS='mbox'\
 EXTRAAUTHENTICATORS='gss'\
 PASSWDTYPE=pam SSLTYPE=nopwd IP=6\
 SSLDIR=/System/Library/OpenSSL SSLINCLUDE=/usr/include/openssl 
SSLLIB=/usr/lib PAMLDFLAGS=-lpam
make build EXTRACFLAGS='-DMAC_OSX_KLUDGE=1' EXTRALDFLAGS='' 
EXTRADRIVERS='mbox' EXTRAAUTHENTICATORS='gss' PASSWDTYPE=pam 
SSLTYPE=nopwd IP=6 `cat SPECIALS` OS=osx \
 CRXTYPE=nfs \
 SPOOLDIR=/var/spool MAILSPOOL=/var/mail \
 BASECFLAGS="-g -O -Wno-pointer-sign"
sh -c 'rm -rf auths.c crexcl.c nfstest.c linkage.[ch] siglocal.c 
osdep*.[ch] *.o ARCHIVE *FLAGS *TYPE c-client.a || true'
Once-only environment setup...
echo cc > CCTYPE
echo -g -O -Wno-pointer-sign '-DMAC_OSX_KLUDGE=1' > CFLAGS
echo -DCREATEPROTO=unixproto -DEMPTYPROTO=unixproto \
 -DMAILSPOOL=\"/var/mail\" \
 -DANONYMOUSHOME=\"/var/mail/anonymous\" \
 -DACTIVEFILE=\"/usr/lib/news/active\" -DNEWSSPOOL=\"/var/spool/news\" \
 -DRSHPATH=\"/usr/ucb/rsh\" -DLOCKPGM=\"/etc/mlock\" > OSCFLAGS
echo   > LDFLAGS
echo "ar rc c-client.a osdep.o mail.o misc.o newsrc.o smanager.o utf8.o 
siglocal.o dummy.o pseudo.o netmsg.o flstring.o fdstring.o rfc822.o 
nntp.o smtp.o imap4r1.o pop3.o unix.o mbx.o mmdf.o tenex.o mtx.o news.o 
phile.o mh.o mx.o;ranlib c-client.a" > ARCHIVE
echo osx > OSTYPE
./drivers mbox imap nntp pop3 mh mx mbx tenex mtx mmdf unix news phile dummy
./mkauths gss md5 pla log
echo -I/usr/local/include 
-DGSS_C_NT_HOSTBASED_SERVICE=gss_nt_service_name >> OSCFLAGS
sh -c '(test -f /usr/local/lib/libk5crypto.a) && echo -L/usr/local/lib 
-lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err || echo -L/usr/local/lib 
-lgssapi_krb5 -lkrb5 -lcrypto -lcom_err' >> LDFLAGS
echo "#include \"kerb_mit.c\"" >> auths.c
echo -DMD5ENABLE=\"/etc/cram-md5.pwd\" >> OSCFLAGS
ln -s os_osx.h osdep.h
ln -s os_osx.c osdepbas.c
ln -s log_std.c osdeplog.c
ln -s sig_bsd.c siglocal.c
ln -s crx_nfs.c crexcl.c
ln -s ip6_unix.c ip_unix.c
ln: ip_unix.c: File exists
make[3]: *** [onceenv] Error 1
make[2]: *** [osx] Error 2
make[1]: *** [OSTYPE] Error 2
make: *** [oxp] Error 2
Red_Faction:/Library/Webserver/Documents/imap-2004g root#

Does anyone know what that means or what I am doing wrong?
Thanks.
Reply
E-mail headers
From: johannes@sipsolutions.net
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:37 -0000
Message-ID: 1152273106.15068.44.camel@localhost permalink / raw / eml / mbox
Hi,

Alexey, for whatever stupid reason I forgot to CC you, if you aren't on
imap-protocol please see the original text here:
http://mailman1.u.washington.edu/pipermail/imap-protocol/2006-July/000228.html


I notice that I didn't really ask any question just posted a few
statements. I realise that p-imap is probably going to refer to this
draft for the in-band notification it wants, but I think this should be
usable even without all of p-imap.

I suggest to add something like I described (one of the options ranging
from low to high complexity) to this, and making p-imap refer only to
the part of this that clarifies the untagged responses. I'd be willing
to help with such a document once we can somehow get to a conclusion as
to what kind of complexity is wanted/needed.

What are other people's opinions on this? Do you think this is useful? A
waste of time? Is a whole new strategy better?

Thanks,
Johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 845 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20060707/14933251/attachment.sig>
Reply