I have set the Internet Mail Service to allow routing only for clients who authenticate. However, I am still getting message in the que with the from "<>" deally (spam) going out to various recipients. What else can I do to stop this?
I am having the same problem with someone relaying or sending spam from my server. The 'From:' address field appears as '<>'. The link provided takes me to the Technet home page. Can anyone tell me how to stop this?
1. SP. After SP3 the routing is changed to better protect your server and route more efficiently.
2. NDR. Send an email to a badly setup Exchange server using any old address and you get an NDR. This gives you plenty of information about the server and you can use that to relay through it.
Read my FAQ in this forum on relaying (its cut from a really good FAQ on my web site so there aren't any screen shots or anything). It tells you what to do.
in Exchange Admin.....Intenet Mail Service.......Routing tab......routing restrictions....choose Host and clients that successfully authenticate and Host and clients with these IP addresses.....but do not put any entry on the list of IP address
I too had some issues with this but have since followed the directions here and now when I do the tests I get the desired results. But, is it possible that since it was open at one time that my GAL was accessed and now they know all our e-mail addresses? Also it seems as though the rate of Virus laden e-mails has increased since I blocked relaying. Could there be a correlation?
TMP
I thank everyone that responded to this post to offer their advice. Zel's FAQ's were very informative. I've done some more extensive testing and believe that the mail I see from "<>" is not being relayed and that is why I see it sitting in the queue. I am able to reproduce the conditions that I believe cause this and each test produced the error 550 "Relaying mail prohibited".
As I understand it the "<>" is accepted by Exchange as valid from address, but Exchange will not route messages that are not being set exclusively to a valid domain address if routing is setup properly to prevent relaying. Can anyone confirm this?
Regarding "<>"
That is correct, if you wish to take it a step further I suggest adding the addresses you see in the queue to your Message Filter. Gradually less and less such entries will be found.
Being in the same boat and still seeing messages from "<>" in my queue and not quite understand Noktar's last message, could you clarify for me? How can I put the address in the message filter if there really is no address? I don't really want to put the destination address since they weren't the ones originating the relay.
Thanks for the help.
So seeing these message from "<>" stuck in the queue is a good thing right?
These are mainly probes, your server doesn't route so they're stuck in a queue till they time out and get dropped. I naturally keep getting new ones, all with wierd domain names, several times a week. So yes, I filter based on destination address all traffic originating at "<>" . It worked for me for a long time now. My filter currently has some 1500 entries but my users never get spammed.
does anyone traced the source of the < > mail?
we have the same problem with < > stucked in the queue, after closed the relay, but when I examined the log, I found that this seem be a NDR but... not really a NDR, I don't know why exchange generated this, because I found for each < > email there is entry in the receiving log, then the exchange sends a email back to the sender but just without the sender info.
does anyone had the similar situation?
I have same problem with originator < > stucked in the queue. My relay is closed, but when I examined,I found that this seem be problem when deleted mailbox is try to send unknown recipient report to a junk mail and junk mail has no receiving address or hidden and they are stucked in the outgoing queue. Is there a way I can stop at exchange server not to send unknown recipient report. I have few deleted mailboxes and they are receiving junk mail.
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.