[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: postfix log query



On Sun, Mar 25, 2007 at 11:14:19PM -0400, Roberto C. Sánchez wrote:
> On Mon, Mar 26, 2007 at 03:25:18PM +1200, Chris Bannister wrote:
> > Hi,
> > 
> > I rec the following by logcheck. Is it anthing I should worry about?
> > 
> > Mar 24 01:48:55 kan postfix/cleanup[25281]: B61E8F7A3:
> > +message-id=<[🔎] 4601DC5D0008159F@mail05.sc2.he.tucows.com> (added by
> > +postmaster@globo.com)
> > Mar 24 01:48:57 kan postfix/cleanup[25281]: 2DB3FF7A3:
> > +message-id=<4601DC5D0008231F@mail05.sc2.he.tucows.com> (added by
> > +postmaster@globo.com)
> > 
> Does the address postmaster@globo.com look familiar?  As a first guess,
> I'd say it looks like you are running as an open relay.  You might want
> to look into it and fix it.  If you can provide longer snippets of your
> log file, it might be a little easier to tell exactly what is going on.

This looks interesting:
===========================================================
Mar 16 23:25:15 kan postfix/smtpd[24950]: 8CAFA1109A:
client=kan[127.0.0.1]
Mar 16 23:25:15 kan postfix/cleanup[25272]: 8CAFA1109A:
message-id=<45F6E5040008D819@mail06.sc2.he.tucows.com> (added by
postmaster@globo.com)
Mar 16 23:25:15 kan postfix/cleanup[25272]: 8CAFA1109A:
resent-message-id=<baZ-_D.A.22F.w8Q-FB@murphy>
Mar 16 23:25:15 kan postfix/qmgr[23872]: 8CAFA1109A:
from=<bounce-debian-doc=mockingbird=ihug.co.nz@lists.debian.org>,
size=3316, nrcpt=1 (queue active)
Mar 16 23:25:16 kan postfix/local[25273]: 8CAFA1109A:
to=<chrisb@localhost>, relay=local, delay=0.49, delays=0.19/0.01/0/0.29,
dsn=2.0.0, status=sent (delivered to command: /usr/bin/maildrop -d
${USER})
=======================================================================
Notice that 8CAFA1109A, also refers to
resent-message-id=<baZ-_D.A.22F.w8Q-FB@murphy>
although I have no idea even if "8CAFA1109A" is related to:
"message-id=<45F6E5040008D819@mail06.sc2.he.tucows.com> (added by
postmaster@globo.com)"
======================================================================
and
======================================================================
Mar 21 15:08:13 kan postfix/smtpd[29807]: AE5A3FEDE:
client=kan[127.0.0.1]
Mar 21 15:08:13 kan postfix/cleanup[31335]: AE5A3FEDE:
message-id=<[🔎] 45FFF346000102ED@mail05.sc2.he.tucows.com> (added by
postmaster@globo.com)
Mar 21 15:08:13 kan postfix/cleanup[31335]: AE5A3FEDE:
resent-message-id=<3OXtZC.A.6xE.YBEAGB@murphy>
Mar 21 15:08:13 kan postfix/qmgr[29762]: AE5A3FEDE:
from=<bounce-debian-user=mockingbird=ihug.co.nz@lists.debian.org>,
size=3860, nrcpt=1 (queue active)
Mar 21 15:08:14 kan postfix/local[31337]: AE5A3FEDE:
to=<chrisb@localhost>, relay=local, delay=0.61, delays=0.3/0.01/0/0.3,
dsn=2.0.0, status=sent (delivered to command: /usr/bin/maildrop -d
${USER})
=============================================================
and
================================================================
Mar 24 01:48:57 kan postfix/smtpd[25066]: 2DB3FF7A3:
client=kan[127.0.0.1]
Mar 24 01:48:57 kan postfix/cleanup[25281]: 2DB3FF7A3:
message-id=<4601DC5D0008231F@mail05.sc2.he.tucows.com> (added by
postmaster@globo.com)
Mar 24 01:48:57 kan postfix/cleanup[25281]: 2DB3FF7A3:
resent-message-id=<7UWUl.A.ik.V62AGB@murphy>
Mar 24 01:48:57 kan postfix/qmgr[24886]: 2DB3FF7A3:
from=<bounce-debian-devel=mockingbird=earthlight.co.nz@lists.debian.org>,
size=3433, nrcpt=1 (queue active)
Mar 24 01:48:57 kan postfix/local[25282]: 2DB3FF7A3:
to=<chrisb@localhost>, relay=local, delay=0.63, delays=0.29/0.01/0/0.32,
dsn=2.0.0, status=sent (delivered
to command: /usr/bin/maildrop -d ${USER})
Mar 24 01:48:57 kan postfix/qmgr[24886]: 2DB3FF7A3: removed
====================================================================

The address is not familiar. I thought I'd checked that if I was running 
an open relay at some stage in the past. 

If I was running an open relay wouldn't I have rec more logs. I'm just 
running postfix with the smarthost being the isp.

postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = yes
config_directory = /etc/postfix
inet_interfaces = all
inet_protocols = all
mailbox_command = /usr/bin/maildrop -d ${USER}
mailbox_size_limit = 0
mydestination = kan, localhost
myhostname = kan
mynetworks = 127.0.0.0/8
myorigin = /etc/mailname
recipient_delimiter = +
relayhost = mail.earthlight.co.nz
smtp_generic_maps = hash:/etc/postfix/generic
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtpd_use_tls = yes

less /etc/postfix/main.cf
[..]
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = yes

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package
# for
# information on enabling SSL in the smtp client.

myhostname = kan
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = kan, localhost
relayhost = mail.earthlight.co.nz
mynetworks = 127.0.0.0/8
mailbox_command = /usr/bin/maildrop -d ${USER}
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all

# Maps local addresses to me@myisp.com
smtp_generic_maps = hash:/etc/postfix/generic

myorigin = /etc/mailname
inet_protocols = all

Does the above look ok?
I thought postfix was *secure* out-of-the-box.

I will somehow have to check whether I am running an open relay.
Thanks for your interest.

-- 
Chris.
======
Don't forget to check that your /etc/apt/sources.lst entries point to 
etch and not testing, otherwise you may end up with a broken system once
etch goes stable.



Reply to: