Bug 36640 - fetchmail obtains mail from pop3 server but does not deliver to sendmail on local host
Summary: fetchmail obtains mail from pop3 server but does not deliver to sendmail on l...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: fetchmail
Version: 7.1
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Miloslav Trmač
QA Contact: Brock Organ
URL:
Whiteboard:
: 37455 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-04-19 13:09 UTC by David Both
Modified: 2007-04-18 16:32 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-06-03 22:30:49 UTC
Embargoed:


Attachments (Terms of Use)
fetchmail -kavu results (6.90 KB, text/plain)
2001-04-19 17:54 UTC, David Both
no flags Details

Description David Both 2001-04-19 13:09:33 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.16-22 i686)


After new installation (I kept /home file system) over RH7.0 fetchmail
obtains mail from pop3 server and deletes (if I don't use -k) messages from
server. The mail never appears in mail or pine and appears to have gone to
the big bit-bucket in the sky. Removing the preexisting .fetchmailrc does
not alter the symptom. Locally sent mail using mail works fine. 

Bugzilla shows no known problems.

Reproducible: Always
Steps to Reproduce:
1. sendmail -k -u dboth einstein1
2. enter password
3. fetchmail indicates that it is reading messages

	

Actual Results:  messages never get to mail or pine.

Expected Results:  Messages should have shown up in my user mail agent

This is a new everything installation of 7.1 with medium firewall modified
to allow ssh. I also flushed all the ipchains rules. The system previously
had 7.0 on it and worked fine. I installed keeping only the /home and
/usr/local file systems. All other file systems were repartitoned and
reformatted.

Comment 1 David Both 2001-04-19 17:54:16 UTC
Created attachment 15788 [details]
fetchmail -kavu results

Comment 2 Gustav Schaffter 2001-04-20 22:06:02 UTC
I did an upgrade from RH6.2+ to RH7.1 and have the same behaviour.

I find the following in my /var/log/maillog whenever fetchmail tries to deliver
mail retreived from the POP3 server at freja.yggdrasil.home:

Apr 20 23:38:54 valhall fetchmail[1171]: 1 message for adsl at
freja.yggdrasil.home (1345 octets). 
Apr 20 23:38:54 valhall fetchmail[1171]: reading message 1 of 1 (1345 octets) 
Apr 20 23:38:54 valhall sendmail[1173]: f3KLcsY01173: tcpwrappers (localhost,
127.0.0.1) rejection
Apr 20 23:38:54 valhall fetchmail[1171]:  flushed 
Apr 20 23:38:54 valhall sendmail[1173]: NOQUEUE: localhost [127.0.0.1] did not
issue MAIL/EXPN/VRFY/ETRN during connection to MTA

My /etc/hosts.allow contains the rows:
ALL:10.0.0.0/255.255.255.0
ALL:127.0.0.1/255.255.255.0

(Added in desperation. ;-)

And the mail is lost in cyberspace...
Gustav


Comment 3 Michael Schwendt 2001-04-26 06:29:06 UTC
Sendmail is compiled with -DTCPWRAPPERS, means you need to tell the tcp wrapper
to accept local connections at least. Try adding one of the following lines to
your /etc/hosts.allow, where YOURDOMAIN is your (local) domain name:

sendmail: ALL@LOCAL : allow

sendmail: ALL@LOCAL ALL@.YOURDOMAIN: allow



Comment 4 Bruce Garlock 2001-05-21 19:11:06 UTC
I had the same trouble.  I did a fresh install of 7.1, and brought over configuration files, and my home directories from backup.  Once I started fetchmail, I 
saw the modem flashing, and was expecting to get about a days worth of emails.  When I went to get the mail, it said no messages.  I noticed then in my 
logs that sendmail was being denied.  Once I added sendmail:127.0.0.1 in /etc/hosts.allow, it started sending mail again.

Things like this should be mentioned in the release notes.  How many other packages are now tcp-wrapped?  Why not put in a default value in 
/etc/hosts.allow that is something like all:127.0.0.1?

How about all the messages that were denied, did they all go to /dev/null?  I cannot find them anywhere.

Comment 5 Miloslav Trmač 2005-06-03 22:30:49 UTC
I'm sorry about the late response.

I'm afraid all components do their work "correctly":
With ALL:ALL in /etc/hosts.deny, sendmail rejects the message with 550,
a "permanent rejection" error code; retrying in a few hours probably won't help.

fetchmail sees the error code and gives up on sending this message.  Keeping
the message in the mailbox won't help in making it deliver, so fetchmail
deletes the message and attempts to send a bounce to the sender (or to
postmaster if "set no bouncemail" is used).

But then the bounce message is rejected too - and fetchmail can't do
anything useful, it can't send a bounce about the bounce.

There can't be a definite list of servers using tcp_wrappers because any
newly installed application can be using them.  The list of applications
using tcp_wrappers within the distribution can be obtained using
(rpm --whatrequires libwrap.so.0).

Yes, it should have been in the release notes, unfortunately it is way too
late to do something about it now.

Comment 6 Miloslav Trmač 2005-06-03 22:34:01 UTC
*** Bug 37455 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.