Hi Jasper
I have found one of the remaining problems - and it isn't postfix
related. See below.
On 13/09/2010 11:39 PM, Richard Chapman wrote:
On 13/09/2010 9:35 PM, Jasper Jongmans wrote:
On 2010-09-13 13:03, Richard Chapman wrote:
Hi again Jasper... I think we are in the home straight, but I still
It looks like a virus somewhere - but I'm not sure where. All the
windows boxes here look well protected - but it almost looks like a
virus on the centos box.. Seems very weird. Or have I seriously broke
something?
Sep 13 17:56:22 C5 postfix/postfix-script: starting the Postfix mail system
> Sep 13 17:56:22 C5 postfix/master[12586]: daemon started -- version 2.3.3,
configuration /etc/postfix
> Sep 13 18:00:07 C5 postfix/smtpd[12802]: connect from localhost[127.0.0.1]
> Sep 13 18:00:07 C5 postfix/smtpd[12802]: warning: Illegal address syntax from
localhost[127.0.0.1] in MAIL command:<vice...@123.24.198.232>
> Sep 13 18:00:07 C5 postfix/smtpd[12802]: warning: Illegal address syntax from
localhost[127.0.0.1] in MAIL command:<cy...@116.118.47.120>
> Sep 13 18:00:07 C5 postfix/smtpd[12802]: warning: Illegal address syntax from
localhost[127.0.0.1] in MAIL command:<ja...@59.99.152.46>
> Sep 13 18:00:08 C5 postfix/smtpd[12802]: 12E981D22332:
client=localhost[127.0.0.1]
> Sep 13 18:00:08 C5 postfix/cleanup[12806]: 12E981D22332:
message-id=<4c8e029b.c076b...@avaya.com>
> Sep 13 18:00:08 C5 postfix/qmgr[12588]: 12E981D22332:
from=<angeline_jeric...@avaya.com>, size=2464, nrcpt=1 (queue active)
> Sep 13 18:00:08 C5 spamd[2532]: spamd: connection from localhost [127.0.0.1]
at port 43970
> Sep 13 18:00:08 C5 spamd[2532]: spamd: setuid to richard succeeded
> Sep 13 18:00:08 C5 spamd[2532]: spamd: processing
message<4c8e029b.c076b...@avaya.com> for richard:500
> Sep 13 18:00:08 C5 postfix/smtpd[12802]: disconnect from localhost[127.0.0.1]
> Sep 13 18:00:12 C5 spamd[2532]: spamd: identified spam (17.8/5.0) for
richard:500 in 4.8 seconds, 2592 bytes.
> Sep 13 18:00:12 C5 spamd[2532]: spamd: result: Y 17 -
BAYES_99,HTML_MESSAGE,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_PBL,RCVD_IN_XBL,RDNS_NONE,URIBL_AB_SURBL,URIBL_JP_SURBL,URIBL_OB_SURBL,URIBL_SBL,URIBL_SC_SURBL,URIBL_WS_SURBL
scantime=4.8,size=2592,user=richard,uid=500,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=43970,mid=<4c8e029b.c076b...@avaya.com>,bayes=1.000000,autolearn=spam
> Sep 13 18:00:13 C5 postfix/local[12807]: 12E981D22332:
to=<rich...@localhost.aardvark.com.au>, orig_to=<rich...@localhost>, relay=local,
delay=4.9, delays=0.06/0.01/0/4.9, dsn=2.0.0, status=sent (delivered to command: procmail)
> Sep 13 18:00:13 C5 postfix/qmgr[12588]: 12E981D22332: removed
>
I have noticed a few of those malformed addresses in my own logs, but
not from localhost. Do you run a content_filter or something similar
that would reinject mails to localhost? This definitely looks
suspicious; judging by the fact you run Postfix 2.3.3, there may be old
(and vulnerable) software on that machine. You should look into this.
I am running both spammassassin and clamd through procmail. I'm not
sure whether these could cause entries like this in the logs. Do you
think they could? The malformed addresses consistently seem to mention
"Vincent", "Cyrus" and "Jemal" which looks highly suspicious to me. It
is a little hard to imagine a genuine infection of a Centos box since
I almost never install applications other than trough the update
channel. I guess an exploit of some serious vulnerability is possible
but seems unlikely. Postfix 2.3.3 is still the current release for
RHEL 5.5 - which is the curent centos release.
2) You may recall that rchapman is an alias to richard on the local
server. If I send email from a local client with rchap...@aardvark...
as the from address - it arrives back with "rich...@aardvark... as the
from address. I'm pretty sure this is new behaviour (rewriting the
user-name) - and not ideal from my purposes. For reference - here is
postconf -n:
Are you talking about envelope-from, header-from or both?
What do you mean with "arrives back"? A bounce?
Send a test mail to some remote account not handled by your mailserver,
and check the raw message on that end to see how it arrives. Also check
your own logs to see if any rewriting happens when sending the message.
I'm really not sure whether I am talking about envelope from or header
from. I mean the from address as seen in the email clients. Probably
"header from"? By arrives back - I was not talking about a bounce but
rather an intended forward. As you suggested - I have since sent an
email from my client machine to a totally independent machine. The
sending client used the "from address" "rchap...@..." and the
receiving client (an independent gmail in this case) received the from
address "rich...@..." I think this is the relevant bit of the logs -
and it is hard to see any obvious rewrite. Hmmm... Not sure what this
all means.
This issue is (almost certainly) caused be my relay through
smtp.google.com - which is replacing the from address with my primary
google apps email address.
Sep 13 23:18:48 C5 postfix/smtpd[15614]: connect from unknown[192.168.0.166]
Sep 13 23:18:48 C5 postfix/smtpd[15614]: 2CA8A1D2145A:
client=unknown[192.168.0.166], sasl_method=PLAIN, sasl_username=richard
Sep 13 23:18:48 C5 postfix/cleanup[15617]: 2CA8A1D2145A:
message-id=<4c8e40d7.6050...@aardvark.com.au>
Sep 13 23:18:48 C5 postfix/qmgr[12588]: 2CA8A1D2145A:
from=<rchap...@aardvark.com.au>, size=665, nrcpt=1 (queue active)
Sep 13 23:18:48 C5 postfix/smtpd[15614]: disconnect from unknown[192.168.0.166]
Sep 13 23:18:51 C5 postfix/smtp[15618]: certificate verification failed for
smtp.gmail.com: num=20:unable to get local issuer certificate
Sep 13 23:18:51 C5 postfix/smtp[15618]: certificate verification failed for
smtp.gmail.com: num=27:certificate not trusted
Sep 13 23:18:58 C5 postfix/smtp[15618]: 2CA8A1D2145A:
to=<chapman.rich...@gmail.com>, relay=smtp.gmail.com[74.125.155.109]:587,
delay=10, delays=0.06/0.02/5.5/4.5, dsn=2.0.0, status=sent (250 2.0.0 OK 1284391138
x9sm12249437waj.15)
Sep 13 23:18:58 C5 postfix/qmgr[12588]: 2CA8A1D2145A: removed
BTW: Do you know how to fix the "Certificate verification failed"
warnings above - though they don't seem to have any averse affect on
mail delivery? I assume I need to establish some root certificate
trust somehow.
Richard.
--
Richard Chapman
