I am seeing a lot of messages in my outbound queue going to addresses that look spammy, but they have no originator. Where are they coming from?? Thank you.
I thought about that, except there are so many. We didn't always have them either. Seemed to kick in a several months back. I thought it might just be auto-replies for out of office--but I have that turned off to the outside. All of the addresses for this stuff points to domains like 167.redopti.com and adult-promos.com. It all looks like junk, but I can't figure out where it is coming from and how to stop it...
I have this problem to. How do you do a mail relay check.
I have telneted to port 25 and did the helo and mail from and the other commands but the e-mail was not sent to the e-mail address specified in the commands and did not pop in the queues. Is there another way?
I have this problem to. How do you do a mail relay check.
I have telneted to port 25 and did the helo and mail from and the other commands but the e-mail was not sent to the e-mail address specified in the commands and did not pop in the queues. Is there another way or another test I could perform?
Dyadmin,
I don't run an ISP just a small LAN. I made the modifications recommended in that link and now I'm getting a crap load of error logs in the event viewer saying that it refused to relay yada yada messege. I did have the do not reroute smtp box checked and still had the same probs that you had. Now when I check the outgoing queue nothing is there except our outgoing messeges. We are a management co. for 4 other companys and many employees have that company e-mail addy, so I put those e-mail addy's into the routing box for inbound and went to routing restrictions and made the changes it said to do in the link. Everything seems to be working fine for now. I will post how everything goes and let you know.
I appreciate all of the feedback, so far. I have done the no relay setting in Exchange. It definitely worked! I got a call within minutes from someone using my box for SMTP messaging (routing.) However, it did not stop these messages from appearing in my outbound queue with no originator listed. This implies, in my opinion, that these messages are coming from an exchange client--that's the only way it would keep accepting such messages. Any ideas? I am wondering if it could be a virus or a security hole...
I have the same thing, blank originator in outbound queue and I would like to stop them also. I have relaying blocked but these are emails that come in for a non-existant user at your domain. The user name is invalid but the domain is valid.
These are probably NDRs trying to get back to a spammer who originally used a fake domain to send the SPAM. When Exchange tries to send the NDR it can't find the SPAM domain and sits in queue. That is my guess.
Not sure the best way to block these. Any ideas?
I had the same problem and made these changes.
Under the routing tab in internet mail service properties
check reroute incoming smtp mail, in that box type in your e-mail address (ex. hotmail.com, yahoo.com) what ever domain you relay for. make sure that they are route to inbound. then click on the routing restrictions button and check host and clients with these ip addresses and leave that box blank but checked. this kinda tricks the e-mail to forward to nothing. After making these changes you will restart the ims service. After I made all these changes I went to the test sites that dmandell recommened in the post and tested it. Everything is ok for now. I made the changes about 4 days ago and havent seen any unknown originators yet. *crossing fingers*
Same thing happening to me... i have tested for relaying and serveral tests all indicate relaying is off
I just guessing but its like the server accepts the attempted relay and just doesnt send them, they get to the queue and sit there til they time out... kinda annoying but only thing i can think of..??
Actually, I have done the same things that quell and few other people have done.. I still get the <> in my outbound queue, when I look at the email being sent I see its a NDR report. This is what I think is being done..
When a spammer sends an email message his email is
spammer@[ipaddressofyourdomain.255]. He sends the spam through the exchange server and your exchange server has no choice but to relay all the while thinking well I relay for that domain so it must be okay. The the Spam gets sent. Question is how can we harden exchange to only accept sending through the local clients and receive internet email from anyone else.
Its either that or...
He uses a fake alias which can be easily done in outlook express and sends spam using the express client. I wonder..
Anyone concurr?
...a silver lining is when I check all email messages being sent from my server none of it is the spammer so he isn't going through my sever... I was reading in Windows & .NET magazine was that the total for all emails in this world by the year 2010, 85% of it will be spam.
<afterthought>
..man what I wouldn't give for 5 minutes in a locked room with a pair of rusty scissors and a spammer...
If I may throw myself into the fray, I'll tell you what I've found this to be 90% of the time (and Dyadmin, you're pretty close...)and it's not open relay:
1) Spammer finds out about your domain, let's COMPANY.COM (this isn't hard to do as domain names are public knowledge)
2) Spammer sends mail(s) to some arbitrary name at COMPANY.COM that winds up being invalid. Of course, the Spammer sends this email using a bogus return address.
3) Exchange accepts the mail, since it's sent to the proper domain name, then discovers that the actual user part is not valid.
4) Exchange uses the bogus return address to try and send an NDR. At the same time, Exchange strips away the sender address, leaving it as <>. This is done to prevent Exchange from going into an endless loop, as it would be constantly reporting back to itself that it's own NDR was undeliverable.
5) Eventually, these messages time out in the queue and should be deleted.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.