none
How can I stop spammers from hi-jacking my mail server?

    Question

  • i run exchange 2003 and spammers have been having their wicked way for too long now

    i've been inundated with SMTP attacks

    how can I stop this from the exchange server?

    i've recently installed Forefront TMG server and started using my ISP's SMTP smart host, still however i'm receiving SMTP attack

    The very helpful Marc Grote from the TMG forum advises that I must " limit relay access at SMTP level at your mail server "

    How do I do this?


    lundi 22 août 2011 08:57

Réponses

  • blimey, yes that's the right IP

    i got my ISP to check the smtp relay and he says its okay now

    how do i know if i'm clear from this further compromise of being spamvertised?

    anti virus is not picking anything dodgy up on the servers (3 of)... smtp relay seems now to be closed

     

    Ok, knowing that's your server and not something else, brings up some further considerations but I'll leave them back for the moment; a quick check against a number of DNS blacklist gave a "clean" (enough) state, so you should be quite ok by now, the real point is... what did really happen ? I mean, was your mailserver an operelay or what ? See, the first thing to do (aside from fixing the issue) should be finding why and how the problem happened and, in case of an "intrusion", finding where someone "got in" and then plugging that hole, otherwise whatever "fix" you'll apply will just be a temporary one.

    As for scanning the servers... I understand that those boxes are production ones and that they can't be brought offline for extended intervals, yet, if you suspect a system may be compromised, you'd better consider taking it offline to perform a deep check and ensure it's "how it should be"; for example, you may try using this "boot CD" to boot and scan the boxes to ensure they're clean or else, you may just take the shorter path and restore a previous "clean" image and then proceed reapplying whatever fix/tweak... yet, checking why/how the issue happened will allow you to plug that hole and hopefully avoid going over it again in a future

    That said and getting back to "mailserver"; keep in mind that spam filtering (and AV scanning emails) doesn't just mean avoiding junk to come in, it also means avoiding your users to fall for scams, fake antivirus programs and so on and helps keeping your network secure, so, please, consider my recommendations (see my other message) and possibly plan a good mail filtering setup; also and since we're at it, the "cairngormmountain.org" domain lists the following MX infos

     
    @ 3600 IN MX 0 email.cairngormmountain.org.
    @ 3600 IN TXT "v=spf1 a mx ptr ~all"
    email 3600 IN A 217.16.216.161
    
    
    now... if you try running an SMTP session against the host sitting at 217.16.216.161 what you get back is the following
    
    220 cairnserve1.mountain.cairngormmountain.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at Tue, 23 Aug 2011 14:14:16 +0100
    EHLO mz185.deathstar.mil
    250-cairnserve1.mountain.cairngormmountain.com Hello [214.14.131.87]
    250-TURN
    250-SIZE
    250-ETRN
    250-PIPELINING
    250-DSN
    250-ENHANCEDSTATUSCODES
    250-8bitmime
    250-BINARYMIME
    250-CHUNKING
    250-VRFY
    250-X-EXPS GSSAPI NTLM LOGIN
    250-X-EXPS=LOGIN
    250-AUTH GSSAPI NTLM LOGIN
    250-AUTH=LOGIN
    250-X-LINK2STATE
    250-XEXCH50
    250 OK
    RSET
    250 2.0.0 Resetting
    QUIT
    221 2.0.0 cairnserve1.mountain.cairngormmountain.com Service closing transmission channel
    
    

     

    and sincerely, it doesn't make much sense, see, that "cairnserve1.mountain.cairngormmountain.com" doesn't resolve (using whatever regular DNS) and doesn't match the MX record contents, so you'll need to either change the mailserver config (at least the "send connector" one) so that the server will present itself using the right name (that is "email.cairngormmountain.org") otherwise some overzealous spamfilters may just reject your messages, also, and since we're at it, your mailserver PTR is invalid; if you try running a reverse lookup on 217.16.216.161 what you get back is the following PTR record

      161.216.16.217.in-addr.arpa. IN PTR gun-ghluasad-217-16-216-161.scotnet.co.uk.   
    

    which, by the way, is wrong since instead of reading "gun-ghluasad..." it should read "email.cairngornmountain.org" that is, resolve to the same name used for the A and MX records; this isn't mandatory but... if you trust me, I can say that it HELPS avoiding issues with spamfilters ;)

    Also (and I'll stop here); you're publishing an SPF (or SenderID if you prefer) record; the problem is that it makes no sense; see, your SPF record reads "v=spf1 a mx ptr ~all" which means that the hosts allowed to send email on the behalf of the "cairngormmountain.org" domain are:

    * The ones listed as A records for "cairngormmountain.org", that is 83.170.101.6

    * The ones listed as MX records, that is email.cairngormmountain.org (217.16.216.161)

    * The ones with a PTR record containing "cairngormmountain.org"

    * and, given the "~all" ... any other host sending email for the domain should be tolerated

    now, the first entry goest to an IP address which belongs to your "www" and I doubt it will directly send emails (usually webservers should be configured to use some smarthost and not to directly send out emails, this to avoid a number of issues), the second one points to your MX and is ok, the third tells to whatever receiver that any host whose PTR resolves with a name ending with your domain name is authorized to send email for your domain... now, while in some cases there may be reasons for such a setup, I don't think it's generally a good idea doing so ! And then... the fourth entry... tells the world that, even if you are publishing an SPF record, emails coming from any other hosts and pretending to be from your domain should be accepted... and this, by the way, totally defeats the purpose of the SPF/SenderID; in my opinion you'd better remove your SPF record (since as it's now it makes NO sense at all) or (better) change it this way

     v=spf1 mx -all   
    

    so only authorizing the servers listed as "MX" to send email on the behalf of your domain and forbidding any other server; this way your SPF/SenderID will work as it was designed and receivers will be able to reject whatever "spoofed" email pretending to come from your domain.



    mardi 23 août 2011 14:07
  • On Wed, 24 Aug 2011 10:19:05 +0000, Ronnie Whittaker wrote:
     
    >how do i resolve then the issues you brought to light?
    >
    >how do i " change the mailserver config (at least the "send connector" one) so that the server will present itself using the right name (that is "email.cairngormmountain.org") "
     
    Have a look at the property page for the SMTP Virtual Server. On the
    "Delivery" tab, click the "Advanced..." button and fill in the
    "Fully-qualified domain name". The name should match the one in the
    PTR record for whatever external IP address is being used (it's not
    mandatory that they match, it's just that there some over zealous
    admins out there that insist that they match or they won't accept
    e-mail from you).
     
    There should be an "A" record in your external DNS for this name, and
    the "A" (at least in your case) should be referenced in your domain's
    "MX" record.
     
    The relationship, in DNS should look something like this:
     
    e-maildomain.com. IN MX mailserver.e-maildomain.com.
    mailserver.e-maildomain.com. IN A 1.2.3.4
     
    >how do i change the PTR record from what it is to be email.cairngornmountain.org ?
     
    That's usually something your ISP does, unless you manage the network
    you're using.
     
    >my webhost manages my DNS so i guess they should do the change?
     
    Usually, but not always. It's the right place to start, though.
     
    >part of the issue here is that i don't know the direct implication of these changes and i don't want to risk knocking out my mail server for any length of time
     
    Changing the PTR record is a "good thing", but just _having_ one for
    the IP address is what's really important. Even if you don't have one,
    it won't affect operation of the server, but just cause some sites to
    refuse your e-mail.
     
    Changing the FQDN on your SMTP virtual server won't bother anything in
    a single-server Exchange organization. However, it'd be a good idea to
    add a matchine "A" record to your internal DNS. If you have multiple
    servers and you use Kerberos for authentication then be sure to update
    the SPNs assigned to the server's AD computer object.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    mercredi 24 août 2011 21:46
  • the FQDN was filled in already on the Delivery/Advanced tab in the SMTP virtual server = cairnserve1.mountain.cairngormmountain.com
    You'll need to change that to email.cairngormmountain.org to match the name used in the A/MX records

    the PTR record ObiWan mentions to have changed to email.cairngormmountain.org (same as MX record) and you mention to change to same as the FQDN in the SMTP virtual server which is cairnserve1.mountain.cairngormmountain.com

    The PTR must be updated on the public DNS; a PTR query against your server (that is 217.16.216.161) currently returns

     

    161.216.16.217.in-addr.arpa. IN PTR gun-ghluasad-217-16-216-161.scotnet.co.uk.
    

     

    while, after updating the public DNS it should return


    161.216.16.217.in-addr.arpa. IN PTR email.cairngormmountain.org.
    

     

    so matching the MX/A name; see, the idea is that the name used by the server should match the one used in MX/A and that running a reverse lookup on the server IP, the returned name should match again; notice that if you aren't the one managing the public DNS for the domain, you should contact your hoster or provider (scotnet.co.uk should be the one to contact) and ask them to make the above change for you

     

     





    jeudi 25 août 2011 08:46
  • i've followed all the instructions in this thread and the firewall is configured only to allow SMTP traffic from the mail server

    the SPF change is the only thing i've yet to receive confirmation about, hopefully soon i get that

    Given the fact that the issue is going on, please, perform a check; go to a PC (not a server) connected to your network and w/o any special "privileges", fire up a command prompt and then enter the following (given that the "telnet" tool has been installed, if not, you may install it on the fly from the add/remove programs)

    telnet 65.55.92.184 25

    the above will attempt a connection to one of the IPs belonging to "mx1.hotmail.com" on port 25/tcp (SMTP); if your firewall is correctly configured, the connection should fail, if otherwise you'll see the SMTP banner from the server, then you'll have to revise your firewall/gateway configuration

    Also, and since we're at it, in case the firewall will be ok, you'll probably need to enable verbose logging in exchange to check which clients are sending out that "spam" and then proceed checking them for signs of malware; notice that given that the reject message you posted refers to your mailserver IP address, an SPF record won't help you; you'll need to stop that junk email going out through your internet connection and this isn't the purpose of SPF/SenderID

    As a last note; a quicker/better way to fix the issue would be calling a local consultant and having someone "in place" to check your network and servers and proceed fixing whatever configuration issue or malware infection; I'm not saying it can't be done here, but, as I hope you see, doing such a thing through forums will require much more time and will need a lot of collaboration

     

    vendredi 9 septembre 2011 15:03

Toutes les réponses

  • What type of SMTP attacks are you talking about?

    Antispam protection help a lot. Excahnge 2003 can use the free IMF (Intelligent Message Filter) http://technet.microsoft.com/en-us/exchange/bb288484.aspx

    Of course you can always by other products which there exists plenty of.

     

    Forefront TMG dont have any antispam functionality by itself, only when used together with Exchange Edge server.

     

     


    lasse at humandata dot se, http://anewmessagehasarrived.blogspot.com
    lundi 22 août 2011 12:40
  • i've been inundated with SMTP attacks

    how can I stop this from the exchange server?

    I suspect that what you call "SMTP attacks" are just spam floods hitting your users mailboxes; in such a case, my suggestion is the following:

    Start by correctly configuring your Exchange ensuring it isn't an open-relay; to do so, read and follow this and this KB articles and then use this online test to ensure the server isn't acting as an open-relay; done that, you may move on and configure "spam filtering", to do so, since you're running Exchange 2003, you'll need to configure the IMF so that junk email trying to hit your mailbox will instead be rejected; to do so, read the following

    * IMFv2 tutorial
    * IMFv2 Operations Guide
    * Approaches to Fighting Spam in an Exchange Server Environment
    * Microsoft Exchange IMF updates
    * Updating the IMF filter
    * Blocking JavaScript in mail messages
    * Archiving SCL rates in IMF
    * View and manage IMF archived messages
    * Microsoft XMLnotepad 2007
    * Exchange 2003 SP2 IMF Keyword Manager
    * IMF Companion

    the above should allow you to understand how to install and configure/operate the Exchange IMF filter; as for the setup, my suggestion is to ensure to configure recipient-filtering and tarpitting as described here, this will avoid generating "backscatter" (also known as bounces) which is bad (see here for a full explanation); then, once your IMF will be up and running, to improve its filtering you may want to use some DNS blacklists (DNSBLs) and, the ones I recommend are the following

    zen.spamhaus.org
    bl.spamcop.net
    ix.dnsbl.manitu.net
    dul.dnsbl.sorbs.net
    combined.njabl.org
    bb.barracudacentral.org
    v4.fullbogons.cymru.com

    to insert them into IMF, please follow this KB article and this document too; notice that it will be a good idea inserting custom reject messages into IMF, that is message like, for example

    Message refused: your IP %0 is blacklisted by %2.

    which means that, assuming the sending IP was 192.0.2.100 and the blacklist which caused the reject was "zen.spamhaus.org", the resulting reject message would be something like

    550 5.5.0 Message refused: your IP 192.0.2.100 is blacklisted by zen.spamhaus.org.

    this way, whenever a given sender will get back a "5xx" reject message from IMF, the message will show the sending IP and the blacklist which caused the reject so that the sender may be able to take the appropriate steps to get de-listed (assuming it's a "good" sender); notice that some DNS blacklists also offer URLs which may be inserted into the reject message to allow the sender to get more details about the reject; in the above example (spamhaus.org) you may modify the message returned by IMF this way

    Message refused: your IP %0 is blacklisted by %2, see http://www.spamhaus.org/query/bl?ip=%0 for details

    the above would then be expanded to something like

    550 5.5.0 Message refused: your IP 192.0.2.100 is blacklisted by zen.spamhaus.org, see http://www.spamhaus.org/query/bl?ip=192.0.2.100 for details.

    notice though that each DNSBL has its own URL, so, if you'll decide to use such kind of messages you'll need to customize each message to match the given DNSBL URL; a good way of finding out the right URLs is running a DNSBL "TXT" type query against the given blacklist using 127.0.0.2 as the IP address, so, for example, you may run (from a command prompt) something like

    nslookup -type=TXT 2.0.0.127.bl.spamcop.net.

    and the above will result in the following answer

    "Blocked - see http://www.spamcop.net/bl.shtml?127.0.0.2"

    at this point, just "extract" the URL from the above response and replace the IP (127.0.0.2) with %0 to build your custom message for the "spamcop" DNSBL, message which may look this way

    Message refused: your IP %0 is blacklisted by %2, see http://www.spamcop.net/bl.shtml?%0 for details.

    which, again, will generate a reject message looking like (e.g.)

    Message refused: your IP 192.0.2.100 is blacklisted by bl.spamcop.net, see http://www.spamcop.net/bl.shtml?192.0.2.100 for details.

    Hope it's clear enough... if not, please reread all the above or... feel free to ask :D !

    Once your server will be configured following the above directions, you may relax a bit... but not too much, see, the above only deals with open-relays and incoming spam, but you'll also need to set things up so that, in case a client on your network gets infected by some malware, it won't be able to send out junk or, at least, it will be easy to identify and "fix" it; to do so, you'll need to modify your edge firewall and add rules so that outbound access to port 25/tcp will only be allowed to your mailserver and denied to any other host (IP), the same goes for outbound access to ports 53/udp and 53/tcp which should only be allowed to your local DNS servers and denied to any other system; by setting up such rules you'll be able, by simply checking your firewall and mailserver logs, to spot any "suspicious" system and react in a short time

    Let me (us, the forum) know how it will evolve :) !

    Forgot (sorry) since you're at it, you may also want to install an antivirus, but NOT a regular one, you will need an AV which will integrate with exchange and scan all messages in transit (both inbound and outbound) and which will reject (not BOUNCE, reject !) all infected ones; this will help you improving your filtering and keeping your users mailboxes (and computers) clean



    • Modifié ObiWan lundi 22 août 2011 14:32
    • Proposé comme réponse Gen Lin jeudi 25 août 2011 03:16
    lundi 22 août 2011 13:20
  • thanks guys

    it seems the issue is spam coming FROM us than it is coming TO us.

    Our ISP is receiving abuse emails from various organisations out there and are threatening to shut down our connection.

     

     

    lundi 22 août 2011 14:25
  • i carried this out from your link above ObiWan, selecting that only computers belonging to our specific windows domain are able to relay.

     

    Though i deselected "Allow all computers which successfully authenticate to relay, regardless of the list above"

     

    Which runs contrary to the instructions from the KB article

     

    Would this cause us problems, bearing in mind that all we have is windows clients?

     



     

     

     

    To check the properties on the Default SMTP Virtual Server, follow these steps:

    1. Click Start, click All Programs, click Microsoft Exchange, and then click System Manager.
    2. Expand Servers, expand <var style="box-sizing: border-box;">Servername</var>, expand Protocols, and then expand SMTP.

      If the server is an upgrade from Small Business Server 4.x, expand Administrative Groups, expand <var style="box-sizing: border-box;">Servername</var>, expand Servers, expand <var style="box-sizing: border-box;">Servername</var>, expandProtocols, expand SMTP.
    3. Right-click Default SMTP Virtual Server and then click Properties.
    4. Click the Access tab.
    5. Click the Relay button at the bottom.
    6. The default settings block open relay. The default settings are as follows:
      • Select Only the list below.
      • The Computers dialog box shows Access Granted to the Internal IP address of the Small Business Server network and to the external IP address (if the server has more than one network card.)
      • Make sure that Allow all computers which successfully authenticate to relay, regardless of the list above is selected.
    7. Set the Default SMTP Virtual Server configuration for relaying as indicated, which restores its settings to their defaults.
    To check the properties for the SmallBusiness SMTP Connector, follow these steps:

    lundi 22 août 2011 14:47
  • thanks guys

    it seems the issue is spam coming FROM us than it is coming TO us.

    Our ISP is receiving abuse emails from various organisations out there and are threatening to shut down our connection.

     

    Such an issue may have several different causes (one or more of...)

    1. Your mailserver is an openrelay and is being abused

    2. Someone grabbed valid credentials and is using them to relay junk through your mailserver

    3. Your mailserver is generating bounces (backscatter) instead of straight rejects

    4. You have one or more infected machine on your network sending out spam

    for #1, use the online check at my other message to ensure your mailserver is NOT an openrelay and, if it isn't the case, revise the config to block it

    for #2, force a password change for your users and revise the server logs to find out if and which credentials were abused

    for #3, ensure to enable recipient filtering (and tarpitting) and to configure your AV scanner to reject messages, never accept messages and generate NDRs, in most cases those will just be bounces going to invalid or fake addresses, see my other message for details (and http://www.dontbouncespam.org/)

    for #4, ensure to block port 25/tcp at your firewall only allowing your mailserver to "go out" to that port, change your credentials (as for #2) and monitor your logs (both the mailserver and the firewall ones)

     

    lundi 22 août 2011 15:23
  • i carried this out from your link above ObiWan, selecting that only computers belonging to our specific windows domain are able to relay.

     

    Though i deselected "Allow all computers which successfully authenticate to relay, regardless of the list above"

     

    Which runs contrary to the instructions from the KB article

     

    Would this cause us problems, bearing in mind that all we have is windows clients?


    Not really, see, only allowing computers belonging to your subnet/domain to relay messages means that only computers belonging to your "LAN" will be able to use your server to send messages to external recipients; this may or may not be desired, for example, if you have some "road warriors" (e.g. people going at remote location with their laptop and using your mailserver) you'll probably need to tick the "allow... which authenticate" option to allow those systems to use your mailserver to send messages to both internal and external recipients

     

    lundi 22 août 2011 15:26
  • thanks i'm just waiting on the abuse website registration so that i can test the open relay.

     

     

    1. Your mailserver is an openrelay and is being abused

    I think this is the case will confirm soon

    2. Someone grabbed valid credentials and is using them to relay junk through your mailserver

    Less likely due to the nature of our organisation

    3. Your mailserver is generating bounces (backscatter) instead of straight rejects

    I'd need to look further into what this actually is to see if its an issue

    4. You have one or more infected machine on your network sending out spam

    Port 25 is restricted only to our mail server

    lundi 22 août 2011 15:31
  • i'm thinking that in order for authenticated users to send email via the server, they'd need to be logging in as a user of the windows domain anyway
    lundi 22 août 2011 15:34
  • thanks i'm just waiting on the abuse website registration so that i can test the open relay.

    Ok, notice that the relaytest may also be performed w/o registration; as an additonal note, you may want to check if your mailserver IP has been added to some DNS blacklist, to do so, you may use this online tool; just enter your mailserver IP and let it run the checks; notice that some DNSBLs may also have a link explaining why the IP was blacklisted and this may in turn help you pinpointing the source of your issue

     

    1. Your mailserver is an openrelay and is being abused

    I think this is the case will confirm soon

    Here I am and... curious to see how this will evolve :) !

    2. Someone grabbed valid credentials and is using them to relay junk through your mailserver

    Less likely due to the nature of our organisation

    Hmmm... never say this, whatever is the "nature", if you look at your SMTP/POP3/FTP... logs you'll find a whole lot of "failed logon" attempts due to bots trying to bruteforce credentials over and over; then... a virus landing on infected machine may have been able to grab the email credentials or... someone forgot to properly wipe the HD of a dismissed computer or... you have some users "reusing" their passwords (see here :D) and btw this IS dangerous

    3. Your mailserver is generating bounces (backscatter) instead of straight rejects

    I'd need to look further into what this actually is to see if its an issue

    Well... maybe that DNSBL check site will help you (along with the links you'll find at that "dontbouncespam" website)

    4. You have one or more infected machine on your network sending out spam

    Port 25 is restricted only to our mail server

    Hmmm... double check, also ensure to restrict port 53/udp and 53/tcp so that only your DNS server(s) will be able to go out and issue queries to external DNS servers then... keep an eye on the firewall logs too ;-) !

    lundi 22 août 2011 15:45
  • great help, thanks a lot !

    i'm off now for the day... back tomorrow

    lundi 22 août 2011 15:47
  • great help, thanks a lot !

    i'm off now for the day... back tomorrow

    Y/W just... let me (us, the forums) know your findings please !

     

    lundi 22 août 2011 15:56
  • On Mon, 22 Aug 2011 08:57:56 +0000, Ronnie Whittaker wrote:
     
    >
    >
    >i run exchange 2003 and spammers have been having their wicked way for too long now
    >
    >i've been inundated with SMTP attacks
    >
    >how can I stop this from the exchange server?
    >
    >i've recently installed Forefront TMG server and started using my ISP's SMTP smart host, still however i'm receiving SMTP attack
     
    TMG isn't going to help with this. What are you using to filter spam?
     
    On the "Recipient Filtering" tab of your "Message Delivery" object,
    hav you checked the box labeled "Filter recipients who are not in the
    Directory"?
     
    Have you enabled recipient filtering on you SMTP Virtual Server? Click
    "Advanced...", "Efit...", and check the "Apply Recipient Filtering"
    box.
     
    Do you make use of any DNSBLs? On your "Message Delivery" properties,
    click the "Connection Filtering" tab. If you don't have any, try using
    zen.spamhaus.org (http://www.spamhaus.org/). I'm not a great believer
    in DNSBLs, but they're a good starting point -- just don't get carried
    away and start using DNSBLs whose policies you don't agree with.
     
    To use the DNSBL after you configure it in the "Message Delivery", you
    have to open the property page of your SMTP Virtual Server, click
    "Advanced..." and then check the "Apply Connection Filter..." box.
     
    Unless you have an absolute need to allow the use of SMTP relay from
    the Internet, I'd disable (uncheck) the "Allow all computers which . .
    .. to relay, . . ." on your SMTP Virtual Server. If you must allow
    relaying from inside the company, add another IP address to your
    server and create a second SMTP Virtual Server, restricting it to only
    internal IP addresses.
     
    >The very helpful Marc Grote from the TMG forum advises that I must " limit relay access at SMTP level at your mail server "
    >
    >How do I do this?
     
    See above . . .
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    lundi 22 août 2011 21:41
  • good info thanks

    mardi 23 août 2011 07:57
  • okay i've made all your recommended changes guys.. tried a relay test http://verify.abuse.net/cgi-bin/relaytest but notice that zenspamhaus blocks email from this address :-)

     

    is there any other way i could test or could you test for me? mobile.cairngormmountain.org


    mardi 23 août 2011 08:08
  • > mobile.cairngormmountain.org

    The host doesn't resolve, on the other hand, the MX
    for the cairngormmountain.org is 217.16.216.161 aka
    email.cairngormmountain.org is that your server IP ?

    If so, I had a look at

    http://www.au.sorbs.net/lookup.shtml?217.16.216.161

    and, given the above is your mailserver IP, it sounds
    like you've bigger problems than just the "spamrelay"
    one since it sounds like some of your servers got compromised
    and are (were ?) used to host spamvertized sites :( !

    mardi 23 août 2011 12:12
  • blimey, yes that's the right IP

    i got my ISP to check the smtp relay and he says its okay now

    how do i know if i'm clear from this further compromise of being spamvertised?

    anti virus is not picking anything dodgy up on the servers (3 of)... smtp relay seems now to be closed

     

    mardi 23 août 2011 13:00
  • blimey, yes that's the right IP

    i got my ISP to check the smtp relay and he says its okay now

    how do i know if i'm clear from this further compromise of being spamvertised?

    anti virus is not picking anything dodgy up on the servers (3 of)... smtp relay seems now to be closed

     

    Ok, knowing that's your server and not something else, brings up some further considerations but I'll leave them back for the moment; a quick check against a number of DNS blacklist gave a "clean" (enough) state, so you should be quite ok by now, the real point is... what did really happen ? I mean, was your mailserver an operelay or what ? See, the first thing to do (aside from fixing the issue) should be finding why and how the problem happened and, in case of an "intrusion", finding where someone "got in" and then plugging that hole, otherwise whatever "fix" you'll apply will just be a temporary one.

    As for scanning the servers... I understand that those boxes are production ones and that they can't be brought offline for extended intervals, yet, if you suspect a system may be compromised, you'd better consider taking it offline to perform a deep check and ensure it's "how it should be"; for example, you may try using this "boot CD" to boot and scan the boxes to ensure they're clean or else, you may just take the shorter path and restore a previous "clean" image and then proceed reapplying whatever fix/tweak... yet, checking why/how the issue happened will allow you to plug that hole and hopefully avoid going over it again in a future

    That said and getting back to "mailserver"; keep in mind that spam filtering (and AV scanning emails) doesn't just mean avoiding junk to come in, it also means avoiding your users to fall for scams, fake antivirus programs and so on and helps keeping your network secure, so, please, consider my recommendations (see my other message) and possibly plan a good mail filtering setup; also and since we're at it, the "cairngormmountain.org" domain lists the following MX infos

     
    @ 3600 IN MX 0 email.cairngormmountain.org.
    @ 3600 IN TXT "v=spf1 a mx ptr ~all"
    email 3600 IN A 217.16.216.161
    
    
    now... if you try running an SMTP session against the host sitting at 217.16.216.161 what you get back is the following
    
    220 cairnserve1.mountain.cairngormmountain.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at Tue, 23 Aug 2011 14:14:16 +0100
    EHLO mz185.deathstar.mil
    250-cairnserve1.mountain.cairngormmountain.com Hello [214.14.131.87]
    250-TURN
    250-SIZE
    250-ETRN
    250-PIPELINING
    250-DSN
    250-ENHANCEDSTATUSCODES
    250-8bitmime
    250-BINARYMIME
    250-CHUNKING
    250-VRFY
    250-X-EXPS GSSAPI NTLM LOGIN
    250-X-EXPS=LOGIN
    250-AUTH GSSAPI NTLM LOGIN
    250-AUTH=LOGIN
    250-X-LINK2STATE
    250-XEXCH50
    250 OK
    RSET
    250 2.0.0 Resetting
    QUIT
    221 2.0.0 cairnserve1.mountain.cairngormmountain.com Service closing transmission channel
    
    

     

    and sincerely, it doesn't make much sense, see, that "cairnserve1.mountain.cairngormmountain.com" doesn't resolve (using whatever regular DNS) and doesn't match the MX record contents, so you'll need to either change the mailserver config (at least the "send connector" one) so that the server will present itself using the right name (that is "email.cairngormmountain.org") otherwise some overzealous spamfilters may just reject your messages, also, and since we're at it, your mailserver PTR is invalid; if you try running a reverse lookup on 217.16.216.161 what you get back is the following PTR record

      161.216.16.217.in-addr.arpa. IN PTR gun-ghluasad-217-16-216-161.scotnet.co.uk.   
    

    which, by the way, is wrong since instead of reading "gun-ghluasad..." it should read "email.cairngornmountain.org" that is, resolve to the same name used for the A and MX records; this isn't mandatory but... if you trust me, I can say that it HELPS avoiding issues with spamfilters ;)

    Also (and I'll stop here); you're publishing an SPF (or SenderID if you prefer) record; the problem is that it makes no sense; see, your SPF record reads "v=spf1 a mx ptr ~all" which means that the hosts allowed to send email on the behalf of the "cairngormmountain.org" domain are:

    * The ones listed as A records for "cairngormmountain.org", that is 83.170.101.6

    * The ones listed as MX records, that is email.cairngormmountain.org (217.16.216.161)

    * The ones with a PTR record containing "cairngormmountain.org"

    * and, given the "~all" ... any other host sending email for the domain should be tolerated

    now, the first entry goest to an IP address which belongs to your "www" and I doubt it will directly send emails (usually webservers should be configured to use some smarthost and not to directly send out emails, this to avoid a number of issues), the second one points to your MX and is ok, the third tells to whatever receiver that any host whose PTR resolves with a name ending with your domain name is authorized to send email for your domain... now, while in some cases there may be reasons for such a setup, I don't think it's generally a good idea doing so ! And then... the fourth entry... tells the world that, even if you are publishing an SPF record, emails coming from any other hosts and pretending to be from your domain should be accepted... and this, by the way, totally defeats the purpose of the SPF/SenderID; in my opinion you'd better remove your SPF record (since as it's now it makes NO sense at all) or (better) change it this way

     v=spf1 mx -all   
    

    so only authorizing the servers listed as "MX" to send email on the behalf of your domain and forbidding any other server; this way your SPF/SenderID will work as it was designed and receivers will be able to reject whatever "spoofed" email pretending to come from your domain.



    mardi 23 août 2011 14:07
  • On Tue, 23 Aug 2011 08:08:03 +0000, Ronnie Whittaker wrote:
     
    >okay i've made all your recommended changes guys.. tried a relay test http://verify.abuse.net/cgi-bin/relaytest but notice that zenspamhaus blocks email from this address :-)
     
    You can exclude the IP address by adding it to the "Global Accept and
    Deny Configuration" on the "Connection Filtering" tab of the "Message
    Delivery" property page.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    mardi 23 août 2011 14:10
  • okay i've made all your recommended changes guys.. tried a relay test http://verify.abuse.net/cgi-bin/relaytest but notice that zenspamhaus blocks email from this address :-)


    Well... just (temporarily) disable DNSBL filtering on your exchange and repeat the test :) !

     

    mardi 23 août 2011 14:15
  • thanks guys for your time, and thanks obi wan for such a full response

     

    the mailserver was an open relay and our network was completely open to the internet. this until last week when i installed TMG server.

    the email.cairngormmountain.org record has never been used

    mobile.cairngormmountain.org is the one i use for accessing OWA and other web applications

    i now use my ISP's smarthost for mail forwarding

    smtp relaying now seems successfully restricted to internal windows domain users

    scotnet.co.uk is my ISP

     

    161.216.16.217.in-addr.arpa. IN PTR gun-ghluasad-217-16-216-161.scotnet.co.uk.   

     

    my servers are reporting clean enough and i'm in the process anyway of rebuilding/refreshing them over the next few weeks


    much else what you've mention obi wan goes over my head just now, i have only a general practical understanding




    mardi 23 août 2011 14:17
  • the email.cairngormmountain.org record has never been used

    mobile.cairngormmountain.org is the one i use for accessing OWA and other web applications

    i now use my ISP's smarthost for mail forwarding

    Ronnie... since the DNS zone for your domain states that "email.cairgorn.." is your MX record, that record IS used by ALL the world, see, anyone willing to send you an email will use that record ! As for the smarthost, that isn't a solution, just a workaround, setting up a smarthost doesn't mean blocking spam from going out from your mailserver IP, it just means letting it go out from some other IP address (your smarthost one) and, again, this is NOT a solution; I think you'd better revise your whole config, plug any holes and properly configure your servers
    much else what you've mention obi wan goes over my head just now, i have only a general practical understanding

    Not willing to give offense, but sincerely, given that you don't have a "good grip" on the whole setup, I hearthly suggest you to ask for help to some local consultant or, in any case, to someone knoledgeable enough to help you properly setting up your server, otherwise... well, a workaround like the one you're using will just work for a while, then you'll be back to the same issue, so, instead of going over it again and again... try fixing it :) !

     

    mardi 23 août 2011 14:33
  • understood 

    so disable the email.cairngormmountain.org MX record and ensure the correct MX record of mobile.cairngormmountain.org

    then...?

     

    mardi 23 août 2011 14:46
  • understood

    sorry but it doesn't seem the case

    so disable the email.cairngormmountain.org MX
    record and ensure the correct MX record of
    mobile.cairngormmountain.org

    then...?

    then you won't receive any email at all :D

    mardi 23 août 2011 14:51
  • what i'd like to do is to take the email.cairngormmountain.org record out the equasion and maintain a single MX record of mobile.cairngormmountain.org

    this mobile.cairngormmountain.org i use for OWA access and other webapps... is it therefore viable to use this too as the MX record?

     

    mardi 23 août 2011 15:12
  • what i'd like to do is to take the email.cairngormmountain.org record out the equasion and maintain a single MX record of mobile.cairngormmountain.org

    this mobile.cairngormmountain.org i use for OWA access and other webapps... is it therefore viable to use this too as the MX record?

    <SIGH> Ok

    The DNS entry "mobile.cairngormmountain.org" is an "A" record which points to 217.16.216.161 which incidentally is the same IP used by "email" so, the answer to your question is yes, what you'll need to do will be editing the DNS zone for the domain and change the MX record to look this way

    cairngormmountain.org. 3600 IN MX 0 mobile.cairngormmountain.org.

    then wait a bit to let the DNS change propagate, at that point, all the incoming email directed to cairngormmountain.org will be sent to the host pointed by the above record

     

    mardi 23 août 2011 15:23
  • thanks for your patience

     

    how do i resolve then the issues you brought to light?

    how do i " change the mailserver config (at least the "send connector" one) so that the server will present itself using the right name (that is "email.cairngormmountain.org") "

    how do i change the PTR record from what it is to be email.cairngornmountain.org ?

    my webhost manages my DNS so i guess they should do the change?

     

    part of the issue here is that i don't know the direct implication of these changes and i don't want to risk knocking out my mail server for any length of time


    mercredi 24 août 2011 10:19
  • how do i " change the mailserver config (at least the "send
    connector" one) so that the server will present itself using
    the right name (that is "email.cairngormmountain.org") "

    [...]

    Ronnie, given the questions, I think the best, quickest and more failsafe way to solve your issue will be contacting some good local consultant and having someone coming at your office to help you properly set things up; see, I don't think these forums are the right place to carry on a crash-course on Exchange, networking and mailservers setup in general.



    mercredi 24 août 2011 12:27
  • i don't have that opportunity and it's why i'm here.. and learning

    thanks for all your help its been really appreciated


    mercredi 24 août 2011 12:31
  • i don't have that opportunity and it's why i'm here.. and learning

    thanks for all your help its been really appreciated


    Ronnie, don't take offense, please, but given all the ongoning discussion and your question, I think you're lacking some fundamental stuff like a good grip on DNS records, on the mechanisms governing (and the RFCs describing) the mail exchange mechanism and then some; now, while it may be possible to expand all those concepts here, it would take a whole lot of time (and space) and the result will be less than perfect, so, my hearthly suggestion is to find someone with the needed skills and ask help; see, there are a whole lot of details and pitfalls and, on a forum, it's just impossible to cover "all the bases" so, again, avoid considering those forums as a place where to learn "in place of reading documents" and start considering them as a place where to ask infos whenever you won't understand some "detail"

    HTH

     

    mercredi 24 août 2011 12:38
  • look Obi Wan enough of your lectures please.. you have no idea my situation here, my skills nor method.

    whilst i'm up to my ears here dealing with several issues on site, i don't quite have the luxury of reading through in complete depth the verbose largely self serving responses you're coming across with.

    now that's not to say i don't appreciate the detail and your time and help but if you could just cut to the chase a little bit and stop rambling, and above all stop patronising other people, then you yourself may benefit professionally!

     

    thanks for the heads up on the DNS anomalies, I've since had time to ingest the info and set myself a bit more straight on what the deal is here in this particular topic of which I've had limited exposure previously.

     

     

     

     

     

    mercredi 24 août 2011 14:29
  • look Obi Wan enough of your lectures please.. you have no idea my situation here, my skills nor method.


    You probably got me wrong; again I was NOT trying to offend you or whatever; what I wrote is that to really answer to your question and let you get a good grip we should start a really loong discussion and I don't think this is the right place; that said, if you think you're too busy to learn thing, then... up to you; but applying "band-aids" isn't the way to fix things and keep them humming along, given it's what you want to obtain

    Anyhow, best of luck

     

    mercredi 24 août 2011 14:38
  • On Wed, 24 Aug 2011 10:19:05 +0000, Ronnie Whittaker wrote:
     
    >how do i resolve then the issues you brought to light?
    >
    >how do i " change the mailserver config (at least the "send connector" one) so that the server will present itself using the right name (that is "email.cairngormmountain.org") "
     
    Have a look at the property page for the SMTP Virtual Server. On the
    "Delivery" tab, click the "Advanced..." button and fill in the
    "Fully-qualified domain name". The name should match the one in the
    PTR record for whatever external IP address is being used (it's not
    mandatory that they match, it's just that there some over zealous
    admins out there that insist that they match or they won't accept
    e-mail from you).
     
    There should be an "A" record in your external DNS for this name, and
    the "A" (at least in your case) should be referenced in your domain's
    "MX" record.
     
    The relationship, in DNS should look something like this:
     
    e-maildomain.com. IN MX mailserver.e-maildomain.com.
    mailserver.e-maildomain.com. IN A 1.2.3.4
     
    >how do i change the PTR record from what it is to be email.cairngornmountain.org ?
     
    That's usually something your ISP does, unless you manage the network
    you're using.
     
    >my webhost manages my DNS so i guess they should do the change?
     
    Usually, but not always. It's the right place to start, though.
     
    >part of the issue here is that i don't know the direct implication of these changes and i don't want to risk knocking out my mail server for any length of time
     
    Changing the PTR record is a "good thing", but just _having_ one for
    the IP address is what's really important. Even if you don't have one,
    it won't affect operation of the server, but just cause some sites to
    refuse your e-mail.
     
    Changing the FQDN on your SMTP virtual server won't bother anything in
    a single-server Exchange organization. However, it'd be a good idea to
    add a matchine "A" record to your internal DNS. If you have multiple
    servers and you use Kerberos for authentication then be sure to update
    the SPNs assigned to the server's AD computer object.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    mercredi 24 août 2011 21:46
  • cheers Rich

     

    the FQDN was filled in already on the Delivery/Advanced tab in the SMTP virtual server = cairnserve1.mountain.cairngormmountain.com

    the PTR record ObiWan mentions to have changed to email.cairngormmountain.org (same as MX record) and you mention to change to same as the FQDN in the SMTP virtual server which is cairnserve1.mountain.cairngormmountain.com

    What should I do?

    the A record associated with the MX record is cairngormmountain.org (our corporate website domain name)

     

     

    jeudi 25 août 2011 08:12
  • the FQDN was filled in already on the Delivery/Advanced tab in the SMTP virtual server = cairnserve1.mountain.cairngormmountain.com
    You'll need to change that to email.cairngormmountain.org to match the name used in the A/MX records

    the PTR record ObiWan mentions to have changed to email.cairngormmountain.org (same as MX record) and you mention to change to same as the FQDN in the SMTP virtual server which is cairnserve1.mountain.cairngormmountain.com

    The PTR must be updated on the public DNS; a PTR query against your server (that is 217.16.216.161) currently returns

     

    161.216.16.217.in-addr.arpa. IN PTR gun-ghluasad-217-16-216-161.scotnet.co.uk.
    

     

    while, after updating the public DNS it should return


    161.216.16.217.in-addr.arpa. IN PTR email.cairngormmountain.org.
    

     

    so matching the MX/A name; see, the idea is that the name used by the server should match the one used in MX/A and that running a reverse lookup on the server IP, the returned name should match again; notice that if you aren't the one managing the public DNS for the domain, you should contact your hoster or provider (scotnet.co.uk should be the one to contact) and ask them to make the above change for you

     

     





    jeudi 25 août 2011 08:46
  • clear, thank you !

    thank you both for your time and great support, much appreciated

    jeudi 25 août 2011 09:10
  • clear, thank you !

    y/w

    thank you both for your time and great support, much appreciated

    Now, if you'd only find the time to read the other infos
    and links... it's not "about me", mind me; it's that those
    will help you improving your setup and getting a better
    grip on your server and this in turn will help you fixing
    issues if/when you may face them

    jeudi 25 août 2011 09:27
  • clear, thank you !

    First change Ok; a telnet to your SMTP returned

    220 email.cairngormmountain.org Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at Thu, 25 Aug 2011 10:31:05 +0100
    


    which means that the "banner" is now ok; at this point, you'll need to go on, contact scotnet.co.uk which is the owner for your IP block (and so handles the reverse DNS for the IPs) and ask them to configure the PTR; just in case, a PTR query against the "authoritative" DNS servers for 217.16.216.161 returned

    ;; QUESTION SECTION:
    ;161.216.16.217.in-addr.arpa.  IN   PTR
    
    ;; ANSWER SECTION:
    161.216.16.217.in-addr.arpa. 86400 IN  PTR   gun-ghluasad-217-16-216-161.scotnet.co.uk.
    
    ;; AUTHORITY SECTION:
    216.16.217.in-addr.arpa. 86400 IN   NS   dns0.scotnet.net.
    216.16.217.in-addr.arpa. 86400 IN   NS   dns1.scotnet.net.
    216.16.217.in-addr.arpa. 86400 IN   NS   dns2.scotnet.net.
    
    ;; ADDITIONAL SECTION:
    dns0.scotnet.net.    9000  IN   A    217.16.223.30
    dns1.scotnet.net.    9000  IN   A    217.16.223.5
    dns2.scotnet.net.    9000  IN   A    217.16.223.31

    so, definitely, the DNS zone is handled by "scotnet" and they're the ones to contact asking to create a PTR record like this one

    161.216.16.217.in-addr.arpa. IN PTR email.cairngormmountain.org.

    so that other detail will be ok too

     

     


    jeudi 25 août 2011 09:36
  • i process information and do things my own way in relation to my own experience and situation

    just as you may do things similarly in your own way

    whilst you might recommend to read a specific document, RFC, or website, I myself may have another way similar of achieving the same result

     

    i'm not your disciple MASTER OBI, nor your subbordinate.... one of whom you can play with your power games

     

    all the best

    jeudi 25 août 2011 09:44
  • i process information and do things my own way in relation to my own experience and situation

    i'm not your disciple MASTER OBI, nor your subbordinate.... one of whom you can play with your power games

    You do whatever you want and... no, I've no disciples; as for "process your way", if that means asking bits and pieces to fix something "here and now" whenever a problem arises, withouth getting a grip on the "whole picture"... well, it's a good way to find out why, sooner or later people avoids such a kind of approach

    all the best

     

    jeudi 25 août 2011 09:52
  • No, "processing my way" does't mean that......sometimes my approach is getting to grips with the whole picture in a top down approach, and then sometimes it's not, taking more the bottom up approach, as what I've done here! It just depends on the situation in any moment.

    I'm sorry I didn't do things your way, or to your expectation mate, but we're all different, and we're all NOT YOU!

    jeudi 25 août 2011 10:14
  • but we're all different, and we're all NOT YOU!

    Which is what makes world an interesting place and... the fact that you're not me, relieves me a lot, thanks for confirming it

     

    jeudi 25 août 2011 10:22
  • now there's no need to be nasty
    jeudi 25 août 2011 10:30
  • Time to calm down a couple of Gigabytes.

    Try to keep this forum friendly and helpful.


    lasse at humandata dot se, http://anewmessagehasarrived.blogspot.com
    jeudi 25 août 2011 12:45
  • Time to calm down a couple of Gigabytes.

    Try to keep this forum friendly and helpful.

    Well, Lasse, I don't think I went "over the rows"; just ... well, some posts need a reply (sometimes), and that's what I did... and btw tried to keep myself quiet

    Anyways... I think we're totally OT, so... what about shutting this all down :D ?

     

    jeudi 25 août 2011 13:03
  • after all of the above, i've just been informed today from my ISP that we've been compromised again (see below)

    is there anything else i can do to stop this???????

     

    This is an email abuse report for an email message with the message-id of D257FD6B7CEC4DF183CABCAA97F9673C@zcizpec received from IP address 217.16.216.161 on Tue, 21 Jun 2011 09:15:40 -0400 (EDT)
    
    For information, please review the top portion of the following page:
    http://postmaster.aol.com/tools/fbl.html
    
    For information about AOL E-mail guidelines, please see
    http://postmaster.aol.com/guidelines/
    
    If you would like to cancel or change the configuration for your FBL please use the tool located at:
    http://postmaster.aol.com/waters/fbl_change_form.html
    
    message/feedback-report type attachment
    Feedback-Type: abuse
    User-Agent: AOL SComp
    Version: 0.1
    Received-Date: Tue, 21 Jun 2011 09:15:40 -0400 (EDT)
    Source-IP: 217.16.216.161
    Reported-Domain: gun-ghluasad-217-16-216-161.scotnet.co.uk
    Redacted-Address: redacted
    Redacted-Address: redacted@
    
    email message attachment
    -------- Forwarded Message --------
    From: SatelliteTV <ltgbs@xcite.com>
    Reply-to: "SatelliteTV" <snkzl@mail.com>
    To: redacted@aol.com
    Subject: Prepare to be amazed! Watch over 4000 TV channels on your PC!
    Date: Mon, 20 Jun 2011 18:10:37 +0300
    
                     How Can You Watch TV Episodes Online?
    Our software is very easy to use. All you need is an internet
    connection, a computer, the software and you have instant access to over
    4000 channels across the world.
    
    
    This software will also provide the viewer the best in digital
    television.
    It performs so well by providing quality channels to you, and with so
    many options and viewing choices, our software blows local cable
    stations clear out of the water.
    
    
    There is no cable company on the planet that could ever give you a deal
    like that.
    
    
    You just need to download and install the software to your PC with
    installation taking between 30 seconds and 5 minutes. Its extremely easy
    to use. All you need is an internet connection, a computer and our
    software and you are ready to go.
    Key Features
          * Easy 1 minute setup
          * Available anywhere
          * No extra hardware, just your
            PC
          * Over 4000 Channels Worldwide
          * No Hidden Costs
          * No Monthly Fees
          * Unlimited Usage
          * No Satellite Dish or
            Receiver Required
          * Access Over the Internet
          * 24/7 Technical Support
    
    
    Regular Cable/Satellite Contract
          * Requires a tehnician
          * Limited access in certain
            areas
          * Requires a satellite/cable
            box
          * Only 150 Channels
          * Over 200dollars in
            installation fees
          * Over 100dollars in monthly
            fees
    Click here to access the best Satellite TV offer.
    If you wish to unsubscribe from this newsletter please send an e-mail
    with the subject "Unsubscribe" to unsubscribe@tveuphoria.com


    vendredi 9 septembre 2011 09:39
  • after all of the above, i've just been informed today from my ISP that we've been compromised again (see below)

    is there anything else i can do to stop this???????

    Yes, follow the guidelines which have already been posted and take time to read the docs; notice that a possible cause for the issue may be due to some box, sitting on your network and being infected by some spamworm which is sending out spam either through your mailserver or directly to the target MX servers; in the latter case you'll need to ensure that your perimeter firewall is properly configured as already suggested in a previous message.

     

    vendredi 9 septembre 2011 09:56
  • i've followed all the instructions in this thread and the firewall is configured only to allow SMTP traffic from the mail server

    the SPF change is the only thing i've yet to receive confirmation about, hopefully soon i get that

     

     

     

    vendredi 9 septembre 2011 10:37
  • i've followed all the instructions in this thread and the firewall is configured only to allow SMTP traffic from the mail server

    the SPF change is the only thing i've yet to receive confirmation about, hopefully soon i get that

    Given the fact that the issue is going on, please, perform a check; go to a PC (not a server) connected to your network and w/o any special "privileges", fire up a command prompt and then enter the following (given that the "telnet" tool has been installed, if not, you may install it on the fly from the add/remove programs)

    telnet 65.55.92.184 25

    the above will attempt a connection to one of the IPs belonging to "mx1.hotmail.com" on port 25/tcp (SMTP); if your firewall is correctly configured, the connection should fail, if otherwise you'll see the SMTP banner from the server, then you'll have to revise your firewall/gateway configuration

    Also, and since we're at it, in case the firewall will be ok, you'll probably need to enable verbose logging in exchange to check which clients are sending out that "spam" and then proceed checking them for signs of malware; notice that given that the reject message you posted refers to your mailserver IP address, an SPF record won't help you; you'll need to stop that junk email going out through your internet connection and this isn't the purpose of SPF/SenderID

    As a last note; a quicker/better way to fix the issue would be calling a local consultant and having someone "in place" to check your network and servers and proceed fixing whatever configuration issue or malware infection; I'm not saying it can't be done here, but, as I hope you see, doing such a thing through forums will require much more time and will need a lot of collaboration

     

    vendredi 9 septembre 2011 15:03
  • thanks

    one of my firewall rules had port 25 enabled outbound for a business application

     


    mardi 13 septembre 2011 10:56
  • one of my firewall rules had port 25 enabled outbound for a business application

    Sorry for being late; if that's the case (but you previously wrote the firewall was locked, now I'm not sure if you really performed all the other checks) you'd better lock the firewall only allowing the mailserver to go out on 25 and then configuring that "business application" to use your mailserver to send out emails; then, if the business application needs to contact whatever external mailserver, you may add an exception to allow other IPs (than your mailserver one) to go out to port 25/tcp of that/those specific external mailservers and only to those

     

    jeudi 15 septembre 2011 16:09
  • yes i thought it was locked down but overlooked the business app.. which in the end doesn't need port 25

     

    my boss now is getting me some additional IT resource... bit late, but never mind.... maybe you should send him an invoice ! :-)
    jeudi 15 septembre 2011 17:10
  • yes i thought it was locked down but overlooked the business app.. which in the end doesn't need port 25

    Well... sounds like you nailed it down at end; now, it would be a good idea opening this site, entering your mailserver public IP and clicking the "send" button; the check may take some time, but at end it will show you which "blacklists" are listing your IP and also give you links which may allow it to get "delisted"
    my boss now is getting me some additional IT resource... bit late, but never mind.... maybe you should send him an invoice ! :-)

    Hey, all in all, the issue helped you gaining some more resources, not bad at all and... no need for invoices; I'm not here for money :)

    All the best

     

    vendredi 16 septembre 2011 07:55
  • thanks
    vendredi 16 septembre 2011 09:21