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.
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[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
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. ***