Bug 119894

Summary:	RedHat fetchmail patch breaks fetchmail CAPA handling
Product:	[Retired] Red Hat Raw Hide	Reporter:	Nicolas Mailhot <nicolas.mailhot>
Component:	fetchmail	Assignee:	Nalin Dahyabhai <nalin>
Status:	CLOSED DUPLICATE	QA Contact:	Brock Organ <borgan>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	1.0
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-02-21 19:02:21 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Nicolas Mailhot 2004-04-02 22:21:31 UTC

Description of problem:

I have lots of mail accounts on different isps - I sort of like to
collect them I guess (and it's handy sometimes). Mail is centralized
using procmail when possible and a master fetchmail on my home box if not.

Recently however one account started giving odd warnings (which is
annoying since fetchmail is in crontab so I have to > /dev/null all
fetchmail output to avoid being mailbombed, and this hides real
errors). Another one sends fetchmail into an infinite loop.

Both problems seem to be linked to CAPA :

1. First isp : annoying warning 

fetchmail: 6.2.5 querying pop.ifrance.com (protocol POP3) at Sat Apr 
3 00:11:21 2004: poll started
fetchmail: POP3< +OK POP3 server ready
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR invalid command, user waited
fetchmail: invalid command, user waited <<<<<<<<< non-blocking warning
fetchmail: POP3> USER nicolas.mailhot
fetchmail: POP3< +OK nicolas.mailhot, i need your password

2. Second isp : infinite loop

fetchmail: 6.2.5 querying pop.wanadoo.fr (protocol POP3) at Sat Apr  3
00:11:26 2004: poll started
fetchmail: POP3< +OK connected to pop3 proxy on mwinf1004
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR unknown command
fetchmail: unknown command
fetchmail: Repoll immediately on Nicolas.Mailhot.fr
fetchmail: POP3< +OK connected to pop3 proxy on mwinf0203
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR unknown command
fetchmail: unknown command
fetchmail: Repoll immediately on Nicolas.Mailhot.fr
fetchmail: POP3< +OK connected to pop3 proxy on mwinf0901
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR unknown command
fetchmail: unknown command
fetchmail: Repoll immediately on Nicolas.Mailhot.fr
fetchmail: POP3< +OK connected to pop3 proxy on mwinf0802
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR unknown command
fetchmail: unknown command
fetchmail: Repoll immediately on Nicolas.Mailhot.fr
fetchmail: POP3< +OK connected to pop3 proxy on mwinf0803
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR unknown command
fetchmail: unknown command
fetchmail: Repoll immediately on Nicolas.Mailhot.fr
fetchmail: POP3< +OK connected to pop3 proxy on mwinf0202
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR unknown command
fetchmail: unknown command
fetchmail: Repoll immediately on Nicolas.Mailhot.fr
fetchmail: POP3< +OK connected to pop3 proxy on mwinf0304
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR unknown command
fetchmail: unknown command
fetchmail: Repoll immediately on Nicolas.Mailhot.fr
fetchmail: POP3< +OK connected to pop3 proxy on mwinf0101
...

Version-Release number of selected component (if applicable):

fetchmail-6.2.5-1

How reproducible:

Always

Is there a way to tell fetchmail to ommit CAPA on some servers ?
Seem some of them really do not like it. The man page is absolutely
silent on CAPA.

Comment 1 Nicolas Mailhot 2004-04-04 18:11:06 UTC

The fetchmail faq proposes using auth password to inhibit CAPA.

Unfortunately, this is broken by rpm/SOURCES/fetchmail-6.2.0-gsspop.patch

Backing out this patch in the SRPM and using the fetchmail FAQ
workaround fixes my setup.

I'd suggest to fix the patch - if the fetchmail guys had to FAQ the
CAPA workaround it must hit quite a lot of people

(see also the whole thread at
http://lists.ccil.org/pipermail/fetchmail-friends/2004-April/008479.html
 )

Comment 2 Bill Nottingham 2004-04-06 04:58:50 UTC


*** This bug has been marked as a duplicate of 115474 ***

Comment 3 Red Hat Bugzilla 2006-02-21 19:02:21 UTC

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.