Red Hat Bugzilla – Bug 36640
fetchmail obtains mail from pop3 server but does not deliver to sendmail on local host
Last modified: 2007-04-18 12:32:44 EDT
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.
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
Created attachment 15788 [details]
fetchmail -kavu results
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: 1 message for adsl at
freja.yggdrasil.home (1345 octets).
Apr 20 23:38:54 valhall fetchmail: reading message 1 of 1 (1345 octets)
Apr 20 23:38:54 valhall sendmail: f3KLcsY01173: tcpwrappers (localhost,
Apr 20 23:38:54 valhall fetchmail: flushed
Apr 20 23:38:54 valhall sendmail: NOQUEUE: localhost [127.0.0.1] did not
issue MAIL/EXPN/VRFY/ETRN during connection to MTA
My /etc/hosts.allow contains the rows:
(Added in desperation. ;-)
And the mail is lost in cyberspace...
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
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.
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.
*** Bug 37455 has been marked as a duplicate of this bug. ***