Getting Spam After Upgrade of IMSS from 5.7 to 7.0
Last Friday, we upgraded IMSS from 5.7 to 7.0. Additionally, we use Postini for both in and outbound email spam protection, so all of our message headers inbound have a Postini "footprint" as it were.
However, after the upgrade to 7.0, we have been getting spam email messages that simply say:
From: postmaster@localhost
Subject: Delivery Final Failure Notice
Body: Can not deliver the message you sent. Will not retry.
The header of the message has no Postini relays mentioned, and is in fact rather short, with a message id of <messageid@127.0.0.1> but the message itself came FROM our IMSS server to our back-end Exchange Server and the postmaster account is NOT the one specified in the IMSS notification settings either.
IMSS is configured to only allow relaying to our internal Exchange server and our Postini relays. What's different about this is that in 7.0, it lists 127.0.0.1 as a valid IP to allow relaying. Trend Micro says we cannot remove it (i tried, twice, it keeps coming back) -- they say it's the way the program operates, but I think it's a little weird that 127.0.0.1 just so happens to be in the message ID of these spam messages too....
Any advice would be appreciated -- am I barking up the wrong tree? Or is Trend really screwing me over in this new version?? Confused and frustrated with their technical support right now :(
However, after the upgrade to 7.0, we have been getting spam email messages that simply say:
From: postmaster@localhost
Subject: Delivery Final Failure Notice
Body: Can not deliver the message you sent. Will not retry.
The header of the message has no Postini relays mentioned, and is in fact rather short, with a message id of <messageid@127.0.0.1> but the message itself came FROM our IMSS server to our back-end Exchange Server and the postmaster account is NOT the one specified in the IMSS notification settings either.
IMSS is configured to only allow relaying to our internal Exchange server and our Postini relays. What's different about this is that in 7.0, it lists 127.0.0.1 as a valid IP to allow relaying. Trend Micro says we cannot remove it (i tried, twice, it keeps coming back) -- they say it's the way the program operates, but I think it's a little weird that 127.0.0.1 just so happens to be in the message ID of these spam messages too....
Any advice would be appreciated -- am I barking up the wrong tree? Or is Trend really screwing me over in this new version?? Confused and frustrated with their technical support right now :(
Where in IMSS do you show 127.0.0.1...? We've just recently moved from IMSS 7.0...but I still have it on the Server and it worked fine for us. Do you have that IP identified somewhere in: Administration > IMSS Configuration > SMTP Routing...or just where do you have it?
ASKER
It's under: Administration > IMSS Configuration > SMTP Routing > Connections tab, under Connection Control, we have "Deny All, except the following list", and to the right is our internal server IP, our Postini relays, and the loopback address....
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Yeah, these settings migrated successfully from 5.7, the two domains we have, and "specified IP Addresses" with only the internal IP of our back end server and the Postini range as well listed under "permitted senders of relayed mail".
What's odd about the delivery notices is the bad grammar and the notification email address doesn't match our customized version of postmaster@"ourdomain.com"
What's odd about the delivery notices is the bad grammar and the notification email address doesn't match our customized version of postmaster@"ourdomain.com"
ASKER
Oh, also, I forgot to mention we're not having any outbound email flow issues...the undeliverable I got last night seemed unrelated to any messages I sent over the past few days....
ASKER
uhoh lol
Screeching halt on the breaks...Just sent a test message to a bogus account and got the same undeliverable notice -- this makes me feel so much better!!! Now, to find out where the heck that pesky "postmaster@localhost" account is hiding so I can get rid of it.
Thanks for your help....sorry for the false alarm but at least you get free points :)
Screeching halt on the breaks...Just sent a test message to a bogus account and got the same undeliverable notice -- this makes me feel so much better!!! Now, to find out where the heck that pesky "postmaster@localhost" account is hiding so I can get rid of it.
Thanks for your help....sorry for the false alarm but at least you get free points :)
kaos theory, I am seeing similar messages after moving to IMSS7. Did you manage to locate the where the source address for the Delivery Final Failure Notice messages was set?
Trend Micro Hotfix 56270 fixes the non-delivery report to include useful information such as the address that failed and remote server response code.