Menu
▾
▴
fetchmail-users
|
From: Peter N. S. <ps...@al...> - 2006-03-02 02:58:58
|
Folks,
After reading the FAQ, I'm hip to fetchmail's "neutrality" on whether an
incoming email has an attachment or not. So I'm hoping for some guidance
on where to look for the source of a recurring problem of randomly lost
or "damaged" pdf attachments. Typically (though not always), the pdfs
that come through unscathed are one-page, sent one per email. The lost
or damaged attachments tend to be larger pdf files and emails with
multiple attachments.
I've been running fetchmail on SuSE 10.0 on my laptop, and until today
(when I installed the latest version of fetchmail) I've been running
6.2.X. Rather than setting up my email clients (variously, Thunderbird,
Evolution, and Sylpheed-Claws) as POP3 to pull mail directly into the
client, I prefer to use fetchmail and procmail to pull email in from my
ISP and run it through spamassassin and clamav before dumping it into
/var/spool/mail/~. From my side of the screen, the mail comes into the
client fully processed; I don't have to wait for the email client to
chunk away looking for spam and virus "on screen" after I've hit the Get
New Messages button.
When I noticed the damaged attachments, I set up my clients for POP3 to
pull the mail directly from the ISP. Then I had the senders resend the
email. All the attachments arrived cleanly from ISP straight into email
client. So although my ISP is Comcast (I noted the Comcast caveats on
the FAQ page), Comcast does not seem to be the problem either. And I've
deactivated clamav, thinking it might not like the attachments for some
reason. But the attachments still come in damaged via the fetchmail et
al route.
So, if Comcast isn't the problem and fetchmail doesn't give a hoot if an
email bears an attachment or not, where else should I look?
Thanks for any help you can give...
With best regards,
Pete Spotts
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Peter N. Spotts | Science Correspondent
The Christian Science Monitor
One Norway Street, Boston MA 02115
Office: 617-450-2449 | Office in home: 508-520-3139
Email: ps...@al... | www.csmonitor.com
Amateur-radio call - KC1JB
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"The knack of flying is to throw yourself at the ground and miss."
-- Douglas Adams
|
|
From: Ed W. <ew...@ew...> - 2006-03-02 03:41:20
|
On Wed, Mar 01, 2006 at 08:58:52PM -0500, Peter N. Spotts wrote: > After reading the FAQ, I'm hip to fetchmail's "neutrality" on whether an > incoming email has an attachment or not. So I'm hoping for some guidance > on where to look for the source of a recurring problem of randomly lost > or "damaged" pdf attachments. Typically (though not always), the pdfs > that come through unscathed are one-page, sent one per email. The lost > or damaged attachments tend to be larger pdf files and emails with > multiple attachments. > > When I noticed the damaged attachments, I set up my clients for POP3 to > pull the mail directly from the ISP. Then I had the senders resend the > email. All the attachments arrived cleanly from ISP straight into email > client. So although my ISP is Comcast (I noted the Comcast caveats on > the FAQ page), Comcast does not seem to be the problem either. And I've > deactivated clamav, thinking it might not like the attachments for some > reason. But the attachments still come in damaged via the fetchmail et > al route. > > So, if Comcast isn't the problem and fetchmail doesn't give a hoot if an > email bears an attachment or not, where else should I look? But Comcast *is* the problem. I have this in my .fetchmailrc and it works fine, with attachments. poll mail.comcast.net proto POP3 user 'ewilts' password 'noneofyourbusiness!' fetchall Without the "fetchall", any attachments over 70k were mangled. -- Ed Wilts, Mounds View, MN, USA mailto:ew...@ew... |
|
From: Peter N. S. <ps...@al...> - 2006-03-02 13:47:42
|
Ed Wilts wrote: > > But Comcast *is* the problem. I have this in my .fetchmailrc and it > works fine, with attachments. > > poll mail.comcast.net > proto POP3 > user 'ewilts' > password 'noneofyourbusiness!' > fetchall > > Without the "fetchall", any attachments over 70k were mangled. > Hmmm...this is interesting. It would imply that when email clients run pop3 and pull the email in directly, they already have a fetchall-like function active? Otherwise, why would all attachments of any size arrive whole to TB, Evolution, or SC via Comcast as pop3 but not via fetchmail? Both presumably are merely polling Comcast for new mail. Ah, it's a curious world out there! Anyway, I've added the fetchall to my fetchmailrc file. Thanks so much for your help... With best regards, Pete -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Peter N. Spotts | Science Correspondent The Christian Science Monitor One Norway Street, Boston MA 02115 Office: 617-450-2449 | Office in home: 508-520-3139 Email: ps...@al... | www.csmonitor.com Amateur-radio call - KC1JB ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "The knack of flying is to throw yourself at the ground and miss." -- Douglas Adams |
|
From: Ed W. <ew...@ew...> - 2006-03-02 13:55:06
|
On Thu, Mar 02, 2006 at 07:47:31AM -0500, Peter N. Spotts wrote:
> Ed Wilts wrote:
> >
> >But Comcast *is* the problem. I have this in my .fetchmailrc and it
> >works fine, with attachments.
> >
> >Without the "fetchall", any attachments over 70k were mangled.
> >
>
> Hmmm...this is interesting. It would imply that when email clients run
> pop3 and pull the email in directly, they already have a fetchall-like
> function active?
Right. fetchmail does things differently. Comcast is broken but since
many clients simply work around broken servers, Comcast doesn't see a
need to fix anything.
.../Ed
--
Ed Wilts, Mounds View, MN, USA
mailto:ew...@ew...
|
|
From: Jakob H. <jh...@pl...> - 2006-03-02 13:58:21
|
Peter N. Spotts wrote: > Hmmm...this is interesting. It would imply that when email clients run > pop3 and pull the email in directly, they already have a fetchall-like > function active? Otherwise, why would all attachments of any size arrive The difference is simply that fetchmail (ab)uses TOP by default to retrieve mail, while usual MUAs use the standard mechanism of RETR. Nevertheless, Comcast's POP3 server is plain broken if he allows TOP but truncates messages with it. |
|
From: Sunil S. <sh...@bo...> - 2006-03-02 14:26:20
|
Quoting from Jakob Hirsch's mail on Thu, Mar 02, 2006:
> The difference is simply that fetchmail (ab)uses TOP by default to
> retrieve mail, while usual MUAs use the standard mechanism of RETR.
> Nevertheless, Comcast's POP3 server is plain broken if he allows TOP but
> truncates messages with it.
There is one case where fetchmail could use RETR instead of TOP. That
is when "uidl" has been enabled.
In this configuration:
poll server
protocol pop3
no fetchall
no keep
uidl
fetchmail currently uses TOP. If the server is supporting "uidl", then
it should not matter if fetchmail uses TOP or RETR as all the email
clients will be using "uidl" anyway. So, in this case, fetchmail
should use "RETR" instead.
I am not aware if Comcast's POP3 server support "uidl" or not. If they
do, I think this change should be made.
Any votes for or against this?
This is probably the change required (somebody confirm this too):
< peek_capable = !ctl->fetchall && (!ctl->keep || ctl->server.uidl);
> peek_capable = !(ctl->fetchall || ctl->keep || ctl->server.uidl);
--
Sunil Shetye.
|
|
From: Matthias A. <mat...@gm...> - 2006-03-03 01:00:16
|
Sunil Shetye <sh...@bo...> writes: > Quoting from Jakob Hirsch's mail on Thu, Mar 02, 2006: >> The difference is simply that fetchmail (ab)uses TOP by default to >> retrieve mail, while usual MUAs use the standard mechanism of RETR. >> Nevertheless, Comcast's POP3 server is plain broken if he allows TOP but >> truncates messages with it. > > There is one case where fetchmail could use RETR instead of TOP. That > is when "uidl" has been enabled. Not in 6.3.X, as that would change semantics WRT other clients. The assumption fetchmail makes is that "TOP" leaves seen flags (where recorded in headers) and the "LAST" pointer (way obsolete) alone. Plus, some b0rked servers apparently remove messages right after RETR (see below). Changing UIDL to imply "use RETR" is an option only for later versions, although it looks sensible in itself -- compatibility matters here. I don't like fetchmail's assumptions about undocumented behavior either (which got us into this trouble), and it appears the price for not using RETR is high, but changes like these are definitely 6.4.X stuff. > fetchmail currently uses TOP. If the server is supporting "uidl", then > it should not matter if fetchmail uses TOP or RETR as all the email > clients This is the thinko. Not all clients use UIDL. Some (including fetchmail) still use LAST... > Any votes for or against this? Against. The TODO in SVN's trunk directory already mentions: | clean up TOP vs. RETR but leave TOP as an option for the server scum | that deletes message right after RETR, voiding client retries (Jakob | Hirsch, 2006-01-03). -- Matthias Andree |
|
From: Sunil S. <sh...@bo...> - 2006-03-03 08:38:46
|
Quoting from Matthias Andree's mail on Fri, Mar 03, 2006: > The TODO in SVN's trunk directory already mentions: > > | clean up TOP vs. RETR but leave TOP as an option for the server scum > | that deletes message right after RETR, voiding client retries (Jakob > | Hirsch, 2006-01-03). Are these "scum" servers supporting "uidl"? Please note that the change I am recommending is that fetchmail *should* use RETR with pop3+uidl servers. Other pop3 servers will not be affected by this change. Are there any logs/bug reports about these "scum" servers? -- Sunil Shetye. |
|
From: Matthias A. <mat...@gm...> - 2006-03-03 09:34:17
|
Sunil Shetye <sh...@bo...> writes: > Quoting from Matthias Andree's mail on Fri, Mar 03, 2006: >> The TODO in SVN's trunk directory already mentions: >> >> | clean up TOP vs. RETR but leave TOP as an option for the server scum >> | that deletes message right after RETR, voiding client retries (Jakob >> | Hirsch, 2006-01-03). > > Are these "scum" servers supporting "uidl"? I don't know, but we need to assume they do since that's the worst case. > Please note that the change I am recommending is that fetchmail > *should* use RETR with pop3+uidl servers. Other pop3 servers will not > be affected by this change. Yes, it's still 6.4.X stuff since it deliberately changes behavior for no good reason. fetchmail 6.3.2 already introduced the (incompatible) "use RETR with Maillennium server" change because it was considered we'd rather screw some message flags and a LAST pointer rather than truncate messages. > Are there any logs/bug reports about these "scum" servers? Sort of. At least the ones that were reported do not delete messages if the connection is hung up without prior "QUIT" command. <http://lists.berlios.de/pipermail/fetchmail-users/2006-January/000220.html> -- Matthias Andree |
|
From: Sunil S. <sh...@bo...> - 2006-03-03 14:15:26
|
Quoting from Matthias Andree's mail on Fri, Mar 03, 2006: > > Please note that the change I am recommending is that fetchmail > > *should* use RETR with pop3+uidl servers. Other pop3 servers will not > > be affected by this change. > > Yes, it's still 6.4.X stuff since it deliberately changes behavior for > no good reason. There is a good reason. The advice being given to force fetchmail to avoid using "TOP" with these buggy servers is to enable the "fetchall" option. The FAQ is littered with this advice for various servers with variety of problems. The problems with "fetchall" option are: - "fetchall" cannot be used with "uidl" - "fetchall" causes mails to be redownloaded if there is a line-hit while fetchmail is downloading mails. If there are consecutive line-hits, the same set of mails could be downloaded any number of times. To avoid the redownloading of mails, one has to now probably add the "expunge" option also. Finding the best value for "expunge" is a problem itself: - "expunge 1" is expensive. It will reconnect for every mail. Many mailservers may not like this too. However, each mail will be downloaded only once. - "expunge 2" is less expensive. Mailservers may still object to this. Very few mails will be redownloaded. - "expunge 20" is relatively cheap. Mailservers may not object to this. Some mails will get redownloaded. However, on a bad day, if you do get consecutive line-hits, you will still end up with multiple copies of mails. In short, the user has to go for some sort of experimentation and use a sub-optimal solution to get the mails(*). The best solution (wherever possible) is to use "uidl" as mails get downloaded exactly once. To use "uidl", one has to use "no fetchall". With "no fetchall", fetchmail refuses to use "RETR". > fetchmail 6.3.2 already introduced the (incompatible) "use RETR with > Maillennium server" change because it was considered we'd rather screw > some message flags and a LAST pointer rather than truncate messages. I don't get this part. If the pop3 server is supporting UIDL and fetchmail is running with the "uidl" option, why bother about the LAST pointer and message flags? After all, even if the user is running multiple fetchmails, all those fetchmails would be running with the same configuration. And, as has already been said, most standard interactive clients use "uidl" anyway. So, they also will not get affected. > Sort of. At least the ones that were reported do not delete > messages if the connection is hung up without prior "QUIT" command. > <http://lists.berlios.de/pipermail/fetchmail-users/2006-January/000220.html> Jakob, please give more details about the Mercury server: - its signature line - its CAPA output - whether it supports UIDL - whether you are using it with "uidl" and finally, - your opinion on whether fetchmail should use "RETR" with "uidl". -- Sunil Shetye. (*) This need for experimentation is not documented now. Currently, there is no entry in FAQ which says that if you are using "fetchall", you should necessarily use say "expunge 10". FAQ O9 does talk of "fetchall" and "expunge". But, it seems to be bad-mouthing "uidl" and switching to IMAP4 is given as a better option than using "expunge". However, this is a documentation issue and not related to the main topic. |
|
From: Matthias A. <mat...@gm...> - 2006-03-03 19:29:04
|
Sunil Shetye <sh...@bo...> writes: > Quoting from Matthias Andree's mail on Fri, Mar 03, 2006: >> > Please note that the change I am recommending is that fetchmail >> > *should* use RETR with pop3+uidl servers. Other pop3 servers will not >> > be affected by this change. >> >> Yes, it's still 6.4.X stuff since it deliberately changes behavior for >> no good reason. > > There is a good reason. > > The advice being given to force fetchmail to avoid using "TOP" with > these buggy servers is to enable the "fetchall" option. The FAQ is > littered with this advice for various servers with variety of > problems. The problems with "fetchall" option are: > > - "fetchall" cannot be used with "uidl" Well, we can fix eventual incompatibilities between these two options any time. 6.3.X is open for bug fixes. > - "fetchall" causes mails to be redownloaded if there is a line-hit > while fetchmail is downloading mails. If there are consecutive > line-hits, the same set of mails could be downloaded any number of > times. Yes, true. So use just uidl without fetchall on flakey lines. There is little reason to add fetchall to uidl. We can decouple TOP/RETR from fetchall in 6.4.X and default to RETR if we want. Not in 6.3.X. Let's do 6.3.3 (thanks for your efforts in getting the IMAP NOOP bugs nailed BTW), and then fork 6.4.X and make all interesting changes and cleanups in particular in 6.4.X. > To avoid the redownloading of mails, one has to now probably add the > "expunge" option also. Finding the best value for "expunge" is a > problem itself: > > - "expunge 1" is expensive. It will reconnect for every mail. Many > mailservers may not like this too. However, each mail will be > downloaded only once. > - "expunge 2" is less expensive. Mailservers may still object to this. > Very few mails will be redownloaded. > - "expunge 20" is relatively cheap. Mailservers may not object to > this. Some mails will get redownloaded. However, on a bad day, if > you do get consecutive line-hits, you will still end up with > multiple copies of mails. The best option would be to use UIDL. Still we'll not be forcing UIDL downloads to use RETR in 6.3.X. We can safely do that in 6.4.X: the 6.3.X manpage already has warnings in place. >> fetchmail 6.3.2 already introduced the (incompatible) "use RETR with >> Maillennium server" change because it was considered we'd rather screw >> some message flags and a LAST pointer rather than truncate messages. > > I don't get this part. If the pop3 server is supporting UIDL and > fetchmail is running with the "uidl" option, why bother about the LAST > pointer and message flags? Why bother? Because I promised I'd stop the ESR madness of gold versions and promised 6.3.X would be compatible with 6.3.0 when I released 6.3.0. > And, as has already been said, most standard interactive clients use > "uidl" anyway. So, they also will not get affected. This is not a valid reason to change behavior in incompatible ways in the midst of a stable version. I'd wondered if I'd wanted to add the Maillennium workaround in 6.3.X at all or delay it until 6.4.X. There'd been loads of reasons to defer it, not the least being a documented workaround. > Jakob, please give more details about the Mercury server: > > - its signature line > - its CAPA output > - whether it supports UIDL > - whether you are using it with "uidl" > and finally, > - your opinion on whether fetchmail should use "RETR" with "uidl". I'm not accepting changes into 6.3.X that switch TOP to RETR except if they fix security bugs, data corruption or other critical issues, so please don't spend your time before we've opened 6.4.X for hacking. Priorities for incompatible changes are: 1. Security 2. Critical bugs (data loss, crash, similar) 3. Compatibility within stable releases 4. Protocol compliance 5. Consistency 6. Anything else -- Matthias Andree |
|
From: Rob F. <rf...@fu...> - 2006-03-03 19:58:52
|
Matthias Andree wrote: > Let's do 6.3.3 (thanks for your efforts in getting the IMAP NOOP bugs > nailed BTW), and then fork 6.4.X and make all interesting changes and > cleanups in particular in 6.4.X. FWIW, I tend to agree with Matthias here. Is it time for the long-awaited UIDL revamp yet? :-) -- ==============================| "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: Sunil S. <sh...@bo...> - 2006-03-04 09:39:56
|
Quoting from Matthias Andree's mail on Fri, Mar 03, 2006:
> > The advice being given to force fetchmail to avoid using "TOP" with
> > these buggy servers is to enable the "fetchall" option. The FAQ is
> > littered with this advice for various servers with variety of
> > problems. The problems with "fetchall" option are:
> >
> > - "fetchall" cannot be used with "uidl"
>
> Well, we can fix eventual incompatibilities between these two options
> any time. 6.3.X is open for bug fixes.
Here is a patch for this.
================================================================
Index: fetchmail-6.3/pop3.c
===================================================================
--- fetchmail-6.3/pop3.c (revision 4719)
+++ fetchmail-6.3/pop3.c (working copy)
@@ -894,7 +894,7 @@
*/
last = 0;
*newp = -1;
- if (*countp > 0 && !ctl->fetchall)
+ if (*countp > 0 && (!ctl->fetchall || ctl->server.uidl))
{
int fastuidl;
char id [IDLEN+1];
@@ -902,6 +902,7 @@
/* should we do fast uidl this time? */
fastuidl = ctl->fastuidl;
if (*countp > 7 && /* linear search is better if there are few mails! */
+ !ctl->fetchall && /* with fetchall, all uids are required */
!ctl->flush && /* with flush, it is safer to disable fastuidl */
NUM_NONZERO (fastuidl))
{
================================================================
> The best option would be to use UIDL. Still we'll not be forcing UIDL
> downloads to use RETR in 6.3.X. We can safely do that in 6.4.X: the
> 6.3.X manpage already has warnings in place.
...
> > I don't get this part. If the pop3 server is supporting UIDL and
> > fetchmail is running with the "uidl" option, why bother about the LAST
> > pointer and message flags?
>
> Why bother? Because I promised I'd stop the ESR madness of gold versions
> and promised 6.3.X would be compatible with 6.3.0 when I released 6.3.0.
Ok.
--
Sunil Shetye.
|
|
From: Matthias A. <mat...@gm...> - 2006-03-04 12:14:06
|
Sunil Shetye <sh...@bo...> writes: > Quoting from Matthias Andree's mail on Fri, Mar 03, 2006: >> > The advice being given to force fetchmail to avoid using "TOP" with >> > these buggy servers is to enable the "fetchall" option. The FAQ is >> > littered with this advice for various servers with variety of >> > problems. The problems with "fetchall" option are: >> > >> > - "fetchall" cannot be used with "uidl" >> >> Well, we can fix eventual incompatibilities between these two options >> any time. 6.3.X is open for bug fixes. > > Here is a patch for this. Hm - how will this avoid redownloads of messages when the line is faulty and the connection is torn down? It will recognize it's downloading seen messages, but download them all the same. -- Matthias Andree |
|
From: Sunil S. <sh...@bo...> - 2006-03-04 13:50:30
|
Quoting from Matthias Andree's mail on Sat, Mar 04, 2006:
> Hm - how will this avoid redownloads of messages when the line is faulty
> and the connection is torn down?
>
> It will recognize it's downloading seen messages, but download them all
> the same.
The only practical use of this patch is if a user with this
configuration:
set daemon 300
poll server
uidl
no fetchall
keep
runs:
fetchmail -a -d 0 ; fetchmail
to download all mails once and then start normal polling. New mails
which have been downloaded by the first instance of fetchmail will not
be downloaded again by the second instance due to this patch.
Of course, an equivalent effect may be achieved by removing all the
relevant entries from the fetchids file or deleting the fetchids file.
This patch has no relevance to our basic topic under discussion.
--
Sunil Shetye.
|
|
From: Matthias A. <mat...@gm...> - 2006-03-04 14:48:15
|
Sunil Shetye <sh...@bo...> writes: > runs: > > fetchmail -a -d 0 ; fetchmail > > to download all mails once and then start normal polling. New mails > which have been downloaded by the first instance of fetchmail will not > be downloaded again by the second instance due to this patch. Ah, so it still has a use and fixes duplicate downloads. I'll reword my NEWS entry and merge the patch. Thanks. -- Matthias Andree |
|
From: Jakob H. <jh...@pl...> - 2006-03-04 13:23:37
|
Sunil Shetye wrote: >> | clean up TOP vs. RETR but leave TOP as an option for the server scum >> | that deletes message right after RETR, voiding client retries (Jakob >> | Hirsch, 2006-01-03). Note that the server i was referring to (MercuryP/NLM, version 1.48) only deletes RETRieved mail after a QUIT, thereby not really violating the RFC. > Are these "scum" servers supporting "uidl"? Please note that the Yes. But I can only speak for the server mentioned above. Anyway, I really think fetchmail should by default simply retrieve all message, using standard MUA mechanisms: RETR and DELE; no TOP, UIDL or LAST. This makes sure that fetchmail works with as much servers as possible without any tweaking. If one wants 'keep', UIDL/RETR should be used, with fallback to LAST/RETR. And there should probably be an option to force one of UIDL or LAST (uidl/nouidl?) so the user can enfore client or server side tracking (with fetchmail bailing out if the requested option is not available on the server). The magic fetchmail does is nice and works in most cases, but final control should be left to the user. As for TOP, there are legit uses, so there should also an option to enable it explicitly. Oh, and all of this should be documented as comprehensible as possible, of course. Anybody with loads of free time on the hand? :) But as Matthias said, all of this is surely nothing for 6.3. |
|
From: Matthias A. <mat...@gm...> - 2006-03-04 14:47:11
|
Jakob Hirsch <jh...@pl...> writes: > Anyway, I really think fetchmail should by default simply retrieve all > message, using standard MUA mechanisms: RETR and DELE; no TOP, UIDL or > LAST. This makes sure that fetchmail works with as much servers as > possible without any tweaking. UIDL is a pretty standard MUA (used by major MUAs) mechanism for "keep messages on server" setups, and it's very likely I'll make UIDL default in future versions. I hope we can also add the often-requested "delete after N days" that ESR refused (probably because he was scared of the implications with the long-winding UID code), but I'm not sure if time permits that for 6.4.X. > If one wants 'keep', UIDL/RETR should be used, with fallback to >LAST/RETR. And there should probably be an option to force one of UIDL >or LAST (uidl/nouidl?) so the user can enfore client or server side >tracking (with fetchmail bailing out if the requested option is not >available on the server). The magic fetchmail does is nice and works in >most cases, but final control should be left to the user. The user should not need to care about protocol details before he runs into a conflict so serious that fetchmail cannot resolve it on its own. I share the view on RETR becoming default. Server-side tracking is a constant source of troubles with respect to interrupted connections, software faults, aborts, reboots, any other things, and relying on POP3 server state beyond UIDL just doesn't work well, so everything will be switched to client-side tracking. I also think I'll be discontinuing obsolete commands such as "RPOP" (insecure, removed with RFC-1460 in 1993), "LAST" (removed with RFC-1725 in 1994, inconsistent behavior with RSET) in 6.4.X. fetchmail should be talking RFC-1939 (POP3)/1734 (AUTH)/2449 (TLS)/2222 (SASL). Massively slashing old protocols may cause me to call the next release 7.0.0 rather than 6.4.0 so people will be warned it's a major upgrade. The exact roadmap for the next fetchmail release isn't fixed yet. -- Matthias Andree |
|
From: Matthias A. <mat...@gm...> - 2006-03-04 19:32:00
|
"Peter N. Spotts" <ps...@al...> writes:
> I've been running fetchmail on SuSE 10.0 on my laptop, and until today
> (when I installed the latest version of fetchmail) I've been running
> 6.2.X.
[...]
> So although my ISP is Comcast (I noted the Comcast caveats on
> the FAQ page), Comcast does not seem to be the problem either.
That would be news.
fetchmail, beginning with version 6.3.2, recognizes Comcast's broken
servers ("Maillennium POP3/PROXY server") and disables the problematic
use of the TOP command and uses RETR instead - so updating to 6.3.2
should have fixed all known Comcast problems.
--
Matthias Andree
|
|
From: Peter N. S. <ps...@al...> - 2006-03-08 14:51:25
|
On Sat, 2006-03-04 at 19:31 +0100, Matthias Andree wrote:
> "Peter N. Spotts" <ps...@al...> writes:
>
> > I've been running fetchmail on SuSE 10.0 on my laptop, and until today
> > (when I installed the latest version of fetchmail) I've been running
> > 6.2.X.
>
> [...]
>
> > So although my ISP is Comcast (I noted the Comcast caveats on
> > the FAQ page), Comcast does not seem to be the problem either.
>
> That would be news.
>
> fetchmail, beginning with version 6.3.2, recognizes Comcast's broken
> servers ("Maillennium POP3/PROXY server") and disables the problematic
> use of the TOP command and uses RETR instead - so updating to 6.3.2
> should have fixed all known Comcast problems.
>
> --
> Matthias Andree
Matthias,
My apologies for the tardy reply. I'll remove the fetchall command from
my rc file and see how things work. I should have said earlier that I
had just updated to 6.3.2 that morning but hadn't tried it yet...I just
had this urge to write something after several weeks of
frustration! ;-)
With best regards,
Pete
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Peter N. Spotts | Science Correspondent
The Christian Science Monitor
One Norway Street, Boston MA 02115
Office: 617-450-2449 | Office in home: 508-520-3139
Email: ps...@al... | www.csmonitor.com
Amateur-radio call - KC1JB
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"The knack of flying is to throw yourself at the ground and miss."
-- Douglas Adams
|
|
From: Matthias A. <mat...@gm...> - 2006-03-08 17:07:32
|
Peter N. Spotts wrote: > My apologies for the tardy reply. I'll remove the fetchall command from > my rc file and see how things work. I should have said earlier that I > had just updated to 6.3.2 that morning but hadn't tried it yet...I just > had this urge to write something after several weeks of > frustration! ;-) Well, I hope that your frustration ended with the installation of 6.3.2 and you'll find out that next time you run it. Otherwise, let me know quick so the fix can become part of the 6.3.3 release. Thanks, Matthias |
×
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