Bug 65481 - ipop3d logs wrong address in /var/log/maillog
Summary: ipop3d logs wrong address in /var/log/maillog
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: imap (Show other bugs)
(Show other bugs)
Version: 6.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2002-05-25 08:06 UTC by Todd
Modified: 2007-04-18 16:42 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-05-26 04:33:45 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Todd 2002-05-25 08:06:24 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.2 (X11; Linux i686; U;) Gecko/20020510

Description of problem:

After updating to the latest imap errata (imap-2001a-1.62.0.i386.rpm) ipop3d
seems to log the wrong IP address in /var/log/maillog for a service init.

Before the update ipop3d would log:

    pop3 service init from <- the IP of the client

After the update it logs:

    pop3 service init from 24.104.33.xxx <- the IP of the server

ipop3d still logs the Login and Logout using the IP of the client.  Here is a
typical set of log messages showing this behavior:

May 25 03:47:38 chaos ipop3d[7590]: pop3 service init from 24.104.33.xxx
May 25 03:47:38 chaos ipop3d[7590]: Login user=username host=client.domain.com
[] nmsgs=0/0
May 25 03:47:38 chaos ipop3d[7590]: Logout user=username host=client.domain.com
[] nmsgs=0 ndele=0

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

How reproducible:

Steps to Reproduce:
1. update to latest imap errata
2. connect to ipop3d server from remote client
3. tail /var/log/maillog

Actual Results:  ipop3d logs 'pop3 service init from <server_addr>'

Expected Results:  ipop3d should log 'pop3 service init from <client_addr>'

Comment 1 Mike A. Harris 2002-05-28 07:57:56 UTC
I've just updated a 6.2 machine to the latest imap erratum, and tested it
both before and after updating, by using fetchmail both across the net,
locally, and on a machine on a private LAN behind the machine.  All of my
pop3 sessions were properly logged both before and after the update, and
all other incoming pop3 traffic from other users of the system also logged

# rpm -q imap

Comment 2 Todd 2002-05-30 21:36:17 UTC
Hmmm, I have now tested this on two different rh-6.2 boxes with the same
result.  One box is a production server, the other is a VMware virtual
machine.  I don't believe there is anything unusual about either system
configuration.  The vm was setup just to test things like this and is a
simple out of the box install.  I don't have this problem on any rh-7.2
boxes I've installed imap-2001a on.

Might you be able to venture a guess as to what other packages might affect
this behavior?  I thought perhaps the kernel or glibc could affect this
possibly.  In case that's relevant, below are the versions I'm using.

The production server:
# rpm -q glibc kernel; uname -r

The VM:
# rpm -q glibc kernel; uname -r

I've looked at the imap source to see that the pop3 service init line is
located in src/osdep/unix/env_unix.c around line 405:

getpeername (0,(struct sockaddr *) &sin,(void *) &i) ? "UNKNOWN" :
  ((sin.sin_family == AF_INET) ? inet_ntoa (sin.sin_addr) : "NON-IPv4");

The Log(in|out) user= lines (that correctly log the client IP) use the
tcp_clienthost function from src/osdep/unix/tcp_unix.c around line 767:

getpeername (0,(struct sockaddr *) &sin,(void *) &sinlen) ?
  cpystr ("UNKNOWN") : ((sin.sin_family == AF_INET) ?
                        tcp_name (&sin,T) : cpystr ("NON-IPv4"));

I'm not a C coder so I wouldn't really recognize a problem unless it was
incredibly obvious. :)  I do notice that the code has been changed to add
the check for non ipv4 addresses since imap-2000.  I replaced the code in
src/osdep/unix/env_unix.c above with the code from the 2000 release and it
exhibits the same problem so I guess the problem is not in that code.  But
where it is at I am clueless.

I appreciate the trouble you've gone to to check this out and realize it's
pretty difficult to diagnose something when it works as expected on your
end.  However, since the imap package requires no configuration I'm at a
loss as to why I'm getting this behavior.  Also since this happens on two
separate machines I'm hoping that you can point me in the right direction
to find out what's going wrong.  I'll gladly run any tests or provide any
details that might help.

Thanks much.

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