none
Sender name contains recipient name RRS feed

  • Question

  • It seems that a lot of our spam that is sent into our system has faked the sender name to contain the recipient name.  For example, if the user the mail is sent to is john.doe@microsoft.com the spam will be sent FROM john.doe@somedomain.com and then a few minutes later an exact copy of the email will come from john.doe@anotherdomain.com.  Is it possible to create a transport rule (or some other filter) that can eliminate any message where the sender address contains the recipient name?  So that any message that contains john.doe is deleted?  Maybe also add an exception unless sender is john.doe@microsoft.com or unless sender is authenticated?
    Monday, May 5, 2014 1:19 PM

All replies

  • Yes, there is a transport rule for this:

    http://exchangepedia.com/2008/09/how-to-prevent-annoying-spam-from-your-own-domain.html

    There is also a caveat...

    I was not able to implement this method because one of my previous organizations would use a third-party company to send mass emailings for it. Among other constituents, these messages were sent to internal users. Of course, this sender could not be authenticated, not being a member of the domain (and I don't think setting up trusts or federation was an option - certainly too complicated for something like that at any rate).

    Also, I think if you enable antispam services on the Hub Transport server, there is a way to block incoming messages with an internal user listed as the sender.


    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

    Monday, May 5, 2014 2:26 PM
  • OK, just verified that last part:

    "Also, I think if you enable antispam services on the Hub Transport server, there is a way to block incoming messages with an internal user listed as the sender."

    The setting I was thinking of is the:

    "Block messages sent to recipients not in the global address list"

    That would prevent email using internal addresses that are not valid from going any further in the mail delivery process - but it's not what you are looking for, since, in your case, apparently valid addresses are being spoofed.


    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

    Monday, May 5, 2014 2:48 PM
  • Thank you for the quick Reply David!

    I followed the instructions in your link.  However, there were two important observations.

    1) Before making any changes, I could telnet to port 25 and send messages to myself as myself (Anonymous Authentication).  Which was expected.  I could also send messages from @hotmail.com to myself.  Again as expected.

    I then made the changes and I could no longer send messages 'from' either address using the telnet to port 25 method (Anonymous Authentication.  Again this made sense as the anonymous authentication was removed.  However, the problem with this is that ALL mail from the internet would be blocked.  This was not desireable as this is the entry point for our internet mail.  I then used the Exchange ECP to add the Anonymous Users permission group back.  When I did that I was again able to send using the telnet port 25 method.  The difference noticed was that while I could send from @hotmail.com, I could not from my @realdomain address which is desirable.  In that regard, I think you've helped me greatly!  (Even though it seems I undid everything I 'did' the system is acting in a desirable way)

    2) The other thing with the solution you provided was that it does not eliminate mail from senders that have the same username but different domain names.  For instance john.doe@abc.com sending messages to john.doe@microsoft.com.  While it might be possible that there is a john.doe@abc.com the chances that he would be mailing john.doe@microsoft.com seems like it might create a tear in the space-time continuum.  Marking the message as spam might be a more probable explanation?


    Monday, May 5, 2014 5:54 PM
  • I think I may have posted in the wrong forum.  I've reposted here
    Monday, May 5, 2014 7:48 PM
  • For the reason I gave in my first post, I never tested this extensively so I was not sure of the results. I just know that Bharat Suneja is an Exchange MVP, and apparently well respected in the Exchange community, so I thought his idea was worth trying. If you look at the comments section, it seems that this might have worked at some point but does not anymore, since Exchange 2010.

    I see in the section where you reposted that some recommend a full-fledged antispam solution - which might be the best solution if the price is within your budget.


    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

    Tuesday, May 6, 2014 1:05 PM