Menu
▾
▴
fetchmail-devel
|
From: Sunil S. <sh...@bo...> - 2005-08-29 12:38:04
|
Hi, Quoting from Matthias Andree's mail on Sun, Aug 21, 2005 at 11:12:45PM +0200: > Rob MacGregor <rob...@gm...> writes: > > > On 21/08/05, David Laight <dav...@l8...> wrote: > >> > >> But, IIRC, the code got broken at some point. > >> ISTR patching my local copy. > > > > Then report the bug to the fetchmail-devel list, detailing what you > > believe is broken. > > No need, I found a similar report (IIRC in bugs.debian.org) and > investigated. The upcoming fetchmail release and IIRC the latest -pre > release from BerliOS.de also will delete oversized messages if NOT run > in daemon mode - be sure to use the --flush option. The 'flush' option is very dangerous as it can even delete mails which have been read by another email client. In particular, if one has the habit of checking a remote mailbox through an interactive email client, new mails can get marked as read. Then, when fetchmail polls that mailbox, it will think that those mails have already been downloaded and just delete those mails due to the 'flush' option. Here, I am assuming a setup like: poll server protocol imap # or "pop3 no uidl" fetchall limit 1000000 flush # this has been put to delete oversized only Without the 'flush' option, mails which are read through another email client also get downloaded without problems. With the 'flush' option, such apparently read mails get deleted. I had created a patch which adds another option to fetchmail. The old patch (against 6.2.4) along with some discussion can be found at: <http://lists.ccil.org/pipermail/fetchmail-friends/2003-October/008017.html>. Eric was against adding new options, hence that patch was not accepted then. If the idea of the above patch is acceptable, I can recreate it for the latest fetchmail. In any case, it would be better if the 'flush' option is not overloaded to delete oversized mails. -- Sunil Shetye. |
|
From: Sunil S. <sh...@bo...> - 2005-08-31 08:49:12
|
Quoting from Matthias Andree's mail on Wed, Aug 31, 2005 at 01:04:04AM +0200: > Current wording, in roff man(7) format: > > .TP > .B \-F | \-\-flush > POP3/IMAP only. This is a dangerous option and can cause mail loss when > used improperly. It deletes old (seen) messages from the mailserver > before retrieving new messages. Warning: This can cause mail loss if > you check your mail with other clients than fetchmail, and cause > fetchmail to delete a message it had never fetched before. Similarly, if > your local MTA hangs and fetchmail is aborted, the next time you run > fetchmail, it will delete mail that was never delivered to you. You > should probably not use this option in your configuration file. > What you probably want is the default setting: if you don't specify > '-k', then fetchmail will automatically delete messages after successful > delivery. This option does not work with ETRN and ODMR. Rather well put. However, this is not the only thing I am after. Please check the revision r4173 which attempts to fix Debian Bug #212240. This fix actually encourages the use of the 'flush' option. It is contradictory to say that $ fetchmail --flush is dangerous, but $ fetchmail --daemon 0 --limit 100000 --flush is ok. In both cases, mails read through another email client are going to get deleted. Thus, both the above usages of 'flush' are eqaually dangerous. What I want us to do: - reverse the commit in r4173: this will break the link between 'flush' and 'limit'. - add a FAQ item which tells that 'flush' option cannot be overloaded to delete oversized mails as 'flush' is dangerous (with or without the overloading) when one is using another email client to check one's mailbox and that 'flush' should be immediately removed from the rc file. - treat Debian Bug #212240 as a new feature request, not a bug. - decide whether this request should should be implemented before 6.3.0. In case, it is decided to implement now: - add a new option which will delete only oversized mails. The patch I had mentioned earlier did exactly that. - update the FAQ item mentioned above. -- Sunil Shetye. |
|
From: Matthias A. <mat...@gm...> - 2005-09-01 10:07:31
|
Sunil Shetye <sh...@bo...> writes: > Rather well put. However, this is not the only thing I am after. > > Please check the revision r4173 which attempts to fix Debian Bug > #212240. This fix actually encourages the use of the 'flush' > option. > > It is contradictory to say that > > $ fetchmail --flush > > is dangerous, but > > $ fetchmail --daemon 0 --limit 100000 --flush > > is ok. In both cases, mails read through another email client are > going to get deleted. Thus, both the above usages of 'flush' are > eqaually dangerous. > > What I want us to do: > > - reverse the commit in r4173: this will break the link between > 'flush' and 'limit'. > > - add a FAQ item which tells that 'flush' option cannot be overloaded > to delete oversized mails as 'flush' is dangerous (with or without > the overloading) when one is using another email client to check > one's mailbox and that 'flush' should be immediately removed from > the rc file. > > - treat Debian Bug #212240 as a new feature request, not a bug. > > - decide whether this request should should be implemented before > 6.3.0. > In case, it is decided to implement now: > > - add a new option which will delete only oversized mails. The patch I > had mentioned earlier did exactly that. > - update the FAQ item mentioned above. Thinking about the options (yet another would be to ignore --flush for all configurations except POP3 UIDL), all are more or less ugly, even a flushoversized option or however you called it in your patch (haven't had time yet to look at it). Some people may want to delete oversized messages depending on mailbox size, some depending on age... -- Matthias Andree |
|
From: Matthias A. <mat...@gm...> - 2005-09-20 02:21:50
|
On Mon, 19 Sep 2005, Yves Boisjoly wrote:
> fetchmail: POP3< +OK Microsoft Exchange Server 2003 POP3 server version 6.5.7226.0 (<the_server>) ready.
> fetchmail: POP3> AUTH MSN
> fetchmail: POP3< -ERR The specified authentication package is not supported.
Please try this patch: (Note you need to have flex or lex installed so
that the configuration parser can be rebuilt.)
Index: pop3.c
===================================================================
--- pop3.c (revision 4284)
+++ pop3.c (working copy)
@@ -69,12 +69,13 @@
* Much source (ntlm.h, smb*.c smb*.h) was borrowed from Samba.
*/
-static int do_pop3_ntlm(int sock, struct query *ctl)
+static int do_pop3_ntlm(int sock, struct query *ctl,
+ int msn_instead /** if true, send AUTH MSN, else send AUTH NTLM */)
{
char msgbuf[2048];
int result,len;
- gen_send(sock, "AUTH MSN");
+ gen_send(sock, msn_instead ? "AUTH MSN" : "AUTH NTLM");
if ((result = gen_recv(sock, msgbuf, sizeof msgbuf)))
return result;
@@ -318,25 +319,20 @@
if (!(ctl->server.sdps) && MULTIDROP(ctl) && strstr(greeting, "demon."))
ctl->server.sdps = TRUE;
#endif /* SDPS_ENABLE */
+
#ifdef NTLM_ENABLE
- /* MSN servers require the use of NTLM (MSN) authentication */
- if (!strcasecmp(ctl->server.pollname, "pop3.email.msn.com") ||
- ctl->server.authenticate == A_NTLM)
- {
- if (!do_pop3_ntlm(sock, ctl))
- {
- return(PS_SUCCESS);
- }
- else
- {
- return(PS_AUTHFAIL);
- }
- }
+ /* MSN servers require the use of NTLM (MSN) authentication */
+ if (!strcasecmp(ctl->server.pollname, "pop3.email.msn.com") ||
+ ctl->server.authenticate == A_MSN)
+ return (do_pop3_ntlm(sock, ctl, 1) == 0) ? PS_SUCCESS : PS_AUTHFAIL;
+ if (ctl->server.authenticate == A_NTLM)
+ return (do_pop3_ntlm(sock, ctl, 0) == 0) ? PS_SUCCESS : PS_AUTHFAIL;
#endif
switch (ctl->server.protocol) {
case P_POP3:
#ifdef RPA_ENABLE
+ /* XXX FIXME: AUTH probing (RFC1734) should become global */
/* CompuServe POP3 Servers as of 990730 want AUTH first for RPA */
if (strstr(ctl->remotename, "@compuserve.com"))
{
Index: conf.c
===================================================================
--- conf.c (revision 4289)
+++ conf.c (working copy)
@@ -284,6 +284,8 @@
stringdump("auth", "ssh");
else if (ctl->server.authenticate == A_OTP)
stringdump("auth", "otp");
+ else if (ctl->server.authenticate == A_MSN)
+ stringdump("auth", "msn");
#ifdef HAVE_RES_SEARCH
booldump("dns", ctl->server.dns);
Index: NEWS
===================================================================
--- NEWS (revision 4296)
+++ NEWS (working copy)
@@ -197,6 +197,8 @@
Bug#212240. Sunil Shetye. (MA)
* Fix MacOS X compilation failures in sink.c (ru_*time has incomplete type).
Berlios Bug #4725. Matthias Andree.
+* Fix "auth ntlm" to send AUTH NTLM (rather than AUTH MSN). Add "auth msn"
+ officially. Matthias Andree
# INTERNAL CHANGES
* Switched to automake. Matthias Andree.
Index: fetchmail.man
===================================================================
--- fetchmail.man (revision 4292)
+++ fetchmail.man (working copy)
@@ -663,19 +663,21 @@
AUTHENTICATION below for details). The possible values are \fBany\fR,
\&\fBpassword\fR, \fBkerberos_v5\fR, \fBkerberos\fR (or, for
excruciating exactness, \fBkerberos_v4\fR), \fBgssapi\fR,
-\fBcram-md5\fR, \fBotp\fR, \fBntlm\fR, and \fBssh\fR. When \fBany\fR (the
-default) is specified, fetchmail tries first methods that don't
-require a password (GSSAPI, KERBEROS_IV); then it looks for methods
-that mask your password (CRAM-MD5, X-OTP, NTLM); and only if the server
-doesn't support any of those will it ship your password en clair.
+\fBcram-md5\fR, \fBotp\fR, \fBntlm\fR, \fBmsn\fR and \fBssh\fR. When
+\fBany\fR (the default) is specified, fetchmail tries first methods that
+don't require a password (GSSAPI, KERBEROS\ IV, KERBEROS\ 5); then it
+looks for methods that mask your password (CRAM-MD5, X-OTP - note that
+NTLM and MSN are not autoprobed); and only if the
+server doesn't support any of those will it ship your password en clair.
Other values may be used to force various authentication methods
(\fBssh\fR suppresses authentication). Any value other than
-\&\fBpassword\fR, \fBcram-md5\fR, \fBntlm\fR or \fBotp\fR suppresses fetchmail's
-normal inquiry for a password. Specify \fBssh\fR when you are using
-an end-to-end secure connection such as an ssh tunnel; specify
-\fBgssapi\fR or \fBkerberos_v4\fR if you are using a protocol variant
-that employs GSSAPI or K4. Choosing KPOP protocol automatically
-selects Kerberos authentication. This option does not work with ETRN.
+\&\fBpassword\fR, \fBcram-md5\fR, \fBntlm\fR, \fBmsn\fR or \fBotp\fR
+suppresses fetchmail's normal inquiry for a password. Specify \fBssh\fR
+when you are using an end-to-end secure connection such as an ssh
+tunnel; specify \fBgssapi\fR or \fBkerberos_v4\fR if you are using a
+protocol variant that employs GSSAPI or K4. Choosing KPOP protocol
+automatically selects Kerberos authentication. This option does not
+work with ETRN.
.SS Miscellaneous Options
.TP
.B \-f <pathname> | \-\-fetchmailrc <pathname>
Index: fetchmail.c
===================================================================
--- fetchmail.c (revision 4289)
+++ fetchmail.c (working copy)
@@ -1536,6 +1536,9 @@
case A_PASSWORD:
printf(GT_(" Password authentication will be forced.\n"));
break;
+ case A_MSN:
+ printf(GT_(" MSN authentication will be forced.\n"));
+ break;
case A_NTLM:
printf(GT_(" NTLM authentication will be forced.\n"));
break;
Index: fetchmail.h
===================================================================
--- fetchmail.h (revision 4289)
+++ fetchmail.h (working copy)
@@ -70,9 +70,17 @@
#define A_KERBEROS_V5 6 /* authenticate w/ Kerberos V5 */
#define A_GSSAPI 7 /* authenticate with GSSAPI */
#define A_SSH 8 /* authentication at session level */
+#define A_MSN 9 /* same as NTLM with keyword MSN */
-/* some protocols (KERBEROS, GSSAPI, SSH) don't require a password */
-#define NO_PASSWORD(ctl) ((ctl)->server.authenticate > A_OTP || (ctl)->server.protocol == P_ETRN)
+/* some protocols or authentication types (KERBEROS, GSSAPI, SSH) don't
+ * require a password */
+#define NO_PASSWORD(ctl) \
+ ((ctl)->server.authenticate == A_OTP \
+ || (ctl)->server.authenticate == A_KERBEROS_V4 \
+ || (ctl)->server.authenticate == A_KERBEROS_V5 \
+ || (ctl)->server.authenticate == A_GSSAPI \
+ || (ctl)->server.authenticate == A_SSH \
+ || (ctl)->server.protocol == P_ETRN)
/*
* Definitions for buffer sizes. We get little help on setting maxima
Index: rcfile_l.l
===================================================================
--- rcfile_l.l (revision 4289)
+++ rcfile_l.l (working copy)
@@ -100,6 +100,7 @@
ssh { SETSTATE(0); yylval.proto = A_SSH; return AUTHTYPE;}
(otp|opie) { SETSTATE(0); yylval.proto = A_OTP; return AUTHTYPE;}
cram(-md5)? { SETSTATE(0); yylval.proto = A_CRAM_MD5; return AUTHTYPE;}
+msn { SETSTATE(0); yylval.proto = A_MSN; return AUTHTYPE;}
ntlm { SETSTATE(0); yylval.proto = A_NTLM; return AUTHTYPE;}
<AUTH>password { SETSTATE(0); yylval.proto = A_PASSWORD; return AUTHTYPE;}
timeout { return TIMEOUT;}
Index: options.c
===================================================================
--- options.c (revision 4289)
+++ options.c (working copy)
@@ -418,6 +418,8 @@
ctl->server.authenticate = A_GSSAPI;
else if (strcmp(optarg, "any") == 0)
ctl->server.authenticate = A_ANY;
+ else if (strcmp(optarg, "msn") == 0)
+ ctl->server.authenticate = A_MSN;
else {
fprintf(stderr,GT_("Invalid authentication `%s' specified.\n"), optarg);
errflag++;
--
Matthias Andree
|
|
From: Yves B. <yve...@cg...> - 2005-09-20 17:21:36
|
Hello Andree,
You confused me with this latest email...
Do you mean you whant me to delete every lines beginning with the minus sign
and add every lines with the plus sign or if there is a way to download such a
patch?
I tried to change the line 77 as per your first email. It fixed the ntlm
authentication excepted that now the server complain with a "bad user or
password" message. Same thing as when I tried to telnet the box and play with
it manually...
Yves
On Tue, 20 Sep 2005, Matthias Andree wrote:
MA >On Mon, 19 Sep 2005, Yves Boisjoly wrote:
MA >
MA >> fetchmail: POP3< +OK Microsoft Exchange Server 2003 POP3 server version 6.5.7226.0 (<the_server>) ready.
MA >> fetchmail: POP3> AUTH MSN
MA >> fetchmail: POP3< -ERR The specified authentication package is not supported.
MA >
MA >Please try this patch: (Note you need to have flex or lex installed so
MA >that the configuration parser can be rebuilt.)
MA >
MA >Index: pop3.c
MA >===================================================================
MA >--- pop3.c (revision 4284)
MA >+++ pop3.c (working copy)
MA >@@ -69,12 +69,13 @@
MA > * Much source (ntlm.h, smb*.c smb*.h) was borrowed from Samba.
MA > */
MA >
MA >-static int do_pop3_ntlm(int sock, struct query *ctl)
MA >+static int do_pop3_ntlm(int sock, struct query *ctl,
MA >+ int msn_instead /** if true, send AUTH MSN, else send AUTH NTLM */)
MA > {
MA > char msgbuf[2048];
MA > int result,len;
MA >
MA >- gen_send(sock, "AUTH MSN");
MA >+ gen_send(sock, msn_instead ? "AUTH MSN" : "AUTH NTLM");
MA >
MA > if ((result = gen_recv(sock, msgbuf, sizeof msgbuf)))
MA > return result;
MA >@@ -318,25 +319,20 @@
MA > if (!(ctl->server.sdps) && MULTIDROP(ctl) && strstr(greeting, "demon."))
MA > ctl->server.sdps = TRUE;
MA > #endif /* SDPS_ENABLE */
MA >+
MA > #ifdef NTLM_ENABLE
MA >- /* MSN servers require the use of NTLM (MSN) authentication */
MA >- if (!strcasecmp(ctl->server.pollname, "pop3.email.msn.com") ||
MA >- ctl->server.authenticate == A_NTLM)
MA >- {
MA >- if (!do_pop3_ntlm(sock, ctl))
MA >- {
MA >- return(PS_SUCCESS);
MA >- }
MA >- else
MA >- {
MA >- return(PS_AUTHFAIL);
MA >- }
MA >- }
MA >+ /* MSN servers require the use of NTLM (MSN) authentication */
MA >+ if (!strcasecmp(ctl->server.pollname, "pop3.email.msn.com") ||
MA >+ ctl->server.authenticate == A_MSN)
MA >+ return (do_pop3_ntlm(sock, ctl, 1) == 0) ? PS_SUCCESS : PS_AUTHFAIL;
MA >+ if (ctl->server.authenticate == A_NTLM)
MA >+ return (do_pop3_ntlm(sock, ctl, 0) == 0) ? PS_SUCCESS : PS_AUTHFAIL;
MA > #endif
MA >
MA > switch (ctl->server.protocol) {
MA > case P_POP3:
MA > #ifdef RPA_ENABLE
MA >+ /* XXX FIXME: AUTH probing (RFC1734) should become global */
MA > /* CompuServe POP3 Servers as of 990730 want AUTH first for RPA */
MA > if (strstr(ctl->remotename, "@compuserve.com"))
MA > {
MA >Index: conf.c
MA >===================================================================
MA >--- conf.c (revision 4289)
MA >+++ conf.c (working copy)
MA >@@ -284,6 +284,8 @@
MA > stringdump("auth", "ssh");
MA > else if (ctl->server.authenticate == A_OTP)
MA > stringdump("auth", "otp");
MA >+ else if (ctl->server.authenticate == A_MSN)
MA >+ stringdump("auth", "msn");
MA >
MA > #ifdef HAVE_RES_SEARCH
MA > booldump("dns", ctl->server.dns);
MA >Index: NEWS
MA >===================================================================
MA >--- NEWS (revision 4296)
MA >+++ NEWS (working copy)
MA >@@ -197,6 +197,8 @@
MA > Bug#212240. Sunil Shetye. (MA)
MA > * Fix MacOS X compilation failures in sink.c (ru_*time has incomplete type).
MA > Berlios Bug #4725. Matthias Andree.
MA >+* Fix "auth ntlm" to send AUTH NTLM (rather than AUTH MSN). Add "auth msn"
MA >+ officially. Matthias Andree
MA >
MA > # INTERNAL CHANGES
MA > * Switched to automake. Matthias Andree.
MA >Index: fetchmail.man
MA >===================================================================
MA >--- fetchmail.man (revision 4292)
MA >+++ fetchmail.man (working copy)
MA >@@ -663,19 +663,21 @@
MA > AUTHENTICATION below for details). The possible values are \fBany\fR,
MA > \&\fBpassword\fR, \fBkerberos_v5\fR, \fBkerberos\fR (or, for
MA > excruciating exactness, \fBkerberos_v4\fR), \fBgssapi\fR,
MA >-\fBcram-md5\fR, \fBotp\fR, \fBntlm\fR, and \fBssh\fR. When \fBany\fR (the
MA >-default) is specified, fetchmail tries first methods that don't
MA >-require a password (GSSAPI, KERBEROS_IV); then it looks for methods
MA >-that mask your password (CRAM-MD5, X-OTP, NTLM); and only if the server
MA >-doesn't support any of those will it ship your password en clair.
MA >+\fBcram-md5\fR, \fBotp\fR, \fBntlm\fR, \fBmsn\fR and \fBssh\fR. When
MA >+\fBany\fR (the default) is specified, fetchmail tries first methods that
MA >+don't require a password (GSSAPI, KERBEROS\ IV, KERBEROS\ 5); then it
MA >+looks for methods that mask your password (CRAM-MD5, X-OTP - note that
MA >+NTLM and MSN are not autoprobed); and only if the
MA >+server doesn't support any of those will it ship your password en clair.
MA > Other values may be used to force various authentication methods
MA > (\fBssh\fR suppresses authentication). Any value other than
MA >-\&\fBpassword\fR, \fBcram-md5\fR, \fBntlm\fR or \fBotp\fR suppresses fetchmail's
MA >-normal inquiry for a password. Specify \fBssh\fR when you are using
MA >-an end-to-end secure connection such as an ssh tunnel; specify
MA >-\fBgssapi\fR or \fBkerberos_v4\fR if you are using a protocol variant
MA >-that employs GSSAPI or K4. Choosing KPOP protocol automatically
MA >-selects Kerberos authentication. This option does not work with ETRN.
MA >+\&\fBpassword\fR, \fBcram-md5\fR, \fBntlm\fR, \fBmsn\fR or \fBotp\fR
MA >+suppresses fetchmail's normal inquiry for a password. Specify \fBssh\fR
MA >+when you are using an end-to-end secure connection such as an ssh
MA >+tunnel; specify \fBgssapi\fR or \fBkerberos_v4\fR if you are using a
MA >+protocol variant that employs GSSAPI or K4. Choosing KPOP protocol
MA >+automatically selects Kerberos authentication. This option does not
MA >+work with ETRN.
MA > .SS Miscellaneous Options
MA > .TP
MA > .B \-f <pathname> | \-\-fetchmailrc <pathname>
MA >Index: fetchmail.c
MA >===================================================================
MA >--- fetchmail.c (revision 4289)
MA >+++ fetchmail.c (working copy)
MA >@@ -1536,6 +1536,9 @@
MA > case A_PASSWORD:
MA > printf(GT_(" Password authentication will be forced.\n"));
MA > break;
MA >+ case A_MSN:
MA >+ printf(GT_(" MSN authentication will be forced.\n"));
MA >+ break;
MA > case A_NTLM:
MA > printf(GT_(" NTLM authentication will be forced.\n"));
MA > break;
MA >Index: fetchmail.h
MA >===================================================================
MA >--- fetchmail.h (revision 4289)
MA >+++ fetchmail.h (working copy)
MA >@@ -70,9 +70,17 @@
MA > #define A_KERBEROS_V5 6 /* authenticate w/ Kerberos V5 */
MA > #define A_GSSAPI 7 /* authenticate with GSSAPI */
MA > #define A_SSH 8 /* authentication at session level */
MA >+#define A_MSN 9 /* same as NTLM with keyword MSN */
MA >
MA >-/* some protocols (KERBEROS, GSSAPI, SSH) don't require a password */
MA >-#define NO_PASSWORD(ctl) ((ctl)->server.authenticate > A_OTP || (ctl)->server.protocol == P_ETRN)
MA >+/* some protocols or authentication types (KERBEROS, GSSAPI, SSH) don't
MA >+ * require a password */
MA >+#define NO_PASSWORD(ctl) \
MA >+ ((ctl)->server.authenticate == A_OTP \
MA >+ || (ctl)->server.authenticate == A_KERBEROS_V4 \
MA >+ || (ctl)->server.authenticate == A_KERBEROS_V5 \
MA >+ || (ctl)->server.authenticate == A_GSSAPI \
MA >+ || (ctl)->server.authenticate == A_SSH \
MA >+ || (ctl)->server.protocol == P_ETRN)
MA >
MA > /*
MA > * Definitions for buffer sizes. We get little help on setting maxima
MA >Index: rcfile_l.l
MA >===================================================================
MA >--- rcfile_l.l (revision 4289)
MA >+++ rcfile_l.l (working copy)
MA >@@ -100,6 +100,7 @@
MA > ssh { SETSTATE(0); yylval.proto = A_SSH; return AUTHTYPE;}
MA > (otp|opie) { SETSTATE(0); yylval.proto = A_OTP; return AUTHTYPE;}
MA > cram(-md5)? { SETSTATE(0); yylval.proto = A_CRAM_MD5; return AUTHTYPE;}
MA >+msn { SETSTATE(0); yylval.proto = A_MSN; return AUTHTYPE;}
MA > ntlm { SETSTATE(0); yylval.proto = A_NTLM; return AUTHTYPE;}
MA > <AUTH>password { SETSTATE(0); yylval.proto = A_PASSWORD; return AUTHTYPE;}
MA > timeout { return TIMEOUT;}
MA >Index: options.c
MA >===================================================================
MA >--- options.c (revision 4289)
MA >+++ options.c (working copy)
MA >@@ -418,6 +418,8 @@
MA > ctl->server.authenticate = A_GSSAPI;
MA > else if (strcmp(optarg, "any") == 0)
MA > ctl->server.authenticate = A_ANY;
MA >+ else if (strcmp(optarg, "msn") == 0)
MA >+ ctl->server.authenticate = A_MSN;
MA > else {
MA > fprintf(stderr,GT_("Invalid authentication `%s' specified.\n"), optarg);
MA > errflag++;
MA >
--
=================================
Yves Boisjoly
Administrateur IXOS/Ariba
CGI - services à BCE
1350, boul. René-Lévesque,
suite 800 bureau 8.446
Montréal, Québec, H3G 1T4
Téléphone : 514-415-3000 x5510
Urgences : 514-540-4672
Fax : 514-415-3987
yve...@cg...
---------------------------------
AVIS DE CONFIDENTIALITÉ :
Ce message peut contenir des renseignements confidentiels appartenant
exclusivement au Groupe CGI Inc. ou à ses filiales. Si vous n'êtes pas le
destinataire indiqué ou prévu dans ce message (ou responsable de livrer ce
message à la personne indiquée ou prévue) ou si vous pensez que ce message
vous a été adressé par erreur, vous ne pouvez pas utiliser ou reproduire ce
message, ni le livrer à quelqu'un d'autre. Dans ce cas, vous devez le détruire
et vous êtes prié d'avertir l'expéditeur en répondant au courriel.
CONFIDENTIALITY NOTICE:
Proprietary/Confidential Information belonging to CGI Group Inc. and its
affiliates may be contained in this message. If you are not a recipient
indicated or intended in this message or responsible for delivery of this
message to such person), or you think for any reason that this message may
have been addressed to you in error, you may not use or copy or deliver this
message to anyone else. In such case, you should destroy this message and are
asked to notify the sender by reply e-mail.
=================================
|
|
From: Rob M. <rob...@gm...> - 2005-09-22 15:50:35
|
On 20/09/05, Yves Boisjoly <yve...@cg...> wrote:
>
> Hello Andree,
>
> You confused me with this latest email...
>
> Do you mean you whant me to delete every lines beginning with the minus sign
> and add every lines with the plus sign or if there is a way to download such a
> patch?
Try the "patch" command :)
--
Please keep list traffic on the list.
Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche
|
|
From: Matthias A. <mat...@gm...> - 2005-08-30 10:09:23
|
Sunil Shetye <sh...@bo...> writes: >> No need, I found a similar report (IIRC in bugs.debian.org) and >> investigated. The upcoming fetchmail release and IIRC the latest -pre >> release from BerliOS.de also will delete oversized messages if NOT run >> in daemon mode - be sure to use the --flush option. > > The 'flush' option is very dangerous as it can even delete mails which > have been read by another email client. In particular, if one has the > habit of checking a remote mailbox through an interactive email > client, new mails can get marked as read. Then, when fetchmail polls > that mailbox, it will think that those mails have already been > downloaded and just delete those mails due to the 'flush' option. Nice to see you back, and to see you've found the new site. > Here, I am assuming a setup like: > > poll server > protocol imap # or "pop3 no uidl" > fetchall > limit 1000000 > flush # this has been put to delete oversized only > > Without the 'flush' option, mails which are read through another email > client also get downloaded without problems. With the 'flush' option, > such apparently read mails get deleted. Yup. There's also a difference between "flush" and "nokeep". I believe if it's not deliberate, then it's at least useful enough to warrant further documentation. > I had created a patch which adds another option to fetchmail. The old > patch (against 6.2.4) along with some discussion can be found at: > > <http://lists.ccil.org/pipermail/fetchmail-friends/2003-October/008017.html>. > > Eric was against adding new options, hence that patch was not accepted > then. If the idea of the above patch is acceptable, I can recreate it > for the latest fetchmail. In any case, it would be better if the > 'flush' option is not overloaded to delete oversized mails. Well, I have some plans for fetchmail, and I believe your option (as well as others) might fit in the medium term - not on short notice though. WRT release management, I hope to release 6.3.0 in early September, only trouble is I have zero feedback on the *RC stuff yet. Does it work for people? Does it fail? Do the recent IPv6 patches break anything? Anyways, with 6.3.0 out, I will open a 6.3.X side branch for bugfixes only, and continue development in the trunk. The most important change will be to switch fetchmail to client-side tracking which mail it has seen. POP3 LAST and IMAP \Seen flags will be removed and we'll no longer care about them. If fetchmail understands itself as mail transfer agent, this translates to "transport each message exactly once, and do it reliably". OK, we may sometimes transfer a message twice, but we must not skip or lose any message unless the user explicitly tells us to discard it. Perhaps this change already involves some database for the UIDs (perhaps SQLite3), and I plan to reuse your "one fetchids per server" patches at least in part, that you wrote two years ago. This would enable us to add a "delete after N days" sort of thing later that users have been longing for for so long. A sponsor is needed for this work however. (ESR's fetchmail version already deletes mail and has limited client-side tracking support ("POP3 UIDL"), so there is no reason why it would not delete mail after some days or as the mailbox grows too large.) Taking a step back from the blackboard, we may need to go less from offering fixed options with a small functionality, but offer fewer but more flexible options. Read: interfaces where users can hook up scripts/programs that decide which messages get deleted, perhaps in which order messages are fetched, and such. This is a long-term plan though. Some details at <http://fetchmail.berlios.de/design-notes.html>. -- Matthias Andree |
|
From: Sunil S. <sh...@bo...> - 2005-08-30 13:13:32
|
Quoting from Matthias Andree's mail on Tue, Aug 30, 2005 at 10:09:19AM +0200: > > Here, I am assuming a setup like: > > > > poll server > > protocol imap # or "pop3 no uidl" > > fetchall > > limit 1000000 > > flush # this has been put to delete oversized only > > > > Without the 'flush' option, mails which are read through another email > > client also get downloaded without problems. With the 'flush' option, > > such apparently read mails get deleted. > > Yup. There's also a difference between "flush" and "nokeep". I believe > if it's not deliberate, then it's at least useful enough to warrant > further documentation. I think there is some misunderstanding here. The change made in r4173 is reintroducing a bug which had been removed and encouraging users to use the 'flush' option without documenting that even mails under 'limit' can get lost permanently. The 'flush' option is dangerous because it can delete mails which have never been downloaded previously by fetchmail. The 'flush' option is supposed to delete previously downloaded mail. fetchmail thinks a mail has been previously downloaded if its \Seen flag is set. Thus, the 'flush' option will delete all \Seen mails. However, when a user uses another email client to check the users' remote mailbox, the \Seen flag gets set here too. In this case, the mails which have been viewed remotely but not downloaded yet too will get deleted. In short, the 'flush' option will in this case delete mails which have not been downloaded even once. In r4173, the 'flush' option is being connected to the 'limit' option. But, the point is if a user add 'flush' to the rc file (or, on the command line) just to delete oversized mails, mails seen through other email clients can get deleted without any warning. [The above comments are applicable only when uidl is off. Obviously, when uidl is used, fetchmail does not use the server side \Seen flag at all.] -- Sunil Shetye. |
|
From: Matthias A. <mat...@gm...> - 2005-08-31 01:04:10
|
Sunil Shetye <sh...@bo...> writes: > Quoting from Matthias Andree's mail on Tue, Aug 30, 2005 at 10:09:19AM +0200: >> > Here, I am assuming a setup like: >> > >> > poll server >> > protocol imap # or "pop3 no uidl" >> > fetchall >> > limit 1000000 >> > flush # this has been put to delete oversized only >> > >> > Without the 'flush' option, mails which are read through another email >> > client also get downloaded without problems. With the 'flush' option, >> > such apparently read mails get deleted. >> >> Yup. There's also a difference between "flush" and "nokeep". I believe >> if it's not deliberate, then it's at least useful enough to warrant >> further documentation. > > I think there is some misunderstanding here. The change made in r4173 > is reintroducing a bug which had been removed and encouraging users to > use the 'flush' option without documenting that even mails under > 'limit' can get lost permanently. > > The 'flush' option is dangerous because it can delete mails which have > never been downloaded previously by fetchmail. > The 'flush' option is supposed to delete previously downloaded mail. > fetchmail thinks a mail has been previously downloaded if its \Seen > flag is set. Thus, the 'flush' option will delete all \Seen mails. I don't think there is a misunderstanding. I am well aware that --flush is dangerous, and I think it can bear some more explicit wording that it is. Perhaps I see the problem smaller than it currently is because I don't subscribe to ESR's pushing people towards IMAP, and I am only using fetchmail for POP3. I do need fetchmail-side tracking of seen mail for fetchmail, but I don't see this happen in 6.3.0. > However, when a user uses another email client to check the users' > remote mailbox, the \Seen flag gets set here too. In this case, the > mails which have been viewed remotely but not downloaded yet too will > get deleted. In short, the 'flush' option will in this case delete > mails which have not been downloaded even once. Right. > In r4173, the 'flush' option is being connected to the 'limit' option. > But, the point is if a user add 'flush' to the rc file (or, on the > command line) just to delete oversized mails, mails seen through other > email clients can get deleted without any warning. > > [The above comments are applicable only when uidl is off. Obviously, > when uidl is used, fetchmail does not use the server side \Seen flag > at all.] Unfortunately, these preclude one another. The UIDL option only works for POP3 which does not know \Seen flags, IMAP on the other hand does not support UIDL at all. We seem to agree that we both want fetchmail to track, on its inbound side, which messages it has fetched and which it has not. So for the time being, until we fix IMAP to use client-side tracking and get rid of all server-side tracking junk in POP3 and IMAP, we should just document this problem in the --flush section, and put a pointer into the BUGS section. Current wording, in roff man(7) format: .TP .B \-F | \-\-flush POP3/IMAP only. This is a dangerous option and can cause mail loss when used improperly. It deletes old (seen) messages from the mailserver before retrieving new messages. Warning: This can cause mail loss if you check your mail with other clients than fetchmail, and cause fetchmail to delete a message it had never fetched before. Similarly, if your local MTA hangs and fetchmail is aborted, the next time you run fetchmail, it will delete mail that was never delivered to you. You should probably not use this option in your configuration file. What you probably want is the default setting: if you don't specify '-k', then fetchmail will automatically delete messages after successful delivery. This option does not work with ETRN and ODMR. -- Matthias Andree |
|
From: Rob F. <rf...@fu...> - 2005-08-31 02:12:09
|
Matthias Andree wrote: > So for the time being, until we fix IMAP to use client-side tracking > and get rid of all server-side tracking junk in POP3 and IMAP, While I agree that the major goal post-6.3.0 should be to fix UIDL for POP3 and get rid of the server-side tracking assumptions there, IMAP is a different story. The whole IMAP protocol is oriented toward server-side state, so it seems appropriate to use it, while allowing the option of using client-side state instead. Though I might just need to read this conversation more carefully. BTW, welcome back Sunil. :-) -- ==============================| "A microscope locked in on one point Rob Funk <rf...@fu...> |Never sees what kind of room that it's in" http://www.funknet.net/rfunk | -- Chris Mars, "Stuck in Rewind" |
|
From: Matthias A. <mat...@gm...> - 2005-09-01 10:25:21
|
Sunil Shetye <sh...@bo...> writes: > I had created a patch which adds another option to fetchmail. The old > patch (against 6.2.4) along with some discussion can be found at: > > <http://lists.ccil.org/pipermail/fetchmail-friends/2003-October/008017.html>. I had a very quick glance at this patch - I have two minor nits to pick: 1. overloading the sign as a flag is plain ugly. A size is a size and as such should be an unsigned type. If we need to track state, we'll add fields (perhaps a bitfield if we're concerned about memory consumption). 2. There are several places where this check, in prose an "if limitflush caused deletion of this message" flag, is coded. The check "if limitflush is effective and the message is too large" had better be put in a macro or function so that the whole logic about this function is in one central place. I've recently wasted some time finding out the gory "#if (defined(__linux__) && !defined(INET6_ENABLE)) || defined(FreeBSD)" or similar, and variants thereof, that pertained to the monitor/interface options. Not all places used the same check, so there were inconsistencies, and about half a dozen files would have to change should someone, for instance, provide --interface support for NetBSD or Solaris. I'm still not too happy with the way it is now, at least it's only in fetchmail.h and interface.c. -- Matthias Andree |
|
From: Sunil S. <sh...@bo...> - 2005-09-08 15:14:46
Attachments:
fetchmail-6.2.9-limitflush.patch
|
Hi Matthias, Quoting from Matthias Andree's mail on Thu, Sep 01, 2005 at 10:24:57AM +0200: > Sunil Shetye <sh...@bo...> writes: > > > I had created a patch which adds another option to fetchmail. The old > > patch (against 6.2.4) along with some discussion can be found at: > > > > <http://lists.ccil.org/pipermail/fetchmail-friends/2003-October/008017.html>. > > I had a very quick glance at this patch - I have two minor nits to pick: Ok, I have created a simplified patch. Please accept this for 6.3.0. Essentially, 'limitflush' is now a boolean option. So, one has to just use --limitflush instead of --flush. -- Sunil Shetye. |
|
From: Matthias A. <mat...@gm...> - 2005-09-17 15:34:02
|
Sunil Shetye <sh...@bo...> writes: > Hi Matthias, > > Quoting from Matthias Andree's mail on Thu, Sep 01, 2005 at 10:24:57AM +0200: >> Sunil Shetye <sh...@bo...> writes: >> >> > I had created a patch which adds another option to fetchmail. The old >> > patch (against 6.2.4) along with some discussion can be found at: >> > >> > <http://lists.ccil.org/pipermail/fetchmail-friends/2003-October/008017.html>. >> >> I had a very quick glance at this patch - I have two minor nits to pick: > > Ok, I have created a simplified patch. Please accept this for 6.3.0. Done - it will show up in 6.2.9-rc3. I backed out the previous 4172 -> 4173 changes that enabled --flush with --limit outside daemon mode. Thanks a lot for your patch! -- Matthias Andree |
|
From: Matthias A. <mat...@gm...> - 2005-09-17 21:05:41
|
On Sat, 17 Sep 2005, Yves Boisjoly wrote: > Unfortunately, my employer decided to move to... Guess what... Exchange! Eek. > I was using Linux and Pine with fetchmail for my mail since two years. I > recently got a Cisco VPN client for Linux and the last thing I have to fix in > this migration is my mail. > > I tried and tried to telnet on port 110, used fetchmail with the NTLM > authentication, without any success. > > I read a lot about the NTLM authentication and I do realised that it doesn't > seem to be so easy to bypass the authentication level. > > I also read that fetchmail can use the NTLM authentication over IMAP with > Exchange, but the Exchange server I have to use only listen on POP3 (110). fetchmail has code in place to do NTLM auth with POP3, too, although the manual page doesn't say so. Can you show the "fetchmail --nosyslog -Nvv" snippet that shows the NTLM negotiation attempt? > I even tried with the Evolution client, apparently the better one to > communicate with Exchange, but again, without good result. > > I also tried to sniff my connection communication with the server, into > Windows (shame on me!)... Everything is encrypted but I saw the "NTLM" string > at some point... Might just have been an advertisement. Can you telnet to Exchange port 110, type CAPA and see what you get (this is redundant if the fetchmail command above showed this information already). > So here are my two questions: > > Is there any development in fetchmail for Exchange? Not on my part, as I don't have Exchange accounts to test against. If you could arrange for a test account for the fetchmail project, that might help - we need a mail address where we can send our test mail and the POP3 account to pull the mail from. > If not, considering that I am pretty good with Perl, do you thing it > could be feasible to incorporate a Perl call into fetchmail, that would take > over the NTLM authentication, and give back the control to fetchmail after > the authentication transaction? Such code is already there - the "plugin" option can do what you want. Your plugin would have to connect (TCP-wise) to the POP3 server, do the NTLM stuff and then either abort or transparently transport all commands (bidirectionally, so you'll probably have to delve into select() magic, it's possible in Perl but looks ugly) until it has had EOF from both sides. > I could be interested to develop this part in Perl, but I don't want to go > into C++, if it's what fetchmail is developed with... fetchmail is done in C currently, and the best way would probably be to fix NTLM auth. -- Matthias Andree |
|
From: Yves B. <yve...@sy...> - 2005-09-19 19:57:01
|
On Sat, 17 Sep 2005, Matthias Andree wrote: MA >fetchmail has code in place to do NTLM auth with POP3, too, although the MA >manual page doesn't say so. Can you show the "fetchmail --nosyslog -Nvv" MA >snippet that shows the NTLM negotiation attempt? Here is the result of the CAPA command (I changed strings for privacy): yves@Voyager:/soft/.install/Sources/02-WEB/01-Fetchmail$ telnet <the_server> 110 Trying <the_server>... Connected to <the_server>. Escape character is '^]'. +OK Microsoft Exchange Server 2003 POP3 server version 6.5.7226.0 (<the_server>) ready. CAPA +OK Capability list follows TOP USER PIPELINING EXPIRE NEVER UIDL SASL NTLM . AUTH NTLM +OK QUIT -ERR Logon failure: unknown user name or bad password. QUIT +OK Microsoft Exchange Server 2003 POP3 server version 6.5.7226.0 signing off. Connection closed by foreign host. yves@Voyager:/soft/.install/Sources/02-WEB/01-Fetchmail$ Here is the fetchmail configuration file: # Configuration created Thu Sep 8 16:40:38 2005 by fetchmailconf set postmaster "yves" set bouncemail set no spambounce set properties "" set daemon 30 poll <the_server> with proto POP3 auth ntlm user 'username' there with password '*******' is 'yves' here options pass8bits The problem seem to be with the authentication. Exchange interpret the string "auth ntlm" as "auth msn"! Here is the results of the command you asked: yves@Voyager:/soft/.install/Sources/02-WEB/01-Fetchmail$ fetchmail --nosyslog -Nvv -f .fetchmailrc.0 fetchmail: démarrage de fetchmail 6.2.5 en tâche de fond fetchmail: 6.2.5 interroge <the_server> (protocole POP3) à lun 19 sep 2005 13:38:29 EDT : récupération en cours fetchmail: POP3< +OK Microsoft Exchange Server 2003 POP3 server version 6.5.7226.0 (<the_server>) ready. fetchmail: POP3> AUTH MSN fetchmail: POP3< -ERR The specified authentication package is not supported.fetchmail: Échec de l'autorisation sur <the_user>@<the_server> fetchmail: POP3> QUIT fetchmail: POP3< +OK Microsoft Exchange Server 2003 POP3 server version 6.5.7226.0 signing off. fetchmail: 6.2.5 interroge <the_server> (protocole POP3) à lun 19 sep 2005 13:38:30 EDT : interrogation finie fetchmail: État de la requête=3 (ECHEC DE L'AUTHENTIFICATION) fetchmail: Effacement du fichier fetchids. fetchmail: mise en sommeil à lun 19 sep 2005 13:38:30 EDT Thank you, Yves -- Yves Boisjoly, Administrateur systèmes UNIX Yve...@sy... http://www.lepetittuxervateur.ca |
|
From: Matthias A. <mat...@gm...> - 2005-09-20 01:41:19
|
Le lun, 19 Sep 2005, Yves Boisjoly à écrit: > fetchmail: POP3< +OK Microsoft Exchange Server 2003 POP3 server version 6.5.7226.0 (<the_server>) ready. > fetchmail: POP3> AUTH MSN > fetchmail: POP3< -ERR The specified authentication package is not supported.fetchmail: Échec de l'autorisation sur <the_user>@<the_server> Merci beaucoup. Please edit line #77 of pop3.c (it contains "AUTH MSN"), change it to "AUTH NTLM", then recompile, reinstall and see if it works and share your findings. It works for me - albeit against a Cyrus server (not Exch*ng* - I don't have such machines to test against). Kind regards, -- Matthias Andree |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X